Snort and VoIP
-
Good afternoon, I seem to be having an issue when I run Snort on a new installation. So we have just setup a completely new network, the previous network we had 5 VoIP phones connecting back to a remote PBX which have been pretty stable and remain connected. With the new setup we set up last week I had the 5 phones connected and over the weekend they were online. Now on Friday the day of the installation I noticed the phones were not connecting reliably so I turned off Snort and then shortly after the phones all connected.
Today we resumed our work and noticed ne extension was offline then 2 more, so I logged into the firewall and noticed Snort was running, so it turned itself back on, after poking around a bit I then not only turned the service off but disabled it, again shortly after all 5 connected and have been connected for about 6 hours. What could cause this in Snort?
-
@stormgate If Snort blocks IPs, you should see entries on the Alerts tab.
If it's a new Snort install, I'd advise not enabling blocking for a day or three in order to look for false positives on said Alerts tab.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@steveits Oh that's a good idea, then I don't risk getting locked out. Thanks
-
@steveits Yup, you can also download the alerts, they'll be in csv format.
-
Is this the sort of noise Snort produces, this seems to be a dominate alert today and I have to assume this could be communication from say a user's mobile connected on our side of the firewall possibly. I'm still just viewing the traffic, no blocking.
-
@stormgate said in Snort and VoIP:
Is this the sort of noise Snort produces, this seems to be a dominate alert today and I have to assume this could be communication from say a user's mobile connected on our side of the firewall possibly. I'm still just viewing the traffic, no blocking.
Yep, really just noise these days as pretty much 100% of email traffic is now encrypted. So IMAP is really IMAPS, and POP3 is POP3S (meaning carried over TLS). That means Snort can't see the real payloads unless you are using a proxy and MITM SSL termination/interception. The encryption can easily confuse the rules because the random bits of encrypted data may occasionally match what a rule is looking for without actually being "bad or malicious traffic".
I would disable that rule.
And to be perfectly honest (and I am the package maintainer for both Snort and Suricata on pfSense as I say this), Snort and Suricata are becoming less and less useful due to the rising use of end-to-end encryption of network traffic. Neither package can see anything of real value in encrypted packets without MITM. In fact, end-to-end encryption at the client level is on a path to totally upend all so called Next Gen firewalls that purport to perform DPI (deep packet inspection).
-
@stormgate Is the 7* address your WAN IP? I'd suggest running Snort on LAN instead. Otherwise it will scan packets before they reach the firewall, and end up blocking a lot of packets that would get blocked by the firewall. Running it on LAN also will show the LAN IP of the device.
The magnifying glass icon will attempt a DNS lookup on the IP.
I have occasionally seen what I think is mobile devices trigger odd alerts, and I say that because it's connecting to a Verizon IP. Seems dependent on the client and/or device though.
-
@steveits That is interesting Steve, I would have thought you would want the WAN as the best attack point from coming in, no? Yes masked "7" is the WAN IP.
-
There are two shortcomings to putting Snort on the WAN. First, most firewalls are going to deny all unsolicited inbound traffic. Snort sits out in front of the firewall engine, so it would waste CPU cycles analyzing traffic the firewall is likely going to drop anyway via its "default deny" rule. The second issue is that because Snort sits between the physical NIC and the firewall engine, it will see all outbound traffic with NAT already applied, and all inbound traffic before NAT is unwound. Thus all your LAN IP addresses will be obscured as everything "local" will show up with the WAN's public IP address. That makes identifying an infected local host much harder.
Now if you are not using NAT, and if you have several permanently open firewall ports, there is a small case to be made for putting Snort on the WAN. But even then I still suggest leaving it on the internal interfaces. No traffic can get to your internal hosts without traversing the internal interfaces of the firewall, so putting the IDS/IPS there is sufficient to protect internal hosts. You hopefully are not using Snort to protect the firewall. If the firewall is so insecure it needs an IPS to protect it, then there are much more pressing issues
.I've shared these two diagrams many times already, so once more won't hurt. Here is where Snort (or Suricata) sits in the network traffic path:
-
@bmeeks Very cool, so basically I could simply disable the current WAN interface on Snort and then create a new Snort interface for all my Vlans accessing the internet. So I am running a Netgate 6100 Plus if that makes any difference.
-
@stormgate Or technically you could change the "Interface" setting. Might be useful to keep them separate though, to refer to, and the suppression lists may not apply (using the router WAN IP for instance)
re: VLAN, run it on the parent interface because it will see all VLAN packets.
-
@SteveITS is correct. If you have VLANs, only run a single Snort instance on the parent VLAN physical interface. It will see all traffic because by default Snort runs in promiscuous mode.
There is a balancing act, though. If you have lots of interfaces or separate networks, and each of those networks is rather unique in terms of threat exposure, that would potentially translate into lots of Snort instances running. Those instances can start to chew up RAM and CPU cycles. So plan carefully. But also remember what I said about encryption and how that is severely handicapping what an IDS/IPS can actually see. Perhaps scanning each interface individually is not really helpful ??
The best security these days is keeping all of your local clients and servers fully patched with security hotfixes!
-
@steveits Thank you so if my Vlan assignments are ix1.50, ix1.30 etc... then my common interface would be assigned ix1 for the Snort interface.
-
@stormgate said in Snort and VoIP:
@steveits Thank you so if my Vlan assignments are ix1.50, ix1.30 etc... then my common interface would be assigned ix1 for the Snort interface.
I will answer for Steve -- "yes, this will be sufficient". Just remember that the same rules are being applied for all of the VLANs on that physical interface. But usually that is fine.
