Hacker sin pasar por iptables

9

(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?

David Wylie
fuente
1
ESTABLISHEDdebería funcionar para UDP. Parece que el paquete fluye y acepta respuestas a solicitudes (salientes). ¿Sus "hackers" tienen IP estáticas? ;-) Si es así, marque / proc / net / nf_conntrack para ver qué contiene la tabla de estado sobre ellos cuando están actualmente / no / conectados ... RELATEDes algo más complicado ... No sé qué hace para SIP . ¿ modprobeQuizás muestra un módulo ipt_sip o algo cargado que haría cosas "mágicas"?
Marki
@ Marki: gracias por ese consejo. / proc / net / nf_conntrack no existe (centos 7), así que tendré que averiguar qué / por qué / dónde.
David Wylie
2
"conntrack-tools" es la cosa, instalable desde el repositorio, y luego ejecutar "conntrack -L" parece enumerarlos. Voy a ver qué produce eso. Típico, sin embargo, se detuvo. Ojalá solo una pausa.
David Wylie
1
Si es posible: trate de limitarse RELATEDa -p icmp. Tal vez esto lo resuelva (o es un trabajo adecuado que no requiere que usted lea sobre los ayudantes de conntrack).
cursi
1
Arruinaste las cosas agregando una cadena. Si las cadenas ACEPTAR se verifican antes de su ALLOWEDSIP personalizado, entonces ALLOWEDSIP puede ser inútil.
Overmind

Respuestas:

1

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
asdmin
fuente
-2

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
remoteitguy
fuente
Quiere parchear el agujero contra cualquier nuevo atacante, no solo bloquear este.
Zdenek