Is event guard working
- Thread starter RTL
- Start date
You're right to think its odd, unless you're doing something to block public attempts you're going to get bots banging at your door, its just what happens when you're on the internet. If I suddenly saw nothing is getting blocked my first thought would be what's broken? Check your logs. The only time I'd be okay with nothing banging at the door is if I've hardened or hidden the door (non-standard ports, ACLs/FW rules blocking unknown IPs, etc...).
Not saying this is what happened to you, but I recall a group that was owning devices and patching/hardening them in order to prevent the vuln they used for entry to be used by another group, so a telltell sign that you've been owned was if you're not vulnerable to the exploit without having patched.
Not saying this is what happened to you, but I recall a group that was owning devices and patching/hardening them in order to prevent the vuln they used for entry to be used by another group, so a telltell sign that you've been owned was if you're not vulnerable to the exploit without having patched.
It's actually easier than that. Just use a port SIP scanners aren't programmed to test and you will see nothing in Event Guard.
Make sure you're not allowing 0.0.0.0/0 or something too permissive in ACLs, I only have my SIP providers subnets in mine. while non-standards ports stop most the attempts I'm not a huge fan of 'security through obscurity', especially when we have to deal with external IT and MSPs who are heavyhanded and refuse to be flexible.
Certainly not got 0.0.0.0/0 in the providers acl. I have acl's to restrict registrations for customers but the providers acl has providers ip's only. What I don't understand is that an ip which isn't in any of the acl's seems to be accepted by event guard as in the acl.
I've seen 20 or so this morning appear whilst I'm running event guard in debug mode.
I've seen 20 or so this morning appear whilst I'm running event guard in debug mode.
Security through obscurity may not be the best security tactic, but it certainly helps. When you run a hosted service and also have mobile apps, it's virtually impossible to lock your system down to just a few IPs. Clients connect from all types of networks. Some of them have dynamic IPs. Unless someone wants a full-time job managing whitelisted IPs every day, you have to open your service to the world. When security through obscurity fails, you end up with an SBC that has a better chance of protecting you from hackers.
Initially, I suggested that you may have a well-protected system. But there is always a chance that a bug exists in the version of Event Guard you are running. There is also a chance it's not designed to protect from whatever you are seeing. I would reach out to support and see if they have any ideas.
A way to test Event Guard is to register with a bad password or try and register to the IP address. However, you have to do this from an IP address that is not in the access control list and not registered to the system to intentionally get blocked. Using a mobile phone with Wifi turned off can help you do this without fully blocking yourself.
@RTL What is your version of FusionPBX?
@RTL What is your version of FusionPBX?
If I run event guard in debug then I can see the ip I'm trying to register from allowed by cache