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