Is there any reliable, easy way to check if the firewall is running via the command line that can either be put in a script or just checked by seeing if a file exists? Right now I just check a port that the firewall would block if it wasn’t running, but that seems like a rather unreliable way to test because, after a firewall restart, it takes quite some time for the rule to take effect on active connections.
This is rather important, as I have had more than one server hacked into because the firewall stopped running randomly and I had no idea until the damage was done. I have monitoring software, and I can set it up to trigger, but I need something to monitor.
FYI, checking /etc/asterisk/firewall.enabled does not work; it’s not always there. Monitoring the /tmp file is not reliable either. Scanning iptables is rather complicated for a yes/no script. Is there any other way?
Why doesn’t remote monitoring software work? Invert the check. It can alert you as soon as a port becomes reachable. Easy to manage too, as you don’t have to whitelist changing source IPs from someone like NodePing.
I think it’s better to monitor the firewall from outside the PBX. If you’re worried about the server being compromised, any monitoring running on the same server can potentially be disabled in seconds, along with the firewall.
Honest question, do you (or anyone else on the forum) have FreePBX directly accessible over the internet? If yes, why? I’d assume any production system would be on a private network with access and peering happening only through an SBC.
That assumes only on-premise deployments and not everything needs an SBC (since that is a specific piece of hardware) and no not everything needs to be on a private network.
But you’re also assuming that just because you’re on a local network behind an SBC that the system is 100% protected. It’s not, it still needs proper protection.
Yes it does, but, when the firewall is started, either from a restart, reboot or whatever, the test for an open port is considered “active/relevant” when it activates so it keeps allowing the traffic for about an hour to two hours before the firewall starts to block it. Yes, it does eventually work, and has saved me a few times, it’s just annoying to have that trigger for a couple of hours after the firewall starts up. I have had servers that for whatever reason the firewall didn’t start and I don’t realize it unless I check because after about three hours I notice the trigger has not cleared and I go into the GUI to see that it didn’t actually start. That is way to long to wait.
First, an SBC is only for SIP, I am not talking about SIP attacks. All the attacks are from REST, apps, and such. An SBC will not help, and actually make things a lot more complicated when you add in Sangoma Talk, WEBRTC and the many other protocols the server uses other than SIP. In order to provide theses services so that remote clients and such have access, you have to keep them open. The advanced firewall of FreePBX fortunately allows you to track the successful registrations so that the extra ports for other services are open to the active phone IP’s but not the world. Also it’s been a long time since I installed a premise system, they are almost all cloud servers now so yes, they all have direct internet access. I have not seen an SBC that can also do standard firewall and routing, and dynamically open TCP ports based on successful SIP registration addresses. Even for our customers that use a premise system, nearly all of them have remote locations, or use Sangoma Talk or services outside the local network. many of them the server and phones are on a dedicated network just for phone services, an SBC would just add another failure point, overly complicate things and not offer much advantage.
Anything that isn’t permitted by the firewall should be blocked within seconds of the firewall starting. The firewall starts minutes after a reboot.
If the monitor performs a fresh TCP/UDP probe each time, rather than holding or reusing an existing flow, then after the firewall rules are restored the next probe is new. It should be blocked immediately.
I am guessing it is not; it is holding the session open. Maybe I just need to lengthen the check times to let the TCP session timer expire. I don’t know how long that timer is.
Have you not looked at SBC’s these days? They do everything needed for communications, not just SIP. They handle RTP/SRTP, transcoding, Websockets/WebRTC, HTTP/HTTPS for RESTful APIs and A2P communications, etc for things like Teams and Zoom. They have legacy stuff like H.323 and ISDN/SS7 protocols.
Most of the SBCs out there on the market and even Kamailio or OpenSIPs can handle all that stuff.