Linux : une sécurité toujours aussi contestable !

NetfilterEn 2010, je décidais de basculer ma station de travail sur Windows 7, faute de disposer d'un outil de filtrage par process  au niveau du pare-feu Linux. Pour rappel, depuis le noyau 2.6.14 sorti en octobre 2005, Netfilter ne dispose plus de la possibilité de filtrer par commande et/ou pid. J'ai depuis, à de nombreuses reprises, demandé aux développeurs de Netfilter les raisons pour lesquelles ils avaient fait ce choix quelque peu curieux. Je n'ai jamais eu la moindre réponse de leur part.

J'ai ensuite utilisé, en solution de remplacement, l'excellent Fireflier qui, hélas, n'est aujourd'hui plus du tout maintenu. Il utilisait Nfqueue. Le paradoxe est donc aujourd'hui que nous ne pouvons pas contrôler les process associés aux applications Tcp/Ip définies dans notre pare-feu. Il est tout de même paradoxal que, sur ce point particulier, Windows assure un niveau de sécurisation bien plus élevé que Linux. Le problème vaut également pour les serveurs, au niveau desquels l'absence de filtrage par process ne répond pas aux exigences minimales en termes de sécurité de ce qu'on peut attendre d'un système d'exploitation. Je n'ai hélas pas d'autres choix que de m'en satisfaire !

Solutions possibles ?

Depuis 2010, je suis donc en quête d'une solution - simple - qui me permette de revenir à Linux, au niveau de ma station de travail et de sécuriser davantage les serveurs qui hébergent les sites de nos clients.

Il y aurait bien SELinux ou AppArmor. Leur problématique est toutefois très éloignée de celle du filtrage par process.  Il y avait aussi NuFw. Cette autre usine à gaz  a disparu des dépôts CentOS depuis que Edenwall a décidé de fermer le site nufw.org. NuFW reste disponible sur Ubuntu Server. J'avais entendu parler de Program Guard, de Tuxguardian. Ces programmes n'apparaissent dans aucun dépôt. Par ailleurs, leur rôle est d'autoriser ou d'interdire des applications.

Nous restons toujours sans solution sur cette problématique ! Le paradoxe, c'est que tout le monde s'en fout.

 

Dsfc Dsfc

Linux : une sécurité toujours aussi contestable !
7 votes, 2.14 avg. rating (48% score)
Tags : , , , , , , , , , , , , ,
Commentaires

Bonjour,

Je ne connais pas la solution et c’est vrai qu’il y a un manque. Mais je constates que tu cites deux softs qui ne se trouvent pas les repos de tes distributions avortés, alors pourquoi ne pas les packager toi même?!

Ça peut être un bon point de départ!

Je pense que c’est lie au fait que les Firewalls sont (normalement) des éléments d’infrastructure plus que d’une station de travail.

Le filtrage par ptotocole/port/destination devrait suffire d’autant que les process exécutés sont beaucoup mieux controlles sous linux.

Je ne suis peut etre pas aussi exigeant mais ne retournerais pas à une station Windows pour cela

@Xavier

C’est vrai. Pourquoi pas ? Je l’ai d’ailleurs fait au début. Mais je préférerais tout de même que nous puissions retrouver les options –pid-owner, –sid-owner et –cmd-owner. ;+)

@ben

Non, ça ne suffit pas. Nous ne contrôlons rien de ce qui sort de nos serveurs par le port qui a été ouvert. Et il peut s’en passer des choses…

Honnêtement je ne vois pas l’intérêt réel de filtrer par processus.
On peut se dire « bon, j’ai un soft A, je lui fait confiance, donc lui il peut faire ce qu’il veut sur le réseau ». Bref, ce que fait de base de firewall intégré de windows.
Ok, mais je ne vois pas trop le manque de sécurité de faire une ou des règles autorisant les protocoles/ports utilisés par ce soft.
S’assurer que le soft qui écoute sur le port 80 est bien mon apache et pas un autre truc qui se serait installé dans mon dos ? C’est pas vraiment le rôle d’un firewall, plutôt d’un IDS, comme snort ou ossec.
Sinon, les règles de type « j’autorise le soft à faire ce qu’il veut parce que je lui fais confiance » sont loin d’être sécurisée. Si jamais, pour une raison où une autre, le soft en question est vérolé, on lui a legué tout pouvoir et il va pouvoir ouvrir pleins de ports dans tous les sens…

