I'm working on migration of my kamailio.cfg from v1.4 to 3.1 and stuck with
weird problem:
0(25026) ERROR: auth_db [authdb_mod.c:236]: empty parameter 1 not allowed
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:433
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:438
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:445
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:445
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:445
0(25026) ERROR: <core> [route.c:1161]: fixing failed (code=-1) at
cfg:/usr/local/etc/kamailio/kamailio.cfg.31:451
ERROR: error -1 while trying to fix configuration
The complained lines are calls like
proxy_authorize("", "subscriber")
proxy_challenge("", "0")
According to auth_db module documentation the "realm" parameter can be an
empty string, but code in modules_k/auth_db/authdb_mod.c line 236 explicitly
checks that parameter value must be non-empty.
On Sunday 24 October 2010, Daniel-Constantin Mierla wrote:
> 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<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
>
_______________________________________________
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
