☰

Die iptables-Regel funktioniert nicht mit AWS NLB und Elastic IP, funktioniert aber mit der öffentlichen IP der EC2-Instanz

tag-icon • tag-icon amazon-web-services amazon-ec2 iptables firewall amazon-elb
Die iptables-Regel funktioniert nicht mit AWS NLB und Elastic IP, funktioniert aber mit der öffentlichen IP der EC2-Instanz

Ich bin ein wenig ratlos.

Zunächst etwas Kontext: Ich habe eine AWS EC2-Instanz hinter einem NLB. Der NLB verwendet eine elastische IP. Die EC2-Instanz betreibt einen DNS-Server und überwacht UDP und TCP 53. Der NLB ist für TCP- und UDP-Port 53 eingerichtet. Die Instanz befindet sich in einer Zielgruppe und ist in den Augen des NLB in Ordnung (und bedient Anfragen wie erwartet).

Problem, das ich zu lösen versuche: Ich möchte sicherstellen, dass ich alle DNS-Abfragen für den Datensatztyp ANY(sowie einige andere Regeln zur Ratenbegrenzung und Filterung) lösche. Daher habe ich die folgenden iptablesRegeln hinzugefügt:

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 40 -j DROP

$ iptables -t raw -I PREROUTING -p tcp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 52 -j DROP

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 40 -j LOG \
    --log-prefix "BLOCKED ANY: "

$ iptables -t raw -I PREROUTING -p tcp --dport 53 -m string \
    --hex-string "|0000FF0001|" --algo bm --from 52 -j LOG \
    --log-prefix "BLOCKED ANY: "

Und nun zum Problem...

Wenn ich es versuche, dig some.domain -t any @public.ip.of.instancewird meine Abfrage blockiert und ich sehe den Protokolleintrag /var/log/kern.logwie erwartet.

Wenn ich es versuche, dig some.domain -t any @elastic.ip.on.nlbwird die Anfrage nicht blockiert und ich erhalte eine Antwort. Kein Protokolleintrag in kern.log.

Das Seltsamste für mich ist, dass ich versucht habe, den NLB aus dem Bild zu nehmen und der Instanz direkt dieselbe Elastic IP zuzuweisen. Dasselbe Ergebnis – die ANYan gesendete Abfrage EIPwird nicht gelöscht, auch wenn die oben genannten iptablesRegeln gelten. Dieselbe ANYAbfrage, die von einer anderen Instanz unter Verwendung der privaten IP anstelle der EIPgesendet wird, wird wie erwartet gelöscht.

natIch habe die gleichen Regeln in den Tabellen (auch mit der PREROUTINGKette) und filter(mit der Kette) ausprobiert INPUT. Übersehe ich in meinen iptablesRegeln etwas Offensichtliches?

Irgendwelche anderen Ideen?

Antwort1

Beim Durchsehen von ServerFault habe ich diese Antwort gefunden -iptables verwirft Paket durch Hex-String-Übereinstimmungbei dem zwischen den Hex-Werten Leerzeichen angezeigt werden, würde ich Folgendes versuchen:

Beispiel aus dieser Frage:

$ iptables --append INPUT --match string --algo kmp \
    --hex-string '|f4 6d 04 25 b2 02 00 0a|' --jump ACCEPT

Ändern Sie Ihre Beispiele also wie folgt:

$ iptables -t raw -I PREROUTING -p udp --dport 53 -m string \
    --hex-string "|00 00 FF 00 01|" --algo bm --from 40 -j DROP

Antwort2

Okay, danachvieleNach stundenlanger Fehlersuche scheint die kurze Antwort zu sein, dass es die ganze Zeit funktioniert hat ...

Ich habe tcpdump auf der EC2-Instanz hinter dem NLB ( tcpdump udp port 53 -X -nn) ausgeführt. Dann habe ich es von meinem Macbook (Catalina 10.15.2) aus ausgeführt dig some.domain -t any @elastic.ip.on.nlbund nicht nur eine Antwort erhalten, sondern die Abfrage wurde nicht einmal in der Paketerfassung auf der EC2-Instanz angezeigt. Es gibt nur eine EC2-Instanz hinter dem NLB, die die Elastic IP verwendet, die ich in der Dig-Abfrage verwendet habe. Völlig verwundert habe ich dann denselben Dig-Befehl auf einer Ubuntu-Maschine und auch auf einem Windows 10-Computer ausgeführt. Bei beiden Abfragen ist eine Zeitüberschreitung aufgetreten (sie wurden von iptables richtig gefiltert), ich habe sie im tcpdump gesehen und die Protokollnachricht war wie erwartet in /var/log/kern.log. Ich gehe zurück zu meinem Macbook, führe denselben Dig-Befehl aus und es gibt immer noch eine Antwort zurück und nichts im tcpdump ... was zur Hölle!

Ich habe mein Macbook neugestartet, zum millionsten Mal überprüft, ob ich die richtigen IPs und dieselbe Abfrage verwende, verschiedene Domänen ausprobiert und wahrscheinlich hundert andere Dinge. Ich bin völlig ratlos, warum dies scheinbar eine Antwort zurückgibt, obwohl die Paketerfassung von meinem Macbook nichts enthält.

Letztendlich scheint es sich also um ein seltsam isoliertes Problem zu handeln (vielleicht ist da irgendein Apple-Defekt im Spiel...) und nicht um eine seltsame Paketmanipulation durch AWS oder eine gebrochene iptables-Regel, wie ich zunächst dachte. Die richtige Antwort lautet also: Probieren Sie es auf mehreren Rechnern aus, bevor Sie es auf StackExchange posten.

EDIT: Zur Klarstellung. Ich sehe die Abfrage in tcpdump von meinem Macbook (und sie läuft wie erwartet ab), wenn ich die öffentliche IP der Instanz und nicht die EIP verwende. Nur mit der EIP sehe ich die Abfrage nicht und sie gibt eine Antwort zurück ...

Außerdem bin ich mir nicht sicher, ob dies ein Antwortbeitrag sein sollte oder ob ich einfach meinen ursprünglichen Beitrag hätte ändern sollen. Mods, macht damit, was ihr wollt!

verwandte Informationen