PCI Scans for IP terminal

[HCHTech]

I've got a new client setting up their first office. They have 2 office computers, 2 public-use computers and a single FirstData IP-connected credit card terminal. They have a block of 5 public IPs with their internet service, so I set them up with a Sonicwall, and have 3 zones with different IP schemes and different public IPs.

The office computers are in zone 1 with say, the IP range of 172.16.2.x and use x.x.x.122 for their WAN
The public computers are in zone 2 with the IP range of 172.16.3.x and use x.x.x.123 for their WAN
The cc terminal is all alone in zone 3 with an IP of 172.16.4.100 (no DHCP range) and uses x.x.x.124 for it's WAN

All of the appropriate rules are in place to prevent traffic between the zones.

So far, so good - everything works as desired. However, the PCI scans are failing because the scan cannot detect the cc terminal. I have no doubt that this is because the firewall is doing its job.

There is verbiage in the PCI documentation that DPS / IPS protection can interfere with scans, and the client can also "sign off" that no intentional blocking of the scan was done, which lets them get a pass after a review.

It goes against my nature to lower the protection so the automated scans can see if we're protected.

Should I be disabling the firewall protection for the cc terminal's LAN? That seems crazy. Plus, the terminal doesn't store any data so there isn't any possible danger as far as I can see anyway. I can tell the client wouldn't be happy having to make the exception statement every quarter...How do I set this up to get a passing scan?

 

[Markverhyden]

However, the PCI scans are failing because the scan cannot detect the cc terminal. I have no doubt that this is because the firewall is doing its job.

There is verbiage in the PCI documentation that DPS / IPS protection can interfere with scans, and the client can also "sign off" that no intentional blocking of the scan was done, which lets them get a pass after a review.

I've always thought it kind of hypocritical that they want to check to make sure the network is secure but require you to expose it. LOL!!! If it was my customer I'd not change anything to the firewall and just have them sign off. I've challenged PCI scan findings before and many of them are not deal killers so to speak and have no effect on rates.

 

[fencepost]

The public computers are in zone 2 with the IP range

I've been doing something similar, but have recently started just handing out 192.168.1.x for the public/guest range after I realized that there's absolutely nothing that I need those guest IPs to have a similar netmask for.

 

[HCHTech]

In this case, I’m going to try and figure out what needs to be done for the scan to actually work. If I have to turn off protection, maybe I can just schedule that for when they queue the scans, I don’t know. There is frustratingly little technical support from the vendor, which in the past has been limited to linking the various compliance docs.

I have this exact situation with my own vendor, I’ve been doing the sign off every quarter for about 4 years now. Pi$$es me off every time I do it.

 

[fencepost]

I'm a bit confused, the customer of ours who's had a PCI scan like that having much of anything exposed was a fail. Heck, I'm requiring port knocking before the VPN connections at this point. I can't imagine how they could fail the scan because the terminal was not world-reachable, I'd expect it to be an auto-fail if it was reachable. I'd request clarification from the scanning party.

Thinking about it, is the entire real-world IP basically a complete blackhole? If so, that might cause issues - they want to see that ports are closed, not that they're nonexistent. I bet that the problem isn't that they can't detect the terminal, it's that they can't detect the firewall.

 

[skdmaster]

I too have encounter this type of request to "lower" my security. In the past I left my security on and just signed off saying it was there but now there are new PCI rules that they have to see a device or it will fail. The way I got around it is I just allowed WAN ping but left all other security at normal settings. This satisfied them seeing something there but nothing opened so it passes. No way am I giving them bypass security even if they are giving me IP addresses to add to an exclude range.

It has irritated me up that they wanted me to make exceptions so they can scan my network when if I am doing my job nothing should be seen to begin with - oxymoron of PCI compliance.

 

[Markverhyden]

It's been some time but I seem to remember that there are some ports that need to be opened and forwarded to the target devices.

 

[HCHTech]

It's been some time but I seem to remember that there are some ports that need to be opened and forwarded to the target devices.

Yes, at one point the scanning folks said 443 had to be forwarded. I futzed around with the firewall settings last night, but I couldn't see how to allow pings on just that public IP or just that device. I tried allowing ICMP traffic, but that wasn't it. I'll have to do some research.

Also, since the cc terminal is in its own zone, and only traffic from the 2nd public IP is forwarded to it, I can't use something like ShieldsUp, for example, to test everything. I guess I could put a PC in that zone and test it that way, but maybe there is another tool that can test a network you are not currently on? ...guess that would be a hacker tool, haha. I found hidemy.name - no doubt there are others.

Edit: Results -
All 1000 scanned ports on static-xx.xxx.xxx.xxx.someplace.verizon.net are filtered
Nmap done: 1 IP address (1 host up) scanned in 201.74 seconds.

and, for the proxy ports scan:

All 399 scanned ports on static-xxx.xxx.xxx.xxx.someplace.verizon.net (xxx.xxx.xxx.xxx) are filtered
Nmap done: 1 IP address (1 host up) scanned in 81.28 seconds

 

[OaksLabs]

Well, there's a cheating way to do ping. I've done it with an Untangle...and it's a bit strange, but a person can configure a port forward rule to "forward" incoming ICMP traffic to the WAN default gateway. This is not exactly an elegant solution, but it's better than allowing ICMP from the outside world to the terminal itself.

 

[LordIntruder]

I must ask a question: what is so bad about icmp that everybody wants to filter it instead of letting it do its job?

 

[HCHTech]

I must ask a question: what is so bad about icmp that everybody wants to filter it instead of letting it do its job?

I'm sure someone will post the real answer, but I would posit that a positive ping result proves that there is something at that IP address (of course), while a negative ping result does not. Something along the lines of "If they can't prove you're there, it's harder for them to infect you".

I have no idea whether this is borne out statistically or not, but it sounds reasonable enough.

 

[skdmaster]

I just use ping because it satisfies the scanning company locating a device at the specified IP address without opening up access to my firewall. I feel if you have your firewall properly setup then a ping is low risk. Below is the email notice from one of the scanning companies my clients have to use:

In accordance with the latest PCI scanning standard, Trustwave will be implementing changes in External Vulnerability PCI scans. These changes, mandated by the Payment Card Industry Security Standards Council, went into effect on Jan. 31, 2018.

PCI scans that passed previously may begin to fail due to changes in the scan assessment requirements. Scans may fail if our scanner cannot reach the scan targets identified in your Scan Setup. This means that you asked Trustwave to scan a target IP address that our scanner was ultimately unable to detect, and therefore unable to make a determination on overall security of the environment.

STEPS YOU SHOULD TAKE NOW:

You can update your Scan Setup now to prepare for the changes. Some things you can do to ensure that scan targets can be reached during a scan:

• Check that an IP Address or Domain Name is correct in the Scan Setup and has not changed since you originally set up your scan.
• Prevent active security measures from blocking targets. Permitting TrustKeeper scan traffic should only be done on active security devices (i.e. IDS/IPS, WAF, DDoS etc.) within or in front of the environment being scanned. Note that creating a rule on a firewall, which permits traffic to pass through, could reduce security defenses and cause additional scanning problems.
• If available for download, install the Endpoint Protection Solution, which will monitor IP changes and help ensure you are always scanning the current IP address. It may also shorten your SAQ assessment.
• Check out our help document for more information and graphics to help you through these steps.

IF SCANS BEGIN FAILING AFTER JAN. 31, 2018 YOU SHOULD:

1. View scan results identified as undetected hosts.
2. Update the Scan Setup to correct or remove the undetected hosts.
3. Review the steps listed above.
4. Rescan.
5. If a rescan continues to yield Undetected Hosts, then your IP address may be hidden by design for business security reasons. In this situation, you may raise a dispute via the Trustwave Dispute process.

As always, our support team is here to help you out. If you have questions after reading the help document posted in the knowledge base, contact us at support@trustwave.com or +1-800-363-1621.

Note: If you monitor your network for activity, note that the scan may originate from IP addresses in these ranges:

64.37.231.0 /24 (64.37.231.1 through 64.37.231.254)
111.108.90.138 - 111.108.90.139
124.211.46.74 - 124.211.46.75
204.225.91.58 - 204.225.91.59
209.90.139.122 - 209.90.139.123
220.101.105.8 - 220.101.105.9
220.101.107.8 - 220.101.107.9

 

[LordIntruder]

If they can't prove you're there, it's harder for them to infect you

Security through obscurity doesn't work, believe me. If an network administrator is not able to prove if his network is running because ICMP is dropped he is not able to give an answer to the question if the network is up and running. If a client is not there, the point before that client will tell "the client is not there". If that don't happen everybody knows that there is something there that just supress all answers to all questions. That is why suppressing icmp is the only and really bad thing someone can do.

 

[Markverhyden]

Blocking ICMP is just one of many security enhancing steps to consider. No response means just that. It does not tell you if something is there and being blocked or nothing is there.

This is the analogy I make about ICMP. Blocking ICMP is like pulling the curtains on the locked windows of your home. Is it perfect? Of course not. They can still look at the type of house and guesstimate what might be there. But if there is a house with the curtains not drawn they'll spend more time looking that one over.

On the OP. I seem to remember that they are not looking for a ping response, at least with the CC device company doing the work. I have a vague recollection that they actually wanted to query the device to verify it was their device and where it was.

 

[HCHTech]

