cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1408
Views
0
Helpful
1
Replies

PIX "CLOSED" vs "FILTERED" responses

rbartels
Level 1
Level 1

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?

1 Reply 1

gfullage
Cisco Employee
Cisco Employee

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.

Review Cisco Networking for a $25 gift card