Pare feu ou pas ?

Hoper · Le 29/05/2013, à 10:55

Si un user lambda télécharger un logiciel .deb depuis un site car il trouve ce logiciel attrayant et l'installe, en l'absence de code source, ce logiciel peut très bien déployer un trojan sur le port 20023... Certes, un rootkit se fera discret et la jouera sur le port 80...

Tu vis vraiment au siècle dernier en matière de sécurité info...
Se mettre en écoute sur un port bidon... Non mais n'importe quoi. Ca n'existe plus depuis belle lurette ça. Pourquoi faire un truc qui ne marchera pas (box adsl etc) alors qu'on peut très facilement faire un truc qui fonctionera dans 100% des cas ?

Pourquoi continu tu a penser qu'un trojan va se "mettre en écoute" ? C'est n'importe quoi. Un malware ne se met pas en écoute, il se connecte ! Via le port 80 ou le 443, un port qui ne sera jamais filtré. Et pour donner l'accès à ta machine, il mettre en place une connexion reverse. Ton firewall ne pourra strictement rien y faire.

En ce moment même à lieu une présentation (très) technique sur les nouveaux vecteurs d'attaque fournis par html5 :
http://www.denyall.com/index.php?option … 58&lang=fr

Tu utilise un navigateur compatible html5 ? Alors ta machine est vulnérable à une tonne de trucs vraiment pas cool. iptable, a part si tu lui demande de t’empêcher de surfer, il servira à que dalle !

SangokuSS · Le 29/05/2013, à 11:38

Cette discussion est intéressante (je suis sérieux là )... Mais alors que pensez-vous de ces recommandations ?
http://www.ssi.gouv.fr/fr/bonnes-pratiq … linux.html

tiramiseb · Le 29/05/2013, à 11:56

que pensez-vous de ces recommandations ?

Ces conseils sont orientés vers les serveurs et non vers le PC de madame Michu. Voilà toutefois mes commentaires de manière générale...

