Différences IpChains, NetFilter, IpTables ?

Recherche :

Dernière réponse

Sujet : Différences IpChains, NetFilter, IpTables ?

Groody

ethernal a écrit a écrit :

il va te loguer qqch du genre (j'ai pas de log sou la main)
...192.168.0.1:3256 try to connect to monip:80...
tu vois tout de suite que ce n'est pas normal ;)

si tu as une machine sur le LAN avec cette IP, ça pourrait etre normal. Nop ? Ou je vois pas quelque chose là ??

Citation :

...aucune application normale (browser, cient ftp, ...) ne produit ce genre de paquet.

Citation :

comme exemple de paquets anormaux tu as aussi des trucs du genre:
212.189.256.3:80 try to connect (syn) to mon_ip:80
les ports <1023 étant des ports spéciaux, aucune application n'utilisera un port <1023 pour se connecter.
(sauf certains serveurs (dns port 53 --> port 53, ntp (syncro de l'horloge port 123), mais c'est rare)

Ah oui, j'y avais pas pensé à ca. on utilise quasiment que des ports dynamiques pour se connecter a des serveurs sur le net.

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Groody

ethernal a écrit a écrit :

il va te loguer qqch du genre (j'ai pas de log sou la main)
...192.168.0.1:3256 try to connect to monip:80...
tu vois tout de suite que ce n'est pas normal ;)

si tu as une machine sur le LAN avec cette IP, ça pourrait etre normal. Nop ? Ou je vois pas quelque chose là ??

Citation :

...aucune application normale (browser, cient ftp, ...) ne produit ce genre de paquet.

Citation :

Ah oui, j'y avais pas pensé à ca. on utilise quasiment que des ports dynamiques pour se connecter a des serveurs sur le net.

ethernal

il va te loguer qqch du genre (j'ai pas de log sou la main)
...192.168.0.1:3256 try to connect to monip:80...
tu vois tout de suite que ce n'est pas normal ;)
iptables permet aussi de rajouter une chaine de caractère en cas de log pour mieux voir ce qui se passe sans devoir spécialement regarder toute la ligne.

sinon, il y a des combinaisons de flag qui ne son pas normale et qui sorrespondent souvent à des scanner. (c'est pas moi qui les ai découvert, c'est stipulé dans la doc ou dans les exemples de firewall)
genre une suite de flag syn, rst, syn, rst

aucune application normale (browser, cient ftp, ...) ne produit ce genre de paquet.

comme exemple de paquets anormaux tu as aussi des trucs du genre:
212.189.256.3:80 try to connect (syn) to mon_ip:80
les ports <1023 étant des ports spéciaux, aucune application n'utilisera un port <1023 pour se connecter.
(sauf certains serveurs (dns port 53 --> port 53, ntp (syncro de l'horloge port 123), mais c'est rare)

Groody

Ok, merci pour SYn et compagnie.

Citation :

la machine dont l'ip est 212.95.66.6 à partir de son port 61017 a essayé de se connecter (syn) sur ta machine sur le port 483 dans le protocol tcp.
ensuite tu as d'autres indications mais faudrait que je revoie mon cours de réseau
le port 483 ne correspond pas à un service connu (ulpnet) (??)
peut-être est-ce un port utilisé par un trojan...

Yep j'avais traduit ;).
Pour le port 483, et bien je ne sais pas. Pour le trojan, là je pense pas. A moins que ce soit quelqu'un qui tente de se connecter...

Citation :

pq il l'indique en "NAT" au fait ?

Je partage ma connexion avec WinRoute, soit du NAT.

J'ai aucun port de visible depuis l'extérieur, excepté le 80 aujourd'hui, pour test, je viens de mettre une SME V5.0 sur le LAN, + Port mapping sur la passerelle, donc..

Citation :

Par contre, j'examine plus en détail qd je vois que la personne fais de l'ip spoofing ou qu'elle tente de se connecter à partir d'un port <1023, ou qd la combinaison des flag n'est pas normale. Dans ce cas, ce sont des logiciels fait pour hacker qui sont à l'oeuvre puisque ce ne sont pas des paquets qui devrait exister normalement, ils ont été fabriqués de toute pièce dans un but précis.

Comment vois tu qu'il spoof ? que la combinaison des flags n'est pas normale comme tu dis ?

Citation :

on sait trouver pas mal de doc spécialisée la dessus sur le net si tu veux en savoir plus sur le protocole tcp-ip

Oui oui, mais pas le tps :D.

ethernal

Groody a écrit a écrit :

Je pense avoir compris que le Flag Syn était une entré, une preuve qu'il y a eu demande, connexion ?
Tu peux m'en dire plus sur FlagSyn stp ?

Chaque paquet comprend un header qui contient un certain nombre d'information (taille, ip sender, ip dest, port source, port dest, des flags,..).
Il existe plusieurs type de flags(drapeau) : syn, hack, rst (reset), fin, urg, psh (push)...
Le flag syn qui indique que le paquet effectue une demande de connexion ; pour les autres je ne suis plus trop sûr : le rst, une fermeture de connexion ; le hack, une confirmation de réception du paquet précédent...)

Le firewall va décomposer les informations pour voir d'ou il vient exactememnt, ou il va, ce qu'il veut faire, et éventuellement quels sont les infos contenues pour appliquer l'action que tu as décidée : loguer/jeter ou accepter.

Le premier paquet d'une connexion tcp a toujours un flag syn activé. c'est normal, tu demandes à te conneter qq part. Une fois la connexion établie, le dialogue s'effectue ensuite sans flag syn. (pour info en udp, il n'y a pas de demande de connection ; en icmp (ping-request, ping-echo, traceroute, ...) il y a également une demande de connexion mais je n'en suis pas sûr)

Groody a écrit a écrit :

[22/Dec/2001 18:39:35] NAT: + proto:TCP, len:54, ip+port:212.95.66.6:61017 -> MONIP:483, flags: SYN , seq:1680278478 ack:0, win:2048, tcplen:0

[22/Dec/2001 18:39:35] NAT: Attempt to establish TCP connection through NAT (in). The following line contains suspicious packet dump:

[22/Dec/2001 18:39:35] NAT: + proto:TCP, len:54, ip+port:212.95.66.6:61017 ->

en français, mais je pense pas que ça va t'aider des masses (à mon avis tu en sais autant que moi dans le domaine)... :
la machine dont l'ip est 212.95.66.6 à partir de son port 61017 a essayé de se connecter (syn) sur ta machine sur le port 483 dans le protocol tcp.
ensuite tu as d'autres indications mais faudrait que je revoie mon cours de réseau :D
le port 483 ne correspond pas à un service connu (ulpnet) (??)
peut-être est-ce un port utilisé par un trojan...

pq il l'indique en "NAT" au fait ?

Avec mon firewall, je logue une 100aine de paquet par jour facilement... mais tous ne sont pas spécialement des attaques, faut pas t'inquiéter.
Par contre, j'examine plus en détail qd je vois que la personne fais de l'ip spoofing ou qu'elle tente de se connecter à partir d'un port <1023, ou qd la combinaison des flag n'est pas normale. Dans ce cas, ce sont des logiciels fait pour hacker qui sont à l'oeuvre puisque ce ne sont pas des paquets qui devrait exister normalement, ils ont été fabriqués de toute pièce dans un but précis.

on sait trouver pas mal de doc spécialisée la dessus sur le net si tu veux en savoir plus sur le protocole tcp-ip ;)

Groody

Heu... OUI, très clair. t'as ICQ ???? :D
;)

Ok, pigé le principe. Pas mal :).

Pour les FW sous Win, ça dépends. Les bons, tu créés tes règles aussi, par exemple avec tiny Personnal Firewall, en fonction du proto, port local, distante, IP, plage d'IP, plage de ports, etc..

Enfin c'est pas le sujet.. ;)

Citation :

Avec ipchains, tu spécifies une règle qui accepte que ton serveur à partir de son port 80 vers une ip quelconque et un port >1023 envoie des paquets sans demande de connexion (pas de flag syn).
Pour chaque services que tu offres (web, mail, ftp,...), tu devras spécifier une règle de dialogue serveur -> client.

Je pense avoir compris que le Flag Syn était une entré, une preuve qu'il y a eu demande, connexion ?
Tu peux m'en dire plus sur FlagSyn stp ?

Pour reviendre au mondre Win 2s, sous WinRoute Pro, j'ai :
[22/Dec/2001 18:39:35] NAT: + proto:TCP, len:54, ip+port:212.95.66.6:61017 -> MONIP:483, flags: SYN , seq:1680278478 ack:0, win:2048, tcplen:0

[22/Dec/2001 18:39:35] NAT: Attempt to establish TCP connection through NAT (in). The following line contains suspicious packet dump:

[22/Dec/2001 18:39:35] NAT: + proto:TCP, len:54, ip+port:212.95.66.6:61017 ->

J'ai pleins de lignes comme ça, et je ne sais pas à quoi ça correspond.

[edtdd]--Message édité par Groody--[/edtdd]

ethernal

Groody a écrit a écrit :

NetFilter, par rapport à IpTables ? C'est léditeur ? Ou un soft, j'ai pas suivi...

Je pige pas trop là. On aurait pas pu faire une règle du port 80 vers l'IP de la connexion dans les deux sens ? (je redis que je ne connais RIEN au monde Linux pour l'insant, je me base sur mes connaissances sur les FW Wuinedause).

pour chaque règle client-> serveur, tu peux avoir une règle serveur-> client.

si tu as un serveur web sur ta machine :
- dans un sens tu acceptes la connexion d'une ip quelconque (et d'un port > 1023) vers le port 80 en tcp de ton serveur web.
Pour dire que c'est une tentative de connexion, tu regardes que le flag syn est activé. Dans ce cas le principe est le même pour ipchains et iptables.
- dans l'autre sens (uniquement si tu limites les communication serveur -> client), tu acceptes que ton serveur répondes à cette demande.
Dans ce cas :
Avec ipchains, tu spécifies une règle qui accepte que ton serveur à partir de son port 80 vers une ip quelconque et un port >1023 envoie des paquets sans demande de connexion (pas de flag syn).
Pour chaque services que tu offres (web, mail, ftp,...), tu devras spécifier une règle de dialogue serveur -> client.

Avec iptables, tu peux spécifier en une ligne que ton serveur réponde à toute connexion qui est déjà établie. C'est à dire que si ton serveur fait aussi ftp, mail, ... il répondra à toutes les demandes de connexion automatiquement puisque s'il accepte cette connexion client -> serveur, il pourra dialoguer du serveur-> client.
Ton serveur sait qui a établi une connexion client -> serveur et sait donc à qui il peut répondre du serveur -> client.

ça fct dans l'autre sens aussi:
si tu limites les connexions sortantes de ta machine vers l'extérieur (internet), tu peux lui dire que si une connexion a été autorisée à sortir, alors la réponse est acceptée.

Un gd avantage aussi est le cas du ftp:
si tu te connectes sur un ftp sur internet, tu fais une demande de connexion sur le port 21 du serveur ftp. Ce serveur ftp va tenter de se connecter chez toi sur le port 20 (port ftp-data).
Avec ipchains, tu étais obligé d'accepter toute connexion sur ton port 20, donc n'importe qui savait s'y connecter (normalement il y a rien derrière mais bon y a moyen...)
Avec iptables, il sait que tu as fait une demande de connexion sur tel serveur ftp. Il n'autorisera en retour qu'une connexion de ce serveur ftp sur ton port 20. Si moi j'essaye je serai jeté comme un malpropre.

j'espère avoir été plus clair ;)
si ce n'est pas le cas n'hésite pas.
Le principe est le même que pour les firewalls windows je pense, mais à mon avis en plus perfectionné. Comme sous win tu travailles avec des logiciels qui font tout pour toi, tu ne sais peut-être pas spécifier exactement ce que tu veux (j'ai jamais testé de firewall sur cet os, donc je ne sais pas trop...) il parait que celui de winxp est assez puissant...
Sous Linux tu te crées tes propres règles toi même.

Groody

NetFilter, par rapport à IpTables ? C'est léditeur ? Ou un soft, j'ai pas suivi...

Citation :

- Une nouvelle notion fait son apparition : le "statefull", c'est a dire que si une connexion a été établie, tu peux considérer le dialogue sur cette connexion comme fiable (tu n'est pas obligé de faire une règle inverse de connexion ; ex: tu acceptes les connexion sur le port 80 de ton serveur, tu n'es plus obligé de gérer les réponses de ton serveur au client, une ligne suffit ).

Je pige pas trop là. On aurait pas pu faire une règle du port 80 vers l'IP de la connexion dans les deux sens ? (je redis que je ne connais RIEN au monde Linux pour l'insant, je me base sur mes connaissances sur les FW Wuinedause).

ethernal

pour la mise en fonction il faut obligatoirement un kernel 2.4.x, et l'activer en module dans le kernel ou compiler le kernel avec le support iptables.

oui, on doit changer les règles, puisque l'utilisation n'est pas la même.

mais tu peux très bien compiler ton kernel avec iptabes et ipchains en module, une fois un des modules chargés en mémoire, il rend impossible l'utilisation de l'autre module (il faut faire un rmmod avant). Donc tu peux avoir un fichier de règles iptables et un fichier de régles ipchains.

tenebrax

Techniquement quelles sont les différences entre Ipchains et Iptable au niveau de la mise en fonction ?
Doit on juste changer les règles dans le fichier où on les stocke ?

ethernal

ipchains ne sera plus supporté d'ici qq années
il a été je pense développé de façon plus modulaire : ipchains pour les connections de bases, ipfwadm pour le nat, des modules pour icq, ...

iptables suit le même principe saut qu'il intègre tout les modules d'origine (enfin ceux que l'équipe de netfilter jugent bon de développper (leur règle est "on développe un module pour tout les programmes qui ont au moins un serveur payant" ce qui veut dire qu'un module icq ne sera jamais développé par eux).
- Une nouvelle notion fait son apparition : le "statefull", c'est a dire que si une connexion a été établie, tu peux considérer le dialogue sur cette connexion comme fiable (tu n'est pas obligé de faire une règle inverse de connexion ; ex: tu acceptes les connexion sur le port 80 de ton serveur, tu n'es plus obligé de gérer les réponses de ton serveur au client, une ligne suffit ;) ).
- iptables gère aussi les quotas, le tri sélectif sur le contenu des paquets envoyés, etc ...
donc iptables est beaucoup plus puissant.

lebibi

je vais essayé de pas dire de connerie

ipchains : firewall dans kernel 2.2x (permet aussi de faire du routing)

iptables et netfilter c'est la même chose

version presente depuis les noyeaux 2.4x permet de faire les même chose que ipchains

Apres point de vue technique je ne sais pas trop, je me limite a iptables (truc de base quoi)

Si j'ai dit des conneries corrigés moi vite :)

Groody

salut,

Je suis avant le stade du débutant dans le monde Nux ;). Je l'ai déjà installer quelques fois pour tester, essayer les 2 commandes indiquées dans les mags, mais sans plus.

Je dois m'y mettre car va falloir que je sécurise l'accès au net au boulot, règles IP, etc..

Je me renseigne déjà sur ces outils.

Si j'ai bien compris, ils servent à appliquer des règles de "firewaling" ?

Mais quelles sont leurs avantages ? Inconvénients ? Différences ?
J'ai aussi cru lire que l'un d'entre eux était dépassé.

D'avance... Merci :jap:

Groody, De Soft&Réseau ;)