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:[email protected] |
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?

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

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