Jeff Lenk added a comment - 30/Sep/11 8:36 AM This is a change that it would be great if someone contributed code using the following patch as the basis for firewall control under Windows. Most Linux users are using fail2ban for this type of thing. http://jira.freeswitch.org/browse/FS-3094

Yuri Ost added a comment - 30/Sep/11 1:28 PM One of the reasons why I've posted here was the scary thought that I had, when I discovered the attack. What if I did not watch FS closely enough and just left it run unattended for a while? May be FS got eventually hacked with a proper guess, leading to interruption of service and other related problems? Logs were made in a pace more then hundreds megabytes per day, there is a big and unnecessary IP traffic, etc. I was lucky to discover it early. I'm running FS on Windows Server. And there is no way to recognize and block such attack by router's firewall (I guess it's possible with more expensive enterprise type routers, but not with $400 one that I use). The traffic may look legitimate to it. Only FS can find out, that stream of REGISTER requests, using guessed account names, means that someone is probing it. And FS can do it right at the beginning of the attack. There is no legitimate reason to send a stream of REGISTER requests from the same host with random accounts and / or send a big stream of INVITE requests, even all of them are rejected... This problem could be easy recognized in application layer. A simple and very effective protection could be implemented using a configured limit for allowed REGISTER requests from one host per minute, blocking it in case if it's reached. And FS should always check and apply it, even if someone tries to hack in it at 3AM... Otherwise I can't consider FS as a safe and reliable service.

Anthony Minessale II added a comment - 30/Sep/11 1:41 PM FreeSWITCH is heavily influenced by UNIX and the UNIX philosophy is do one thing and do it well. So re-inventing the auto ban wheel within FreeSWITCH may be a large task to perform and possibly could create regressions and who knows what else. As Jeff described there is a patch to fire events which could be monitored by a program that could block the ports at the OS level which is much better protection than trying to ignore the packets from the application layer. Meanwhile, if you want to be safe, use the provided ACL feature to whitelist your devices and have a default deny blacklist. We have a saying in open source land.... Patches Welcome!

Yuri Ost added a comment - 01/Oct/11 2:11 AM I see your point and agree with it - it's always better do thing in one place. But: 1. Windows is different form other OS and doesn't have the capability, mentioned above (dynamically block hosts) 2. FS is the best place to recognize the start of account probing attack (watch for two requests REGISTER and INVITE and see). FS knows if REGISTER request failed and if it fails many times during some period of time - it means just one thing - a probing attack. In this case FS may just drop any further requests from the same host. Why do we need a third party process, that will do that logic and why do we need a firewall to block the host? It's like trying to block with firewall password guessing attack...Possible, but not the best way. It all means one thing to me - running FreeSWITCH on Windows, I have always watch it closely, all the time. Not a fun... BTW, how do I suppose to even find out, that someone starts account guessing attack with the latest change in sofia_reg.c file (2011-09-21) , which has downgraded the logging level for REGISTER events from SWITCH_LOG_WARNING to SWITCH_LOG_DEBUG10? By default, I don't see register attempts anymore... So, now hackers may start probe my FS configuration at any time, and I will not even know about it... In other words, additionally to inability on Windows platform to recognize and prevent attack automatically, I lost even ability to see it too. May be that's the plan and I should feel better now - don't worry, be happy. Right? ;)

Anthony Minessale II added a comment - 01/Oct/11 3:01 PM I guess I can put it back to warning but it's rather annoying. Ideally you would apply the patch jlenk was talking about and then write an event listener app to pick up on it. BTW Did you miss my suggestion about ACL?