- mettant à jour régulièrement le système : impératif
- supprimant les logiciels inutiles : surtout, ne pas en installer. le système de base est très bien pour madame Michu - avec Ubuntu Server, c'est encore plus léger
- limitant au juste besoin les services en écoute pour chaque interface réseau : ça tombe bien, le système de base d'Ubuntu le fait déjà : il n'y a quasiment rien en écoute (sur Ubuntu Server, il n'y a vraiment rien du tout en écoute par défaut)
- désactivant le chargement dynamique des modules : mouais, si un module se charge dynamiquement à notre insu c'est déjà trop tard, ça veut dire que quelqu'un ou quelque chose a pénétré le système. ça complexifie la gestion, parce que si jamais on branche un matériel qui a besoin d'un module pas encore chargé, eh bien ce matériel ne fonctionnera pas. pas sûr que ce soit vraiment utile, sauf pour les grands paranos
- appliquant le principe de moindre privilège aux logiciels : pas compris ce qu'ils veulent dire par là ; si par "moindre privilège" ils parlent de ne pas lancer de logiciel en tant que root, je suis d'accord à 100%
- utilisant un mécanisme de contrôle d’accès reposant sur les rôles (Tomoyo, AppArmor, ACL grsecurity) : chiant à mettre en œuvre et à gérer ; à voir au cas par cas mais je ne conseille pas de le mettre en œuvre si on ne veut pas y passer du temps
- adaptant le noyau (suppression des éléments inutiles, application des patchs de durcissements) au contexte d’emploi envisagé : il s'agit donc de recompiler le noyau. On devra donc nous-même gérer les mises à jour. Je préfère faire confiance au noyau d'Ubuntu qui se met à jour avec les paquets de l'éditeur, je trouve qu'il y a moins de risque à avoir un noyau accompagné de modules potentiellement inutiles mais mis à jour aussi tôt que possible plutôt qu'un noyau qu'on a nous-même compilé et qu'on mettra à jour quand on en aura le temps

- utilisant un pare-feu local : sur l'ordinateur de madame Michu, inutile, je l'ai déjà expliqué en long, en large et en travers. Sur un serveur, pourquoi pas, ça dépend des cas et des besoins
- implémentant un schéma de partitionnement et les options de montage adaptés au contexte d’emploi : clairement, ce conseil s'applique surtout pour les serveurs ; pourquoi pas, mais attention : cela est beaucoup plus lourd à gérer, dans un de mes précédents emplois on l'a fait pendant quelques mois et on est retournés en arrière car c'était trop pénible à gérer (par exemple, un /usr en lecture seule c'est très bien, mais devoir le remonter en lecture-écriture à chaque mise à jour pour le remonter ensuite en lecture seule, quand on doit le faire sur plusieurs dizaines de serveurs tous les jours c'est juste trop chiant)
- positionnant les droits en lecture, écriture et exécution sur les fichiers après une analyse fine des besoins des utilisateurs mais aussi des services locaux. Une attention particulière sera portée sur les scripts lancés automatiquement : ah oui carrément, les droits sont à donner avec parcimonie et toujours si cela est justifié - pour les scripts c'est simple, personne ne devrait avoir le droit de les modifier une fois qu'ils sont en production, sauf l'administrateur concerné pour corrections.
- chiffrant les données : selon les cas, je suis d'accord ; chiffrer les transferts sur Internet, c'est impératif ; chiffrer le disque local d'un serveur enfermé dans une salle climatisée avec code, c'est a priori inutile

Réaliser un cloisonnement des éléments applicatifs selon leur sensibilité : oui, c'est mieux de faire comme ça. Par contre, attention à la surcharge de travail en terme de gestion de ce cloisonnement
Rédiger et appliquer les procédures d’administration sécurisées : c'est juste LE point faible de la majorité des sociétés que je rencontre ; malheureusement, peu sont sensibilisées à ce genre de questions et s'en foutent, tout simplement, même quand je leur explique les enjeux.

Définir et mettre en place une politique de journalisation d’événements cohérente : difficile à bien faire, mais ce serait mieux, c'est sûr
- distinguant différents niveaux de criticité selon leur impact sur la sécurité du système : oui, évidemment
- permettant la remontée d’alertes en fonction de ces niveaux : si seulement les sociétés y étaient sensibilisées...

Hoper · Le 29/05/2013, à 12:03

Réduire la surface d’attaque en :
- mettant à jour régulièrement le système

Une évidence, c'est une chose que les distributions linux actuelles permettent de faire très facilement, et c'est heuresement quelque chose qu'une immense majorité d'utilisateurs, y compris les madame michu, parviennent à faire sans problème.

- supprimant les logiciels inutiles,

Il n'est pas forcément facile de supprimer des logiciels installés par défaut sous ubuntu. Mais ils sont peu nombreux, sans réel danger et/ou bien configurés par défaut. Cette recommandation de bon sens peut donc devenir : Ne pas installer de logiciels dont vous n'avez pas l'usage (c'est un peu ce qu'on répète ici depuis le début avec tiramiseb ça...)

- limitant au juste besoin les services en écoute pour chaque interface réseau

Cela revient strictement au même que le point précédent

- désactivant le chargement dynamique des modules,

C'est un très bon conseil, mais qui n'est techniquement pas facile à réaliser pour des non informaticiens. Surtout, si cela ne pose pas de problème pour un serveur de production (qui ne change pas de matériel etc), c'est beaucoup plus délicat pour un poste bureautique, ou on attend du système un certain coté "plug and play" (j'ajoute une clef wifi ou bluetooth, j'aimerai bien qu'elle soit reconnue et utilisable directement sans devoir re-compiler le noyau...).
Personnellement j'ai appliqué cette recommandation sur mon lieu de travail et sur certains serveurs perso. Mais je ne le ferait pas sur mon poste bureautique. Globalement il faut comprendre que les inconvénients de cette solution dépassent les avantages qu'elle procure en terme de sécurité.

- appliquant le principe de moindre privilège aux logiciels

Cela est fait par défaut sous ubuntu. Cela fait heureusement longtemps qu'on ne voit plus sur ce forum d'absurdités du genre "Aidez moi, je veux être root tout le temps sur ma machine" etc.

- utilisant un mécanisme de contrôle d’accès reposant sur les rôles (Tomoyo, AppArmor, ACL grsecurity),

