In performing a port scan (notably with NMAP, but other tools report similar results), I am receiving results which I cannot justify in the access lists/conduits (yes, they have a couple conduits statements still - tsk tsk).
The PIX is running 5.3(1).
When port scanning a device located behind the PIX, I receive a mix of "FILTERED" and "CLOSED" responses, with the difference being that "FILTERED" indicates that a firewall dropped the incoming packet and did not send any response. "CLOSED" indicates that a response was received from either the firewall or the destination host.
Here's a sample of the NMAP output...
=====BEGIN CUT HERE========
Interesting ports on 10.11.12.13:
(The 1620 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
1/tcp filtered tcpmux
7/tcp filtered echo
9/tcp filtered discard
11/tcp filtered systat
13/tcp filtered daytime
15/tcp filtered netstat
19/tcp filtered chargen
22/tcp filtered ssh
23/tcp filtered telnet
37/tcp filtered time
43/tcp filtered whois
80/tcp open http
93/tcp filtered dcp
111/tcp filtered rpcbind
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
161/tcp filtered snmp
162/tcp filtered snmptrap
443/tcp open https
445/tcp filtered microsoft-ds
512/tcp filtered exec
513/tcp filtered login
514/tcp filtered shell
515/tcp filtered printer
517/tcp filtered talk
518/tcp filtered ntalk
540/tcp filtered uucp
593/tcp filtered http-rpc-epmap
1234/tcp filtered hotline
1900/tcp filtered UPnP
5000/tcp filtered UPnP
12345/tcp filtered NetBus
27374/tcp filtered subseven
31337/tcp filtered Elite
According to the ACLs, only HTTP and HTTPS are open from the Internet and all others should be denied based on the implied "deny any any" at the end of the access list.
A packet capture shows that for each "CLOSED" response, a "RST|ACK" packet is received by the scanning computer. No response is received at all for the "FILTERED" ports (as expected).
My question is: Why is the firewall responding to some packets with a RST|ACK packet, while it is not responding to others at all (which is the desired action)? Or is there another problem that's causing the PIX to not firewall as expected?
The default behaviour in around 6.1 code (sorry, can't remember the exact version, 6.1(4) I think but not sure) is to silently discard packets destined for closed ports when received on the outside interface, and to send an RST for packets received on the inside interface (so the connection closes down quicker).
If you want the PIX to reply with an RST on the outside int as well you can use the "service resetinbound" command.
In short, if you upgrade this PIX to 6.2/6.3 code what you're seeing should go away.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...