Yuri Ost added a comment - 02/Oct/11 9:00 PM I agree with you. Logging all incoming REGISTER requests could be annoying and unnecessary. There should be a better solution. Could it be possible to set an option (using configuration file and a console command), that will control (turning on/off) logging successful registration events (very useful to troubleshoot some SIP clients)? At the same time, I think logging unsuccessful registration requests should be done at a warning level (as a warning about potential ongoing attack), the same way (and for the same purpose) as logging all unsuccessful INVITE attempts too. BTW, with regard to registration, it'd be nice to have a command that will display all currently logged accounts using very simple format - one registered client per line. I know that I can use 'F9' for checking, but that brings a lot of additional information for that simple task - to see picture of registered clients at a glance. Each line could contain just this info: account@domain , IP:port, last_time, expired. May be at the bottom it'd be nice to see a total number of registered clients. That simple and condense format will bring current picture of all registered clients. > BTW Did you miss my suggestion about ACL? No, I did not. With ACL I can statically block specific IP's (not domains though). That functionality also exists in other applications. To block specific IP's I can use (and actually do use): 1. Firewall, running on router (as a quick and dirty tool) 2. PeerBlock, running locally along with FS The latter is very effective tool to perform that task - blocking big lists of IP's (talking about philosophy to do one thing and do it well)... But, all three tools (ACL, firewall, PeerBlock) have one big drawback - they all are statically configured. I've started this thread specifically to deal with dynamic threats and protection from them in real time. Only FS can recognize threat in real time (watching REGISTER requests, hosts, sending them to FS, and how often they do that)... Later on I can add the host to a blocking list, no problem. But I can't do it at 3AM or if I'm in a business trip or vacation. Currently I can't leave FreeSWITCH unattended for a while, because it could be hacked by an attacker (blocking all IP's and then whitelisting only specific IP's is not an answer here - SIP clients can connect from any and random IP's). Without some kind of automatic protection mechanism - to make a right guess by attacker is just a matter of time. With current implementation of FS, if I live it for a while, there is a chance they could eventually get it "right"... Why we facilitate rainbow attacks, while they could be easily preventable?

Anthony Minessale II added a comment - 03/Oct/11 8:43 AM Ok, So you have defined a valid use case for developing this feature. That's a good first step. The next one would be to find a cross-platform solution to handle the problem and come up with the time and resources to implement the solution.

Marc Olivier Chouinard added a comment - 15/Dec/11 8:43 PM I've just crossread this... But wont fail2ban protect againt this ?

Avi Marcus added a comment - 21/Dec/11 1:13 PM iptables can rate-limit registrations and fail2ban can ban a register flood, even if it doesn't actually attempt to register with a bad password: http://wiki.freeswitch.org/wiki/Fail2ban#SIP_DOS_Attack This is only for *nix stuff though and not windows... Anthony: I wrote a patch for letting you choose if you want a) logging auth errors and b) logging auth attempts - you can turn on only one if you want. I put it in http://jira.freeswitch.org/browse/FS-3586

Jeff Lenk added a comment - 23/Aug/12 4:51 PM Attached a zip authored by Dave Kompel which is quite nice for this very purpose. this code uses mod_managed.

Yuri Ost added a comment - 02/Dec/12 2:28 AM Today I've noticed yet another type of DOS attack. During 7s sec remote host sent a flood of requests making FS to create more then 130 new channels. Here is one of such requests: ---------------- 2012-12-01 11:32:18.434313 [NOTICE] switch_channel.c:968 New Channel sofia/internal/test1234@IP.ADD.RES.FS[325a1026-bd26-446b-8456-fc669ac3a779] 2012-12-01 11:32:18.524450 [DEBUG] switch_core_session.c:975 Send signal sofia/internal/test1234@IP.ADD.RES.FS[BREAK] 2012-12-01 11:32:18.554496 [DEBUG] switch_core_session.c:975 Send signal sofia/internal/test1234@IP.ADD.RES.FS[BREAK] ... ---------------- After the first 41 new channels were created, FS reported bunch of errors: ---------------- 2012-12-01 11:32:19.686213 [CRIT] switch_core_session.c:2166 Throttle Error! 41 2012-12-01 11:32:19.686213 [CRIT] switch_core_session.c:2166 Throttle Error! 41 ... ---------------- Then it proceeded to serve other requests... generating next bunch of errors after a while, until more then 130 new channels where created/destroyed... 1. It's be very nice to stop this activity (making new channels) after very limited number of similar requests coming from a host with this pace. Let say after 5 or 10 new channels created, FS may stop accepting (and processing) new requests from that host. At this point it becomes obvious, that remote host tries to DOS FreeSWITCH. 2. I see that FS is able to recognize some (actually critical) problem, but the threshold is way too high (more then 40 channels were created before first error was reported). Is there any way to reduce that threshold (may be a configuration option) and stop further processing?