[OpenSIPS-Users] attack from friendly-scanner

SamyGo govoiper at gmail.com
Tue Oct 9 18:58:07 CEST 2012


Just a quick reply while I can : *Honeypot*
Attract flies and kill them. An intelligently created honeypot-network
across VoIP-Friends/Colleagues can be a very useful and beautiful thing.

Hope to reply in detail later if needed (lesser chances as Brett has
already covered pretty much everything).

I hope OP has his question answered.


On Tue, Oct 9, 2012 at 9:42 PM, Brett Nemeroff <brett at nemeroff.com> wrote:

> Sammy,
> Thanks for the detailed and well thought out replies. Of course nothing is
> CPU free. However, if you use a method that uses a lot of CPU, such as a
> per call source IP db lookup, it's going to totally hose the box up. Point
> is, you need to be able to handle an intrusion without tying up critical
> system resources if at all possible.
> iptables with fail2ban is a good way to block, but it's not without it's
> problems. By the time you block in fail2ban, they already know you are a
> SIP server. You are now "on their hit list". So the "drop()" suggestion is
> to prevent your box from appearing to be alive and "juicy".
> Keep in mind, even with fail2ban and iptables, the traffic is still
> hitting your box and using up valuable network resources. The higher up in
> the network stack you can block the offender the better.
> I do think that a community ran sipvicious list would probably be good.
> Something similar to Vipul's Razor. However, there is a horrible
> opportunity for this to be abused and it would require some policing. On
> that note, nothing stops you from using fail2ban to create your own pool of
> offenders. I like to make one of my fail2ban actions be a http request to
> another server.. That OTHER server is also running fail2ban, detects the
> http hits and logs the request (which contains the original offender's IP)
> into a central DB I can use for blocking.
> As Sammy said, this is a very complicated issue and as of about 2-3 years
> ago has become an issue we all deal with on a regular basis and it's a big
> pain. I'd love to see something a little more unified as a system to block
> this kind of traffic.
> Just keep in mind, if you arn't being attacked, you *will* be attacked.
> You can delay the point in which you are attacked by hiding. Or ultimately
> don't put your server out there where just anyone can hit it. :)
> -Brett
> On Tue, Oct 9, 2012 at 2:11 AM, SamyGo <govoiper at gmail.com> wrote:
>> Hi,
>> Very nice suggestions by Brett. I remember there are regular thread like
>> these on the mailing lists and people share a lot of experiences. AFAIR
>> there was some service which contains the IP addresses of known attackers
>> available for users. OP needs to do some searching in this regard to
>> collect more ideas.
>> * Nothing is _NOT_ CPU cycles free *
>> I'm not sure about sip vicious but if I were to detect and hack a SIP
>> server I'd first start by sending OPTIONS on its ports. Mostly that's where
>> things kick off. Changing the user-agent field is nothing big, so question
>> is how do you know a hacker is about to get angry !!
>> I'd say it needs a time populated repository and a well crafted shell
>> script to maintain the list of Hacker IPs captured in the past and use it
>> across all the servers or devices. Let me explain the idea.
>> * ii)* - For any incoming packets one needs to look-up the hacker's
>> listing and detect if a known hacker or not.
>>  *i)* - Take fail2ban for example, or pike module , or iptables rate
>> limit mechanism to initially detect a new born hacker trying to access your
>> sip server (yes will take few minutes to finally conclude that a particular
>> source IP is hacker) - Store that IP in your hacker's listing.
>> *iii)* - Use an intelligent script to share the detected hacker's IP
>> across all the other SIP servers and router devices/firewall to block the
>> traffic at network layer.
>> *Critical Exceptions:*
>> Always ensure that the IP which is going to get blocked across the whole
>> network perimeter is not your own server or within the same subnet as
>> your's. It shouldn't be localhost as well.(Hint: IP spoofing)
>> *Focus on Security rather Friendly-scanner:*
>> *
>> *
>> One need to secure each and everything when it comes to security, just
>> one layer security  i.e fail2ban or iptables or pike module is never
>> enough. Like Brett said you can drop packets once detected a "very friendly
>> scanner", how about a customer who wants to toy with your service ! how
>> about a massive DoS attack !! drop() won't help alone. iptables needs to be
>> there to stop the packets from even reaching the SIP server app, then again
>> why should the server's NIC be chocked up by that massive DoS ! your
>> firewall or networking device should stop the packets from entering the
>> network !
>> This is just not enough: How about a different unique new tool which
>> sends malicious or malformed SIP packets to crash the server !! its just
>> one packet but malformed -- all the above measures WILL fail !! Obviously
>> needs to go one step ahead and use SNORT or anything like IDS+IPS to verify
>> that the packet going through the network is not malformed.
>> Thats pretty much it for now. There are things which I've forgotten to
>> write at the moment OR might not even know which I expect some one else may
>> like to add.
>> Networks and Data Security is a huge field, and VoIP security alone has
>> hundreds of book on the topic.
>> *Interesting threads to read: *
>> *
>> *
>> http://lists.opensips.org/pipermail/users/2010-November/015243.html
>> http://lists.opensips.org/pipermail/users/2011-June/018271.html
>> Read: http://blog.sipvicious.org/ to know more about the tool we all
>> face every once a while.
>> Fail2ban for openSIPS ::
>> http://www.opensips.org/Resources/DocsTutFail2ban
>> --
>> Best Regards
>> Sammy
>> On Mon, Oct 8, 2012 at 6:31 PM, Brett Nemeroff <brett at nemeroff.com>wrote:
>>> First of all,
>>> This is an attack from sipvicious. It is an *attack*. It will be very
>>> high rate (cps) and you do *not* want to use anything that consumes
>>> resources to attempt to block it.
>>> First recommendation is to use iptables. In addition, you *should* put a
>>> check in your config for friendly-scanner and drop() the packet. Do not
>>> reply with a sip code. You want to be invisible to the attacker. If you
>>> reply with a sip code, they'll just scan you attempting to find a request
>>> combination that will return a usable result.
>>> 1. Do whatever you can to not use CPU resources to block this
>>> 2. Don't look like a SIP server to source IPs you do not recognize
>>> I guarantee, if you look like a SIP server, you will get brutally
>>> attacked from unsolicited sources.
>>> Read up on the fail2ban docs for asterisk. They have some good ideas in
>>> there on how to perform intrusion detection and how to automatically add
>>> offending traffic to fail2ban. You can do something similar in OpenSIPs.
>>> I would be very curious to hear about other people's experiences using
>>> the Pike module to block this type of traffic. For what it's worth, I've
>>> seen attack traffic high enough in bandwidth to saturate a pretty beefy
>>> internet connection and I've even seen it crash routers. If you can avoid
>>> them finding you in the first place, that would be a much better option.
>>>  -Brett
>>> On Mon, Oct 8, 2012 at 7:53 AM, Engineer voip <forvoip4 at gmail.com>wrote:
>>>> Hi,
>>>> I'm trying to use pike module and i'm using the script above, but when
>>>> i execute this command " opensipsctl fifo pike_list"
>>>> i don't get any address blocked
>>>> My opensips config is:
>>>> loadmodule "pike.so"
>>>> modparam("pike", "sampling_time_unit", 10)
>>>> modparam("pike", "reqs_density_per_unit", 30)
>>>> modparam("pike", "remove_latency", 120)
>>>> modparam("pike", "check_route","pike") # enable automatic checking
>>>> modparam("pike", "pike_log_level",1)
>>>> route[pike]
>>>> {
>>>>  if (src_ip==x.x.x.x ||src_ip==gw_ip) # Trusted IP
>>>>   xlog("L_INFO", "in pike route ");
>>>>   drop();
>>>> }
>>>> have you an idea please toresolve that?
>>>> 2012/10/8 SamyGo <govoiper at gmail.com>
>>>>> Hi,
>>>>> Relax it says its Friendly !!
>>>>> But still if you want to block it you've many options i.e in
>>>>> opensips.cfg start put a condition $ua =~ "friendly-scanner".  If matched
>>>>> return stateless some error.
>>>>> Other option is to use pike module.
>>>>> Another option is use fail2ban for opensips logs.
>>>>> More sophisticated options involve firewalls with IPS and IDS modules.
>>>>> I hope it was helpful.
>>>>> BR
>>>>> Sammy
>>>>>  On Oct 8, 2012 2:33 PM, "Engineer voip" <forvoip4 at gmail.com> wrote:
>>>>>> Hi All,
>>>>>> I receveid several packets of registration from a "friendly-scanner"  on my opensips server
>>>>>> how can i do to block that please??
>>>>>> --
>>>>>> Best Regards.
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> --
>>>> Best Regards.
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121009/4b1795c5/attachment-0001.htm>

More information about the Users mailing list