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#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

--
Daniel-Constantin Mierla
http://www.asipto.com


_______________________________________________
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

Reply via email to