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
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@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
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 jh@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
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 Heinanenjh@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
2010/10/24 Daniel-Constantin Mierla miconda@gmail.com:
Using fail2ban together with IP tables has the advantage of dropping the packets before getting to application and eating cpu
I have a testing platfotm with Kamailio and fail2ban working more or less as explained in this thread. But I wonder if fail2ban is a good idea as it works inspecting regular expressions in each line of the log. Is it good enough and feasible under high traffic? wouldn't fail2ban eat too much CPU by inspecting the log file? Just wondering.
Of course, the perfect solution would be Kamailio acting as fail2ban. This is, "pike" module inserting dynamic rules in iptables. Opinnions?
On 10/24/2010 12:18 PM, Iñaki Baz Castillo wrote:
Of course, the perfect solution would be Kamailio acting as fail2ban. This is, "pike" module inserting dynamic rules in iptables. Opinnions?
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/10 8:24 PM, Alex Balashov wrote:
On 10/24/2010 12:18 PM, Iñaki Baz Castillo wrote:
Of course, the perfect solution would be Kamailio acting as fail2ban. This is, "pike" module inserting dynamic rules in iptables. Opinnions?
You could spawn a Perl script that does it, but it'd be kind of slow.
If you use the perl module, then the perl interpreter is embedded, nothing is spawn. Same is with app_lua module and Lua scripts - execution should be very fast.
If you invoke other applications via exec() (exec module) then is spawning.
Cheers, Daniel
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:
If you use the perl module, then the perl interpreter is embedded, nothing is spawn. Same is with app_lua module and Lua scripts - execution should be very fast.
If you invoke other applications via exec() (exec module) then is spawning.
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/10 9:17 PM, Alex Balashov wrote:
On 10/24/2010 03:16 PM, Daniel-Constantin Mierla wrote:
If you use the perl module, then the perl interpreter is embedded, nothing is spawn. Same is with app_lua module and Lua scripts - execution should be very fast.
If you invoke other applications via exec() (exec module) then is spawning.
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.
what do you mean by outside process?
For example, with app_lua, the interpreter is linked to the code, so is no external process, it is like cfg interpreter, just that it resides in a module, not in core.
Cheers. Daniel
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:
what do you mean by outside process?
For example, with app_lua, the interpreter is linked to the code, so is no external process, it is like cfg interpreter, just that it resides in a module, not in core.
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?
On 10/24/10 10:14 PM, Alex Balashov wrote:
On 10/24/2010 03:34 PM, Daniel-Constantin Mierla wrote:
what do you mean by outside process?
For example, with app_lua, the interpreter is linked to the code, so is no external process, it is like cfg interpreter, just that it resides in a module, not in core.
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?
perl module loads the script specified by filename parameter in mod init. It parses it in the interpreter and then you can execute perl functions from inside the script at runtime.
So, it is not loading it every time a function is executed. There is some code to be able to reload, but afaik, feature was not finished.
Regarding lua, there are couple of functions, some of them allowing to execute parts of a file loaded at startup, other will load the script every time.
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Sergey Okhapkin -
Uriel Rozenbaum