[DA WALL] securité ?

[marvin rouge]

bjour,

Il y a une question qui me turlupine depuis quelques temps, et je ne trouve pas de réponse satisfaisante : à la fois claire, explicative et convainquante. Cette question c'est simple : à quoi sert un firewall ?

Alors là on va me répondre "oh t'es trop nul, ca sert à filtrer les paquets, et comme ca MrCracker de www.crack.w4r3z.com ne peut pas rentrer chez toi". Mouais. Ma question est encore plus simple: ca fait quoi de laisser un port ouvert sur son firewall si il n'y a aucun service qui écoute derriere ce port (genre je laisse le 22 ouvert, mais j'ai pas sshd qui tourne) ? Quels sont les risques ? Qu'est-ce qu'un hypothétique MrCracker peut faire si il trouve sur mon serveur le port 27451 ouvert (au hasard) ?

En fait j'ai l'impression qu'un firewall (genre un script iptables) ca sert pour des routeurs qui font du NAT et qui servent de passerelles entre un réseau local et le ouèbe. Mais pour un serveur tout seul ca sert pas à grand chose.

Corrigez moi, dites moi ce que vous en pensez, éclairez moi ...

[Mac Cloud]

Bah tu as raison pour un seveur seul sa ne sert qu'a virer les packets agressifs : genre un packet mal formatté qui utilise une faille dans ton httpd par exemple. Ou a definir qui (@IP) peut aller sur ton port 22 ...
Des qu'il y a plus d'une machine derrire les application sont quasiment infinies nat pat load balancing ....
_________________
Vous prouver que j'ai raison serait admettre que je puisse avoir tort.
Beaumarchais

[kwenspc]

Hum en fait on peut partir d'un constat simple : un firewall mal configuré est souvent pire que ne pas avoir de firewall sur une machine bien configurée.

Après le "bien configurée" pour ce qui est de la machine ça implique pas mal de chose...
fermeture des ports inutiles, eviter que X ne soit accessible de l'exterieur, inetd/xinetd si on en a pas besoin zou poubelle etc...

