(spostato da SO)
Ho iptables che protegge un server SIP. Blocca tutti gli IP tranne quelli che ho aperto in modo specifico e sembra funzionare per quasi tutti. Ho testato da molti indirizzi IP che non sono elencati in bianco e tutti vengono eliminati come dovrebbero.
MA, ho preso un "hacker" che sembra in grado di aggirare le regole di iptables. I suoi INVITE di sondaggio riescono a superarlo, e non ho idea di come, o che fosse persino possibile. In 10 anni non l'ho mai visto prima.
Suppongo che debba essere qualcosa che ho fatto, ma non riesco a vederlo.
iptables creato in questo modo (MYIP definito in alto - redatto):
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
Ora, con NIENTE in ALLOWEDSIP, tutto ciò che dovrei essere in grado di fare è SSH (che posso). Se lancio chiamate, tutte vengono lasciate cadere. Ma WireShark mi mostra questo (il mio IP è stato redatto):
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 |
Le sue chiamate hanno colpito il mio interruttore e, sebbene alla fine siano state respinte dall'ACL, non dovrebbero mai arrivarci. Nient'altro passa. Mi sto strappando i capelli. Qualcuno sa?
Solo per completezza, ecco il risultato di 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
EDIT: appena visto questo da WireShark. Potrebbero fare qualcosa di orribile come stabilirsi in un altro modo e giocare sulla regola stabilita? Forse stanno giocando in qualche buco in CORRELATI?
89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm Destination port: sip
EDIT 2: UDP è la chiave qui. Quando ho impostato OpenSIPS per l'ascolto solo per TCP, il problema sembra scomparire. Nessuno dei loro tentativi riesce più a superare, anche se stanno inviando più di quei messaggi "tag-pm". Tuttavia non spiega perché i pacchetti stiano arrivando a opensips. iptables avrebbe dovuto prima fermarli. Mi piacerebbe sapere cosa ho fatto di sbagliato qui.
EDIT 3: Se rimuovo RELATED smetto di rispondere a loro, quindi è qualcosa a che fare con quello. Ma penso di aver bisogno di relazioni. Qualche suggerimento su soluzioni alternative?
RELATEDa -p icmp. Forse questo lo risolve (o è un lavoro adatto intorno al quale non è necessario che tu legga gli aiutanti di Conntrack).
ESTABLISHEDdovrebbe funzionare per UDP. Sembra che il flusso di pacchetti e accetta risposte a richieste (in uscita). I tuoi "hacker" hanno IP statici? ;-) In tal caso, controlla / proc / net / nf_conntrack per vedere cosa contiene la tabella di stato su di loro quando sono attualmente / non / connessi ...RELATEDè una cosa più complicata ... Non so cosa fa per SIP . Famodprobeforse mostrare un modulo ipt_sip o qualcosa che avrebbe caricato fare cose "magico"?