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