null route

Le
Christophe PEREZ
Bonjour,

Dans l'intention de faire les choses plus proprement, je me suis mis à
(tenter de ?) nullrouter au lieu de droper les ip.

D'après ce que j'ai pu comprendre, faire :
/sbin/ip route add unreachable 5.9.112.0/27
devrait me "bloquer" la tranche qui m'interesse.
Pourtant, je continue à trouver dans mes logs des requetes d'adresses ip
de cette tranche, et je ne comprends pas pourquoi.
Un route -n fait bien apparaître :
5.9.112.0 - 255.255.255.224 ! 0 - 0 -

Je fais forcément mal, mais je ne sais pas trop quoi analyser puisque
forcément, je n'ai pas de log à consulter et que ça reste compliqué à
tester pour moi.

NB : je parle de cette tranche pour l'exemple, mais j'ai le même problème
sur d'autres.

Merci d'avance pour votre aide.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #25306572
Christophe PEREZ , dans le message écrit :
Pourtant, je continue à trouver dans mes logs des requetes d'adresses ip
de cette tranche, et je ne comprends pas pourquoi.



Quels logs précisément ?
Christophe PEREZ
Le #25309102
Le Wed, 27 Mar 2013 15:08:32 +0000, Nicolas George a écrit :

Quels logs précisément ?



ssh, apache, asterisk... probablement d'autres aussi. Mais cela a une
importance ?
Christophe PEREZ
Le #25309092
Le Fri, 29 Mar 2013 01:50:20 +0000, Christophe PEREZ a écrit :

Le Wed, 27 Mar 2013 15:08:32 +0000, Nicolas George a écrit :

Quels logs précisément ?



ssh, apache, asterisk... probablement d'autres aussi. Mais cela a une
importance ?



Ah ben tiens, un exemple concret. Avec shorewall, je "logdrop" la même
ip, et dans shorewall show dynamic, je vois cette ip "interceptée". J'en
déduis, peut-être à tort, que le null route n'a pas eu son effet...
Christophe PEREZ
Le #25309122
Ah ben tiens, un exemple concret.



Oui, bon, j'ai voulu répondre vite, et je n'ai sans doute pas été très
clair. Je vais tenter de faire mieux.
Je nullroute par :
/sbin/ip route add unreachable 37.8.0.0/16

en //, je bloque par shorewall (en fait, c'était fait avant que je ne
null route) :
shorewall logdrop 37.8.0.0/16

et après un moment, je constate dans "shorewall show dynamic" que
certains paquets sont "interceptés" par la règle iptable correspondante :
# shorewall show dynamic
Shorewall 4.5.11.2 Chain dynamic at serveur2 - jeu. mars 28 23:24:14 AST
2013

Counters reset sam. mars 23 10:39:41 AST 2013

Chain dynamic (12 references)
pkts bytes target prot opt in out source
destination
10 7709 logdrop all -- * * 37.8.0.0/16
0.0.0.0/0

Je vais aussi trouver des traces de cette ip dans mes logs asterisk, ou
apache, ou ssh (je n'ai pas d'exemple concret sous la main, mais c'est
par là que mon premier doute sur le nullroutage est venu).
Christophe PEREZ
Le #25312622
Le Fri, 29 Mar 2013 10:29:52 +0100, Pascal Hambourg a écrit :

D'après toi, s'il te le demande ?



D'après toi, si je demande ?

Ta "nullroute" a pour effet de rendre la destination injoignable,
c'est-à-dire d'empêcher la machine d'envoyer des paquets vers cette
plage d'adresses. Pas d'en recevoir depuis cette plage.



Ah ben forcément, vu que je n'avais pas compris ça, je ne pouvais déjà
pas en cerner les conséquences.

Il n'est donc
pas anormal que les logs d'iptables, ou d'Asterisk (la VoIP utilisant
généralement un transport UDP) montrent des paquets reçus avec une
adresse source dans cette plage [1].



Ok, clair.

En revanche, c'est un peu plus
étonnant pour un serveur SSH ou HTTP qui utilisent un transport TCP, car
l'établissement d'une connexion TCP nécessite l'envoi d'un paquet
SYN/ACK par le serveur au client en réponse au SYN initial, et la
réception d'un paquet ACK du client en réponse au SYN/ACK (3-way
handshake). Sauf erreur, c'est uniquement ensuite que le processus qui a
ouvert la socket en écoute est informé de la connexion entrante et peut
le logger. Or comme dit plus haut la réponse du serveur ne peut être
émise à cause de la nullroute, donc la connexion TCP ne peut s'établir.



Alors on va dire que c'est ma mémoire qui m'a fait défaut, et que les
traces que j'ai trouvées dans des logs apache ou autre du genre viennent
soit d'avant le nullroutage, soit n'ont aucun rapport. Bref, pour
l'instant, on oublie. Et si ça s'avère, j'y reviendrai.

[1] La nullroute peut toutefois agir sur les paquets reçus via
l'activation de la validation d'adresse source par "reverse path
filtering" (rp_filter). Si celle-ci est active pour l'interface
d'entrée, alors les paquets émis depuis une adresse non routable sont
jetés lors de la décision de routage (entre PREROUTING et INPUT ou
FORWARD).



Là, j'avoue, malgré plusieurs relectures, je ne comprends pas, ou du
moins, je dois manquer de bases pour comprendre le fond.

En conclusion, le nullroutage, pour mon serveur asterisk (par exemple),
il a quand même un intérêt ou aucun ?
Sinon, à part ou en plus du drop iptables/shorewall, y a t'il autre
chose ?
Christophe PEREZ
Le #25312692
Le Sat, 30 Mar 2013 20:31:32 +0000, Christophe PEREZ a écrit :

Là, j'avoue, malgré plusieurs relectures, je ne comprends pas, ou du
moins, je dois manquer de bases pour comprendre le fond.



Malgré tout, j'ai la sensation que la réponse à ma question pourrait bien
avoir un rapport étroit avec ça.

J'ai donc cherché un peu, et trouvé un paramètre global ROUTE_FILTER, ou
par interface "routefilter" qui semble correspondre.

# echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
# /etc/init.d/shorewall restart
* Stopping
firewall ...
[ ok ]
* Starting
firewall ...
[ ok ]
# cat /proc/sys/net/ipv4/conf/ppp0/rp_filter
1

C'est bien ça ?
Puis-je en déduire que maintenant que rp_filter est actif sur ppp0, les
adresses nullroutées du net seront automatiquement rejetées sans
"atteindre" mes applications, que ce soit TCP ou UDP ?
Si oui, ça serait super.
Christophe PEREZ
Le #25313272
Le Sun, 31 Mar 2013 13:10:51 +0200, Pascal Hambourg a écrit :

Puis-je en déduire que maintenant que rp_filter est actif sur ppp0, les
adresses nullroutées du net seront automatiquement rejetées sans
"atteindre" mes applications, que ce soit TCP ou UDP ?



Normalement oui.



Alors c'est parfait. Un grand merci pour tes explications.
Publicité
Poster une réponse
Anonyme