Hacker umgeht iptables

(von SO verschoben)

Ich habe Iptables, die einen SIP-Server schützen. Es blockiert alle IPs außer denen, die ich speziell geöffnet habe, und es scheint für fast alle zu funktionieren. Ich habe viele IP-Adressen getestet, die nicht auf der weißen Liste stehen, und sie werden alle gelöscht, wie sie sollten.

ABER ich habe einen "Hacker" gefunden, der in der Lage zu sein scheint, die iptables-Regeln zu umgehen. Seine Sondierungseinladungen schaffen es durch, und ich habe keine Ahnung, wie oder dass es überhaupt möglich war. In 10 Jahren habe ich das noch nie gesehen.

Ich nehme an, es muss etwas sein, was ich getan habe, aber ich kann es nicht sehen.

Auf diese Weise erstellte iptables (MYIP oben definiert - redigiert):

iptables -F
iptables -X
iptables -N ALLOWEDSIP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -d $MYIP --dport 22 -j ACCEPT
iptables -t filter -A INPUT -j ALLOWEDSIP

# This is my white list.
iptables -A ALLOWEDSIP -j RETURN

Jetzt, mit NICHTS im ALLOWEDSIP, sollte ich nur noch SSH in (was ich kann) tun können. Wenn ich es anrufe, werden sie alle fallen gelassen. Aber wireshark zeigt mir das (meine IP redigiert):

89.163.146.25 -> x.x.x.x SIP/SDP 805 Request: INVITE sip:521088972597572280@x.x.x.x |
x.x.x.x -> 89.163.146.25 SIP 417 Status: 100 Giving a try |
x.x.x.x -> 89.163.146.25 SIP 875 Status: 407 Proxy Authentication Required |

Seine Anrufe trafen meinen Schalter und obwohl sie letztendlich von der ACL abgelehnt wurden, sollten sie niemals dort ankommen. Sonst kommt nichts durch. Ich ziehe mir die Haare aus. Weiß jemand?

Der Vollständigkeit halber hier das Ergebnis von iptables -L:

# iptables -L --line-numbers -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       10   640 ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
2        0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
3        0     0 ACCEPT     tcp  --  any    any     anywhere             <redacted>.com  tcp dpt:6928
4        0     0 ALLOWEDSIP  all  --  any    any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6 packets, 544 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain ALLOWEDSIP (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RETURN     all  --  any    any     anywhere             anywhere

EDIT: gerade gesehen von Wireshark. Könnten sie etwas Schreckliches tun, als sich auf andere Weise zu etablieren, als nach der etablierten Regel zu spielen? Vielleicht spielen sie auf einem Loch in RELATED?

89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm  Destination port: sip

EDIT 2: UDP ist hier der Schlüssel. Wenn ich OpenSIPS so einstelle, dass nur auf TCP gewartet wird, scheint das Problem zu verschwinden. Keiner ihrer Versuche kommt mehr durch, obwohl sie mehr dieser "Tag-PM" -Nachrichten senden. Erklärt nicht, warum die Pakete überhaupt zu OpenSips gelangen. iptables sollten sie zuerst gestoppt haben. Würde gerne wissen, was ich hier falsch gemacht habe.

EDIT 3: Wenn ich RELATED entferne, höre ich auf, auf sie zu antworten, also hat das etwas damit zu tun. Aber ich denke ich brauche verwandte. Irgendwelche Tipps zur Problemumgehung?

— David Wylie
quelle

ESTABLISHEDsollte für UDP funktionieren. Es sieht so aus, als ob der Paketfluss und Antworten auf (ausgehende) Anforderungen akzeptiert. Haben Ihre "Hacker" statische IPs? ;-) Wenn ja, überprüfen Sie / proc / net / nf_conntrack, um zu sehen, was die Statustabelle über sie enthält, wenn sie aktuell / nicht / verbunden sind ... RELATEDist eine schwierigere Sache ... Ich weiß nicht, was es für SIP tut . Zeigt modprobevielleicht ein ipt_sip-Modul oder etwas Geladenes, das "magische" Dinge tun würde?

— Marki

@ Marki - danke für diesen Tipp. / proc / net / nf_conntrack existiert nicht (Centos 7), also muss ich herausfinden, was / warum / wo.

— David Wylie

"conntrack-tools" ist das Ding, das vom Repo installiert werden kann, dann scheint das Ausführen von "conntrack -L" sie aufzulisten. Ich werde sehen, was das bringt. Typisch ist jedoch, dass er aufgehört hat. Hoffentlich nur eine Pause.

— David Wylie

Wenn möglich: Versuchen Sie zu begrenzen , RELATEDzu -p icmp. Vielleicht löst dies das Problem (oder ist eine geeignete Lösung, bei der Sie nicht über Conntrack-Helfer lesen müssen).

— kitschig

Sie haben die Dinge durcheinander gebracht, indem Sie eine Kette hinzugefügt haben. Wenn ACCEPT-Ketten vor Ihrem benutzerdefinierten ALLOWEDSIP überprüft werden, kann ALLOWEDSIP unbrauchbar sein.

— Overmind

Die einzige plausible Erklärung, wie es funktionieren könnte, ist, dass die fehlerhaften UDP-Datagramme irgendwie passieren --state ESTABLISHED,RELATED.

Angesichts der Tatsache, dass UDP ein zustandsloses Protokoll ist, bezweifle ich, dass das stateModul eine effektive Nachverfolgung aufweist.

Um das Problem zu beheben, beschränke ich die Statusprüfung auf das TCP-Protokoll durch:

-A INPUT -m tcp -m state -p tcp --state ESTABLISHED,RELATED -j ACCEPT`

Und Vorfilterung ALLOWEDSIPmit UDP-Protokoll (und vorzugsweise auch mit dem Zielport):

iptables -t filter -A INPUT -m udp -p udp --dport 5060 -j ALLOWEDSIP

— asdmin
quelle

-2

Sie könnten nullroute. Dies sollte iptables umgehen.

route add 89.163.146.25 gw 127.0.0.1 lo

prüfen Sie

netstat -nr

ODER

route -n

— remoteitguy
quelle

Er möchte das Loch gegen jeden neuen Angreifer flicken und nicht nur diesen blockieren.

— Zdenek