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.
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 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...
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...
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
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).
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).
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 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 ?
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 ?
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 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.
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.
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.
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.
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 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.
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.
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.
