Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
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
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.
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.
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
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.
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1557 | |
1033 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.