Item 1.3.6 of PCI DSS is this : Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established sesion.)
According to nmap documentation, you can test for a stateful packet inspection firewall by using the following command. In my example, I’m testing port 443 (https) as I know that it is an open port. -Pn tells nmap to NOT run the ping test, and -sA tells nmap to send an ACK packet.
# nmap -Pn -sA -p 443 #.#.#.#
nmap discussions I’ve read state that an “unfiltered” response indicates a stateless firewall, and a “filtered” response indicates a stateful firewall. Unfortunately, nmap lists my firewall’s response as “unfiltered” or stateless. This leads me to believe that the NSA 240 is NOT an stateful firewall.
PORT STATE SERVICE 443/tcp unfiltered https
If I do a tcpdump on the source system that is running nmap, I’ll see that an ACK is sent, and that an RST is returned from the target system. All this leads me to believe that the NSA 240 is stateless, and is allowing the RST’s to come back from the target system.
However, if I do a tcpdump of port 443 on the target system, I see absolutely NO packets from the source system.
I believe that the SonicWall NSA 240 is responding with the RST packet without actually forwarding the ACK packet to the target system.
So I’m sitting here wondering if nmap can accurately tell whether a system is stateful or stateless? Just because an RST packet is returned, doesn’t necessarily mean it is coming from the target system.
Conclusion : I’m going to log a ticket with SonicWall to clarify this issue for me. And for now, I’m going to use the empty tcpdump log from the target system to verify that the NSA 240 is stateful. This should allow us to pass the PCI 1.3.6 check. But I still want an answer from SonicWall as to why it is responding with an RST packet.
Did you ever get a response from Sonicwall RE is the NSA240 stateful? If so, what was the response?
Well shucks. Good question. I just went through both accounts that I have with SonicWall and I can’t find any indication that I submitted this ticket. I’m going to bet that I was too busy with an on-site audit at the time, so I just took my tcpdumps as proof that the nmap scans were NOT getting through the firewall.
As it turns out, there were many things (like this) that I was prepared to answer with proof, but the auditor did not ask for proof on this particular item.
I had satisfied myself though that the firewall is indeed stateful, regardless of the nmap result. I also seem to recall finding white-papers or other material on the SonicWall website that says they are stateful.