Faux positif de mon firewall ?

Support Debian
#1

Bonjour

Mon ordi principal tourne en Debian Squeeze (amd64), et j’ai installé sur mon Iceweasel (Firefox) le plugin NoScript permettant de gérer explicitement l’exécution de JavaScript durant la navigation sur le vaste Oueb : noscript.net ; d’abord : ai-je eu raison de l’installer ?

Aujourd’hui, je lance Iceweasel, qui se souvient qu’une MàJ de ce plugin est disponible. J’accepte de la télécharger, et Iceweasel se lance ensuite avec automatiquement un onglet supplémentaire ouvert sur la page du site NoScript décrivant les nouveautés de la MàJ ; je ferme cet onglet avant même qu’il ne soit complètement chargé, et là mon firewall FireStarter m’annonce un « hit » dont voici le descriptif tel qu’enregistré :Time:Jul 4 13:17:46 Direction: Inconnu In:eth1 Out: Port:80 Source:noscript.net Destination:192.168.1.3 Length:68 TOS:0x00 Protocol:ICMP Service:HTTPInstinctivement, je pencherais pour un faux positif lié au fait que cette fois j’ai fermé l’onglet vraiment très vite, alors que d’autres onglets se chargeaient (j’ouvre mon navigateur avec deux ou trois pages gardées en mémoire de la fois précédente) d’une part, et d’autre part au fait que FireStarter est, autant que j’ai pu l’apprendre, parfois un peu inutilement chatouilleux.

À votre avis ?

Pour rappel :Linux 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

#2

Mon avis, qui, je le crains, ne va pas beaucoup t’aider, est que l’information fournie par firestarter est particulièrement confuse et incomplète.

  • Port:80 -> port source ou destination ?

  • Source:noscript.net -> on ne voit que le reverse DNS (ou pire, une partie du reverse) de l’adresse IP source et non l’adresse IP source elle-même, alors qu’il est facile de falsifier un reverse DNS.

  • Protocol:ICMP Service:HTTP -> faudrait savoir ! si le protocole est ICMP alors ça ne peut pas être HTTP qui est transporté sur TCP, et il n’y a pas de ports ; en revanche il devrait y avoir un type et un code ICMP.

Je peux supposer qu’il s’agit d’un paquet ICMP avec un type d’erreur (ex: destination unreachable) émis en réponse à un paquet TCP d’une connexion HTTP. Mais il manque des informations autant sur le paquet ICMP que sur le paquet originel pour savoir exactement à quoi il correspond. Il vaudrait mieux regarder directement dans les logs des règles iptables.

#3

OK, je vais aussi en rester là, de toutes façons ça date déjà et retrouver ça dans les logs iptables est en théorie possible, en pratique dissuasif.

EDIT : mon modem-routeur (acheté avant que les FAI n’imposent leur *box respectives) est peut-être en fin de carrière, car j’ai cru remarquer que ce genre de phénomène se réduit (voire disparaît) lorsque je le débranche électriquement quelques minutes … à croire que que sa RAM sature, et qu’il n’arrive plus a gérer correctement.

#4

l’icmp est a bloquer/desactiver , c’est conseiller un peu partout ;p

#5

Bloquer l’ICMP echo request est une pratique détestable :slightly_smiling:

Parcqu’empêcher le debug, c’est génial …

#6

N’importe quoi. Certains types ICMP sont utiles, voire indispensables au bon fonctionnement du protocole IP et des protocoles de niveau supérieur. Si tu passes en IPv6, amuse-toi à bloquer tout l’ICMPv6 et tu m’en diras des nouvelles.

Seuls ceux qui n’y connaissent rien peuvent conseiller cela. Je veux bien croire qu’il y en a un peu partout.

[quote=“haleth”]Bloquer l’ICMP echo request est une pratique détestable
Parce qu’empêcher le debug, c’est génial[/quote]
D’un autre côté, le ping peut être utilisé pour causer un déni de service (exemple : saturation de la voie montante d’une ligne ADSL). C’est pourquoi je limite le taux de réponses au ping sur mon routeur.

#7

rhooo le pascal , tutti venerr :laughing:

[quote]Pour les ICMP, tout doit être bloqué, sauf :

