pix port scan bug? 1

[cpeloso]

Hallo,
I've tried to scan ports open on my pix 515 (IOS6.3.1).
Even if I've no port leaved open the scanner finds that
ports 110 and 25 are open...
The log shows that also connection on those ports are blocked (maybe not all..)
I've tried three different port scanner but the result it's the same.
On the servers there are no mail services active.

Ideas?

 

[baddos]

Is this scan incoming or outgoing?

 

[cpeloso]

Incoming

 

[baddos]

Post your config.

 

[cpeloso]

PIX Version 6.3(1)
interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security10
enable password xxxxxxxxxxxxxxx encrypted
passwd xxxxxxxxxxxxx encrypted
hostname Pix515-01
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
pager lines 24
logging on
logging buffered informational
logging trap warnings
logging host inside xxxxxxxxxxxxxxx
no logging message 106014
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside xxxxxxxxxxxxxx 255.255.255.248
ip address inside 192.168.3.254 255.255.255.0
ip address intf2 192.168.4.254 255.255.255.0
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
failover
failover timeout 0:00:00
failover poll 15
failover ip address outside xxxxxxxxxxxxxx
failover ip address inside 192.168.3.253
failover ip address intf2 192.168.4.253
pdm history enable
arp timeout 14400
global (outside) 1 interface
global (intf2) 1 192.168.4.200-192.168.4.210
nat (inside) 1 192.168.3.0 255.255.255.0 0 0
nat (intf2) 1 192.168.4.0 255.255.255.0 0 0
static (intf2,outside) xxxxxxxxxxxxx 192.168.4.10 netmask 255.255.255.255 1000 10
access-group sata1 in interface outside
route outside 0.0.0.0 0.0.0.0 80.206.187.193 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet xxxxxxxxxxxxx 255.255.255.255 ins
ide
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80

 

[baddos]

Did you used to have an access-list called "sata1"?

 

[cpeloso]

Yes, it only enables port 1000 (needed for our office)

 

[baddos]

Is it no longer in the running configuration?

 

[cpeloso]

Yes it is running , I've only delete it posting:

access-list sata1 permit tcp any host xxx.xxx.xxx.xxx eq 1000

 

[cpeloso]

I've tryied dowgrading to 6.1.4 with no results...
PLEASE HELP ME!!!
Since pix logs say that connection on tcp 25/110 are blocked,
these ports are open...
WHY??

 

[baddos]

Do you have any conduit statements?

If not, then given the information you provided, you don't have any ports open.

 

[yizhar]

HI.

How exactly did you run the test, and from where (directly in the outside network, or via the Internet and ISP)?

* I think that this is the "TCP intercept feature" of the pix.
I don't know why only ports 25 and 110 are affected (maybe the port scanner is more aggresive with these ports?).

For the test, you can change this:
> static (intf2,outside) xxxxxxxxxxxxx 192.168.4.10 netmask 255.255.255.255 1000 10
To this:
static (intf2,outside) xxxxxxxxxxxxx 192.168.4.10 netmask 255.255.255.255 0 0
and see if removing the connection limits changes the picture.
Then place again your initial static with the limits to protect your server, as this is probably what you wanted in the first place.

Read here:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/cmdref/s.htm#11459

Here is a quote from the above link:
=== Start quote ===
"
TCP Intercept Feature
Prior to version 5.3, PIX Firewall offered no mechanism to protect systems reachable via a static and TCP conduit from TCP SYN attacks. Previously, if an embryonic connection limit was configured in a static command statement, PIX Firewall simply dropped new connection attempts once the embryonic threshold was reached. Given this, a modest attack could stop an institution's Web traffic. For static command statements without an embryonic connection limit, PIX Firewall passes all traffic. If the affected system does not have TCP SYN attack protection, and most operating systems do not offer sufficient protection, then the affected system's embryonic connection table overloads and all traffic stops.

With the new TCP intercept feature, once the optional embryonic connection limit is reached, and until the embryonic connection count falls below this threshold, every SYN bound for the affected server is intercepted. For each SYN, PIX Firewall responds on behalf of the server with an empty SYN/ACK segment. PIX Firewall retains pertinent state information, drops the packet, and waits for the client's acknowledgement. If the ACK is received, then a copy of the client's SYN segment is sent to the server and the TCP three-way handshake is performed between PIX Firewall and the server. If and only if, this three-way handshake completes, may the connection resume as normal. If the client does not respond during any part of the connection phase, then PIX Firewall retransmits the necessary segment using exponential back-offs.
"
=== End quote ===

* Another option is that there is some kind of transparent mail filter at the ISP which intercepts that traffic.

Bye


Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[cpeloso]

Hi,
as i've posted I've no conduit..
I've made the test via internet (and ISP) but the same test few months ago gave right result.
I've tried to change the config as Yizhar suggest with no results... but if a port is blocked by access-list,nothing of that port traffic arrives at the static route.. so I think it doesn't matter what is write in "static" statements..

I'm sad...:-(

 

[baddos]

Do a clear xlate after making the changes and try again.

 

[cpeloso]

ok,but nothing to do.. today I've put an explicit deny
(access-list sata deny tcp any host XXXXXXXXXXX eq smtp)
to control the hit counter.
I've noticed that the pix blocks first three connection attemps but the next passes....

Ideas?

 

[baddos]

Why don't you try to do a "telnet xx.xxx.xxx.xxx 25" to the IP you think is having the problem and see if you get a connection. Remember, the PIX won't respond that the port is closed, but just drop the packet. So if your port scanning software is misintrepreting that, then it's not the PIX's fault. However, if you can connect on port 25, then there is something else in your configuration allowing it.

-Bad Dos