We'd love to hear about it! Click here to go to the product suggestion community
We just installed a new XG 115 for a client of ours that had a ~15 old Cisco ASA and was failing PCI compliance scans due to firmware updates not being available. Now that we have installed this new UTM, I re-ran the scans. Unfortunately, the scan failed citing "The remote host does not discard TCP SYN packets that have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules". The suggested 'fix' is to update the appliance, but it is already up-to-date. I need to figure out how to fix this because I am going to have a hard time explaining why their new UTM isn't passing scans! Ideas?
Hey Paul Schwegler
What SFOS version is your XG 115 running?
Did you have any Business Application rules performing a direct DNAT to your local network? (Feel free to share this information via PM if you would like to keep this info private)
In reply to FloSupport:
We have 17.0.8 MR-8 installed. There are no Business Application rules. Since there is nothing that needs to come into this network normally, we are just using the default rule with HTTP scanning, lantowan_general IPS, the 'No Ads or Explicit Content' web filtering rule, and no application control (yet). Basically, we went with the defaults on set up, but turned off MTA mode for e-mail scanning as it was causing some issues with their legacy e-mail.
I did create a firewall rule at the top that exempts the scanning IPs from all protections. I was told this needed to be done to prevent the port scanning from triggering the IPS protections. This seemed to be the way to do it per the articles I found online. Here is a screenshot of the rule, is this right? I can remove it and rescan, but it takes 24-36 hours for a scan to run, so trial and error is time-consuming.
In reply to Paul Schwegler:
Hi Paul ,
Try disabling the rule and check again.
In reply to Aditya Patel:
I disabled the rule, so the only thing still there is the default rule that was created during setup. The scan still fails citing the same issue.
Anyone have any ideas?
What "Device Access" options are enabled on the Zone you are testing? My thinking being that User Portal or Console access is active on the IP's being tested.
In reply to AADD:
The only things enabled on the WAN were the user portal and SSL VPN. We use neither so I disabled them.
Then, I realized that the Sophos is behind a Centurylink Modem. I fear this port scan is catching something wrong with the modem. I put the Sophos in the modem's DMZ and will see if the scan passes. If that doesn't work, I'll have to put the modem in bridge mode and let the Sophos handle PPPoE. Ah, the joys of small office networking /s
What was the outcome?
Still failing. The next step will be to put the modem into bridge mode to keep it from interfering with the scan.
I don't have anything to add except that, at least for the people who do our PCI scanning, we're required to whitelist their IP's so the scanners get a clean crack at us. Apparently IPS/IDS can detect the scan as an attack and just block everything from the scanner, but that paradoxically results in a "failure" scan since the scanner cannot complete its survey.
If you have RED enabled, you'll get dinged for weak ciphers unless something has recently changed.
In reply to Bill Roland:
I did initially whitelist their IPs but disabled that in troubleshooting. I scheduled a scan to run yesterday, and it is still pending, I will update when I know if this worked or not.