Prevent active security measures from blocking targets. Permitting TrustKeeper scan traffic should only be done on active security devices (i.e. IDS/IPS, WAF, DDoS etc.) within or in front of the environment being scanned. Note that creating a rule on a firewall, which permits traffic to pass through, could reduce security defenses and cause additional scanning problems.

Ok, I guess I'm dense. Let's break this down, maybe I'll get it:

"Permitting TrustKeeper scan traffic should only be done on active security devices (i.e. IDS/IPS, WAF, DDoS, etc.)"

Does this mean "You should only make changes (permitting traffic) on your firewall or edge device, Don't change anything with the environment (terminals) themselves"? Is what they are really trying to say "Don't put your terminals outside of the firewall? Or, are they saying "don't run IPS/DPS protection" because that would "block the targets"?

Then, they follow with "note that creating a rule which permits traffic to pass could reduce security". So, now they are saying "Don't create a rule to allow traffic to pass through"? Isn't that in direct opposition to the first statement?

 

[LordIntruder]

It does not tell you if something is there and being blocked or nothing is there.

No, Mark. Absolutely no. IF there's nothing there, the point BEFORE will tell you that there's nothing there. It's exactly that misunderstanding what ends in "haha, I am stealth because I suppress icmp". You can verify this at every local network. If the host is not running, the router (in this case the router for sure is the point before the host) will tell you "host unrechable". if the host is running but suppresses icmp you just don't get an answer. So there IS a difference between blocking icmp and just really don't having a network device at the end of the route. And that is why I ask why not letting ICMP just doing its job and everything would be fine.

 

[fencepost]

active security devices

Some devices will actually detect that a port scan is in progress and immediately blacklist the remote IP doing the scanning after it checks just a few ports. That's considered failing because they want to verify that there are no vulnerable ports no matter what port the scanning starts with, so they want you to exempt their source ranges from those "active" blocking configurations.

It could be better phrased, but it's bureaucratese written by people who spend way too much time with lawyers.

 

[HCHTech]

I've spent some additional time on this, and I think they've worn me down. Although I have disabled IPS, DPI, Gateway Antivirus & Gateway Antispyware on that public IP, and have successful firewall rules in place to forward all traffic from the PCI Scan company's unreasonably large IP range directly to the IP CC terminal, I'm still getting a failing scan with the note "No response from far end - scan customer must provide the ASV with sufficient evidence to indicate that a valid scan has been performed and the scan was not actively blocked"

I can prove the rules are working by adding the IP address of my residential internet to the whitelist and pinging the public IP used by the scan. Looking at the firewall logs, I can see the ping come in, and be forwarded to the device.

As a test, I tried opening up all traffic with an any-any rule, and I still failed the scan. Ugh.

I spoke to sonicwall support, had them remote into my firewall and check my work. All is ok. I asked them if they had any advice on PCI scans...to which they somewhat predictably responded "we can only help you setup your firewall". haha.

I spend an infuriating hour on the phone with the PCI scanning company's support. The final conclusion is that they cannot tell me what is required to get a passing scan. I spoke to two supervisors and learned nothing new. "Do you have the proper IPs whitelisted?" Yes. "Do you have IPS disabled?" Yes. "Then you must sign the waiver to get a pass."

First of all, SOMEBODY has to know what the scan is looking for and what is required to actually have it work - after all, someone had to program the darned thing, right? Let me talk to THEM, dammit. I presented this logic to the supervisors but it fell on deaf ears. "We don't have access to anyone like that" I asked if ANYONE ever gets a passing scan - "I can't tell you that, sir".

So, now I'm doing what I probably should have done earlier in this process - I setup a packet capture log for all traffic that comes in on the subject public IP, then I queued yet another scan. I'll sift through the log tomorrow and look for IPs from their range to see what is actually happening. I'll bet that I'll find the traffic coming in and being forwarded to the terminal, just like the rules are supposed to be doing. At least I'll know what ports are being used, etc. Maybe the whole problem is that the ONLY thing on that subnet is the cc terminal, and the scan is "looking" for a network full of computers. I have no idea, but I'm definitely ready to concede this fight. I was hoping to better understand this so to better advise my clients. What a waste of time & effort.

Edit: The scan completed sooner than I expected. It failed, of course. But there are NO entries in my capture log from any IP on the scanning company's whitelist. This is maddening. I wonder if they gave me an outdated IP range to whitelist....

 

[HCHTech]

There was only one series of traffic from a single address in the log, Do you think that was the scan? Here is an edited snap:

 

[skdmaster]

Under your Firewall Setting do you have any of the Detection Prevention options enabled during the scan (Stealth mode, etc)? Just to pass the scan see about enabling ping on your WAN interface and run a new scan - I have to do this a lot so they can "see a device" to pass it. I have gone round after round with them on the same principles they are all brain dead and are worthless for help.