LaBienPensanceMaTuer a écrit 1611 commentaires

Peux tu me dire au juste à quel moment je t'ai "mal" parlé à toi ? (d'ailleurs, c'est plutôt "écrire" dans le cas présent… mais bon).

J'ai effectivement dit à Bruno que sa façon d'affirmer ça était stupide…. Mais, Bruno peut se défendre tout seul non ? Il a pas besoin d'un preux chevalier pour se faire respecter … à moins que ce soit ton petit frère, je sais pas …

Dans l'absolu, je crois que mes contributions à ce thread, même si parfois discutable sur la forme, ont beaucoup plus apporté a l'OP que les tiennes, non ?

Ok, erratum, my bad, il faut deux règles.

iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Ca ne change cependant strictement rien à l'opinion que j'ai exprimé sur le sujet du "firewall inutile sur un poste de travail"

Tu veux pas arrêter de faire ton idiot 5 minutes ?

Je viens pas ici pour du combat de quequette, mais pour aider un(des) débutant(s) à mieux comprendre quelque chose.

Ta contribution ne sert qu'à une chose ici: rendre confus quelque chose qui est déjà suffisament compliqué comme ça.

Je t'ai vexé ? Tu veux qu'on en parle ? Pas de soucis, mais arrête de faire ch**r sur ce thread, le pauvre redraven n'a rien fait pour ça.

Tes règles autorisent le flux sortant (à savoir ton PC vers le port (80|443|53) du serveur).

Mes tes règles n'autorisent pas implictement le flux retour (la réponse du serveur à ton PC).

C'est à cela que sert les lignes s'appuyant sur l'état ESTABLISHED: autoriser les flux correspondant… et ça, c'est parce qu'on a la chance d'avoir un firewall statefull sur Linux.

Sur un firewall stateless, il t'aurait fallu te faire toutes les règles à la main …

Voir cette page : https://inetdoc.net/guides/iptables-tutorial/userlandstates.html

A noter que, si ma mémoire est bonne, il n'est pas utile d'autoriser le TCP/53 car celui c'est n'est utilisé que pour les "grosses" requêtes DNS type transfert de zone.

A ce sujet, tu peux lire l'article de M Bortzmeyer : https://www.bortzmeyer.org/dns-over-tcp.html

Quel argumentaire ! Tu es si constructif…

Je vais replacer une dernière fois le contexte car ça a l'air confus dans ton cerveau:

1. On est sur une station de travail qui n'est pas sensé offrir un service réseau.
2. On y a installé un wordpress pour "tester"
3. On a pas nettoyé derrière.

Dans ce cas précis (et pas un autre), avec un firewall qui interdit toutes les connections entrantes sur l'IP publique, on est tranquille.

Le commentaire sur lequel j'ai réagi dit qu'un parefeu sur un poste de travail est inutile… Mes réponses visent à démontrer que cette affirmation est infondée.

Alors OK, si le seul usage d'un Linux pour toi consiste à mater youtube sur firefox, alors OK pas besoin de pare-feu.

Si par contre, t'es un peu développeur, un peu sysadmin et un peu passionné (c'est mon cas), il est probable que t'installe plein de trucs sur ton poste de travail a des fins de tests.

Et, dans l'éventualité ou tu nettoies pas après, avoir un pare-feu évitera d'exposer sur le réseau des services qui n'ont qu'une raison d'être: le test.

Maintenant, chacun fait bien ce qu'il veut hein… Si vous estimez que, pour votre usage, un pare-feu est inutile, grand bien vous fasse.

Mais, par pitié, ne faites pas de votre petit cas particulier une généralité et ne sortez pas des conneries du genre "un parefeu sert à rien sur un poste de travail" à un débutant.

Rolalala … tant de mauvaise foi !

ifdown, t'as plus de réseau…. c'est pratique le réseau, non ?

iptables -P INPUT DROP, bein t'as juste plus de connections entrante possible.

Si tu parviens pas à déceler la différence entre les deux approches, je crois qu'il vaut mieux arrêter de discuter, on se comprendra pas.

Bin oui mais c'est facile de prendre les gens de haut en donnant des exemples dans le vide.

Allé, tiens, après une recherche de 10 secondes sur google:

