En effet, Les solutions pare-feu sous Linux n'ont cessé de se bonifier avec le temps grâce en grande partie au couple phare : netfilter/iptables. Ces derniers fournissent une solution robuste, mais néanmoins flexible pour ce genre de tâche.
Pour ceux qui ne les connaîtraient pas encore, netfilter est le nom du projet et iptables est le nom de la composante logicielle. Le fait est que c'est un système intégré dans les noyaux Linux 2.4.x et qui a en charge le filtrage de paquets.
A découvrir d'urgence !
Aller plus loin
- L'article sur ZDNet Australie (9 clics)
- L'adresse de référence pour en savoir plus (8 clics)
# Et les utilisateurs
Posté par Arnaud . Évalué à 10.
C'est sur qu'avec l'IRC? le P2P et ses amis, la tâche n'est pas simple!
[^] # Re: Et les utilisateurs
Posté par Alain Degreffe . Évalué à 5.
Le top c'est tout via proxy et sinon: nada.
et en "sus" des contrôles sur les D/L et les mails via un AntiVirus placé sur le FW. Pour le streaming, un proxy est aussi nécessaire. L'administration du proxy est aussi importante que le FW sinon gare au tunnel http etc...
Le firewall maison ,c'est autre chose. La le user , c'est le FWadmin et la question IN-OUT ne se pose plus vraimment.
[^] # Re: Et les utilisateurs
Posté par Arnaud . Évalué à 10.
[^] # Re: Et les utilisateurs
Posté par Gaël Le Mignot . Évalué à 10.
Combien de fois ai-je utilisé au taf la connexion ssh sur ma machine perso, pour récupérer quelque chose que j'avais fait un jour, regarder un fichier de conf, faire des requètes DNS quand notre DNS est tombé, ...
Il y a aussi d'autres services, comme les pserver CVS publics, ... qui ne sont pas accessibles via un proxy.
Même en parlant de l'IRC, outre le fait que c'est parfois un moyen rapide d'avoir une réponse à une question, c'est aussi une bonne chose de pouvoir se défouler un peu pendant la pause midi par exemple, et un IRC ça sert aussi à ça (enfin, c'est vrai, y'a la tribune aussi :) )
Donc, à part dans certains cas exceptionnels où il est nécessaire de contrôller toutes les infos sortantes de la boite, fermer tous les ports en sortie est pour moi quelque chose de très mauvais, car il prive l'utilisateur de beaucoup de libertés, qui peuvent être utiles même pour la qualité de son travail. Et niveau sécurité ça n'apporte vraiment pas grand chose. Je ne dis pas qu'il faut tout laisser sur la chaîne "OUTPUT", mais qu'il _faut_ laisser aux utilisateurs la possibilité d'établir des connexions ssh, pserver, ftp, ntp, et pourquoi pas aussi irc.
[^] # Re: Et les utilisateurs
Posté par PLuG . Évalué à 10.
A mon avis, gerer la securite sans savoir quels sont les protocoles utilisés, par qui et pour quoi, c'est impossible. Donc je coupe tout et tout le monde sait a qui s'adresser pour les besoins spécifiques. Sur les 3000 personnes de la boite, il y en a disons une 20aine qui a besoin de ssh/ftp/irc ? et les autres se satisfont des solutions prédéfinies: proxy http/https uniquement.
Du coup les besoins spécifiques sont remontés vers moi pour étudier une méthode sécurisée d'accès, pour documenter le biniou et surtout savoir le surveiller. Quand il y a un besoin spécifique urgent je sais le traiter aussi au coup par coup.
Tu as donc raison: l'admin, est d'abord la pour les utilisateurs. Mais cela ne veut pas dire tout laisser faire. Ca veut dire tout fermer ET SE RENDRE DISPONIBLE immediatement pour tout probleme. C'est le cas ou je bosse en tant qu'architecte, avec l'admin (meme bureau), on est a l'ecoute permanente pour trouver des solutions et améliorer l'architecture, modifier/ajouter des proxy, affiner des regles, ajouter des VPN, mettre au point/adapter le monitoring ...
Et on se rend compte que les besoins spécifiques c'est nous qui les avons (équipe reseau et équipe sécurité). Les developpeurs et l'équipe système en moindre mesure, les autres quasiement pas du tout.
(sauf pour napster mais etre a l'ecoute ne veut pas dire qu'on accepte tout non plus :-)
[^] # Les admins chiants ;))
Posté par Moby-Dik . Évalué à 5.
Pareil pour le SSH, à mon avis. Je ne vois pas trop en quoi une connexion sortante par ce protocole peut faire du mal au réseau interne. En gros, le comportement que tu préconises est de tout interdire par paresse ou par incompétence, afin d'éviter d'avoir à évaluer et pondérer le danger lié à chaque application potentielle (ce qui est pourtant le boulot de l'admin).
[^] # Re: Les admins chiants ;))
Posté par PLuG . Évalué à 10.
Après il y a le filtrage des sites "interdits" a mettre en place si la direction de la boite veut eviter les heures sur "le loft" ou les sites de cul (mais ca s'ecarte du probleme de sécurité).
filtrer tout et parler ensuitre demande beaucoup plus de boulot que de tout laisser passer dès le depart -- un peu contradictoire avec ton accusation de "paresse".
quand au ssh, honnetement PERSONNE en dehors de l'équipe réseau n'en a jamais fait la demande.
SSH est un protocole embetant a filtrer car il permet de faire des tunnels cryptés donc sans trop laisser aux admins la possibilité de juger du danger que représente ce tunnel. Accepter du ssh sortant c'est aussi accepter les yeux fermer du n'importe-quoi entrant (au gré d'un user lambda donc ni vu ni connu de l'équipe de sécurité).
--alors oui, je suis incompétant a tes yeux et je le revendique --
Pour remédier a ces problèmes liés a SSH, on utilise un "proxy-ssh" spécialement mis en place par moi-meme (deja causé sur linux-fr), qui permet de supprimer toutes les possibilitées de tunnel automatique de ssh (mais les users malins peuvent encore jouer evidement), et d'enregistrer ce qui est fait a travers la connection si besoin (connections ssh entrantes pour maintenance des machines). C'est un peu lourd j'en convient, mais c'est la seule condition qui a été acceptée par la direction. en plus le proxy-ssh oblige les gens a utiliser des clefs (pas de mot de passe) et ces clefs sont filtrés sur des critères que l'on a ajouté comme "date debut de validite" et "date fin de validite", comme ca pas besoin de se souvenir de revoquer la clef.
pour revenir a tes accusations, je passe sur incompétant, je suis mal placé pour juger, quand a FAINEANT, je le revendique haut et fort. Un bon informaticien se doit d'etre faineant, cela le pousse a toujours plus automatiser, scripter, ... au lieu de tout faire a la main. Le fainéant que je décrit aime bien aller au boulot mais pas faire 2 fois la meme chose, il s'arrange donc pour que la 2ieme fois le traitement soit automatique.
[^] # Re: Et les utilisateurs
Posté par ludovic claude . Évalué à 1.
Vous pouvez le telecharger sur http://cvsgrab.sourceforge.net(...)
[^] # Re: Et les utilisateurs
Posté par Alain Degreffe . Évalué à 8.
Scripts qui génèrent les règles de firewall avec dans l'ordre (enfin + ou -): zone,policy,rules,tos,TC,masq, snat et dnat et j'en oublie et tout cela de manière très claire et beaucoup plus simple. Imaginez la config pour un FW avec 3 localnets et 2 providers ( 5 cartes ethernet )... Avec shorewall c'est comme une 'couque' comme on dit chez nous les belges...
lien: http://www.shorewall.net/(...)
[^] # Re: Et les utilisateurs
Posté par DaFrog . Évalué à 5.
Tout parano que tu sois, si tes utilisateurs ne sont pas éduqués, ils laisseront trainer leurs mots de passe (si possible le nom de leur chien) partout et le résultat ne sera pas beau a voir...
Moralite: etre parano c'est bien, mais la sécurité passe aussi par l'education des utilisateurs.
DaFrog.
# T'appelle ca un article a découvrir d'urgence ?
Posté par Jérome K . Évalué à -10.
Fabien franchement ? t content de tes modéros ?
Y a rien dedans ce torchon .
# Mise en place d'un firewall... EzFireBox
Posté par Sami Dalouche . Évalué à 10.
Je vais profiter de la news pour faire un peu de pub...
<version type="courte"> http://savannah.gnu.org/projects/ezfirebox/(...)
</version>
<version type="longue">
Je suis en train de créer un script de firewall à partir du package ipmasq de debian.
Le but de ce script est de permettre à quiconque de créer un firewall sécurisé en se concentrant seulement sur les règles de firewall.
Le script ajoute lui même un ensemble de règles destinées à protéger contre les attaques du type spoof, flood.
La détection des interfaces externes et internes se fait automatiquement, et le script initilise aussi l'ip masquerade.
Pour le moment, le script n'est disponible que sous forme de règles pour le package ipmasq sous debian, mais je devrais bientôt packager ca sous le nom de EzFireBox
Ceux qui sont interessés peuvent télécharger le logiciel sur http://savannah.gnu.org/projects/ezfirebox(...)
, ceux qui veulent aider peuvent rejoindre le projet, et ceux qui veulent donner des idées peuvent le faire..
Je compte aussi intégrer des règles pour initialiser le traffic shaping et pemettre notamment de donner la priorité au téléchargement face à l'upload..
</version>
[^] # Re: Mise en place d'un firewall... EzFireBox
Posté par Sami Dalouche . Évalué à 1.
# Le NAT rien de plus efficace
Posté par RB . Évalué à 3.
[^] # Re: Le NAT rien de plus efficace
Posté par Alain Degreffe . Évalué à 2.
Le DOS tu connais ? le spoofing tu connais ?
[^] # Re: Le NAT rien de plus efficace
Posté par RB . Évalué à 3.
La machine qui fait le firewall peut tjs être victime de DOS, mais en général avec un OS fiable et bien configuré, les DOS n'ont pas d'effets permanents (la machine marchera tjs à la fin du DOS).
En gros je comprend pas ta remarque.
[^] # Re: Le NAT rien de plus efficace
Posté par Vanhu . Évalué à 8.
Bien sur, il faut deviner ton plan d'addressage, mais c'est souvent pas trop dur, et puis au pire, on fait un petit script qui tente toutes les classes RFC1918, et si ca marche pas, on bourrine....
En résumé, comme toute technique de sécurité par l'obscurité, le NAT peut être un bon complément mais fait une mauvaise base.
[^] # Re: Le NAT rien de plus efficace
Posté par woof . Évalué à 5.
tu configures ton gateway en NAT et tu bloques tout ce qui vient de l'exterieur et qui est pas pour ta box specifique ...
[^] # Re: Le NAT rien de plus efficace
Posté par Kyrill Guiborsky . Évalué à -2.
SI tu n'as que du NAT (et pas de filtrage du tout, donc), tes machines internes sont généralement accessibles en traffiquant les tables de routage de la machine qui essaie d'entrer (a moi que ton FAI ne fasse des verifications d'adresses (donc du filtrage), mais c'est rare).
Parce que toi tu laisse rentrer des paquets avec options de routage à la source ?
Ca fout la trouille (c) (tm)
[^] # Re: Le NAT rien de plus efficace
Posté par Vanhu . Évalué à 2.
Au passage, il ne s'agit pas forcément de "source routing", mais aussi plus simplement de table de routage "bien faite"....
[^] # Re: Le NAT rien de plus efficace
Posté par Kyrill Guiborsky . Évalué à -2.
Mauvais fournisseur, changer de fournisseur.
Ca fout la trouille (c) (tm) #2
[^] # Re: Le NAT rien de plus efficace
Posté par PLuG . Évalué à 10.
les techniques de spoofing peuvent permettre de se connecter a ton intranet si le firewall n'est pas bien configuré (le NAT seul ne suffit pas). Sur internet c'est pas toujours facile a utiliser comme attaque -- en théorie c'est possible (en pratique demande a mitnick, c'est ce qu'il avait utilisé pour se rendre en taule).
un utilisateur peut tres bien creer un tunnel depuis son adresse NATée vers une machine externe et router tout le traffic qu'il veut dedans. Si un des utilisateurs fait cela ton réseau entier est exposé.
De toutes facons la sécurité doit etre en relation avec ce que tu protege.
A la maison un firewall qui fait principalement du NAT et qui est bien parametré suffit largement (confiance maxi dans les utilisateurs).
Au boulot cela depend de la taille de la boite, des données a protéger, du niveau des utilisateurs ...
A mon avis tu n'as pas tord. Mais tu n'es pas assez parano pour opérer dans un milieu hostile/à risque.
[^] # Re: Le NAT rien de plus efficace
Posté par RB . Évalué à -2.
Mais bon, je parlais vraiment de petit réseau appartenant à des particuliers ou à des petits groupes de travail relié au cable ou a de l'adsl, donc voilà.
[^] # Re: Le NAT rien de plus efficace
Posté par Anne Onimousse . Évalué à 2.
Les gens qui travaillent sur Ipv6 ont un article qui explique pourquoi il ne faudrait plus l'utiliser (surtout pour faire de la sécurité !). En gros leur argument est que ça fout en l'air la transparence du réseau, que ça empêche l'emergence de nouvelles applications (peer 2 peer, téléphonie sur IP, ...) qui ne fonctionnent plus suivant le modèle client-serveur
# à ce propos...
Posté par fasthm . Évalué à 6.
http://www.boingworld.com/workshops/linux/iptables-tutorial/iptable(...)
c'est plutot bien expliqué
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.