Tcpdump contourne-t-il iptables?
J'ai configuré par erreur un serveur DNS ouvert résolveur, qui a rapidement été utilisé pour de nombreuses attaques DDoS provenant de/vers la Russie. Pour cette raison, j'ai complètement bloqué le port 53 sur les deux serveurs DNS pour tout le monde, à l'exception des adresses IP de confiance. Cela fonctionne, je ne peux plus me connecter à eux, mais ce qui me semble bizarre, c’est que, lorsque je lance tcpdump sur eth1 (interface sur le serveur avec Internet public), je vois beaucoup de paquets entrants de l’attaquant au port 53.
Est-il normal que tcpdump affiche ces paquets même si iptables les supprime? Ou ai-je mal configuré iptables?
D'autre part, je ne vois aucun paquet sortant de mon serveur, ce que je faisais auparavant, alors je suppose que le pare-feu fonctionne en quelque sorte. Cela me surprend que le noyau ne laisse pas tomber les paquets entièrement? Ou bien tcpdump est-il connecté au noyau de manière à ce qu'il voie les paquets avant même qu'ils ne parviennent à iptables?
C'est une bonne question.
En fait, tcpdump est le premier logiciel trouvé après le fil (et la carte réseau, si vous voulez) sur le chemin DANS, et le dernier sur le chemin OUT.
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
Ainsi, tous les paquets atteignant votre interface et tous les paquets quittant votre interface sont visualisés. Comme les paquets sur le port 53 ne reçoivent pas de réponse, comme le montre tcpdump, vous avez vérifié que vos règles iptables ont été correctement configurées.
EDIT
Je devrais peut-être ajouter quelques détails. tcpdump est basé sur libpcap , une bibliothèque qui crée un socket de paquet . Lorsqu'un paquet ordinaire est reçu dans la pile réseau, le noyau commence par vérifier s'il existe une socket de paquet intéressée par le paquet nouvellement arrivé et, si il y en a un, il transfère le paquet à cette prise de paquet. Si l'option ETH_P_ALL est choisie, alors tous les protocoles passent par la prise de paquet.
libpcap implémente un de ces sockets avec l'option activée, conserve une copie pour son usage personnel et duplique le paquet dans la pile réseau, où il est traité par le noyau dans le processus. manière habituelle, y compris en le passant d’abord à netfilter , l’homologue espace-noyau de iptables . Même chose, dans l'ordre inverse (, c'est-à-dire , d'abord netfilter, puis dernier passage dans la socket), en sortie.
Est-ce que c'est sujet au piratage? Mais bien sûr. Il existe certainement des rootkits de preuve de concept utilisant libpcap pour intercepter les communications destinées au rootkit avant que le pare-feu ne parvienne à mettre la main dessus. leur. Mais même cela reste dérisoire par rapport au fait qu’une simple requête Google détache du code de travail masquant le trafic même de libpcap . Néanmoins, la plupart des professionnels pensent que les avantages du débogage des filtres de paquets réseau l'emportent largement sur les inconvénients.