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].
