Richiesta SIP UDP che si rompe con iptables

Question

Richiesta SIP UDP che si rompe con iptables

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

7

Recentemente ho indagato su alcuni casi in cui il traffico SIP UDP ha in qualche modo eluso il set di regole definito in iptables che mi porta a sospettare che ci sia un buco nelle nostre regole, quindi sto cercando consigli su come rafforzare le difese sul sistema locale. Abbiamo un firewall davanti a questo server che potrebbe essere migliorato, tuttavia sembra importante che questo problema venga compreso prima di esaminare ulteriori misure, in quanto tale questione riguarda direttamente le difese del server locale, in particolare iptables.

I pacchetti SIP stanno iniziando a includere i tentativi di iniezione SQL e temo che senza essere indirizzato direttamente all'applicazione possa essere compromessa. Al momento il "chiamante" riesce a stabilire una chiamata che riproduce semplicemente il nostro annuncio di non servizio in modo che stiano iniziando una conversazione SIP con il server locale - non ideale!

Ho copiato i dettagli di seguito con uno schema di redazione coerente, tuttavia se sono necessarie informazioni aggiuntive, per favore commentate di seguito e io lo inserisco.

Apprezza i consigli, grazie per dare un'occhiata!

IP ORIGINALE: 185.107.83.35 IP SIP SERVER: 200.200.114.207

Inizierò con un esempio del pacchetto SIP offensivo:

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

Configurazione IP sull'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

Ecco l'output di 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

linux sql-injection sip firewalls iptables

posta puppyFlo 20.02.2018 - 11:27

fonte

4 risposte

Leggi altre domande sui tag linux sql-injection sip firewalls iptables

Blueborne - Chiarimento sullo scenario di attacco L'XSS è possibile con jQuery (location.hash)?

score 1 · Answer 1

Dovresti controllare l'intestazione IP su quel pacchetto. Subito dopo il valore TTL, dovrebbe indicare il protocollo. Se il protocollo viene inserito come uno, questo sarà il tuo problema. Ho visto qualcosa di simile prima.

Un valore di protocollo di uno indica ICMP, che puoi autorizzare globalmente come prima regola. Anche se è necessario che il ping funzioni, consentirà pacchetti malformati a meno che non si disponga di un firewall perimetrale configurato per rifiutarli.

Un'intestazione di pacchetto SIP valida dovrebbe utilizzare 17 per UDP o 6 per TCP, a seconda della particolare configurazione.

Se l'utente malintenzionato utilizza pacchetti SIP non validi (impostati sul protocollo 1 anziché su 17), è possibile configurare il firewall in modo da eliminare ogni tipo di pacchetto ICMP, ad eccezione del ping. C'è ben poco motivo per accettare qualcosa oltre ai ping validi da host esterni.

score 0 · Answer 2

Probabilmente il file pcap con l'aiuto in questo caso, tuttavia, ecco cosa penso stia accadendo dalle informazioni fornite:

L'INVITE ha IP 200.200.114.207 di origine e destinazione,

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

se INVITE è correttamente, sembra che l'indirizzo IP corrisponda a una delle tue regole, credo.

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

Quello che puoi fare è iniziare con le regole di porta, 5060 e 5061 sono le normali porte SIP e dopo va per gli intervalli IP sul tuo iptables.

score 0 · Answer 3

Hai una regola relativa / stabilita all'inizio della catena (come facciamo tutti noi). Controlla se è presente il modulo sip per iptables.

lsmod |grep -i sip

Potrebbe essere la fonte della perdita. In tal caso, prova a ignorarlo per ottenere il traffico sorso.

score 0 · Answer 4

Per tua informazione, ho esattamente lo stesso problema. Dai test, sembra che in qualche modo il tracciamento della connessione UDP (invocato nella regola RELATED, ESTABLISHED) stia identificando i pacchetti designati per UDP / 5060 come parte di una sessione esistente o correlata. È possibile verificarlo osservando la tabella di tracciamento delle connessioni e cercando le voci su UDP / 5060; le voci offensive avranno flag [ASSURED].

La mia ipotesi è che il conn tracker stia vedendo i pacchetti come parte di una sessione correlata e permettendo il passaggio del pacchetto. Il server risponde quindi (di solito una risposta SIP INVALID), e questo lo invia nello stato ASSURED. Tecnicamente la parte relativa dovrebbe essere invocata da un helper tracker di connessione (come l'helper SIP ALG); Non ho caricato quel modulo del kernel, quindi forse sono leggermente fuori e non lo vedo come correlato, ma in realtà una sessione stabilita. Se è così, è un bug ancora più grande.

La mia soluzione attuale è bloccare i pacchetti da quegli IP che precedenti offendono per colpire la regola ESTABLISHED / RELATED. Questo lo risolve e non ce ne sono molti, ma è piuttosto fastidioso.