Hacker sin pasar por iptables

(movido de SO)

Tengo iptables protegiendo un servidor sip. Bloquea todas las IP, excepto las que abrí específicamente, y parece funcionar para casi todos. He probado de muchas direcciones IP que no están en la lista blanca y todas se descartaron como deberían.

PERO, he recogido a un "hacker" que parece capaz de eludir las reglas de iptables. Sus sondeos INVITES lo logran, y no tengo idea de cómo, o de que incluso fue posible. En 10 años no he visto esto antes.

Supongo que debe ser algo que he hecho, pero no puedo verlo.

iptables creados de esta manera (MYIP definido en la parte superior - redactado):

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

Ahora, con NADA en el ALLOWEDSIP, todo lo que debería poder hacer es SSH (que puedo). Si lanzo llamadas, todos se caen. Pero wireshark me muestra esto (mi IP fue eliminada):

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 |

Sus llamadas golpearon mi interruptor y, aunque finalmente fueron rechazadas por la ACL, nunca deberían llegar allí. Nada más pasa. Sacando mi cabello. ¿Nadie sabe?

Solo para completar, aquí está el resultado de 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

EDITAR: acabo de ver esto desde cables ¿Podrían estar haciendo algo horrible como establecerse de otra manera y luego jugar con la regla establecida? Tal vez están jugando en algún hoyo en RELACIONADO

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

EDIT 2: UDP es la clave aquí. Cuando configuro OpenSIPS para que solo escuche TCP, el problema parece desaparecer. Ninguno de sus intentos ha llegado a su fin, aunque están enviando más de esos mensajes "tag-pm". Sin embargo, no explica por qué los paquetes incluso están llegando a losips abiertos. iptables debería haberlos detenido primero. Me encantaría saber qué he hecho mal aquí.

EDITAR 3: si elimino RELACIONADO, dejo de responderles, así que es algo que tiene que ver con eso. Pero creo que necesito relacionados. ¿Algún consejo sobre soluciones alternativas?

La única explicación plausible de cómo podría funcionar es que los datagramas UDP ofensivos de alguna manera pasan --state ESTABLISHED,RELATED.

Dado que UDP es un protocolo sin estado, dudo que el statemódulo tenga un seguimiento efectivo sobre él.

Para solucionar el problema, limitaría la verificación de estado al protocolo TCP por:

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

Y prefiltre ALLOWEDSIPcon el protocolo UDP (y preferiblemente, también con el puerto de destino):

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

Podrías anular el camino. Esto debería omitir iptables.

route add 89.163.146.25 gw 127.0.0.1 lo

Revisalo

netstat -nr

O

route -n