I just experienced a full blown “attack” from someone attempting to register over 2000 different SIP peers to my asterisk box. Has anyone else experienced this recently? And what are the best ways to combat this outside of network ACL?
Thoughts?
It’s becoming more and more frequent. I have implemented fail2ban, and it works quite well: http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk.
Regards
Ian
Yes, I have also noticed that these attacks have become more frequent now!
And for me fail2ban works great and stops about 2-5 attacks every day! 
Another possibly simpler way is to add firewall rules. You can add rules like the ones below to prevent brute force ssh attacks:
1. iptables -I INPUT -p tcp --dport 22 -m state --state NEW \
2. -m recent --set
3.
4. iptables -I INPUT -p tcp --dport 22 -m state --state NEW \
5. -m recent --update --seconds 60 --hitcount 3 -j DROP
So for sipreg attacks just use the same rules on the appropriate port.
[quote] iptables -I INPUT -p tcp --dport 22 -m state --state NEW \
2. -m recent --set
3.
4. iptables -I INPUT -p tcp --dport 22 -m state --state NEW \
5. -m recent --update --seconds 60 --hitcount 3 -j DROP [/quote]
I can’t see how this would work… Doesn’t NEW mean packets have been seen in only one direction? When asterisk replies with a failed authentication message, the TCP session will become ESTABLISHED even if asterisk rejects the authentication attempt…
Ian
The most important steps are covered here
blogs.digium.com/2009/03/28/sip-security/
and to be honest looking at logs if you just implement alwaysauthreject=yes most bots will give up after a few attempts.
and keep your firewall upto date, for example if you dont have uses in say China and Israel add all subnets for those countries into your firewals and drop all the packets dont reject them .
Ian
and keep your firewall upto date, for example if you dont have uses in say China and Israel add all subnets for those countries into your firewals and drop all the packets dont reject them .
That is an excellent idea - where would you go to find this information? I am used to the other way around, but a list of the subnets in these countries would be awesome!
Greg
[quote]
I can’t see how this would work… Doesn’t NEW mean packets have been seen in only one direction? When asterisk replies with a failed authentication message, the TCP session will become ESTABLISHED even if asterisk rejects the authentication attempt…[/quote]
Perhaps each attempt is a new session? These rules do work to block ssh login bots, but I have not actually tried it yet for sipreg attacks. I’ll give it a shot next time I see a bot and I’ll reply here.
Indeed, but I was not talking about a TCP connection state (although my post was not clear about that - apologies.) I believe, although I am far from an expert on iptables so please correct me if I’m wrong, iptables associates packets with logical connections by tracking IP source address, destination and ports, assigning to the packets to the following flow states:
NEW: the packet is starting a new connection, or it belongs to a connection that has not yet seen packets in both directions.
ESTABLISHED: the connection has seen packets in both directions
RELATED: the packet is starting a new connection, but it’s related to an existing connection (e.g. FTP, SIP/RTP)
INVALID: it doesn’t belong to any tracked connections.
So I was, and I am still unsure about how the proposed rules could prevent authorisation attempts.
Regards
Ian
Just for fun I tested the rules above (for ssh) and indeed after the 3rd failed attempt, the server stopped responding. So the rules do work for ssh attacks. I have not tested this for SIP, but it has been suggested above that it won’t work, at least for SIP over UDP.
Just remove “-m state --state NEW” and put udp:
iptables -A INPUT -p udp --dport 5060 -m recent --set --name ASTERISK
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 60 --hitcount 10 --name ASTERISK -j DROP
You can easy test it with nc:
nc -u ip.of.asterisk 5060
then write something and enter (this is one packet).
a properly configured SSH daemon would not require this, the firewall would be for additional security.
If you don’t need 5060 open for SIP close it? Is that possible. Reduce the likelihood of even getting to the box.
-Jake
www.voipcitadel.com
Additional to deny/allow config, this is what is working atm for me:
etc/sysconfig/iptables:
-A INPUT -i lo -j ACCEPT
########################################################################################
Allow only local and our provider
PERMITIDO
-N PERMITIDO
-A PERMITIDO -s 10.10.0.0/16 -j ACCEPT
-A PERMITIDO -s X.X.X.X/32 -j ACCEPT # X.X.X.X = Your provider’s IP
########################################################################################
SSL Only local
-A INPUT -p tcp -s 10.10.0.0/16 -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j PERMITIDO
-A INPUT -p icmp -j PERMITIDO
#SIP 5060 Only PERMITIDO
-A INPUT -p udp -m udp --dport 5060 -j PERMITIDO
#IAX2 4569 Only PERMITIDO
-A INPUT -p udp -m udp --dport 4569 -j PERMITIDO
RTP - the media stream Only PERMITIDO
-A INPUT -p udp -m udp --dport 10000:20000 -j PERMITIDO
########################################################################################
Block everything else
-P INPUT DROP
Allow all exit
-P OUTPUT ACCEPT
Block all forwarded
-P FORWARD DROP
COMMIT
Hope this work for you as well