Pour les ICMP entrants : Echo reply, Destination Unreachable, Time Exceeded
Pour les ICMP sortants : Echo[/quote]

wiki.backtrack-fr.net/index.php/ … _Entrantes

openmaniak.com/fr/ping.php

[quote=“PascalHambourg”]
D’un autre côté, le ping peut être utilisé pour causer un déni de service (exemple : saturation de la voie montante d’une ligne ADSL). C’est pourquoi je limite le taux de réponses au ping sur mon routeur.[/quote]

je parlais effectivement de cela ;p

fais chaud hein t-day ;p

#8

[quote=“Grhim”]Pour les ICMP, tout doit être bloqué, sauf :
Pour les ICMP entrants : Echo reply, Destination Unreachable, Time Exceeded[/quote]
J’aime mieux ça. C’est nettement différent de “l’icmp est a bloquer/desactiver”.
On peut y ajouter le type “Parameter Problem” (bien que je ne me rappelle pas en avoir jamais vu) et, selon la situation, le type “Redirect”.
A noter que ces paquets, lorsqu’ils sont reçus en réponse à un paquet émis (et vice versa), sont dans l’état ESTALBLISHED pour le premier type et RELATED pour les autres. On n’a donc pas besoin de règles spécifique pour les accepter si on a la règle générale classique qui autorise les paquets dans ces deux états.

Mais non, réfléchis deux secondes.
Si on autorise les types précédents en entrée, il faut bien aussi les autoriser en sortie. Sinon, si tout le monde fait pareil, alors personne ne pourrait les recevoir s’ils sont bloqués à l’émission.

Ah, où ça ?

#9

:whistle:

si je veux faire chier le monde en bloquant les “standards de fait” c’est mon probleme et chacuns est libre de le faire …ou pas

et le type 5 ? bon tu me diras si c’est pour un ordi perso …

let’s smurf w/ wu-tang

#10

Chacun est maître chez soi. Mais de là à le conseiller aux autres, il y a de la marge.

A condition que ce soit en connaissance des tenants et aboutissants et pas sur la foi d’un “conseil” non argumenté asséné sur un site ou un forum.

Le type 5, c’est le “Redirect” que j’ai évoqué plus haut. C’est un peu compliqué. Provenant d’internet ou de l’extérieur de son propre réseau, il faut le bloquer ou l’ignorer, évidemment. En revanche provenant de ses propres routeurs, si on a du routage bizarre ça peut éviter les sauts inutiles.

Exemple : un serveur de VPN qui n’est pas la passerelle par défaut pour le LAN, les postes du LAN envoient les paquets à destination du VPN à la passerelle par défaut qui renvoie vers le serveur VPN. Si la passerelle renvoie un ICMP Redirect et le poste l’accepte, alors il enverra les prochains paquets directement au serveur VPN. C’est quand même assez marginal.

Il y a d’autres cas où il faut au contraire ne pas envoyer les paquets directement (exemple : la première passerelle fait du NAT), donc il faut bloquer les ICMP Redirect (à la source de préférence).

#11

En fait je laisse passer tout ICMP dans l’espoir que quelqu’un me fasse un DOS. Je pourrais alors dire que mon site est dérangeant/rebelle/subversif/génant (aux choix) au point qu’on le censure… Ce serait la gloire!

Sérieusement, je sais qu’on n’est pas chez les bisounours, mais pour un site d’un particulier le DOS est tout de même peut probable.

#12 
#!/bin/sh

# script /etc/firewall.sh

# Firewall d'exemple a but pédagogique
# Arnaud de Bermingham
# duracell@apinc.org

# Activation du forwarding
# C'est pas pour faire joli, on aura des règles
# de forward et il faut bien que les paquets
# traversent la machine, donc on met ce fichier à 1

echo 1 > /proc/sys/net/ipv4/ip_forward

# Alors la, on va appliquer quelques astuces
# pour empêcher les attaques de type spoofing
# et bloquer les réponses ICMP du firewall,
# comme ça c'est très propre. Attention, le
# fait de bloquer le trafic ICMP sur
# le firewall bloque les pings.

# Je veux pas de spoofing

if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

