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

[AndreaSoliva]

Hi what I do not really understand is why you are implementing for this scan something special. This means you have the firewall configured as from best know-how and practice. What is required within a audit is a scan from outside world trying to access whatever. There will be some ports open from outside world like: - IKE 500 TCP/UDP - UDP 4500 for NAT Traversal - etc. This rules open are most based on Implied Rules. All what is the scan from the audit recongizing to be open you have to verfiy or give statement. This means if you implement the range of the audit organization you will not have a scan which represents the really open ports etc. What the audit organization should do (can be done by Qualys) is not a aggresive scanning meaning a low scan which takes some hours more but which does not impact your firewall. If the audit finds as example IKE 500 to be open and you use site2site VPN you can implement some rules to cover more security by command: config firewall local-in-policy This rules are manually defined local-in-policy and would overwrite the local-in-policy. At the moment I do not understand why the auditor gives you his IP range to be whitelisted? hope this helps have fun Andrea

[rwpatterson]

Try this: Put an old crappy workstation on an unused interface (dmz, for example) Create a VIP without port mapping and point it to that unit Make a policy from the outside to that PC This won' t be accurate, but it won' t expose your network to internet bad guys either...

[Dave_Hall]

Much like Bob has indicated -- the security audit check/scan that I am more familiar with simply involves sticking a small box (mini pc?) on the network, behind the firewall with a VIP connection from outside the firewall (WAN connection) pointing to it from the security company' s IP space; but from what I gather a " PCI compliance audit" is geared towards assessing a company' s POS system. Still, Neil' s description of what the vendor wants is a bit cryptic. I would just ask the vendor if the above scenario would work better for them.

[ShrewLWD]

Hi everyone, I manage and monitor over 200 Fortinet firewalls, that have to be PCI scanned quarterly. The only way to satisfy this request, is to program all their whitelisted IPs in, set them up as a group, then create a firewall rule (the very top rule, although I technically have a Banned Countries rule even above that one) that says; Source interface: WAN1 Source IP: PCI_Scan_Group Destination Interface: LAN Destination IP: ANY Ports: ANY Schedule: ANY That' s it. If the firewall has no inbound rules, nothing is found. If you do, it uses that rule to snoop what is alive behind the firewall. NOTE: If you allow your firewall login site to be accessed from anywhere (eg no restriction by IP) it will; 1) fail on weak SSL (' set strong-crypto enable' in the global), as well as 2) the SSL certificate not matching the location, and 3) not being a valid signed SSL Cert. Hope this helps! EDIT: Be aware, after the No Such Agency outrage, and after all my devices failed because a firmware update changed the strong crypto back to weak, I contacted a senior engineer at Fortinet, who claimed the need to lower strong crypto was to facilitate easier snooping of SSL Deep Packet Inspection. So, if you do do DPI on webfiltering, the strong crypto setting may affect this. I can' t say by how much (e.g. whether it fails outright, or forces more resources to be used).

[NeilG]

The PCI compliance seems to require the audit scan to scan from Outside IN as ShrewLWD confirms. I don' t like it, but the audit is given a failing mark if scanning attack attempts on the WAN interface are blocked by IPS. [link=]https://www.controlscan.com/support_resources_qa.php#22b[/link] ShrewLWD - [ul]

Thanks for the warning about the strong-crypto.

I am running 5.0.7 - do you, by any chance, have some cli commands of your current settings for that rule that you could share or private message me? [/ul] Thanks again! -N

[Mark_Oakton]

The PCI DSS audit requirement for an ASV scan is to have all live IP addresses scanned that are part of the CDE (firewall wan interface IP and all vip' s) on a quarterly basis, and that IPS is disabled for the scanner source range. So a dmz box will not help, the scan must be on the visible range

[Mark_Oakton]

you do not have to enable inbound traffic for a PCI scan, just disable IPS for the scanner range

[NeilG]

Mark Oakton wrote:
you do not have to enable inbound traffic for a PCI scan, just disable IPS for the scanner range

Mark,

I had already tried adding exceptions for IPS before going with the Allow to LAN but maybe I am doing it in the wrong place?

(I personally don't understand how whitelisting IP addresses can be a safe policy given the ability to spoof so if there is a better way that works I would like to know it.)

btw Does anyone use Fortinet for their external PCI compliance scans? Do they offer that?

Thanks!

-Neil

[seadave]

I'd push back against the auditors, you have a right to despite what they imply.  I have to all the time.  If they can't connect, I think that demonstrates that your config is working.  I would NEVER reduce my rules to allow someone to attack me unless it was for a very specific exercise (which this may be so please excuse my casual observations if that is the case).  If they are trying to run vuln scans, they should either connect via a VPN or bring something in-house if they need unfiltered access to your LAN systems.  Again I would never open my firewall to comply with something like this.  It is madness.  My guess is that most of the dimwits they scan have SOHO routers with NATs and not IPS/IDS.  They are most likely not familiar with the UTM2 world.

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.