(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: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 |
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?
RELATEDà -p icmp. Peut-être que cela le résout (ou est un travail approprié qui ne nécessite pas de votre part de lire sur les assistants conntrack).
ESTABLISHEDdevrait fonctionner pour UDP. Il semble que le flux de paquets et accepte les réponses aux demandes (sortantes). Vos "hackers" ont-ils des IP statiques? ;-) Si c'est le cas, vérifiez / proc / net / nf_conntrack pour voir ce que la table d'état contient à leur sujet lorsqu'ils sont actuellement / non / connectés ...RELATEDest une chose plus délicate ... Je ne sais pas ce qu'il fait pour SIP .modprobePeut - être montre- t - il un module ipt_sip ou quelque chose de chargé qui ferait des choses "magiques"?