Haker omija iptables

(przeniesiony z SO)

Mam iptables chroniące serwer SIP. Blokuje wszystkie adresy IP oprócz tych, które specjalnie otworzyłem, i wydaje się, że działa dla prawie wszystkich. Testowałem z wielu adresów IP, które nie są na białej liście i wszystkie są upuszczane tak, jak powinny.

ALE, wybrałem „hakera”, który wydaje się być w stanie ominąć reguły iptables. Jego sondujące ZAPROSZENIA przeszły, a ja nie mam pojęcia, jak to było, ani że było to możliwe. Przez 10 lat nie widziałem tego wcześniej.

Przypuszczam, że to coś, co zrobiłem, ale nie widzę tego.

iptables utworzone w ten sposób (MYIP zdefiniowane u góry - zredagowane):

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

Teraz, mając NIC W ZEZWOLENIU POMOCY, wszystko, co powinienem móc zrobić, to SSH w (w którym mogę). Jeśli rzucę na nią połączenia, wszystkie zostaną odrzucone. Ale Wireshark pokazuje mi to (zredagowany adres IP):

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 |

Jego wezwania trafiły na moją zmianę i chociaż ostatecznie zostały odrzucone przez ACL, nigdy nie powinny tam dotrzeć. Nic innego się nie przedostaje. Wyciągam włosy. Ktoś wie?

Dla kompletności, oto wynik 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

EDYCJA: właśnie widziałem to z wireshark. Czy mogliby robić coś tak okropnego, jak osiedlenie się w inny sposób niż granie według ustalonej zasady? Może grają na jakimś dołku w PODOBNYM?

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

EDYCJA 2: Kluczem jest tutaj UDP. Gdy ustawiam OpenSIPS tak, aby nasłuchiwał tylko TCP, problem wydaje się znikać. Żadna z ich prób już się nie udaje, chociaż wysyłają więcej takich wiadomości „tag-pm”. Nie wyjaśnia jednak, dlaczego pakiety docierają nawet do openipsa. iptables powinien je najpierw zatrzymać. Chciałbym wiedzieć, co zrobiłem tutaj źle.

EDYCJA 3: Jeśli usunę POWIĄZANE, przestanę na nie odpowiadać, więc ma to coś wspólnego z tym. Ale myślę, że potrzebuję pokrewnych. Wszelkie wskazówki dotyczące obejścia?

Jedynym możliwym wytłumaczeniem tego, jak mogłoby to działać, jest to, że obrażające datagramy UDP jakoś mijały --state ESTABLISHED,RELATED.

Biorąc pod uwagę, że UDP jest protokołem bezstanowym, wątpię, aby statemoduł skutecznie go śledził.

Aby rozwiązać problem, ograniczę sprawdzanie stanu do protokołu TCP przez:

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

I wstępnie filtruj za ALLOWEDSIPpomocą protokołu UDP (a najlepiej także portu docelowego):

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

Możesz nullroute. To powinno ominąć iptables.

route add 89.163.146.25 gw 127.0.0.1 lo

Sprawdź to

netstat -nr

LUB

route -n