On parle ici d'un cadre pro, pas d'un cadre perso.

- adaptant le noyau (suppression des éléments inutiles, application des patchs de durcissements) au contexte d’emploi envisagé ;

Ce point est lié à la désactivation des modules dynamique. Si on désactive le chargement dynamique de driver, c'est évidement pour compiler un noyau personnalisé, intégrant tout ce qui est nécéssaire, mais SEULEMENT le nécéssaire au travail à réaliser.

Appliquer le principe de défense en profondeur en :
- utilisant un pare-feu local,

Cette recommandation est la première de la liste que je n'approuve pas.
Cela dit, comme certaines des recommandations précédente le montre, ce document s'adresse à des entreprises, pas à des particulier. Dans un cadre pro, certaines machines sensibles de part leur activité ou leur position dans le réseau (DMZ etc) peuvent avoir intérêt à utiliser un firewall. Mais ce n'est pas du tout le cas d'une façon générale. Bref, sur un réseau de 2000 machines, il y en aura peut être 10 ou 20 qui auront un firewall pour des raisons précises. Mais certainement pas les 2000. Sachant qu'une entreprise de ce type la utilise de toute façon des firewall matériels, un firewall logiciel sur la machine serait inutile et redondant (mais encore une fois, tout dépend de la façon dont on l'utilise, iptable permet de faire beaucoup plus de chose que de simplement droper des paquets)

- implémentant un schéma de partitionnement et les options de montage adaptés au contexte d’emploi,

Le rapport avec les aspects sécurités sont très flou. Sous entende ils que certains FS pourraient être montés en read only ? Peut etre... Ce n'est pas clair.

- positionnant les droits en lecture, écriture et exécution sur les fichiers après une analyse fine des besoins des utilisateurs mais aussi des services locaux.

On est la aussi dans un contexte pro. Quand un utilisateur ubuntu veut modifier des droits sur les fichiers, c'est en général pour faire de grosses bêtises (se donner tous les droits sur tous les fichiers ce qui n'est bien sur pas le cas par défaut etc).

Voila ce que pense de ces recommandations. La plupart sont très bonnes et peuvent s’appliquer aussi bien aux entreprises qu'aux particuliers. D'autre sont en revanche uniquement applicables aux entreprises. Celle qui concerne l'usage d'un firewall est inadaptée en l'état, et ressemble plus à un reliquat de vielles pratiques qu'autre chose.

EDIT : je vois au moment ou je post que tiramiseb à répondu quelques minutes avant moi. Je n'ai bien sur pas lu sa réponse avant d’écrire la mienne. Il va être intéressant de comparer nos points de vue, mais je suis quasiment certain que nos remarques seront plus ou moins les mêmes.

EDIT 2: Orthographe...

Dernière modification par Hoper (Le 29/05/2013, à 13:07)

tiramiseb · Le 29/05/2013, à 12:06

Sous entende ils que certains FS pourraient être montés en read only ? Peut etre... Ce n'est pas clair.

read-only sur /usr, noexec sur /var ou sur /var/log ou éventuellement sur /tmp (mais attention, certains logiciels crado exécutent des trucs à partir de /tmp), ce genre de choses

Hoper · Le 29/05/2013, à 12:11

Oui enfin, si on rentre dans ce genre de considération, autant y aller franco et mettre en œuvre SElinux...

tiramiseb · Le 29/05/2013, à 12:11

Un petit "noexec" sur /var ça reste quand même plus simple que SELinux

Hoper · Le 29/05/2013, à 12:19

Et de loin

Cela dit en deux secondes de surf sur le sujet j'ai bien l'impression que le noexec peut apporter pas mal de problèmes... Paquet debian qui ne peuvent plus s'installer si le tmp ou le var est en noexec etc.

C'est vieux, mais même sur redhat 5, on dirait qu'il ne mette pas le var en noexec :
http://www.softpanorama.info/Commercial … stem.shtml

tiramiseb · Le 29/05/2013, à 12:36

Paquet debian qui ne peuvent plus s'installer si le tmp ou le var est en noexec etc.

Oui il y a ce genre ce choses. C'est assez sensible tout ça.
Il y en a qui posent moins de problèmes, un noexec sur /var/log par exemple, ça ne m'a jamais posé de problème.