Je comprend tout à fait que la perte de fonctionnalité soit difficile à accepter, mais de la a dire que la sécurité ne vaut plus rien, même moins que sous Windows, il ne faut pas exagérer.

Au passage, Netfilter possède une lib couplée à une cible, la NFQUEUE. Il te suffit de mettre une règle qui envoie les paquets dans la cible NFQUEUE et tu les récupèrera en userspace afin de les manipuler via la lib nfqueue. Autrement dit, tu peux tout à fait crée la fonctionnalité en créant ton propre programme.
Je sais, ça à l’air super complexe dit comme ça, mais il semblerai que ce ne soit pas si dur. Petit exemple assez drole : https://www.wzdftpd.net/blog/index.php?post/2010/06/16/46-le-pare-feu-openoffice

Je ne comprends pas.
Si tu utilises des logiciels libres, à priori, tu peux espérer que le logiciel n’essaiera pas de tromper l’utilisateur.
Si tu utilises des logiciels non-libres, qu’est ce qui empêche celui-ci de créer un autre processus pour communiquer?
Quand bien même un logiciel fermé a besoin de connexion réseau et fait du SSL (gendre les services Google sur android), tu fais comment? tu coupes tout?

@ctxnop

Je suis un peu surpris (c’est un euphémisme !) que tu n’en vois vraiment pas l’intérêt. C’est même plutôt inquiétant. Snort que je connais très bien pour l’avoir mis en œuvre au Luxembourg dans une grande banque française n’est pas compatible avec le fonctionnement d’un serveur Web : il ralentit tout.

Nfqueue : Fireflier le faisait très bien, même si l’afflux de paquets – non gérés par Iptables et Fireflier – avait une fâcheuse tendance à ralentir la machine !!!

Je ne suis pas expert en sécurité, mais le filtrage par PID me semble l’idée la plus stupide qui soit. Cela implique qu’une fois le pare-feu configuré il faut prier pour que jamais aucun process ne plante et qu’on n’aie jamais de la vie à rebooter le système, sinon il faudra de nouveau configurer le pare-feu (et le dé-configurer avant bien entendu)…

Ça n’est pas ce que j’appelle de l’administration, et certainement pas de la sécurité… une « sécurité » remise en question à chaque changement, ne ressemble à rien.

La seule raison que je vois pour laquelle on pourrait devoir filtrer par PID, serait motivée par le fait qu’on ne pourrait pas être sûr lorsqu’un programme est lancé qu’il est bien celui que l’on aurait sollicité. Si tel est le cas, il y a, à mon sens, un monstrueux problème de sécurité en amont, auquel le pare-feu le plus sophistiqué de la voie Lactée ne pourra hélas rien.

Ou bien aurais-je raté le chapitre le plus important dans ‘la sécurité pour les nuls’? C’est aussi possible.

J’ai donné les raisons pour lesquelles je ne voyais pas l’intérêt. Ce n’est pas en me disant que tu es surpris que je vais avoir une illumination… Quelles sont les besoins réels ?
J’ai cité snort, mais également ossec, et ce n’était que des exemples. Pour l’exemple que j’ai donné, simple script de monitoring ferai l’affaire.

Sinon, autre possibilité : un service bien fait tourne avec un user spécifique, pour lequel il n’y a pas de login possible. Conséquence, tu peux utiliser uid-owner ou gid-owner, ce qui revient grosso modo à pid-owner puisque seule l’application cible tourne avec cet user.
D’autant que les pid changent changent à chaque redémarrage du service, et parfois plus souvent encore (dans le cas des services qui se forkent par exemple).

@ctxnop