https://blog.ripstech.com/2019/wordpress-image-remote-code-execution/

L'intro du billet en question:

This blog post details how a combination of a Path Traversal and Local File Inclusion vulnerability lead to Remote Code Execution in the WordPress core. The vulnerability remained uncovered in the WordPress core for over 6 years.
> On égraine les autres exemples aussi ?

Vazy je t'en prie.

La seule règle de firewall que j'ai vu passer dans tes commentaires c'est iptables -P INPUT DROP.

Quel est l'objet de cette remarque ?
Oui, c'est, de mon point de vue, la seule règle à mettre sur un firewall de desktop.

J'ai oublié de répondre à ça:

Et si comme tu me dis tu fais n'importe quoi sur ton poste de travail : installer des tas de services sans passer par les dépôts officiels, tu finiras par avoir des problèmes et le pare-feu n'aurafait que te donner un faux sentiment de sécurité.

Même sur Debian, il arrive que des softs ne soient pas packagés.
Souvent sur Debian il arrive que des softs soient packagés mais franchement ancien et pas toujours dans debian-backports.

Dans ces cas là, une seule issue: la compil' à la mano.
Ce n'est pas parce que c'est quelque chose que, dans ton utilisation d'une machine Linux, tu ne fais pas que c'est nécessairement "n'importe quoi"…

Globalement d'accord avec toi Bernez.
Juste une petite correction:

iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
Avec ça tu bloques tout le trafic TCP.

Non, ce n'est pas le cas. Il va bloquer tout les packets ou tout les flags sont à 1, dixit cette doc dont j'ai collé un extrait ci-dessous.

--tcp-flags
suivi d'un `!' optionnel, puis 2 chaînes de caractères pour les fanions, vous permet de filtrer sur des fanions TCP spécifiques. La première chaîne correspond au masque : la liste de fanions que vous désirez examiner. La deuxième chaîne précisent lesquels doivent être présents. Par exemple :


C'était un exemple.

Et comme je l'ai dit plus haut, avoir un service en écoute sur une machine n'implique pas nécesasirement qu'on souhaite le laisser joignable depuis l'extérieur.

SSH fait bien souvent partie de l'install de base, filtrer le port sur un desktop et l'ouvrir au besoin ("hey collègue, tu peux me scp-er le dernier album de dick rivers ?") me parait plus pertinent que de tout bonnement supprimer le service et le reinstaller si un jour t'en as besoin.

Si tu as déployé à l'arrache et que ce devait être accessible de l'extérieur, le pare-feu avec les ports http/https ouverts n'y aurait donc rien changé.

Comme je te l'écrivais: "à des fins de tests".
Et oui, à des fins de tests, il m'est arrivé de dire à mysql d'écouter sur autre chose que la "boucle locale" (vrai traduction de loopback).

Mysql n'est en écoute que sur l'interface de bouclage et ce n'est généralement pas installable sans mot de passe « root » (Celui-ci n'est plus nécessaire sur les versions récentes de toute façon).

Sur debian, un MySQL s'installe sans soucis sans mdp root …

Dernière élément: que se passe-t-il si, un jour, le mainteneur se loupe sur une évolution d'un fichier de config ou autre et que ton MySQL se met à écouter sur INADDR_ANY plutôt que sur 127.0.0.1 ?

On est dans le même cas que précédemment, si le service SSH devait être accessible de l'extérieur le port a été ouvert et le pare-feu n'y change rien.

Je ne vois pas l'intérêt d'autoriser un quelconque port sur un desktop, que ce soit ssh ou autre.
Dans l'idée, je préfère faire:

iptables -P INPUT DROP

plutôt que:

apt-get remove --purge openssh-server samba …

Ca permet d'ouvrir le service temporairement en cas de besoin.

Tu connais beaucoup de cas où de telles failles ont été exploitées sur un système GNU/Linux ?

Généralement, quand les mecs s'emmerdent à trouver des failles et à ne pas les divulguer, c'est pas pour juste les garder au chaud sur un coin du disque mais bien pour les exploiter oui …
Après, effectivement, dans le cas d'une station de travail, on va plus avoir à composer avec des bots scanner de SSH et de SMTP en open-relay qu'avec un vilain black hat.

