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]> 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]> 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 --->
> >> INVITE 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>;tag=9481SIPpTag001
> >> To: sut <sip:[email protected]:5060>
> >> Call-ID: [email protected]
> >> CSeq: 1 INVITE
> >> Contact: 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]> 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]> 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]> 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]
> >> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >> > >
> >> > > Donations to support AstLinux are graciously accepted via PayPal to
> >> > > [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]
> >> > > 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].
> >> >
> >> >
>
> ------------------------------------------------------------------------------
> >> > 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].
> >>
> >>
>
> ------------------------------------------------------------------------------
> >> 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].
>
>
> ------------------------------------------------------------------------------
> 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].
