Thanks! Kamailio is up. Now I need to make it working... :-)
On Sunday 24 October 2010, Daniel-Constantin Mierla wrote:
> please start a new email each time you have a different topic, do not
> reply to old messages, otherwise the subject is misleading and the
> discussion gets in former email thread.
>
> Use as first parameter "$fd" for proxy_authorize() and "$td" for
> www_authorize() (same for challenge counterpaths) -- you can see the
> kamailio.cfg shipped with 3.1. These were the implicit values taken when
> the parameter was empty in the older versions. 3.1 deliberately asks for
> the the parameter, the docs have to be updated.
>
> Cheers,
> Daniel
>
> On 10/24/10 10:44 PM, Sergey Okhapkin wrote:
> > 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#id27530
> >>>>68
> >>>>
> >>>> Added also note in migration wiki page:
> >>>> http://www.kamailio.org/dokuwiki/doku.php/install:3.0.x-to-3.1.0#modul
> >>>>es _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
>
_______________________________________________
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
