Correction - auth module is merged in 3.1, but auth_db modules are still separate.
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<j...@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