# pas de icmp

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

lea-linux.org/documentations/Res … u-iptables

…

#13

Super

Tu sais que 97% des virus utilisent le protocole IP ?

En conséquence, je pense que drop les paquets IP est une excellente sécurité.

#14

[quote=“haleth”]Super

Tu sais que 97% des virus utilisent le protocole IP ?

En conséquence, je pense que drop les paquets IP est une excellente sécurité.[/quote]

et les 3 % restant ? :wink:

#15

Arp

#16

Grhim : Ce n’est pas ce que j’appelle argumenté. Et il y a des imprécisions (pour ne pas dire des erreurs) : spoofing, ICMP.

#17

:smiley:

je fais un peu le tour des wiki pour voir ou en sont les references de nos jours , afin de voir ceux qui sont le plus accessible pour les nouveaux avec iptables , certe lea linux n’est plus vraiment d’actualité (2001) je ne sais pas si tu as ete verifié la page …

j’aime beaucoup celui de archlinux, notre wiki debian et debian.net ,beaucoup d’hummour chez lea je pense que c’est un pluss…

#18

Salut,
@pascalHambourg, quelles seraient des règles “raisonnables” pour se protéger un peu ?

J’utilise ceci dans mes scripts, pour éviter (je crois) de me faire “flooder” avec des pings.
Je t’avouerais que je pense que ça n’a jamais servi à rien…

$IPTABLES -t filter -A INPUT -p icmp -j LOG $IPTABLES -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/second -j ACCEPT $IPTABLES -A INPUT -p icmp -j DROP

Ou est-ce que, finalement, il suffit de ne pas avoir de services inutiles sur son serveur, et de “droper” le reste + un bon vieux fail2ban pour se débarrasser des tentatives des bots & lourdauds ?

#19

ha j’ai trouver ceci en tuto basic youtube.com/watch?v=7pG76XmOUDI

#20

Pourquoi moi ? Les autres n’ont pas le droit de répondre ?

Protéger quoi contre quoi ? Il n’y a pas de réponse universelle, chaque situation est un cas particulier. C’est notamment pourquoi je n’utilise pas les pare-feux (réforme de l’orthographe de 1990, on accorde au pluriel…) “généralistes” et préfère écrire mes propres scripts adaptés à chaque situation.

Déjà, la règle LOG est idéale pour se faire flooder les logs. J’ai sûrement déjà évoqué la fois où un scan basique même pas méchant avec nmap avait mis à genoux une machine sous Windows juste parce que son pare-feu (sais plus lequel) loggait si abondamment tout ce qui passait qu’il avait fini par saturer l’espace disque.

Ensuite, un rappel de bon sens : on a (normalement) la maîtrise de ce qu’on envoie, pas de ce qu’on reçoit. Corollaire : aucune règle iptables ne peut “éviter de se faire flooder”. La conséquence la plus grave du flood, c’est la saturation de la voie descendante, et il n’y a qu’en amont qu’on peut agir là-dessus. Sur la machine victime, on peut au mieux limiter les conséquences du flood. En règle générale, tout ce qu’on peut faire c’est de limiter l’impact du flood sur la consommation des ressources de la machine. Ici ta règle limite la quantité de paquets qui vont être traités, et donc la quantité de réponses qui vont être émises. C’est utile pour éviter d’une part de saturer soi-même sa voie montante, et d’autre part de flooder à son tour de pauvres machines innocentes si les adresses sources du flood sont usurpées.

C’est la base.

C’est une bonne chose, mais cela n’intervient qu’en deuxième ligne de défense. Les paquets arrivant sur des ports sur lesquels aucun processus local n’écoute ne sont pas dangereux par eux-même, et normalement les applications qui tournent sur la machine n’envoient que du trafic autorisé. Le blocage du trafic non autorisé ne sert donc que s’il y a du trafic non autorisé depuis ou vers un processus local compromis ou qui ne fonctionne pas comme prévu.

Là encore, ce n’est qu’une deuxième ligne de défense qui sert surtout à moins polluer les logs. L’important est d’avoir des services solides par eux-mêmes, sans faille connue donc à jour et bien configurés qui n’ont normalement rien à craindre d’attaques par force brute.