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(a)tutpro.com> wrote: _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Using fail2ban together with IP tables has the advantage of dropping the packets before getting to application and eating cpu

On 10/24/2010 12:18 PM, Iñaki Baz Castillo wrote: You could spawn a Perl script that does it, but it'd be kind of slow.

I think to come up with a good way to implement this, it is necessary to recognise that there are many topologies other than a firewall local on the Kamailio host that need to be accommodated, as well as an asynchronous architecture. Many people would not want spam requests to even get to the Kamailio box to take up any resources, however small (netfilter), once they have been determined to be spam. Some sort of IPC queue that can be consumed by an outside, non-Kamailio process would probably be the best way to do this. Many commercial routers (such as Vyatta) are beginning to have firewall control APIs via HTTP/REST with which rules can be added. Adding a ban rule to the router is something that could be done with utils:http_qiery(). Blocking could probably be fixed by deferring the HTTP requests with mqueue + rtimer.

On 10/24/2010 03:16 PM, Daniel-Constantin Mierla wrote: I did not mean the invocation of the interpreter; I just meant that there is always overhead when data interchange to an outside process is involved.

On the other hand, it gives you the ability to use the full capabilities of Perl, of course, instead of being limited to Kamailio script.

On 10/24/2010 03:34 PM, Daniel-Constantin Mierla wrote: Oh, I did not realise it is so persistent. I thought it worked more like Apache's mod_php, where the interpreter and dependencies are loaded into memory so that the entire language runtime does not need to be initialised each time a script is invoked, but the script itself is still loaded anew every time. What you are suggesting is that the 'perl' module works more like mod_perl, where the user-supplied script itself is loaded into memory persistently?