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