De toute façon si ce sont des failles dans un service, on est toujours dans le même cas: tu as probablement ouvert le port concerné de ton pare-feu parce que tu avais besoin d'y accéder de l'extérieur. La faille est donc toujours potentiellement exploitable.

Dixit ma remarque plus haut. Que le service soit là à ne rien faire n'implique pas qu'on l'ouvre sur l'extérieur…

Si tu as mis en place un partage samba c'est que tu es sur un réseau local privé. Personne (enfin j'espère) n'utilise de partage SMB accessible sur l'Internet.

Oui sauf que sur une machine portable, un jour t'es sur un réseau local privé et le lendemain t'es sur un réseau local de gare.
D'habitude t'oublie pas de faire /etc/init.d/samba stop, mais il se trouve que ce jour là, t'as oublié …

De manière générale la sécurité commence par la sécurisation des services qui sont en écoute plutôt que d'essayer d'enfoncer des portes ouvertes (ouvrir des ports sur lesquels un service est déjà en écoute) ou de mettre des cadenas sur les murs (fermer des ports sur lesquels aucun service n'est en écoute).

Pas tout à fait d'accord.
L'un des principes de base de la sécurité informatique est celui du moindre privilège (et c'est pas moi qui le dit mais l'ANSSI).
L'article wikipedia à ce sujet parle principalement de code, mais ce principe s'applique aussi au réseau: n'ouvrir que ce dont on a besoin.
Avoir un firewall qui droppe tout ce qui arrive en entrée est la première application de ce principe.
Ensuite vient la sécurisation des services.

Un pare-feu ne rendra pas le réseau auquel tu es connecté plus sûr, évidemment.
Par contre, il rendra inexploitable certaines failles laissées béantes par oubli.

Il va servir en vrac à:

• Eviter qu'un petit malin s'amuse à exploiter un truc que t'aurais déployé à l'arrache à des fins de tests (apache + wordpress, mysql ouvert sans pass root, serveur upnp/minidlna) pour executer du code sur ta bécane.

• Eviter qu'un petit malin exploite des failles avant que tu n'aies le temps de te mettre à jour (failles des clefs SSH faibles sur debian).

• Eviter qu'un petit malin exploite des failles dites 0 days (failles non divulguées au publique qu'un pirate garde pour lui).

• Eviter qu'un partage samba sur lequel t'as mis tes photos soit browseable par n'importe qui

• Eviter qu'un petit malin s'amuse à vider les cartouches d'encre de ton imprimante à cause d'un CUPS mal configuré

Le problème d'une machine dite "de bureau", c'est que généralement, on y fait plein de trucs à l'arrache sur un coin de table en prenant rarement le temps de nettoyer derrière et on se retrouve avec des services en écoute, pas nécessairement installés via le gestionnaire de paquets et donc sans suivi de sécurité…

Je t'ai convaincu ?

Dernier ajout (car les règles iptables ça passent souvent mieux après plusieurs lectures ;-p)

iptables -A INPUT -m state --state ESTABLISHED -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT

ta règle INPUT, si je ne me trompe pas, n'autorise que les connections établies... mais n'autorise pas les connections à s'établir pour autant.

D'ailleurs, cette règle ne sert à rien car déjà couverte par tes premières règles:

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT


Et dernier truc, quand tu listes tes règles avec iptables -L, rajoute un -v, ça va te rajoute devant chaque ligne le nombre et le volume des paquets que la règle a matché.
Utile pour savoir si une règle sert à quelque chose.

Ajout:

L'état //related//

Dans tes règles, tu utilises les état //new// et //established//.

Un état qui peut t'être utile est également l'état //related//.

Prenons un exemple: le protocole FTP utilise, de base, les ports 20 et 21. Sauf que en fonction du type de fonctionnement demandé par le client, il peut également utiliser des ports hauts (aka > 1024) de façon dynamique.
Ces ports hauts vont être négociés à travers le port ftp-data (21 de mémoire).

L'état related sert justement à ça: à ouvrir à la volée les ports négociés dans le protocole.
Pour cela, le noyau utilise ce qu'on appele des "helpers conntrack" qui sont chargés d'analyser les paquets pour justement détecter ces ouvertures de port dynamiques.

