Hi, We run hosted Freeswitch instances in VMs with the internal profile on port 5060 connecting to clients mostly behind NAT and then the external profile connecting to our proxies only. Protecting the external profile its straightforward.. we only allow traffic to/from our proxies at the firewall level. But protecting the internal profile seems to be a bit more difficult because the UACs could be theoretically anywhere on the network. I'm currently using Fail2Ban to prevent brute force registration and INVITEs on auth failures, e.g.: failregex = \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(REGISTER\) on sofia profile \'\w+\' for \[.*\] from ip <HOST> \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(INVITE\) on sofia profile \'\w+\' for \[.*\] from ip <HOST> My question is, since its part of a normal SIP dialog to challenge the INVITE, is there any way to prevent a possible DoS from just sheer volume of incoming INVITEs on an Internet facing server automatically. I.e., If you block the logged challenge, you'd block all legitimate INVITEs and registrations. Since its UDP traffic I couldn't come up with a way to do it automatically at the iptables level. i.e. number of concurrent connections. Is there some option to just not respond if a client is sending a number of requests over a certain threshold? It might not stop them from sending the traffic but pretty soon they'd get the idea that it wasn't going to go anywhere. My concern is say there are 50 Freeswitch instances on a box (albeit 8 core, 32GB ram, 8 15K raid 10 storage) and someone starts sending thousands of rouge INVITEs to every VM on a physical box that the CPU load from just challenging the incoming INVITEs would create a DoS. We the logs regularly to try to catch people doing this sort of thing and drop them at a router upstream of the core network, but I'd like to have it happen without human intervention. Have I completely over thought this and am missing something obvious? Thanks, Spencer