Par script, il y avait des moyens très simples d’associer le programme au pid via –cmd-owner, comme je l’indiquais dans un des commentaires précédents. Concernant le uid-owner, c’est tout simplement ingérable.

Le besoin réel, il est simple : contrôler le fonctionnement d’un système, maîtriser l’origine de la sortie de paquets.

Ça frise la malhonnêteté, là… Certes, la fonctionnalité n’est pas disponible telle que tu la décris, mais ctxnop (et moi-même dans un message personnel) t’avons indiqué le moyen d’obtenir un résultat tout à fait identique avec uid-owner ou gid-owner. Des services du type apache, mysql, oracle, informix et consorts utilisent tous des users spécifiques, donc ça ne demande aucune étape d’administration supplémentaire. Avec en plus l’assurance que tout nouveau service forké sera sans problème astreint aux règles définies.

Et quand bien même ça ne serait pas le cas, tu peux toujours lancer ton service avec un autre utilisateur créé spécialement pour l’occasion. C’est le genre de truc qui se paramètre une seule fois, et après plus besoin d’y toucher.

Il faudrait faire ça avec les cgroups (noyau recent). Il me semble que c’est bien plus propre

@Nico

Malhonnête ? Ok. On fait comment pour le SSH et pour tous les services lancés en mode root ? Mais, admettons.

Pour la station de travail, considérons Firefox avec un plugin Acrobat, Flash, Silverlight ou équivalents… et un tas d’autres. Il faudrait donc que chaque plugin ait son compte utilisateur. C’est pas un peu compliqué, non ? La question que je me pose en dehors de la complication que cela pose est de savoir si c’est réaliste. En revanche, –cmd-owner, c’était franchement bien.

@Simon

Je ne connais pas. Mais ça ne ressemble pas un peu à SELinux ? Je vais regarder. Merci, en tout cas.

@Tuxicoman

« La confiance n’exclut pas le contrôle ». ;+)

@makidoko

Faut relire ce que j’ai écrit, je crois. Et il ne s’agit pas là d’une punition. ;+)

Je ne vois pas l’intérêt de remettre une couche de filtrage par dessus SSH, vu le niveau de sécurité fourni. Et soit dit en passant, je cherche encore un équivalent de SSH pour Windows.

Quant aux autres services lancés en root qui réclament une connexion vers l’extérieur, pourrais-tu me fournir des exemples ? Parce que parmi les plus communs (apache, mysql, oracle, ftp, openvpn, bind…), ils tournent tous avec un user particulier, voire acceptent le chroot (là encore, pour trouver un équivalent Windows de chroot…).

Finalement, pour un desktop, ton exemple de Flash et Silverlight est mal choisi : ce sont des plugins, pas des programmes externes. D’un point de vue du firewall, il voit juste une connexion venant de Firefox, et ne fait pas de différence si c’est du Flash ou Silverlight qui est appelé. Par ailleurs, pour un vrai contrôle de Flash, rien ne vaut Flashblock voire NoScript pour être sûr que rien n’est exécuté dans ton dos. Là encore, si tu as des exemples de softs dont tu veux contrôler les connexions sortantes, je suis preneur car je n’en trouve pas.

En fait, de manière générale, si tu pouvais donner un exemple concret de ce que tu ne sais pas faire avec ce que propose iptables, je suis intéressé.

Et pour être constructif : http://sourceforge.net/projects/leopardflower/

@Nico

Tiens, je viens encore de modifier la configuration de mes iptables cet après-midi en v4 et en V6. Lis un peu ce que j’écris.

Je pose un problème qui est réel. On peut choisir d’être dans le déni de réalité.

NB OpenSSH existe sur Windows. Je pense avoir un avantage : je connais et Linux et Windows. Par ailleurs, je ne suis pas pour ma part dans un rapport identitaire avec le libre et je connais très bien Windows. Ça ne semble pas être ton cas. Maintenant, la conversation est close ! J’ai autre chose à faire.

Désolé, les commentaires sont clos pour le moment.