Enfin si on s'interesse aux attaques possibles...firewall ou pas on peut toujours passer outre.
Maintenant ça peut être sacrément compliqué, j'ai lu quelques trucs là dessus et il est clair que c'est pas môsieur cracker du coin qui peut se fader les manips (attaques sur les couches TCP par echo syn bidules enfin : fo être au parfum pour piger le machin je pense parce que perso j'ai pas compris. Il y a aussi encapsulation de trames filtré dans des trames non-filtrés qui permettent de passer outre un fw...)

moi je n'utilise un firewall que pour le partage de la connexion
Jusque là d'ailleurs j'ai pas eu à me plaindre, je bloque les echo ICMP enfin : tout ce qui a de plus banale.

pour beaucoup en tout cas les firewalls representent la protection utlime...c'est n'importe quoi. et beaucoup là encore se sentent protégé tout ça parce qu'ils ont un fw.
moi je suis pas de leur avis m'enfin bon.

conclusion personnelle : je pense que ta question n'est pas nulle et qu'en effet ça mérite refléxion sur le fait de devoir utiliser ou non un fw. et je suis tout ouï sur les réponses qui seront postées sur ce topic

[Mac Cloud]

Il y a aussi un problème : c'est quoi un firewall ? une option cochée dans un OS verolé de partout, un switch net-gear a 15 euro, un ipcop, une achie compléte avec 2 net-app et dmz ?

réponse : tout ca ! du coup ca devient vachement vaste comme domaine !
_________________
Vous prouver que j'ai raison serait admettre que je puisse avoir tort.
Beaumarchais

[bosozoku]

Un ordinateur faisant office de passerelle et partageant la connexion peut aussi faire office de firewall non ? Et dans ce cas c'est beaucoup plus sécurisé qu'un simple logiciel. (arretez moi si je me trompe, j'y connais pas grand chose dans ce domaine.)
_________________
Stationlinux.org - Wiki Fvwm FR - Config Fvwm

[kwenspc]

ben pour faire passerelle/firewall ton pc a besoin de logiciels...donc la comparaison est pas valable là.

[bosozoku]

[kwenspc]

moui ça doit se valloir comme idée.

moi j'ai une passerelle/serveur ssh/firewall

j'y fais tourner quelques applis dessus (client irc)

je pense en effet que si tu fais rien tourner d'autres que ta paserelle/firewall tu risques moins...mais rien ne t'empèche d'attaquer les machines qu'il y a derrières. d'ailleurs dans ce cas mieux vaut ne pas se faire repérer par le firewall pour continuer à faire croire que tout va bien...

[marvin rouge]

et oui, c'est vaste et compliqué ... c'est bien pour ca que j'essaie de revenir à la base, pour comprendre, à mon niveau d'utilisation. Et à mon humble avis (mais je me trompe peut etre) la question de base est la suivante : est-ce qu'un attaquant peut tirer parti d'un port ouvert ? comment ?

Je comprends bien (enfin je pense) que si une appli est mal configurée (exemple : ssh avec user/user en login/psswd) c'est un gros trou de sécurité, firewall ou pas. Je comprends bien que si une appli est sensible à un certain type de requete (genre le serveur web microsoft et des trucs du genre \x90\x90\x90\x90\x90\x90\x90\x90 ...) alors ca peut faire planter l'appli. Mais tout ca c'est indépendant du firewall.

J'ai comme l'impression beaucoup de monde (moi en premier) se colle un firewall sans savoir vraiment à quoi ca sert.



Je traverse une crise existentielle ...

[kwenspc]

un firewall c'est un truc qui a été "inventé" pour être vendu très cher à des patrons qui ainsi ont tout de suit crus qu'ils étaitent à la pointe de la technologie et surtout à l'abri (que neni d'ailleurs!).
Penses donc : ils ont un Mur De Feu! ouaaaah les boules...

techniquement parlant je pense que ça peut être intéréssant si le rézo qui est derrière est TRES MAL configuré (machines zindoz etc...), et ce pour des entrerprises qui n'y connaissent rien à l'informatique. Ou alors ça permet auss ide bloquer les attaques communes et bénignes. Sinon je pense que ça vaut pas un pet de lapin face à quelqu'un determiné à entrer par tout les moyens.

[Mac Cloud]

Une machine ne faisant que firewall n'est pas forcément plus secu = > prenons le cas typique de "ipcop" : tu ouvres le port 81 pour pouvoir administrer a distance ton firewall... d'abord de chez toi... puis vu que ton "emule" te joue des tours tu ouvres ce port le 81 coté wan car tu veux pouvoir jouer avec depuis le bureau (on l'a tous fait) comme c'est du https tu te dis que c'est la fete tu risques rien tu es le roi du pétrole...
Seulement voila le httpd (apache pour ne pas le cité) de ton ipcop a une faille ... et quelqu'un a un nessus bien a jour et connais ton IP (bas oui c'est ca les joies des dyn-dns gratuits...) en 2 secondes il voit ton port 81 ouver devine donc que c'est un ipcop retrouve l'"exploit" qui va bien, envoie une requette http truquée qui touvre (via l'install d'un netcat par exemple) le moyen de lui ouvrir un telnet sur ta machine.
Le voila donc logé en user=apache sur ton FW... un buffer over flow du kernel plus loin (en gros il télécharge un autre exploit tout fait....) il se retrouve en root sur ton FW... si tes mots de passes sont identiques partout tu est mort sinon tu est mort aussi car brute force est avec lui ...
C'est clair ?
Voila pk il faut pas ouvrir de service inutiles ... blaster fait tout ca seul sur le service M$ que je ne connais pas et qui troune sur le port port 135
_________________
Vous prouver que j'ai raison serait admettre que je puisse avoir tort.
Beaumarchais

[bosozoku]

Oué enfin faut vraiment pas avoir de bol pour tomber sur un mec comme ça. En général les gens qui savent faire ce genre de choses n'ont pas de mauvaises intentions, au contraire.

Les 'crackers' sont souvent des jeunes boutonneux qui veulent se la jouer à la pirate et qui joue avec un trojan sur windows... C'est un peu caricaturé mais pas trop loin de la vérité.
_________________
Stationlinux.org - Wiki Fvwm FR - Config Fvwm

[Mac Cloud]

[yoyo]

[sireyessire]

[Trevoke]

Faut dire tout de meme que la majorite des hackers passent par une phase crackers (en general c'est la phase dite "larve" avant de devenir papillon quoi..)
_________________
Votre moment detente
What is the nature of conflict?

[sireyessire]

[kwenspc]

franchement le côté osbcur de la force (lol) il serait plutôt du côté des gvts, majors et autres...

Alors les crackers (hum c'est pas le nom des biscuit dans wallace et gromit ça? ) ils sont plutôt dans le côté clair de la force

[Trevoke]

Sireyessire: les deux ne sont pas incompatibles...

Si je n'avais pas eu un peu trop peur de foutre quelque chose en l'air en entrant n'importe ou, j'aurais bien fait ca pour apprendre moi..
_________________
Votre moment detente
What is the nature of conflict?

[kwenspc]

@Trevoke : personne ne t'empèche de le faire allez allez au boulot!

bon en même temps moi c'ets apreil, je suis surtout bloqué par le fait qu'on puisse être emmerdé et servir de bouc émissaire...

[Trevoke]

Y a pas quelqu'un qui veut se sacrifier et faire une machine sur laquelle on peut faire joujou non? )))
_________________
Votre moment detente
What is the nature of conflict?

[kwenspc]

bah si t'en as une en rab tu l'installes avec différents os dessus (mutliboot) et tu te fais la main sur les logiciels les plus usités. déjà là y a de quoi faire

[Celeborn]

C'est marrant le thread part plutot sur l'idée de comment protéger son ordi, est-ce qu'un firewall c'est important, ça fait quoi exactement, etc... et là, c'est en train de passer à HOW-TO : hacker pour les nuls

[Trevoke]

Bah les deux sujets se valent
_________________
Votre moment detente
What is the nature of conflict?

[genAlphA]

Bonjour à tous,

j'arrive un peu après tout le monde dans ce thread mais je vais donner mon point de vue quand même

Alors, historiquement un parefeux c'est un "boitier" situé entre un point A et un point B. Par exemple entre le réseau interne d'une société et l'extérieur. Faut voir que l'utilisation d'adresse CIDR + translation d'adresse est relativement récente. Auparavant, la notion d'adresse non routable sur internet n'existait pas trop. Donc on pouvait avoir des postes de travail, des serveur internes, etc reliés au net et adressable depuis internet ! D'où la nécessité de mettre en place des équipements filtrants. Ensuite est venue la notion de CIDR et on a commencé à déployer des adresses non routables, ce qui, par effet de bord, permet de gagner un peu en sécurité, mais attention CIDR ne veut PAS dire qu'on est protégé : cf google sur le spoof d'adresse et le source routing. (Quoi que ces problèmes sont devenus très peu courant).

Mais bon le CIDR c'est bien joli mais comment donc on met en place un serveur web publique alors dans une société ? Ben il lui faut une adresse publique (sauf ruse) et on revient au problème précédent à savoir que ma machine est exposé. Donc on colle un parefeu devant de façon à filtrer le trafic qui entre et qui sort. De là découle la notion de DMZ, c'est à dire un réseau adressable depuis le net mais séparé du réseau interne par des moyens de protection. Si ma dmz est compromise, j'ai une défense supplémentaire.

Alors pourquoi vouloir filtrer le trafic ? Ben déjà pour limiter ce qui entre. Mon serveur web dans l'exemple précédent, il n'y a pas besoin que du trafic autre qu'à destination du port 80 entre dans la DMZ donc on le droppe sur le parefeux. Mais un parefeux sert également à filtrer le trafic sortant ! et c'est là qu'une incompréhension liée iptables, pf, etc sur le poste de travail direct existe parfois. C'est qu'on voit pas l'intérêt de filtrer son trafic parce que tout le trafic sortant est "généralement" soit initié par l'utilisateur de la machine, soit en réponse à du trafic entrant (les ACK d'une cnx ssh depuis l'extérieur par ex).

Donc reprenons l'exemple de notre serveur web. Il offre un seul service : http tcp port 80 mais pour diverses raisons (log des cnx, etc), on veut qu'il soit capable également de faire des requêtes DNS à destination d'un dns externe donc on va faire ceci sur le parefeux :
*interdire tout en entrée sauf le trafic entrant vers le serveur port destination 80 en tcp et le trafic entrant vers le serveur avec le port source 53 en udp
*interdire tout en sortie sauf le trafic sortant depuis le serveur port source 80 en tcp et le trafic sortant depuis le serveur avec le port destination 53 en udp

Donc avec ça on est sur (bon, on est jamais vraiment sur : faille, etc) que
le trafic qui passera dans notre DMZ sera ben celui que l'on a autorisé explicitement en fonction de l'usage que l'on fait de notre machine.

C'est une notion qui avec les parefeux personnels style iptables sur le poste de travail, ou kerio sous win, on néglige un peu : c'est que le firewall filtre dans les 2 sens. Si je n'ai jamais besoin d'initier des connexions vers le port 31337 en tcp, je le bloque explicitement, simplement parce que dans ma "politique de sécurité" je n'en ai pas besoin. Donc grosso modo avec un parefeux on va ajouter une muraille à notre machine qui marchera dans les 2 sens : supprimer une cnx entrante qui n'a pas à avoir lieu (même si je n'ai pas de service sur le port en question, c'est décidé comme ça un point c'est tout) et supprimer les connexions sortantes de ma machine pour lesquels je n'ai pas de raison de le faire.

Dans les firewalls sous win, on a des notions en plus, (on peut faire pareil avec certains modules iptables iirc) c'est la notion de processus autorisé à émettre des cnx sortantes. Ben c'est un peu pareil. Pour surfer sur le net, j'ai besoin d'autoriser les connexions depuis mes ports clients (> 1024) vers (la plupart du temps) le port 80 des serveurs que j'accède. Donc il me faudrait une régle qui dise : autoriser tcp (port > 1024) vers * (port = 80). Ben là, en autorisant IE par exemple à se connecter, implicitement, on active à la volée la régle qui va bien dans le sens poste de travail vers le net. Une fois ie fermé, si un autre programme essaye -> /dev/null. Bon c'est pas parfait. Y'a eu des pbs avec ça : malware renommé en processus licite, injection de code dans les processus (createRemoteThreadEx est ton ami), etc. Mais bon, c'est pas le sujet de disserter des pf sous win

Pour finir ce (déjà trop) long post, un petit comparatif rapide des différents types de parefeux : y'a 3 types grosso modo :

* packet filter : un truc tout bête qui agit sur le quintuplet (ip src, port src, ip dst, port dst, protocole). c'est ultra basique, ça part en live dès qu'il faut des protocoles tordus (ftp par ex) mais en 1ère ligne de défense c pas mal car peu consommateur de ressource p/r à ce qui suit.

* Stateful Packet Filters : un peu plus évolué que ci dessus. On trouve la notion d'état (vivi en udp également, bon c factice mais ça marchote). C'est à dire que le pare feux va être capable de valider qu'un paquet appartient bien à une connexion donnée selon les normes tcp. Respect des handshake, suivi des seq / ack, etc. Donc il va devenir plus difficile pour un attaquant d'injecter du trafic dans une connexion existante et validée par le parefeux car son paquet aura peu de chance de faire partie d'un contexte valide. Pour info, iptables n'est pas complètement stateful.

* proxy : alors là, c'est encore pire (ou mieux ) le proxy va casser la connexion directe entre le client et le serveur. Le proxy est le serveur au yeux du client et il est le client au yeux du serveur. "On ne traverse donc pas, on rebondit". Là, grâce à ça, on va reformater le trafic au niveau ip et tcp et également pouvoir inspecter le contenu du packet donc là on filtre carrément au niveau protocolaire. Pour le serveur web en dmz par exemple, mon proxy peut par exemple interdire les méthodes HEAD, PUT et CONNECT , autoriser le GET et le loguer, etc. Bon, faut par réver, c'est pas ça qui protégera contre une attaque de type directory transversal ou autre (sauf si on couple avec un moteur de signature, etc mais ça devient *très* cher là).

Transversalement à ces 3 catégories, on trouve des facilités offertes, par exemple le connection tracking (cf iptable + ftp) qui va permettre d'ouvrir des régles à la volée pour certains protocoles casse pied (dcc pour irc, cnx data pour ftp, etc) voir même en plus faire de la translation d'adresse là dessus.

Voila, j'espère que ça aura pu éclaircir un peu le rôle du parefeu. Donc je la refais en concis : le parefeu c'est un moyen de n'autoriser que le trafic prévu lors de la phase de conception du système. Je veux du web sortant, du dns sortant et du ssh entrant. Je n'autorise que ça et c'est tout. Le reste out (+ logué éventuellement). Faut pas voir le parefeu comme un système de protection ultime, ça ne l'est pas.
_________________
You don't need reasons when you've got Linux