(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: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 |
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?
RELATEDdo -p icmp. Może to rozwiązuje problem (lub jest odpowiednią pracą, która nie wymaga od ciebie czytania o pomocnikach conntrack).
ESTABLISHEDpowinien działać dla UDP. Wygląda na to, że pakiet przepływa i akceptuje odpowiedzi na (wychodzące) żądania. Czy twoi „hakerzy” mają statyczne adresy IP? ;-) Jeśli tak, sprawdź / proc / net / nf_conntrack, aby zobaczyć, co zawiera tabela stanu na ich temat, gdy są aktualnie / nie / połączeni ...RELATEDto trudniejsza sprawa ... Nie wiem, co robi dla SIP . Czymodprobemoże pokazuje moduł ipt_sip lub coś załadowanego, co zrobiłoby „magiczne” rzeczy?