>>ton CPU sera content :-)
>Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
bon ben ton temps de ping a UT alors :-)
non j'admet completement l'argument martelage et regles independantes meme si cela finit par faire des scripts un peu "lourds".
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même
humm ok.
argument accepté mais tout de meme tordu amha :-))
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing. Et l'antispoofing tu peux l'ecrire de 2 facons: soit tu rejette tout ce qui ne t'es pas destiné (ne fontionne que pour les acces particuliers avec une seule adresse IP a-tout-faire). Soit tu rejette tous les reseaux RFC1918, y compris et surtout ceux que tu utilises en interne (et ca c'est une invariante, donc independant de l'IP de ta machine, qui fontionne meme en entreprise).
Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P"
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 3.
>Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
bon ben ton temps de ping a UT alors :-)
non j'admet completement l'argument martelage et regles independantes meme si cela finit par faire des scripts un peu "lourds".
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même
humm ok.
argument accepté mais tout de meme tordu amha :-))
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing. Et l'antispoofing tu peux l'ecrire de 2 facons: soit tu rejette tout ce qui ne t'es pas destiné (ne fontionne que pour les acces particuliers avec une seule adresse IP a-tout-faire). Soit tu rejette tous les reseaux RFC1918, y compris et surtout ceux que tu utilises en interne (et ca c'est une invariante, donc independant de l'IP de ta machine, qui fontionne meme en entreprise).
Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P"
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.