[OpenSIPS-Users] attack from friendly-scanner
brett at nemeroff.com
Tue Oct 9 18:42:04 CEST 2012
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. :)
On Tue, Oct 9, 2012 at 2:11 AM, SamyGo <govoiper at gmail.com> wrote:
> 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: *
> 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
> 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.
>> On Mon, Oct 8, 2012 at 7:53 AM, Engineer voip <forvoip4 at gmail.com> wrote:
>>> 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)
>>> if (src_ip==x.x.x.x ||src_ip==gw_ip) # Trusted IP
>>> xlog("L_INFO", "in pike route ");
>>> have you an idea please toresolve that?
>>> 2012/10/8 SamyGo <govoiper at gmail.com>
>>>> 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.
>>>> 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
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>> Best Regards.
>>> Users mailing list
>>> Users at lists.opensips.org
>> Users mailing list
>> Users at lists.opensips.org
> Users mailing list
> Users at lists.opensips.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users