How do I NOT block PCI scans on WAN ports?

[NeilG]

I am trying to determine what I am doing wrong. I' m working with a vendor who requires that they scan the external (WAN1) interface of the firewall for PCI compliance audit check process. To that effect they require a range of IP addresses to be " whitelisted" within IPS. I thought I had done that by doing the following: [ul]

For the IPS profile that is assigned to the SSLVPN port, for each policy add the IP address/subnet mask to the IP exceptions list

Reboot the firewall

[/ul] The vendor performing the scan' s indicates that they are still being blocked. Have I " whitelisted" them wrong? Is there a better way of doing this? Thanks in advance! -Neil

[NeilG]

dfollis wrote:

I'd push back against the auditors, you have a right to despite what they imply.  I have to all the time.  

<snip> 

Like others have said, they should be able to scan your open ports (I'll assume you have 80, 443, and perhaps 23 open) and run recon that way.  That is how an attacker would do it.  White-listing them so their scans will succeed doesn't make sense.  Scanning as you have it will provide a more accurate result as it will demonstrate what an attacker is actually able to see.

In this case the only external ports are SSLVPN on the fortigate itself, and this scan has to pass every quarter so the configuration is ongoing.

The worst is that with no firewall changes, scans that last quarter pass, now this quarter fail saying they are being blocked on 443 which is the SSLVPN.

IPS logs shows NOTHING, I had already created a WAN->ALL rule with an IPS whitelist, and modified the WAN->ROOT(SSLVPN) rule to whitelist the IPS for their IP range.

Other than reboots, nothing had changed between the pass/fail. but then the last pass before that failed due to not having 2FA, which we now have -- and they have no way of testing for without a valid login.

This whole PCI-DSS external vulnerability scan seems lame - since their old, weak, IPS provided modem/router "firewall" always passed without fail.

How ridiculous is that, that a cheap home firewall passes the PCI external vuln scan but a UTM device takes 8-20 hours of time every 90 days to get to pass.

-Neil

[seadave]

Target and Home Depot were PCI Compliant.  I would try and work with the auditors to gain a more accurate benchmark.  I would say give them a test login to simulate someone stealing credentials, but now that you have 2FA, that is less likely to occur.  Then again if someone has a bot on a home computer they can attack you that way even with 2FA unless you sandbox their connection adequately.

Unless you are a Security Manager and audits are your primary responsibility I would go to your Finance/Regulatory department and explain the situation to see if you can find another metric since it is wasting so much of your time.  I definitely would not lessen my rules to allow them to get a "good" scan.  That defeats the entire purpose of the exercise.    Good luck.

[Dave_Hall · Accepted solution]

NeilG wrote:

In this case the only external ports are SSLVPN on the fortigate itself, and this scan has to pass every quarter so the configuration is ongoing.

If the scans are directed at the Fortigate itself, you will likely need to set up a local-in policy to handle that traffic. By default, the fortigate has "open ports", which are shown (if feature is enabled) under policy/policy/local in policy. 

[ShrewLWD]

Hi everyone,

It seems the majority of the responders, while thinking logically, have not had to do PCI Audit Compliance scanning.

PCI will not accept our say-so on what ports are open, and what ports are not, they MUST find out for themselves, determine what is listening on that port, and then test that application against a set of known vulnerabilities.

Their sweep is incidental (while critical) to them testing the application that is internet facing.  Given how prevalent exploits are for specific applications, hackers don't often do full sweeps anymore, they just go looking for those open ports.  PCI needs to know those applications are updated with fixes, and not just relying on a UTM feature of the firewall to protect it.

Because of this, they must be able to do a full sweep, and they must be able to do an unhindered vulnerability assessment of the application behind it.

[RyanKam]

Solved: So the issue that is happening with NeilG and the same with me is this. When you enabled SSL-VPN and/or turn on HTTP and/or HTTPS access on your firewall it is creating webserver ports that are being scanned. The internal webserver on the firewall doesn't allow  multiple connections and blocks the server from scanning everything it needs to scan. There is no way that I know of to let the server on the firewall allow this to happen. IPS and all that other whitelisting doesnt work. The way I got it to work was to do the following:

1. Create ports under: "Services". Add the ports that are listed under the SSL-VPN and settings. Usually 443, 80, and what ever your VPN port is. (SSL-VPN Settings)

2. Create Virtual IP: Map the IPv4 to 1.2.3.4. Toggle on Optional Filters and toggle on source address. If you use Qualsys as the engine for PCI scans you want to add 64.39.96.0/20 and 139.87.112.0/23 as source addresses. This may be different for your company. Check your scanner page right before you schedule a scan and it will tell you what servers are scanning you. Under Services toggle that on and add those ports your created under "services".

3. Under firewall policy create a new policy and set the following:

Incoming interface: Wan1

Outgoing interface: internal

Source: all

Destination: <Add your virtual IP>

Schedule: always

Services: all

Action: Deny

You are all done. Make sure that policy is enabled and you will be able to access all your open ports on the firewall but the scanner will be banned from scanning your firewall ports and allow you to pass the scan. You dont need an actual computer at 1.2.3.4 its just going to come back as a dead server.