Pix passing traffic even with a 'deny ip any any' rule

tuskenraider · ‎09-21-2012

Hello,

So I was doing some testing with my BB Playbook where I wanted to see what outside connections it tried to make during startup and whatnot. I have a pix 506e running 6.3(5). I created an simple 'deny ip any any' access list on the inside interface so that the Playbook doesn't actually make any connections, but I set up a 'capture' on the inside interface accepting 'ip any any' to see what kind of traffic I could see heading outbound from the Playbook. Well, it started off showing attempts to query DNS (and failed, naturally), but then after a couple of minutes, it tried to connect to a couple of IPs over port 443 and actually got a response!!! For the life of me, I can't figure out how this can happen. NO traffic should be allowed outbound due to my explicit 'deny' rule, but for some reason some traffic on port 443 made it past the firewall and got a response back. There are no other rules in the access list except the 'deny' rule. My PIX configuration is quite simple and I cannot see anything that would allow the Playbook traffic to circumvent the access list.

Does anyone have any idea why this could happen?

I've come to think that either RIM has found away around Cisco access-lists, or there is a bug in the Pix OS. I know it's an old appliance/OS, but still. I wouldn't think it could be THAT easy to bypass the firewall.

Any insight or suggestions would be appreciated.

Thanks!

Jennifer Halim · ‎09-21-2012

Pls kindly share your config and i am assuming that you have "access-group" configured for that access-list on the inside interface?

tuskenraider · ‎09-21-2012

Hi Jennifer. Yes, I have the access-group configured appropriately for the inside interface for that ACL.

Here is my config. Although, I've removed any sensitive info from it.

pix506e# show run
: Saved
:
PIX Version 6.3(5)
interface ethernet0 100full
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ****
passwd ****
hostname pix506e
domain-name domain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
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
fixup protocol tftp 69
names
access-list ACL_OUTSIDE permit icmp any any unreachable
access-list ACL_OUTSIDE permit icmp any any echo-reply
access-list ACL_OUTSIDE permit icmp any any time-exceeded
access-list ACL_INSIDE deny ip any any
access-list capture-acl permit ip any any
access-list NONAT permit ip 192.168.2.0 255.255.255.0 10.0.0.0 255.255.255.0
pager lines 24
logging on
logging buffered notifications
icmp deny any outside
mtu outside 1500
mtu inside 1500
ip address outside pppoe setroute
ip address inside 192.168.2.2 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPN_IP_POOL 10.0.0.10-10.0.0.20 mask 255.255.255.0
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NONAT
nat (inside) 1 192.168.2.0 255.255.255.0 0 0
static (inside,outside) tcp interface 3389 192.168.2.286 3389 netmask 255.255.255.255 0 0
access-group ACL_OUTSIDE in interface outside
access-group ACL_INSIDE in interface inside
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
aaa authentication ssh console LOCAL
http server enable
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
tftp-server inside 192.168.2.23 /config.cfg
floodguard enable
crypto ipsec transform-set ESP-AES256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 10800
crypto dynamic-map OUTSIDE_DYN_MAP 10 set transform-set ESP-AES256-SHA
crypto dynamic-map OUTSIDE_DYN_MAP 10 set security-association lifetime seconds 28800 kilobytes 4608000
crypto map OUTSIDE_MAP 10 ipsec-isakmp dynamic OUTSIDE_DYN_MAP
crypto map OUTSIDE_MAP interface outside
isakmp enable outside
isakmp identity address
isakmp nat-traversal 20
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption aes-256
isakmp policy 1 hash sha
isakmp policy 1 group 5
isakmp policy 1 lifetime 86400
isakmp policy 2 authentication pre-share
isakmp policy 2 encryption 3des
isakmp policy 2 hash md5
isakmp policy 2 group 2
isakmp policy 2 lifetime 86400
vpngroup VPNGRP address-pool VPN_IP_POOL
vpngroup VPNGRP idle-time 1200
vpngroup VPNGRP password ********
vpngroup groupmarketing idle-time 1800
telnet timeout 5
ssh 192.168.2.0 255.255.255.0 inside
ssh timeout 30
console timeout 0
vpdn group GROUPNAME request dialout pppoe
vpdn group GROUPNAME localname *******
vpdn group GROUPNAME ppp authentication pap
vpdn username ******** password *********
dhcpd address 192.168.2.100-192.168.2.200 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 300
Cryptochecksum:7415a984aad0e7ee046d8802a7ea4003
: end

And here is part of the capture that shows a response from a couple of IPs out on the internet. It's not establishing a connection as they're just RST packets coming back, but it's still a response from a public IP which shouldn't happen...

01:15:49.967982 192.168.2.100.65522 > 68.171.242.26.443: S 685081971:685081971(0) win 65535

01:15:49.968089 68.171.242.26.443 > 192.168.2.100.65522: R 0:0(0) ack 685081972 win 65535

01:15:50.047269 192.168.2.100.65521 > 216.9.242.86.443: S 3523366885:3523366885(0) win 65535

01:15:50.047330 216.9.242.86.443 > 192.168.2.100.65521: R 0:0(0) ack 3523366886 win 65535

Thanks for having a look!!

Jennifer Halim · ‎09-22-2012

The first and third packets are just SYN packets which will be denied by the access-list. Capture will see the packet off the wire before being processed by any access-list.

The second and the forth packets are just the firewall tell the host that it is being resetted, ie: no connection.

The firewall isn't passing any traffic out to the internet.

tuskenraider · ‎09-22-2012

Hmmm, interesting. A few questions then...

1) Why is the firewall actively resetting denied packets and not just simply dropping them like, I would think, a firewall should? I would think a firewall should try to be as invisible as possible to the user.

2) If you didn't have the means to look at the access-list to determine, how can you tell the difference between the firewall resetting the connection, or the other host/server resetting the connection when looking at the captured traffic? I simply looked at the source address (public IP) and assumed it came from the server.

3) Is there a way to disable this behavior and have the firewall simply drop the denied packets and not send reset packets back? I don't think this happens on the outside interface...

Thanks again for your insight!

Cheers.