Je ne sais pas si torrent:
* utilise ce mécanisme
* a son conntrack helper dans linux

Mais c'est une piste à creuser …

Affirmer ce genre de chose avec tant d'aplomb est d'une stupidité rare …

Il y a au minimum deux cas ou un firewall sur une machine de bureau est utile:

1. Dans un environnement "hostile" (au bureau avec des collègues blagueurs, machine qui se connecte souvent à des wifis publiques, machine dans un LAN de fac)

2. Si il se connecte directement au net sans passer par une box de FAI et donc qu'il a une IP publique directement sur sa bécane.

En général et en sécurité en particulier, quand on sait pas, c'est quand même mieux de se taire …

Les flags

Concernant les flags TCP, une connection TCP/IP "normale" se déroule ainsi:

1. client --- SYN ---> serveur
2. serveur --- SYN,ACK ---> client
3. client --- ACK ---> serveur

C'est ce qu'on appele la Three Way Handshake.

Ensuite le client qui souhaite mettre fin à la connection utilisera un flag FIN.

Ensuite ce qu'il faut savoir c'est que:

• Les autres flags peuvent également être utilisés mais de façon plus marginale.
• Chaque OS traite les paquets "invalides" à sa façon.

Le truc de base quand on écrit un scanner de port, c'est d'envoyer un paquet avec le flag SYN placé et de voir si:
* on se prend un SYN/ACK: le port est ouvert.
* on se prend un FIN ou RST : le port est fermé.
* on se prend rien : le port est filtré, sur un linux à coup de -j DROP (le -j REJECT aurait pour conséquence de répondre "non" et renverrai donc le port comme fermé).

L'astuce ici, c'est que des scanneur de ports comme nmap s'appuie justement sur les spécificités d'implémentation de la pile TCP/IP pour chaque OS pour découvrir justement quel OS tourne sur la machine (c'est ce qu'on appelle de l'OS Fingerprinting).

Tes règles interdisant des paquets avec certains flags visent vraisemblablement à empêcher ce fingerprinting.

Les bonnes pratiques

J'ai jeté un oeil rapide à ton jeu de règle, et globalement, tu l'as un peu "écris à l'envers": en effet, tu mixes les règles permettant le traffic (-j ACCEPT) et celle l'interdisant (-j DROP) pour finir par une règle "catchall" de log (-J LOG).
Le hic avec cette démarche, c'est que si un paquet est droppé par une règle que tu as mis en place, tu ne le verras pas dans ton log …

Généralement, on fait plutôt

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

le -P permet de préciser la "politique par défaut", celle qui est appliqué si aucune des règles n'a matché ton paquet.

Ensuite, tu autorises chacun des services qui t'intéresse à coup de

iptables -A [..] -j ACCEPT

Enfin, tout à la fin, tu mets ta règle de log

iptables -A INPUT LOG

Comme ça, tout les paquets qui ne sont pas explicitement autorisés seront entraineront une ligne de log avant d'être droppés.

Note qu'il est plutôt rare pour un poste de travail de filtrer le "OUTPUT".
On fait plutôt ça sur les serveurs pour éviter la prise de contrôle par un pirate qui se servirait d'un shellcode avec "connect back" (en gros, le serveur va se connecter à une machine détenue par le pirate).

Ultime conseil

As tu bien vérifié que ton routeur/ta box internet/ton modem/ton FAI autorisait par défaut le protocole torrent ?
Pour t'en assurer, tu dégages toutes tes règles iptables et tu testes. Si avec un iptables vide et les policy à "ACCEPT" ton trafic ne passe toujours pas, il faut plutôt regarder du côté de ta box internet …

Est ce que tu penses vraiment gagner beaucoup d'espace en compressant? Parce que une utilisation courante d'un utilisateur, c'est télécharger des vidéos, images, mp3

Par sûr que ce soit vraiment une utilisation "courante" sur un serveur….

supprimé par l'auteur.

read aussi, vu que les sockets AF_UNIX sont des mécanismes d'IPC.

Yep, tout à fait.
Après, j'imagine qu'un segment de mémoire partagé est peut être plus performant qu'une socket (mais ce n'est que présomption)

