New Member

Solved

How do I NOT block PCI scans on WAN ports?

Forum|Forum|11 years ago
May 27, 2014
8 replies
28550 views

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

Best answer by Dave_Hall

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.

AndreaSoliva

New Member

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

New Member

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

New Member

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

New Member

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).

NeilGAuthor

New Member

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

New Member

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

New Member

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

NeilGAuthor

New Member

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

New Member

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.

ShrewLWD

New Member

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

New Member

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded