La solicitud SIP UDP se abre paso a través de iptables

Navega tus respuestas
7

Recientemente he estado investigando algunos casos en los que el tráfico SIP UDP ha estado evadiendo el conjunto de reglas definido en iptables, lo que me lleva a sospechar que hay un agujero en nuestras reglas, así que estoy buscando consejos sobre cómo reforzar las defensas en el sistema local Tenemos un servidor de seguridad delante de este servidor que podría mejorarse, sin embargo, parece importante que se comprenda este problema antes de ver medidas adicionales, ya que esta pregunta se relaciona directamente con las defensas del servidor local, específicamente iptables.

Los paquetes SIP están empezando a incluir intentos de inyección de SQL y me preocupa que, sin ser dirigido directamente, la aplicación pueda verse comprometida. En la actualidad, el "llamante" logra establecer una llamada que simplemente reproduce nuestro anuncio de no servicio para que se inicie una conversación SIP con el servidor local, ¡no es lo ideal!

He copiado los detalles a continuación con un esquema de redacción consistente, sin embargo, si se requiere información adicional, comente a continuación y lo pondré.

Aprecio cualquier consejo, ¡gracias por echar un vistazo!

IP DE ORIGEN: 185.107.83.35 IP DEL SERVIDOR SIP: 200.200.114.207

Comenzaré con un ejemplo del paquete SIP ofensivo: 

INVITE sip:00*[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 185.107.83.35:5060;branch=z9hG4bK-524287-1---i9aif7pifkudxkd8
Max-Forwards: 70
Contact: <sip:...hi'or...x...='x';@185.107.83.35:5060;transport=UDP>
To: <sip:00*[email protected];transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16
Call-ID: LztInRxh5KJSOAGxCOGB0T..
CSeq: 1 INVITE
Content-Type: application/sdp
User-Agent: Avaya one-X Deskphone
Allow-Events: presence, kpml, talk
Content-Length: 515

v=0
o=Avaya 0 0 IN IP4 185.107.83.35
s=Avaya
c=IN IP4 185.107.83.35
t=0 0
m=audio 8000 RTP/AVP 18 3 110 8 0 97 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:98 AMR/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 SPEEX/8000
a=rtpmap:99 AMR-WB/16000
a=rtpmap:102 SPEEX/16000
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:105 opus/48000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Configuración de IP en el host: 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.20/24 brd 255.255.255.255 scope global em1
    inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
       valid_lft forever preferred_lft forever
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:7f brd ff:ff:ff:ff:ff:ff
    inet 200.200.114.207/26 brd 200.200.114.255 scope global em2
    inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
       valid_lft forever preferred_lft forever
4: em3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:11:22:33:44:81 brd ff:ff:ff:ff:ff:ff
5: em4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:11:22:33:44:83 brd ff:ff:ff:ff:ff:ff

Aquí está la salida de iptables -v -n --list 

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
4769K  538M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           /* 000 accept all icmp */
 645M  276G ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           /* 001 accept all to lo interface */
  11G 2946G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 002 accept related established rules */ state RELATED,ESTABLISHED
4036K  238M ACCEPT     tcp  --  em1    *       0.0.0.0/0            0.0.0.0/0           multiport ports 22 /* 101 accept SSH from internal interface */
36907 2036K ACCEPT     all  --  em1    *       192.168.4.0/24       0.0.0.0/0           /* 102 accept all traffic from site 1 LAN */
 160K 6397K ACCEPT     all  --  em1    *       192.168.5.0/24       0.0.0.0/0           /* 103 accept all traffic from site 1 LAN */
8651K  527M ACCEPT     all  --  em1    *       192.168.20.0/24      0.0.0.0/0           /* 105 accept all traffic from site 2 LAN */
    0     0 ACCEPT     tcp  --  em2    *       190.190.89.10        0.0.0.0/0           multiport ports 22 /* 106 accept SSH from WAN */
    0     0 ACCEPT     tcp  --  em1    *       0.0.0.0/0            0.0.0.0/0           multiport ports 2812 /* 107 accept monit from LAN */
41878   19M ACCEPT     udp  --  em2    *       190.190.89.0/26      0.0.0.0/0           multiport ports 5060 /* 150 accept SIP from WAN */
 144K   55M ACCEPT     udp  --  em2    *       200.200.114.192/26   0.0.0.0/0           multiport ports 5060 /* 152 accept SIP from WAN */
    0     0 ACCEPT     udp  --  em2    *       180.180.63.32/27     0.0.0.0/0           multiport ports 5060 /* 201 accept SIP from carrier */
    0     0 ACCEPT     udp  --  em2    *       180.180.63.32/27     0.0.0.0/0           multiport ports 8000:60000 /* 202 accept RTP from carrier */
    0     0 ACCEPT     udp  --  em2    *       170.170.67.2         0.0.0.0/0           multiport ports 5060 /* 210 accept SIP from carrier */
    0     0 ACCEPT     udp  --  em2    *       170.170.67.2         0.0.0.0/0           multiport ports 8000:60000 /* 211 accept RTP from carrier */
  55M 8576M ACCEPT     udp  --  em2    *       0.0.0.0/0            0.0.0.0/0           multiport ports 16384:32768 /* 300 accept all RTP */
 489K  219M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 999 reject all other requests */ reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 998 reject all FORWARD */ reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 12G packets, 3230G bytes)
 pkts bytes target     prot opt in     out     source               destination
    