Donc, mmap serait moins efficace dans ces cas que read? Cela n'impliquerait-il pas d'avoir une configuration pour read adéquate?

Bein, à mon taf on a du hard avec 8MiB de RAM. Autant te dire que mapper un fichier ne serait ce que de 1 ou 2 MiB à coup de mmap() met un vilain coup au système :-)

Pour ajouter de l'eau à ton moulin, dans ton sens, si tu mappes une zone mémoire entre deux processus, il va aussi te falloir gérer les accès concurrentiels, et du coup, utiliser un socket est nettement plus simple (c'est, en gros, un pipe), mais sera effectivement plus lourd qu'un mémoire partagée entre 2 processus.

Bien sûr, mais disons que le segment de mémoire partagé ne t'impose pas un scénario/protocole de communication contrairement au socket (aka proc-A envoie un message X à proc-B et bloque ensuite en l'attente d'une réponse Y).
A l'inverse, l'utilisation de sendmsg() avec un socket peut faciliter le développement (puisque les messages transmis sont directement mappable sur une structure C)… chose qui reste cependant possible avec un mmap() en utilisant un cast.

Puisque le fond de ton message semble concerné l'IPC, je vais dériver un peu sur ce sujet.
A mon humble opinion, il n'y a pas de solution miracle ou d'IPC à tout faire. En vrac et sans être exhaustif, je dirai que:

• Si tu veux qu'un processus X offre un "service" à un process Y sans connaitre Y au préalable, je partirai sur des sockets unix en effet.

• Si tu veux échanger des données que tu vas au préalable manipuler à coup de transformation de pointeur, mmap() est probablement plus adapté.

• Si le système cible est performant (au minimum une carte avec un ARM AXX), je partirai sur un composant plus haut niveau:

  • dbus est puissant mais particulièrement pénible à utiliser.
  • LCM et ZCM sont pas mal, plutôt performant mais s'appuie sur du code généré à partir de description textuelle des messages… faut aimer.
  • ubus est un système d'ipc light: pas énormément de fonctionnalité, mais ça peut suffire.
  • … il y en a d'autres .. à toi de voir ;-)

Pour conclure, en 2019, je m'embêterai pas à écrire moi même un système d'IPC à moins que:
* Ce soit un délire personnel, pour le plaisir (mais faut être un peu maso ;-).
* Le système cible soit vraiment très contraignant (peu de RAM en particulier).

Pour un usage classique (aka lire un fichier), je suis pas sûr en effet qu'il y ai un grand intérêt: c'est à ta convenance mais aussi et surtout en fonction du système hôte car il faut se souvenir que linux tourne sur du hard embarqué avec parfois très peu de RAM: dans ce contexte, mapper l'intégralité d'un fichier en mémoire est parfois impossible.

Pour tout les usages ou tu vas préferer utiliser un pointeur (plus souple, te permet de te ballader facilement) plutôt qu'un fd (séquentiel, rewind & co), mmap sera probablement plus adapté.

De mémoire, mmap() peut aussi être utilisé pour de la communication interprocess… (genre j'ouvre un shm qui me donne un fd, puis je mappe ce fd à coup de mmap et hop, j'ai un pointeur partagé entre mes deux process).

En espérant t'avoir déjà donné quelques éléments …

Comme te l'a fait remarqué un autre membre, ta question est mal posée.

Il nous faudrait le script que tu tentes d'écrire pour pouvoir t'orienter.

Personne ne t'écrira ton script ici, ce n'est pas la logique des contributeurs, par contre, on t'aidera.

Allé, vu que je suis pas vache:

• La manpage de cron pour l'execution périodique.

• La manpage de quota pour les détails sur les quotas.

• La manpage de tar pour compresser.

• Le manuel de Bash pour faire coller tout ça.

Tout est dans le titre.
A part peut être la mailing list, ton cahier des charges est entièrement rempli par un bête wordpress et les plugins qui vont bien.

Et bein voilà ! OP, ton nouveau meilleur ami est là ;-)

Oups… réponse à côté de la plaque.

s/cloudflare/cloudfront/g et là, ça se comprend mieux.

C'est ma punition pro qui m'a monté à la tête … désolé !