James, of course if the attacks don't change and you are seeing only always the same pattern, you should be fine - for now. But I would not lean back and relax because you have somehow mastered this challenge. The world changes and SIP attacks are now more and more advancing.
Regards, Ingmar On 05/19/2011 10:18 PM, James Babiak wrote: > Ingmar, > > You raise some valid points. However the vast majority of SIP-based > attacks is for toll-fraud. I was getting hit with at least one a day, > and somedays 4-5. The scans were very straighforward and not trying to > implement any advanced circumvention tactics (like using varying spoofed > source IPs). So by blacklisting the IPs where the traffic was coming > from, I've been able to dramatically decrease the number and duration of > the attacks. The latter being a single attempt. > > Lonnie's implementation of my blacklisting dialplan snippit into the > Adaptive-Ban plugin already takes your concerns into account. You can > easily specify whitelisted IP addresses that won't be banned. Such as > your SIP trunk provider(s) or other PBXs. This eliminates the concern > that an attack with inside knowledge could use your protection mechanism > against you. > > Yes it's not a perfect solution to eliminate 100% of attacks, but it > will eliminate 99% of them. And the other 1% is going to get through > almost anything you put together on an open system. > > And it's simply an option. If you don't want to enable it, you don't > have to. Personally, I find (and have found) it very useful. > > -James > > On Thu, May 19, 2011 at 4:05 PM, Ingmar Schraub <[email protected] > <mailto:[email protected]>> wrote: > > The problem with SIP over UDP is that you can flood destinations with > random source IPs. Send out tons of INVITEs to let phones ring which are > registered with a PBX is a common type of attack. Do you really want to > block all those source IP addresses? The answer is 'no'. It simply > doesn't > make sense. > > UDP is a bad protocol for SIP signaling in terms of security. It's a > known > fact that it is hard & very difficult to fight against UDP attacks. > If the > attacker is not aiming for i.e. toll fraud but just for DoS (on > application > level) there is little you can do. > > Blacklisting/banning can be also dangerous. Let's assume the > attacker uses > as source IP the address of your SIP trunk provider. Do you really > want to > blacklist this address? Certainly not! The only real protection is to > switch completely to TCP (which includes SIP over TLS) and apply proper > security controls here. > > Regards, > > Ingamr > > On Thu, 19 May 2011 14:13:03 -0500, Lonnie Abelbeck > <[email protected] <mailto:[email protected]>> wrote: > > James, > > > > Excellent testing, much appreciated... > > > > In summary, it appears adding support for: > > -- > > ; For Asterisk 1.4 > > exten => s,n,Set(BANIP=${SIPCHANINFO(recvip)}) > > exten => s,n,Log(NOTICE,\'${BANIP}\' - Dialplan Noted Suspicious IP > > Address) > > > > ; For Asterisk 1.6/1.8 > > exten => s,n,Set(BANIP=${CHANNEL(recvip)}) > > exten => s,n,Log(NOTICE,'${BANIP}' - Dialplan Noted Suspicious IP > Address) > > -- > > in the Adaptive-Ban plugin seems useful. I will do that. (a one line > > addition :-) ) > > > > It appears the asterisk functions SIPCHANINFO()/CHANNEL() are the best > > tools we have to determine the SIP source IP address via the dialplan, > > while not always perfect, it is quite useful for this application. > The > > Adaptive-ban ADAPTIVE_BAN_WHITELIST and > ADAPTIVE_BAN_WHITELIST_INTERNAL=1 > > should take care of problematic spoofed IP's. > > > > Thanks for planting the seed for this feature. > > > > Lonnie > > > > > > > > On May 19, 2011, at 12:13 PM, James Babiak wrote: > > > >> Lonnie, > >> > >> Yeah I have persistent logging enabled. I also changed the 10MB > default > >> down to 2MB to help with keeping the processing of the log file down. > The > >> (complex) sed call is what was spiking the system load up very high > when > >> the log files were close to 10MB. I would agree with making the > syslogd > >> options exposed to be tweaked by users through the GUI. > >> > >> I like the SIPCHANINFO/CHANNEL variable use better. It seems to more > >> accurately acquire the true IP address of the attacker. As I > mentioned > >> before, while it would cut down tremendously on scans, I would > see the > >> occasional false positive in my bans. Things such as my own IP or > >> 127.0.0.1 or a NAT'd address. Using your variable, in my own testing, > >> seems to alleviate *some* of that. > >> > >> When calling from a NAT'd phone, it used to pull the NAT IP, but now > >> will pull the public one, which is good. But when I was using sipp to > try > >> and spoof my IP to see the effect, I noticed some strange behavior... > >> > >> The first few attempts would show up as: > >> -- Executing [service@from-pstn-unknown:6] > Set("SIP/5060-000003a1", > >> "BANIP=127.0.1.1") in new stack > >> -- Executing [service@from-pstn-unknown:7] > NoOp("SIP/5060-000003a1", > >> "IP is 127.0.1.1") in new stack > >> -- Executing [service@from-pstn-unknown:8] > >> System("SIP/5060-000003a1", "echo 127.0.1.1 >> > /mnt/kd/banlist") in > >> new stack > >> using the SIPCHANINFO(recvip) variable. I wasn't even specifying any > >> special IP, just running it against my box. > >> > >> The invite looked like this: > >> --==-- > >> <--- SIP read from 72.64.129.130:1316 <http://72.64.129.130:1316> > ---> > >> INVITE sip:[email protected]:5060 > <http://sip:[email protected]:5060> SIP/2.0 > >> Via: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK-9481-1-0 > >> From: sipp <sip:[email protected]:5060 > <http://sip:[email protected]:5060>>;tag=9481SIPpTag001 > >> To: sut <sip:[email protected]:5060 > <http://sip:[email protected]:5060>> > >> Call-ID: [email protected] <mailto:[email protected]> > >> CSeq: 1 INVITE > >> Contact: sip:[email protected]:5060 <http://sip:[email protected]:5060> > >> Max-Forwards: 70 > >> Subject: Performance Test > >> Content-Type: application/sdp > >> Content-Length: 129 > >> > >> v=0 > >> o=user1 53655765 2353687637 IN IP4 127.0.1.1 > >> s=- > >> c=IN IP4 127.0.1.1 > >> t=0 0 > >> m=audio 6000 RTP/AVP 0 > >> a=rtpmap:0 PCMU/8000 > >> --==-- > >> > >> Which is identical to the way my NAT'd phone's invite looked. The > only > >> difference is that the BANIP for my phone was it's public address, > >> whereas the BANIP for the sipp call above was 127.0.1.1. Seems weird. > >> > >> Even weirder, when I used sipp to launch ten calls at once, the first > >> two showed up as 127.0.1.1, the rest showed up as my public IP. This > was > >> using simply "./sipp [host". I wonder if this is some kind of bug? > >> > >> When changing the from/contact/etc. sip headers manually, it doesn't > >> seem to have any affect, and sets the correct SRC IP for the > variable. > I > >> assume changing the IP header would allow you to pass the variable a > >> spoofed result, which in turn could be used as a form of DoS attack. > >> > >> -James > >> > >> On Wed, May 18, 2011 at 7:02 PM, Lonnie Abelbeck > >> <[email protected] <mailto:[email protected]>> wrote: > >> James, > >> > >> By default "syslogd -s 1024 -m 60 -b 2" /var/log/messages are rotated > at > >> 1MB. Note that if the syslog is rotated the pre-existing ban'ed > IP are > >> not removed, unless the box is rebooted or the firewall is restarted. > I > >> have only seen minor effects on a net5501 under these conditions. A > >> single (albeit complex) 'sed' call does the grunt-work in the > >> adaptive-ban plugin. > >> > >> If PERSISTLOG = yes, then the logs are rotated at 10MB (and on slow > >> flash instead of RAM) this could become slow. I never set > PERSISTLOG. > >> Possibly we need more control of the syslogd options with > PERSISTLOG = > >> yes . > >> > >> Michael and I have been playing around with the idea (spawned by you) > of > >> generating a Log() for the adaptive-ban plugin to catch. To get > the IP > >> address we found a better method: > >> -- > >> ; For Asterisk 1.4 > >> exten => s,n,Set(BANIP=${SIPCHANINFO(recvip)}) > >> exten => s,n,Log(NOTICE,\'${BANIP}\' - Dialplan Noted Suspicious IP > >> Address) > >> > >> ; For Asterisk 1.6/1.8 > >> exten => s,n,Set(BANIP=${CHANNEL(recvip)}) > >> exten => s,n,Log(NOTICE,'${BANIP}' - Dialplan Noted Suspicious IP > >> Address) > >> -- > >> > >> A question for anyone, is the BANIP value above spoof-able? > >> > >> Lonnie > >> > >> > >> > >> On May 18, 2011, at 5:23 PM, James Babiak wrote: > >> > >> > Lonnie, > >> > > >> > Good idea, never thought about doing it that way. > >> > > >> > I would still personally want to keep track of them in some > persistent > >> > file though to be reloaded on reboots. > >> > > >> > I also noticed that when my log files get large (>5MBs), the > adaptive > >> > ban script seems to require large amounts of processing power. I > >> > noticed the other day where my load level was spiking close to 1. > When > >> > I disabled the plugin, or started rotating my logs at 2MBs, it > dropped > >> > dramatically. Have you had similar issues? > >> > > >> > Many attackers will actually try to place the call attempts using > your > >> > own IP address, so I need to add the ability for it to filter out > those > >> > IPs, otherwise it will put invalid entries into the banned list. It > >> > doesn't actually cause any negative side effects (outside of extra > >> > useless entries), but it also doesn't block the traffic. > >> > > >> > -James > >> > > >> > On Tue, May 17, 2011 at 8:08 PM, Lonnie Abelbeck > >> > <[email protected] <mailto:[email protected]>> > wrote: > >> > James, > >> > > >> > Very clever! > >> > > >> > It probably is a little too convoluted, but if the dialplan > contained: > >> > -- > >> > exten => _.,n,Set(BLKIP1=${CUT(CHANNEL,\/,2)}) > >> > exten => _.,n,Set(BLKIP2=${CUT(BLKIP1,\-,1)}) > >> > exten => _.,n,Log(NOTICE,\'${BLKIP2}\' - Dialplan Ban IP Address) > >> > -- > >> > it would generate the log > >> > -- > >> > May 17 18:55:14 pbx local0.notice asterisk[30186]: NOTICE[30186]: > Ext. > >> > s:5 in @ default: '10.10.50.1' - Dialplan Ban IP Address > >> > -- > >> > Then the AIF adaptive-ban plugin could be tweaked to have > support for > >> > that forced syslog string. > >> > > >> > Lonnie > >> > > >> > > >> > On May 17, 2011, at 2:14 PM, James Babiak wrote: > >> > > >> > > I too was getting scanned a lot. My system is locked down, so I > >> > > wasn't really worried about tollfraud, but it would fill up > my logs > >> > > and CDRs which got annoying. > >> > > > >> > > I wanted to still be able to accept certain unauthenticated > inbound > >> > > calls (conf@ and james@, etc.), so I couldn't disable them > >> > > altogether. So I put together this little dialplan entry as a > last > >> > > resort in my incoming context: > >> > > > >> > > ; Don't accept any calls not identified above > >> > > exten => _.,1,Progress() > >> > > exten => _.,n,Set(CDR(userfield)=${EXTEN}) > >> > > exten => _.,n,Wait(1) > >> > > exten => _.,n,Answer() > >> > > exten => _.,n,Set(BLKIP1=${CUT(CHANNEL,\/,2)}) > >> > > exten => _.,n,Set(BLKIP2=${CUT(BLKIP1,\-,1)}) > >> > > exten => _.,n,Noop(BLOCKING ALL VOIP TRAFFIC FROM ${BLKIP2}) > >> > > exten => _.,n,System(echo ${BLKIP2} >> /mnt/kd/banlist) > >> > > exten => _.,n,System(iptables -A ADAPTIVE_BAN_CHAIN -p udp -s > >> > > ${BLKIP2} -j ADAPTIVE_BAN_DROP_CHAIN) > >> > > exten => _.,n,Zapateller() > >> > > exten => _.,n,Playback(the-number-u-dialed) > >> > > exten => _.,n,SayDigits(${EXTEN}) > >> > > exten => > _.,n,Playback(has-been-disconnected&or&no-longer-in-service) > >> > > exten => _.,n,Playback(check-number-dial-again) > >> > > exten => _.,n,Congestion(5) > >> > > exten => _.,n,Hangup() > >> > > > >> > > It will echo the IP address into a persistent banlist (which gets > >> > > reimplemented on a reboot), and then adds an iptables rule to > block > >> > > any more udp traffic from that host. So if someone tries to scan > me, > >> > > the first attempt will be accepted and logged, but any future > >> > > attempts will be blocked. > >> > > > >> > > Has helped tremendously! > >> > > > >> > > And I use the adaptive ban plug-in for sshd and asterisk user > >> > > account scans. > >> > > > >> > > -James > >> > > > >> > > On Thu, Apr 28, 2011 at 9:19 AM, Lonnie Abelbeck > >> > > <[email protected] > <mailto:[email protected]>> wrote: > >> > > > >> > > On Apr 28, 2011, at 7:27 AM, Ingmar Schraub wrote: > >> > > > >> > > > On 04/28/2011 01:06 PM, Joss Giffard wrote: > >> > > >> Hi, > >> > > >> > >> > > >> I recently updated our asterisk system to astlinux 0.7.7 > whilst > >> > > >> moving > >> > > >> to a new SIP trunk provider. Everything seems to be up and > running > >> > > >> correctly apart from the fact that very occasionally each > of the > >> > > >> VoIP > >> > > >> phones will receive an incoming call from 'asterisk' that once > >> > > >> answered > >> > > >> is simply silence... I was wondering if anyone else has > >> > > >> experienced > >> > > >> anything similar or has any idea what would be causing > this (or > >> > > >> indeed > >> > > >> how to cure it). The phones themselves are all Grandstream > >> > > >> GXP2000s. > >> > > > > >> > > > Looks like SIP scanning/spamming/toll fraud attack. You could > >> > > > tweak your > >> > > > Asterisk configuration to not allow any other un-authenticated > >> > > > inbound > >> > > > calls than from your SIP trunk provider and/or add some further > >> > > > security > >> > > > controls to prevent such things. > >> > > > > >> > > > Here is a report from someone who had a similar experience: > >> > > > > >> > > > > > http://www.fonality.com/trixbox/forums/trixbox-forums/open-discussion/blank-call-caller-id-asterisk > >> > > > > >> > > > There are also some ideas on how to block such calls. Some are > >> > > > good, > >> > > > some may not make sense to everyone. > >> > > > > >> > > > Regards, > >> > > > > >> > > > Ingmar > >> > > > >> > > I agree with Ingmar, additionally if you are using Asterisk > 1.4 you > >> > > might want to set: > >> > > -- > >> > > alwaysauthreject=yes > >> > > -- > >> > > (Asterisk 1.8 defaults to yes) to reduce the amount of > information > >> > > to the scanner. > >> > > > >> > > You may also want to enable the Adaptive Ban plugin: > >> > > > >> > > Network Tab -> Firewall Plugins: [ adaptive-ban ] > >> > > > >> > > set to ENABLED=1 via the { Configure Plugin } button, adjust any > >> > > options and "Restart Firewall" to apply. > >> > > > >> > > The Adaptive Ban firewall plugin operates on the same > principle as > >> > > Fail2Ban, automatically blocking IP addresses that generate > errors > in > >> > > the logs over a pre-defined threshold. > >> > > > >> > > Lonnie > >> > > > >> > > > >> > > > >> > > > > ------------------------------------------------------------------------------ > >> > > WhatsUp Gold - Download Free Network Management Software > >> > > The most intuitive, comprehensive, and cost-effective network > >> > > management toolset available today. Delivers lowest initial > >> > > acquisition cost and overall TCO of any competing solution. > >> > > http://p.sf.net/sfu/whatsupgold-sd > >> > > _______________________________________________ > >> > > Astlinux-users mailing list > >> > > [email protected] > <mailto:[email protected]> > >> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > > > >> > > Donations to support AstLinux are graciously accepted via > PayPal to > >> > > [email protected] <mailto:[email protected]>. > >> > > > >> > > > > ------------------------------------------------------------------------------ > >> > > Achieve unprecedented app performance and reliability > >> > > What every C/C++ and Fortran developer should know. > >> > > Learn how Intel has extended the reach of its next-generation > tools > >> > > to help boost performance applications - inlcuding clusters. > >> > > > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > >> > > Astlinux-users mailing list > >> > > [email protected] > <mailto:[email protected]> > >> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > > > >> > > Donations to support AstLinux are graciously accepted via > PayPal to > >> > > [email protected] <mailto:[email protected]>. > >> > > >> > > >> > > > ------------------------------------------------------------------------------ > >> > What Every C/C++ and Fortran developer Should Know! > >> > Read this article and learn how Intel has extended the reach of its > >> > next-generation tools to help Windows* and Linux* C/C++ and Fortran > >> > developers boost performance applications - including clusters. > >> > http://p.sf.net/sfu/intel-dev2devmay > >> > _______________________________________________ > >> > Astlinux-users mailing list > >> > [email protected] > <mailto:[email protected]> > >> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > > >> > Donations to support AstLinux are graciously accepted via PayPal to > >> > [email protected] <mailto:[email protected]>. > >> > > >> > > > ------------------------------------------------------------------------------ > >> > What Every C/C++ and Fortran developer Should Know! > >> > Read this article and learn how Intel has extended the reach of its > >> > next-generation tools to help Windows* and Linux* C/C++ and Fortran > >> > developers boost performance applications - including clusters. > >> > > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > >> > Astlinux-users mailing list > >> > [email protected] > <mailto:[email protected]> > >> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > > >> > Donations to support AstLinux are graciously accepted via PayPal to > >> > [email protected] <mailto:[email protected]>. > >> > >> > >> > > ------------------------------------------------------------------------------ > >> What Every C/C++ and Fortran developer Should Know! > >> Read this article and learn how Intel has extended the reach of its > >> next-generation tools to help Windows* and Linux* C/C++ and Fortran > >> developers boost performance applications - including clusters. > >> http://p.sf.net/sfu/intel-dev2devmay > >> _______________________________________________ > >> Astlinux-users mailing list > >> [email protected] > <mailto:[email protected]> > >> https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > >> Donations to support AstLinux are graciously accepted via PayPal to > >> [email protected] <mailto:[email protected]>. > >> > >> > > ------------------------------------------------------------------------------ > >> What Every C/C++ and Fortran developer Should Know! > >> Read this article and learn how Intel has extended the reach of its > >> next-generation tools to help Windows* and Linux* C/C++ and Fortran > >> developers boost performance applications - including clusters. > >> > > http://p.sf.net/sfu/intel-dev2devmay_______________________________________________ > >> Astlinux-users mailing list > >> [email protected] > <mailto:[email protected]> > >> https://lists.sourceforge.net/lists/listinfo/astlinux-users > >> > >> Donations to support AstLinux are graciously accepted via PayPal to > >> [email protected] <mailto:[email protected]>. > > > > > > > > ------------------------------------------------------------------------------ > > What Every C/C++ and Fortran developer Should Know! > > Read this article and learn how Intel has extended the reach of its > > next-generation tools to help Windows* and Linux* C/C++ and Fortran > > developers boost performance applications - including clusters. > > http://p.sf.net/sfu/intel-dev2devmay > > _______________________________________________ > > Astlinux-users mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > > [email protected] <mailto:[email protected]>. > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Astlinux-users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected] <mailto:[email protected]>. > > > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > > > > _______________________________________________ > Astlinux-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected]. ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Astlinux-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [email protected].