Mais ce n'est pas facile à mettre en place.

Hoper · Le 29/05/2013, à 12:48

un noexec sur /var/log par exemple, ça ne m'a jamais posé de problème.

Ca ne dois pas bloquer beaucoup d'attaques non plus !

Dernière modification par Hoper (Le 29/05/2013, à 12:48)

tiramiseb · Le 29/05/2013, à 12:54

Certes...

pires57 · Le 29/05/2013, à 13:07

un djeun's qui installait ses logiciels à coup de .deb dans 70% des cas

Sur une machine linux je pars du principe qu'il ne doit y avoir qu'un seul administrateur !
Installer les .deb à la mains je le fait aussi mais pour certaine chose spécifiques (par exemple une version précise d'un logiciel qui ne serais pas dans les dépôts officiels). Ce n'est pas une pratique à recommander et c'est effectivement le meilleur moyen de chopper de la saloperie...

bilgates · Le 03/06/2013, à 22:41

Bonjour,

Je ne suis qu'un simple utilisateur de Linux depuis 6 -7 ans, je n'ai jamais eu de problème du genre virus ou autres et jamais entendu parler de quelqu'un qui en aurait eu,a part ce cas qui apparemment n'a pas eu de conséquences
A votre connaissance connaissez vous,sur Linux, des cas d'intrusion de virus , malware ou bestioles de ce genre
Je regardais dernièrement une émission télé qui parlais de logiciels espions qui recherchent les mots de passe , sur Linux, est on a l'abri ?

Dernière modification par bilgates (Le 03/06/2013, à 22:44)

tiramiseb · Le 04/06/2013, à 07:07

Bonjour bilgates,

On est plutôt à l'abri sous Linux, pour une bonne et simple raison : le système étant bien moins diffusé, ça intéresse moins ceux qui créent ces virus et autres malwares : l'« intérêt » de ces outils c'est leur diffusion à grande échelle, ce qui n'est pas possible aujourd'hui sous Linux.

Historiquement, les utilisateurs de distributions Linux ont toujours été prudents concernant la sécurité, ils n'installent pas n'importe quoi.
Sauf que ces dernières années, avec Ubuntu notamment, de nombreux utilisateurs "lambda" arrivent sous Linux et ne font pas gaffe à la sécurité. Pire encore, ils reproduisent leurs habitudes acquises sous Windows, installent des choses qui proviennent de n'importe où, n'ont peut-être pas compris l'intérêt de la Logithèque... Du coup dans l'absolu "on" est moins en sûreté sous Linux.

Cela étant dit, si on reste vigilant sur ce qu'on installe sur son PC et qu'on garde tout à jour, on n'a pas de problème. Aujourd'hui en tout cas.

Hoper · Le 04/06/2013, à 09:10

On est plutôt à l'abri sous Linux, pour une bonne et simple raison : le système étant bien moins diffusé, ça intéresse moins ceux qui créent ces virus et autres malwares : l'« intérêt » de ces outils c'est leur diffusion à grande échelle, ce qui n'est pas possible aujourd'hui sous Linux.

Ah tiens...Première fois sur ce thread que je ne suis pas du tout d'accord avec toi.

Ce que les "pirates" recherchent en priorité, ce sont des machines allumés 24h/24, avec une bonne bande passante réseau. Que ce soit pour balancer des spams, pour utiliser comme rebond, pour stocker du warez, pour n'importe quoi en fait. Les critères sont toujours les mêmes. Une box stable, une bonne bande passante, et bien sur le top du top un admin pas doué qui se rendra compte de rien.

Or je pense qu'on a toujours plus de la moitié des serveurs web qui tourne sous linux. Linux n'est donc pas "rare", loin de la. (sauf chez les particuliers, mais le "pirate" en a pas grand chose à battre d'une machine allumé qu'une fois de temps en temps.

Sauf que, et la on se rejoint, les admins linux sont beaucoup plus sensibilités à la sécurité que les admins sous windows. (Ce qui malheureusement est en train de changer avec ubuntu, la aussi on est d'accord, cf certains billets de korben ou je pense des gueulantes quand il explique comment installer tel ou tel trucs obscure sans prendre le moindre recul, ni précautions.

A votre connaissance connaissez vous,sur Linux, des cas d'intrusion de virus , malware ou bestioles de ce genre

C'est arrivé oui. En fait, il y a TRES longtemps (plus de 15 ans), certaines distributions étaient vraiment trouées lors de l'installation. Donc si tu faisais une simple installation et aucune mise à jour, tu pouvais parfaitement te faire "rooter" ta machine en quelque heure, à cause de bots qui fouillait le net à la recherche de ces installations basiques. (La situation était bien pire sous windows hein...). La différence c'est que les distributions linux sont mises à jour très fréquemment (presque trop).

Tu comprend bien qu'avec une ubuntu, mise à jour tous les 6 mois, il reste pas beaucoup de trou sur ton CD d'install. Alors que si tu prend un CD d'installation de windows XP qui à 10 ans, que tu fais une installation basique en laissant la machine branchée au réseau, tu aura meme pas le temps de commencer à installer les services pack que ton OS sera déjà vérolé...

Dernière modification par Hoper (Le 04/06/2013, à 09:57)

nam1962 · Le 04/06/2013, à 09:53

Hoper a écrit :

(...). Alors que si tu prend un CD d'installation de windows XP qui à 10 ans, que tu fais une installation basique en laissant la machine branchée au réseau, tu aura meme pas le temps de commencer à installer les services pack que ton OS sera déjà vérolé...

Ça, çà m'est arrivé une fois : moins de 70 secondes il avait fallu

Après, 2 heures de boulot pour éradiquer.

Depuis que je suis sur Xubuntu et pour les 29 installs que j'ai faites, zéro problème.
Bon, j'active par principe Gufw sur toutes, en dehors de sécuriser les box de mes amis. (WPA2 et tout le toutim)

pires57 · Le 04/06/2013, à 16:42

Une machine vérolé sous linux? Cela m'es arrivé également une fois sur une fedora 15, un rootkits qui été venu élir résidence dessus mais il n'es pas rester très longtemps, on a rapidement découvers et résolu le probleme.
Les admins Linux sont, de maniere général plus axé sur la sécurité qu'un admin Windows. C'est vrai mais comme l'a dit hoper la tendence est a la diminution.
Pour moi, il y a plusieurs causes:
--> la réussite des distributions "users friendly" qui rapporte de nouvelle personnes issue du monde Windows (dans le domaine info ou pas) et qui garde leurs ancienne habitudes.
--> un manque de temps (parce que certain préfere ne pas sécuriser que de perdre X heures a le faire )
--> un manque de connaissance de la part de certain admin notamment issue du monde Windows (en général)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 29/05/2013, à 10:55

Re : Pare feu ou pas ?

#102 Le 29/05/2013, à 11:38

Re : Pare feu ou pas ?

#103 Le 29/05/2013, à 11:56

Re : Pare feu ou pas ?

#104 Le 29/05/2013, à 12:03

Re : Pare feu ou pas ?

#105 Le 29/05/2013, à 12:06

Re : Pare feu ou pas ?

#106 Le 29/05/2013, à 12:11

Re : Pare feu ou pas ?

#107 Le 29/05/2013, à 12:11

Re : Pare feu ou pas ?

#108 Le 29/05/2013, à 12:19

Re : Pare feu ou pas ?

#109 Le 29/05/2013, à 12:36

Re : Pare feu ou pas ?

#110 Le 29/05/2013, à 12:48

Re : Pare feu ou pas ?

#111 Le 29/05/2013, à 12:54

Re : Pare feu ou pas ?

#112 Le 29/05/2013, à 13:07

Re : Pare feu ou pas ?

#113 Le 03/06/2013, à 22:41

Re : Pare feu ou pas ?

#114 Le 04/06/2013, à 07:07

Re : Pare feu ou pas ?

#115 Le 04/06/2013, à 09:10

Re : Pare feu ou pas ?

#116 Le 04/06/2013, à 09:53

Re : Pare feu ou pas ?

#117 Le 04/06/2013, à 16:42

Re : Pare feu ou pas ?

Pied de page des forums