[Spce-user] Fwd: autoban or fail2ban

Matthew Ogden matthew at tenacit.net
Fri Aug 10 08:13:31 EDT 2012


---------- Forwarded message ----------
From: Matthew Ogden <matthew at tenacit.net>
Date: Fri, Aug 10, 2012 at 2:13 PM
Subject: Re: [Spce-user] autoban or fail2ban
To: Lorenzo Mangani <lorenzo.mangani at gmail.com>


Hi Guys,

I'm back on this thread from a different perspective.

Is there a way to set a whitelist of IPs that Pike wont ban?

Sometimes a client link goes down or there is congestion (I'm not 100% sure
of the cause), then you see some ICMP desitnation unreachable coming back
to the server, then all of a sudden you see tons of registereing from the
client device (trying to reconnect I guess), and the S:CE just bans them
for 5 minutes.

Any suggestions (obviously deriving the cause of the problem must happen),
for avoiding this.

Where do I change the settings for pike? And or fine a whitelist?

Kind Regards


On Tue, May 8, 2012 at 12:38 PM, Matthew Ogden <matthew at tenacit.net> wrote:

> Just for everyone else:
>
>
>
> The link on http://kb.asipto.com/kamailio:usage:k31-sip-scanning-attackpointing to
> http://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/
>
>
>
> Was very helpful and immediately stopped the attack.
>
>
>
> I believe if the 100 Trying is not sent, its unlikely that their attack
> would have persisted though, as their initial sniffing would have shown
> that we weren’t going to try authenticate them.
>
> As Andreas points out, it should not reply with 100 Trying once it has
> exceeded the threshold.
>
>
>
>
>
>
>
> *From:* Lorenzo Mangani [mailto:lorenzo.mangani at gmail.com]
>  *Sent:* 07 May 2012 10:01 PM
> *To:* Matthew Ogden
> *Cc:* Andreas Granig; spce-user at lists.sipwise.com
>
> *Subject:* Re: [Spce-user] autoban or fail2ban
>
>
>
> Matthew,
>
>
>
> Once the source is banned, the REGISTER requests are not forwarded
> internally to the database, so there are zero chances of brute forcing
> anything. The scanner might as well guess and never know; Anyhow, sometimes
> sending back a false 200 OK can help stop the flooding if it the
> "unfriendly" scanner is in stateless mode, wasting your bandwidth or
> cluttering your monitoring. They'll get a useless password and your attack
> should drop.
>
>
>
> Best,
>
>
>
> Lorenzo Mangani
>
> QXIP.NET
>
>
>
> On Mon, May 7, 2012 at 9:05 PM, Matthew Ogden <matthew at tenacit.net> wrote:
>
> Thanks, so if I understand this correctly then,
>
> You have your defaults at 20 times per 2 seconds. But, at this point, pike
> is not banning them from trying to connect, it is simply ignoring trying to
> authenticate them, is that correct?
>
> In other words, I will continue to see their traffic hitting my network
> card, in and out, and entries in ngrep? But they are very unlikely to
> succeed in brute forcing a password? (Or perhaps I have misunderstood this)
>
> As so:
> (Friendly scanner indeed!)
>
> U 2012/05/07 20:02:08.715659 213.189.34.21:5341 -> MY_SERVER_IP:5060
> REGISTER sip:MY_SERVER_IP SIP/2.0'
> Via: SIP/2.0/UDP 213.189.34.21:5341;branch=z9hG4bK-285169266;rport'
> Content-Length: 0'
> From: "102" <sip:102 at MY_SERVER_IP>'
> Accept: application/sdp'
> User-Agent: friendly-scanner'
> To: "102" <sip:102 at MY_SERVER_IP>'
> Contact: sip:123 at 1.1.1.1'
> CSeq: 1 REGISTER'
> Call-ID: 828443369'
> Max-Forwards: 70'
> '
>
> #
> U 2012/05/07 20:02:08.715727 MY_SERVER_IP:5060 -> 213.189.34.21:5341
> SIP/2.0 100 Trying'
> Via: SIP/2.0/UDP 213.189.34.21:5341;branch=z9hG4bK-285169266;rport=5341'
> From: "102" <sip:102 at MY_SERVER_IP>'
> To: "102" <sip:102 at MY_SERVER_IP>'
> CSeq: 1 REGISTER'
> Call-ID: 828443369'
> Server: Sipwise NGCP LB 2.X'
> Content-Length: 0'
> '
>
> #
> U 2012/05/07 20:02:08.728398 213.189.34.21:5341 -> MY_SERVER_IP:5060
> REGISTER sip:MY_SERVER_IP SIP/2.0'
> Via: SIP/2.0/UDP 213.189.34.21:5341;branch=z9hG4bK-1723630567;rport'
> Content-Length: 0'
> From: "102" <sip:102 at MY_SERVER_IP>'
> Accept: application/sdp'
> User-Agent: friendly-scanner'
> To: "102" <sip:102 at MY_SERVER_IP>'
> Contact: sip:123 at 1.1.1.1'
> CSeq: 1 REGISTER'
> Call-ID: 4175934776'
> Max-Forwards: 70'
> '
>
> #
> U 2012/05/07 20:02:08.728478 MY_SERVER_IP:5060 -> 213.189.34.21:5341
> SIP/2.0 100 Trying'
> Via: SIP/2.0/UDP 213.189.34.21:5341;branch=z9hG4bK-1723630567;rport=5341'
> From: "102" <sip:102 at MY_SERVER_IP>'
> To: "102" <sip:102 at MY_SERVER_IP>'
> CSeq: 1 REGISTER'
> Call-ID: 4175934776'
> Server: Sipwise NGCP LB 2.X'
> Content-Length: 0'
>
>
>
> -----Original Message-----
> From: spce-user-bounces at lists.sipwise.com
> [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of Andreas Granig
> Sent: 07 May 2012 08:46 PM
> To: spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] autoban or fail2ban
>
> Hi,
>
> On 05/07/2012 08:35 PM, Jon Bonilla (Manwe) wrote:
> > The spce has SIP attack protection against DOS and DDOS attacks.
> >
> > If you're talking about ssh or similar you should use iptables. Please
> > check the security chapter of the handbook.
>
> To make it clear, flood traffic above a certain threshold is blocked in
> user-space on the load-balancer. You can check the blocked ips with the
> following command:
>
> ngcp-sercmd lb htable.dump ipban
>
> Every time an IP gets into this blacklist, a warning is logged in
> kamailio-lb.log, using this kamailio config line:
>
> xlog("L_WARN", "IP '$var(banip)' is blocked and banned - M=$rm R=$ru F=$fu
> T=$tu IP=$pr:$si:$sp ID=$ci\n");
>
> Sometimes it makes sense to block the traffic on kernel level already to
> keep the receive queue clean, so fail2ban could make sense here. See the
> section "Fail2Ban" in
> http://kb.asipto.com/kamailio:usage:k31-sip-scanning-attack (the rest is
> already implemented in the SPCE), just adapt the "failregex" to the log
> message shown above.
>
> Andreas
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>
>
>
>
>
> --
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20120810/c4e8d9af/attachment.html>


More information about the Spce-user mailing list