pregunta puppyFlo 20.02.2018 - 11:27
fuente

4 respuestas

1

Debes verificar el encabezado de IP en ese paquete. Justo después del valor TTL, debe indicar el protocolo. Si el protocolo viene como uno, ese será tu problema. He visto esto algo así antes.

Un valor de protocolo de uno indica ICMP, que usted admite globalmente como su primera regla. Si bien esto es necesario para que funcione el ping, permitirá paquetes mal formados a menos que tenga un firewall perimetral configurado para rechazarlos.

Un encabezado de paquete SIP válido debe usar 17 para UDP o 6 para TCP, dependiendo de su configuración particular.

Si el atacante está utilizando paquetes SIP con formato incorrecto (configurado en el protocolo 1 en lugar de 17), puede configurar su firewall para eliminar todos los tipos de paquetes ICMP, excepto ping. Hay muy pocas razones para aceptar nada además de los pings válidos de hosts externos.

    
respondido por el DoubleD 04.04.2018 - 16:17
fuente
0

Probablemente el archivo pcap con ayuda en este caso, sin embargo, esto es lo que creo que está sucediendo a partir de la información proporcionada:

El INVITE tiene IP de origen y destino 200.200.114.207, 

To: <sip:00*[email protected];transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16

si el mensaje INVITE es correcto, parece que la dirección IP coincide con una de tus reglas, creo. 

144K   55M ACCEPT     udp  --  em2    *       200.200.114.192/26   0.0.0.0/0

Lo que puedes hacer es comenzar con las reglas de puertos, 5060 y 5061 son los puertos SIP normales y luego se aplican los rangos de IP en tus iptables.

    
respondido por el camp0 20.02.2018 - 15:17
fuente
0

Usted tiene una regla relacionada / establecida al principio de la cadena (como todos lo hacemos). Echa un vistazo a si el módulo sip para iptables está presente. 

lsmod |grep -i sip

Esa podría ser la fuente de la fuga. Si es así, intente omitirlo para el tráfico SIP.

    
respondido por el MTG 08.04.2018 - 15:29
fuente
0

FYI, tengo este mismo problema exacto. De las pruebas, parece que de alguna manera el seguimiento de la conexión UDP (invocado en la regla RELACIONADA, ESTABLECIDA) identifica los paquetes designados para UDP / 5060 como parte de una sesión existente o relacionada. Puede verificar esto mirando la tabla de seguimiento de la conexión y buscando las entidades en UDP / 5060; las entradas ofensivas tendrán marcas [ASEGURADAS].

Mi conjetura es que el rastreador de conn está viendo los paquetes como parte de una sesión relacionada, y está permitiendo que el paquete pase. El servidor responde (generalmente una respuesta SIP NO VÁLIDA), y esto lo envía al estado ASEGURADO. Técnicamente, la parte relacionada solo se supone que debe ser invocada por un ayudante del rastreador de conexión (como el ayudante ALG SIP); No tengo ese módulo del kernel cargado, así que quizás esté un poco apagado y no lo veo como relacionado, sino como una sesión establecida. Si ese es el caso, es un error aún más grande.

Mi solución actual es bloquear los paquetes de las IPs ofensivas anteriores para que lleguen a la regla ESTABLECIDO / RELACIONADO. Esto lo soluciona y no hay tantos, pero es bastante molesto.

    
respondido por el lidocaineus 23.09.2018 - 09:39
fuente

Lea otras preguntas en las etiquetas

¿Cómo funcionan los certificados en términos de cifrado, hash y firma? Omisión de ASLR con fuga de información