Hacker contournant iptables

(déplacé de SO)

J'ai iptables protégeant un serveur SIP. Il bloque toutes les adresses IP sauf celles que j'ai spécifiquement ouvertes, et il semble fonctionner pour presque tout le monde. J'ai testé de nombreuses adresses IP qui ne sont pas sur liste blanche et elles sont toutes supprimées comme il se doit.

MAIS, j'ai ramassé un "hacker" qui semble capable de contourner les règles iptables. Ses sondages INVITE s'en sortent, et je ne sais pas comment, ni que c'était même possible. En 10 ans, je n'avais jamais vu ça auparavant.

Je suppose que ce doit être quelque chose que j'ai fait, mais je ne le vois pas.

iptables créés comme ceci (MYIP défini en haut - expurgé):

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

Maintenant, avec RIEN dans le ALLOWEDSIP, tout ce que je devrais être en mesure de faire est SSH dans (que je peux). Si je lance des appels, ils sont tous abandonnés. Mais Wirehark me le montre (mon IP expurgée):

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 |

Ses appels ont touché mon interrupteur et, bien que finalement rejetés par l'ACL, ils ne devraient jamais y arriver. Rien d'autre ne passe. Tirer mes cheveux. Quelqu'un sait?

Juste pour être complet, voici le résultat d'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: vient de voir cela de Wireshark. Pourraient-ils faire quelque chose d'horrible comme s'établir d'une autre manière que de jouer sur la règle établie? Peut-être qu'ils jouent sur un trou dans RELATED?

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

EDIT 2: UDP est la clé ici. Lorsque j'ai défini OpenSIPS pour écouter uniquement TCP, le problème semble disparaître. Aucune de leurs tentatives ne passe plus, bien qu'ils envoient plus de ces messages "tag-pm". N'explique cependant pas pourquoi les paquets parviennent même à des ouvertures. iptables aurait dû les arrêter en premier. J'adorerais savoir ce que j'ai fait de mal ici.

EDIT 3: Si je supprime RELATED j'arrête de leur répondre, c'est donc quelque chose à voir avec ça. Mais je pense que j'ai besoin de parents. Des conseils sur les solutions de contournement?

La seule explication plausible de la façon dont cela pourrait fonctionner est que les datagrammes UDP incriminés passent en quelque sorte --state ESTABLISHED,RELATED.

Étant donné que UDP est un protocole sans état, je doute que le statemodule dispose d'un suivi efficace.

Pour régler le problème, je limiterais la vérification de l'état au protocole TCP en:

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

Et préfiltrez ALLOWEDSIPavec le protocole UDP (et de préférence, avec le port de destination aussi):

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

Vous pouvez nullroute. Cela devrait contourner iptables.

route add 89.163.146.25 gw 127.0.0.1 lo

Vérifie ça

netstat -nr

OU

route -n