Built-in VPN Connected Phones causing failures of security probing from Nessus

We are having issues with the phone system (PBXact UC 100) causing HIGH LEVEL vulnerability reports using Nessus scanning software. We have to perform these scans for several clients to assure both corporate security policies and PCI compliance are met quarterly.

It appears to be with the remote connection ports being open to the phone system through the firewall. We have had to write detailed quarterly reports explaining the need for these remote access ports to get the PCI people satisfied and explain it to corporate leadership. Is there anything anyone knows that could improve this issue? Does anyone else do security scans and have these issues? If so, how do you deal with this?

Explain your concern to us. I suspect this is a problem somewhere else in your config, but without some details, it’s a guessing game.

Also rememebe that automated security scans are flawed as they only look to major versions of software on the minor patch version that RedHat does so most scans give back false positives.

We are using Nessus and it is not an automated scan. It is pretty accurate.

[Dave Burgess] What information could I provide to you? I have a multi page Nessus report but it is confidential. Specifically, what info would be helpful?

The most obvious would be the ports (not the addresses, just the ports) that Nessus is complaining about.

For example, 5060 might be open because of the Adaptive Firewall, which is true, but the risk is limited by the adaptive firewall. It’s also possible that port 5060 (or even 5160) is open on the Local LAN, but not routed by the outside router, limiting your exposure to local machines.

Also, because of the way that RTP works, you might have UDP ports 10000-20000 open, which is actually fine because the ports are only open on this server because we have to have a place to connect the RTP from a phone call.

The analysis on the ports might be simpler to explain (and possible to explain through to a long life-cycle document) once we’ve got a feel for what the ports are. Without specifics, though, you are going to get non-specific answers, which isn’t really going to get you where you want to go.

It’s actually port 1194, the openVPN that is throwing up the High Risk alert.

But why is having that port open casuing an alert. It’s a port for VPN. If they don’t like it shut it down and do a hardware VPN but my guess is they will compain about that next. If you want outside people to connect you need ports opened. If they have a known security vuln that is not patched on your PBX for openvpn than complaining about the port being opened is legit but on SNG7 we sync monthly from upstream CentOS.

Agreed, but when people reading a vulnerability report see a HIGH on the list, they freak out. Mostly it’s the %[email protected]# credit card PCI people, whom I happen to hate :slight_smile:

I have to complete the quarterly PCI compliance rubbish for the credit card payments vendor too… it’s a ballache but not particularly terrible. The report runs, highlights the issues, you respond with the justification for the open ports and the security steps taken to mitigate the risk and they nod, smile and say OK for another three months.

If your hardware/connections permit it, you could choose a non-standard port for your VPN/SIP traffic etc - if the connections are UDP and you’re not using a well-known port the highlighted “issue” may just vanish

Thank you, that is what we do every quarter as well, but it seems they never get it and are getting more pushy as time goes along. I appreciate having another person’s experience to convey to our clients.

If I was running the scans, I’d start the report with the “standard” response to the items that you know are coming. I don’t know exactly how you start up your quarterly assessment, but including something to the effect of “We expect the following “HIGH RISK” items to be in place. The following specifics are expected and deviation from these norms should be construed as an interest item.” Then list out the specific items that NESSUS is going to find. If you find deviations, document those as “fails”.

When I was working with Nagios (in the early days), there was a lot of discussion about what a “fail” should look like. Port 666 (SATAN) being open was an automatic failure, and port 25 (SMTP) being closed was also a fail. In your case, since the OpenVPN port needs to be open, any other state should flag as a fail. Sure, lots of other people want that port closed, but since you are using OpenVPN, you need it open. Seem pretty logical to me.