PCI Scans for IP terminal

[fencepost]

Would providing them a copy of that log be adequate?

 

[HCHTech]

Would providing them a copy of that log be adequate?

It doesn't appear they are really interested in the details, unfortunately. Pass or don't pass, they don't seem care about the particulars. They certainly don't want to provide tech support.

So....now that I have a clue, I can follow it. I believe I'll schedule another scan and watch the log to see if I get a similar "multiple ports tried from one source IP address". If I do, then that will give me an idea of the IP range they are actually using, I can put that in the whitelist and see if that gets me an actual scan. If it DOES, then I have evidence that I can go back to them with and get somebody to find out the REAL IP range their scans use, as opposed to the one listed in their documentation.

If I don't get an obvious clue, then I'm back to square one and might just give in. I have some extra time right now because I'm recovering from tendon surgery and can only work with one arm - so I'm limiting my onsite visits and spending more time in the office (I just typed this reply with my left hand, only took me 10 minutes - haha). That won't last forever and I'll be back to the normal schedule.

 

[fencepost]

I'm recovering from tendon surgery and can only work with one arm

That sounds like it cries out for Dragon (one of the current versions, apparently they're better with cheap microphones) and use that hand for editing and punctuation if required.

 

[Markverhyden]

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:

View attachment 9001

Most likely. A whois of the IP points to Aperia Solutions

And yes, all they care about is check boxes. I've given up on communications with those enitites unless it's a procedural thing.

 

[HCHTech]

Most likely. A whois of the IP points to Aperia Solutions

Yep - that's them all right. So I'm going to email them the pertinent section of the firewall log, along with a copy and paste of the whois lookup - then ask for a confirmation of the CURRENT IP range in use for their scans. I'll bet the range they gave me was from an old technote or something and, surprise, they didn't verify the information, they just passed it on.

 

[HCHTech]

OK, back from a client appointment, and I have my results. I changed the IP whitelist to include the IP they scanned from the last time and queued another scan. Sure enough, about 20 minutes into the capture, I find this traffic:

So, their traffic is coming in, and it's being forwarded by the rule (to the cc terminal). A bit later in the capture is traffic going from me to them:


So..."Generated" doesn't prove the traffic left (I don't think), but there is nothing preventing that. So...I'm not sure what to do next. Their traffic is coming in and being forwarded to the terminal. I *AM* allowing ping on the main WAN interface.

Unfortunately the scan still fails with the same message: "No response from far end". Any ideas on the next steps?

 

[HCHTech]

Oops, something went wrong with the first image paste - here it is:

 

[HCHTech]

Ok, last post on this for today. From the details in the scan log, I think I can make a conclusion here.

Take one of the initial entries inbound from them to me on TCP port 443. The details of that log entry are:

Ethernet Header
Ether Type: IP(0x800), Src=[b0:a8:6e:7c:a7:c1], Dst=[xx:xx:xx:09:d5:f1]
IP Packet Header
IP Type: TCP(0x6), Src=[63.241.203.203], Dst=[XX.XXX.XX4.123]
TCP Packet Header
TCP Flags = [SYN,], Src=[51943], Dst=[443], Checksum=0x34f6
Application Header
HTTPS
Value:[0]
Forwarded 1:1)

This is a SYN packet - the first step in a TCP handshake. With a successful connection process, the receipt of the SYN packet should be followed by a SYN-ACK packet being returned, and then finally, by an ACK packet being received in response. IN my case, there is no SYN-ACK packet. Instead, 29 seconds later, I see a log entry outbound from me to them. The details of this entry are:

Ethernet Header
Ether Type: IP(0x800), Src=[xx:xx:xx:09:d5:f1], Dst=[b0:a8:6e:7c:a7:c1]
IP Packet Header
IP Type: TCP(0x6), Src=[XX.XXX.XX4.123], Dst=[63.241.203.203]
TCP Packet Header
TCP Flags = [ACK,RST,], Src=[443], Dst=[51943], Checksum=0xfe2d
Application Header
HTTPS
Value:[0]
Generated (Sent Out) 0:0)

This is an ACK-RST packet. I think this is the termination of the attempted connection, or that port 443 is not being listened to, I guess.

SO......I think this is telling me that the cc terminal is not responding to the connection attempt. As far as I know, there is no control over this. This is probably by design on the terminal. I don't know because I didn't design the thing. I'm already treading water trying to figure this stuff out. Oi, vat a day!

 

[HCHTech]

This is a SYN packet - the first step in a TCP handshake. With a successful connection process, the receipt of the SYN packet should be followed by a SYN-ACK packet being returned, and then finally, by an ACK packet being received in response. IN my case, there is no SYN-ACK packet. Instead, 29 seconds later, I see a log entry outbound from me to them. The details of this entry are:

*Bump*

Any thoughts on this anyone? I've stopped spending time on it for now, but would give it another go if there are any new ideas. It doesn't make sense to me that the device wouldn't acknowlege an attempted connection. It's possible I suppose that the Sonicwall is mangling the process somehow, but my packet capture doesn't show that. The only idea I have is to put a computer on that connection in place of the terminal (with the same IP address) and try another scan - I could monitor the connection attempt from the computer AND through the Sonicwall that way - kind of a pain, though so I haven't actually done that yet.

 

[fencepost]

I have no great insight. The remote PCI scans I've had to deal with didn't want to see ANYTHING connectable on the firewall except well-known ports, and for those they checked security (TLS version for VPN being the only thing open). Frankly I'd be astonished if the terminal had a web interface, and even more so if the vendor says that it should be connected open to the Internet. If they're going to harden it like that, why TF would they care about security on the internal network?

 

[Markverhyden]

At this point I think it's time to self-attest there is no risk If you really want to spend more time on this you could pull the terminal, drop in a regular computer configured with the IP info and then run the scan. Make sure the machine firewall is off. You can also just put the terminal and a computer on a standalone switch, same IP scope and then see if it pings.

 

[HCHTech]

At this point I think it's time to self-attest there is no risk If you really want to spend more time on this you could pull the terminal, drop in a regular computer configured with the IP info and then run the scan. Make sure the machine firewall is off. You can also just put the terminal and a computer on a standalone switch, same IP scope and then see if it pings.

I think you're right - it's maddening. I was *hoping* to learn enough about the process to setup clients so that we had a way to make the scans pass (even if it involved a temporary configuration change each quarter). It just looks so much better than finding a good way to say "I don't know how the scans work - just sign the waiver and you'll be OK". I'm going to go with "When the scans can't contact your terminal, it means the firewall I sold you is doing it's job. We could lower security to let the scans through, but that makes you less secure, so just sign the waiver and you'll be fine." I think, anyway. The one I have coming up is a physical therapist so HIPAA. Awesome.

This was not the outcome I was hoping for, but it's the one I'll have to live with. That sounds like a quote from a superhero movie, haha.

 

[HCHTech]

If they're going to harden it like that, why TF would they care about security on the internal network?

Well yes, exactly. But they *do* care, apparently. In my mind, the failure to connect should be an automatic pass, not an automatic fail...but I digress.

 

[Markverhyden]

Well yes, exactly. But they *do* care, apparently. In my mind, the failure to connect should be an automatic pass, not an automatic fail...but I digress.

I think I mentioned above where I ran into a situation years ago where the customer actually had to open ports. Every other time you get a check minus for having any open ports. And have to attest why they are not a threat. I guess the problem is you can't get a real human to tell you what they are actually looking for. They may not even be trying to ping, they may be trying to SSH in or something else.