|Summary:||ASTERISK-18129: Urgent need for IP permit-deny at the GLOBAL level, not at the peer level|
|Reporter:||Private Name (falves11)||Labels:|
|Date Opened:||2011-07-12 11:44:25||Date Closed:||2011-07-26 09:27:58|
|Description:||I talked to Bryan Johns and he agrees that we need URGENTLY a global permit/deny option for sip.conf. My clients and hundreds of companies have lost huge amount of money to hackers from Eastern Europe and other regions of the world. Using fail2ban is not practical since it implies iptables, and for very busy systems, iptables slows down the machine dramatically. So we need a basic filter for IP address of origin before processing the packet.|
Also, we need a global "ignore registration attempts" that simply discard REGISTER packets, and does not reply or otherwise process the request, simply ignore it. These two options will advance security a long way.
|Comments:||By: Paul Belanger (pabelanger) 2011-07-13 13:47:10.945-0500|
I believe we talked about this at AstriDevCon as a feature request, patches welcome.
By: Birger "WIMPy" Harzenetter (wimpy) 2011-07-13 16:33:48.856-0500
What makes you think, Asterisk could do it faster than iptables?
My bet would be that iptables will be faster.
By: Private Name (falves11) 2011-07-13 17:40:13.730-0500
The IP tables module filters or touches every packet. I don´t want to touch media packets, for instance. I just need UDP 5060 Inbound and only INVITES and REGISTER packets filtered. If you think that Iptables can do that and ignore the rest of the network traffic, then I will implement an iptables-based filter. But I guess that since we work with only a subset of packets with two specific headers, Asterisk may be a faster approach.
By: Private Name (falves11) 2011-07-14 04:13:51.510-0500
I designed an Ip tables rule to block any inbound packet from Russia, China, Korea and Taiwan, which were the source of the attacks before. Using only two octets in the rule, like "/sbin/iptables -A INPUT -s 126.96.36.199/16 -j DROP", I get 9048 rules. Can somebody with experience tell me if this amount of rules will affect the performance or this is manageable for a modern Xeon /64 Bits box? How can I test the effect? Also, would it be faster for iptables if I use instead a rule like
/sbin/iptables -A INPUT p udp -m udp --dport 5060 -s 188.8.131.52/16 -j DROP
If anybody needs the script or wants to block any particular set of countries in this manner, let me know.
By: Walter Doekes (wdoekes) 2011-07-14 06:59:31.222-0500
The less "complex" filtering you do, the faster it probably is:
/sbin/iptables -A INPUT -s 184.108.40.206/16 -j DROP
should be faster than:
/sbin/iptables -A INPUT -s 220.127.116.11/16 -p udp --dport 5060 -j DROP
Because in the second case iptables has to check more packet data than in the first one.
You should be able to reduce those 9k rules to even less. Look at adjacent blocks and reduce the netmask to cover them with a single rule.
By: David Woolley (davidw) 2011-07-14 07:01:16.487-0500
As this is a feature request without a patch, reported against an unsupported version, I shouldn't really say anything here, but the use of multiple tables with iptables should eliminate non-SIP very quickly and reduce the SIP analysis to O(log( n )).
By: Private Name (falves11) 2011-07-14 10:04:59.347-0500
Can you provide a link to an example of that technique? I had to stop iptables since it was eating 79% of a core, and I have only a few cores.
By: David Woolley (davidw) 2011-07-15 05:35:32.200-0500
That would not be appropriate here. If you ask on forums.digium.com, in the Asterisk Support forum, I will try and explain what I mean.
By: Private Name (falves11) 2011-07-23 10:21:24.145-0500
I found a very interesting thread
. Re: Securing Asterisk - How to avoid sending, "SIP/2.0 603
Declined" (Paul Belanger)
asterisk-users Digest, Vol 84, Issue 43
In fact, I think Digium is hiding its head on the sand. The issue is securing Asterisk and avoiding Denial of Service attacks has costed millions to a small industry, where nobody is getting rich. What we need is exactly what the thread is asking. DO NOT REPLY to a REGISTER if the information is bad. Simply ignore it. That should be a configurable option in sip.conf.
By the way, I succeeded blocking any traffic at all from 4 countries, RU, CN, KR and TW, at minimal cost in terms if CPU. It is very difficult but it can be done. However, the evil guys always can use proxies. There is way to also block most known open proxies. The real solution is what the thread is asking for.
By: Leif Madsen (lmadsen) 2011-07-26 09:27:58.570-0500
There are tools outside of Asterisk that are more efficient. Regardless, this is a feature request without a patch, so I'm closing this.