[SR-Users] dictionary attacks
Daniel-Constantin Mierla
miconda at gmail.com
Sun Oct 24 22:20:54 CEST 2010
On 10/24/10 10:12 PM, Sergey Okhapkin wrote:
> Correction - auth module is merged in 3.1, but auth_db modules are still
> separate.
yes, only auth modules were merged, like I wrote.
auth_db functions use return codes and API functions from auth module.
Cheers,
Daniel
> On Sunday 24 October 2010, Daniel-Constantin Mierla wrote:
>> probably omitted by mistake, but please keep the mailing list cc-ed.
>>
>> On 10/24/10 3:38 PM, Sergey Okhapkin wrote:
>>> Note that I check return code of www_authorize to be -1 (invalid user)
>>> and block IP in this case only. Other error codes should not block the IP
>>> address.
>> This one remembered me that in 3.1 we merged the auth modules and we
>> used the one coming from ser because it has better nonce protection and
>> other enhancements than kamailio version.
>>
>> That means the return codes have changed, the new ones are listed now at:
>> http://kamailio.org/docs/modules/stable/modules_k/auth_db.html#id2753068
>>
>> Added also note in migration wiki page:
>> http://www.kamailio.org/dokuwiki/doku.php/install:3.0.x-to-3.1.0#modules_k_
>> auth_db
>>
>> Cheers,
>> Daniel
>>
>>> On Sunday 24 October 2010, you wrote:
>>>> I watched live an attack on voipuser.org while running 3.1 before
>>>> release. It lasted 18 hours. I didn't want to ban it because was useful
>>>> for testing and see if it reveals any weak. In most of the cases it hit
>>>> pike module. I got some data and plan to make an article about it soon.
>>>>
>>>> Anyhow, as a result of that, default config for kamailio has a section
>>>> for detecting and banning such "bad" IPs, using pike to detect floods
>>>> and htable to keep it blocked. Search WITH_ANTIFLOOD directive. It can
>>>> be enhanced like you pointed here, so if the authorize fails, add the IP
>>>> in the banned list stored in htable.
>>>>
>>>> Using fail2ban together with IP tables has the advantage of dropping the
>>>> packets before getting to application and eating cpu, although in the
>>>> case of voipuser.org the cpu was not affected much - the rate was
>>>> 170-200 requests per second.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 10/24/10 3:06 PM, Sergey Okhapkin wrote:
>>>>> I'm second for fail2ban. I block IP addresses with failed registration
>>>>> attempts for 1 hour. Here is my setup:
>>>>>
>>>>> kamailio.cfg:
>>>>>
>>>>> if (is_method("REGISTER")) {
>>>>> if(www_authorize("", "subscriber")< 0) {
>>>>> if($rc == -1) {
>>>>> xlog("L_INFO","Invalid username from
>>>>> $proto:$si:$sp\n"); sl_send_reply("200","OK");
>>>>> } else
>>>>> www_challenge("", "0");
>>>>> exit;
>>>>> }
>>>>> ....
>>>>>
>>>>> /etc/fail2ban/filter.d/openser.conf:
>>>>>
>>>>> [Definition]
>>>>> #_daemon = kamailio
>>>>> failregex = Invalid username from ...:<HOST>:
>>>>>
>>>>> /etc/fail2ban/jail.conf:
>>>>>
>>>>> findtime = 600
>>>>>
>>>>> [openser-iptables]
>>>>> enabled = true
>>>>> filter = openser
>>>>> action = iptables-allports[name=OPENSER, protocol=all]
>>>>> logpath = /var/log/openser/openser # Replace with your sr log location
>>>>> maxretry = 10
>>>>> bantime = 3600
>>>>>
>>>>> On Sunday 24 October 2010, Uriel Rozenbaum wrote:
>>>>>> Juha,
>>>>>>
>>>>>> I think we should be specially careful about black-lists. We receive
>>>>>> many of these attacks in a per-day basis and a lot of them are from
>>>>>> residential addresses or university, so I'm guessing some kind of worm
>>>>>> or trojan performing the attack from various IPs.
>>>>>>
>>>>>> If you have the time, try fail2ban deamon. It can relate some
>>>>>> brute-force events and act accordingly blocking an IP on iptables,
>>>>>> executing a script. You send to "jail" those addresses for a period of
>>>>>> time, then you can get them out again; and of course you can manually
>>>>>> revert.
>>>>>>
>>>>>> Last, as a description of the attacks I saw, first it runs an NMAP
>>>>>> like scan checking which IPs answer from 5060, then it starts sending
>>>>>> registers (usually asterisk answers 404 if the user does not exist),
>>>>>> then when the proxy challenges, it interprets the user is found and
>>>>>> starts making dictionary attacks on the password (1234, admin, and so
>>>>>> on). Keep safe complicated passwords, make kamailio challenge
>>>>>> everything and you'll be safe. and again, fail2ban is a pretty good
>>>>>> solution for brute force.
>>>>>>
>>>>>> This might help you finding a solution for your attacks.
>>>>>>
>>>>>> Cheers,
>>>>>> Uriel
>>>>>>
>>>>>> On Sun, Oct 24, 2010 at 8:54 AM, Juha Heinanen<jh at tutpro.com> wrote:
>>>>>>> while doing some tests, i noticed that one of my proxies started to
>>>>>>> receive lots of register requests with different user names starting
>>>>>>> from a letter. there was also invite attempts in the logs. they
>>>>>>> came from ip 202.82.16.99 which according to traceroute is somewhere
>>>>>>> in china.
>>>>>>>
>>>>>>> should we start publishing a black list of these attack ip addresses?
>>>>>>>
>>>>>>> -- juha
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>>> list sr-users at lists.sip-router.org
>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>> list sr-users at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
More information about the sr-users
mailing list