1. Home
  2. Cisco Systems
  3. Deny all foreign IP traffic using Cisco PIX 501

Deny all foreign IP traffic using Cisco PIX 501

Thank you all for your time and assistance.

I am looking for a simple solution, whereby our Cisco PIX 501 can be configured correctly to prevent the access of the servers behind it by filtering any IP addresses that do no originate for the USA.

Our Email server is being viciously attacked on port 25, mostly by IP addresses originating from the APNIC, LATNIC and RIPE networks. Thus, causing much unneeded processing power on our servers and upsetting many of our customers due to increased lag time, etc. In addition, most of the SPAM that originates from these countries would ultimately be prevented at the front-line of our network.

We are using a Cisco PIX 501 Firewall running the latest firmware and pdm. Using the syslog and kiwi program, we have been able to generate a list of the malicious IP addresses and have created groups in accordance with their respective IP network range name (ie APNIC, LATNIC, etc). As time goes on, we will continue to see the IP ranges that we missed and add them to the group.

Below is our current applicable "show run", however for some reason we continue to see certain IP addresses in the log files of our mail server that should have been blocked. What are we doing wrong? Please help.

access-list acl_outside deny ip object-group RIPE any access-list acl_outside deny ip object-group SIDTA any access-list acl_outside deny ip object-group APNIC any access-list acl_outside deny ip object-group LACNIC any

object-group network RIPE network-object 81.0.0.0 255.0.0.0 network-object 82.0.0.0 255.0.0.0 network-object 83.0.0.0 255.0.0.0 network-object 85.0.0.0 255.0.0.0 network-object 88.0.0.0 255.0.0.0 network-object 212.0.0.0 255.0.0.0 network-object 213.0.0.0 255.0.0.0 network-object 80.0.0.0 255.0.0.0 network-object 62.0.0.0 255.0.0.0 network-object 84.0.0.0 255.0.0.0 network-object 91.0.0.0 255.0.0.0 network-object 92.0.0.0 255.0.0.0 network-object 93.0.0.0 255.0.0.0 network-object 94.0.0.0 255.0.0.0 network-object 95.0.0.0 255.0.0.0 network-object 86.0.0.0 255.0.0.0 network-object 87.0.0.0 255.0.0.0 network-object 89.0.0.0 255.0.0.0 network-object 90.0.0.0 255.0.0.0 network-object 139.10.0.0 255.255.0.0 network-object 139.12.0.0 255.255.0.0 network-object 139.16.0.0 255.255.0.0 network-object 139.18.0.0 255.255.0.0 network-object 139.24.0.0 255.255.0.0 network-object 139.28.0.0 255.255.0.0 network-object 139.30.0.0 255.255.0.0 network-object 147.83.0.0 255.255.0.0 network-object 147.84.0.0 255.255.0.0 network-object 147.91.0.0 255.255.0.0 network-object 193.0.0.0 255.0.0.0 network-object 194.0.0.0 255.0.0.0 network-object 195.0.0.0 255.0.0.0 network-object 217.0.0.0 255.0.0.0 network-object 58.0.0.0 255.0.0.0 network-object 59.0.0.0 255.0.0.0 network-object 60.0.0.0 255.0.0.0 network-object 61.0.0.0 255.0.0.0 network-object 202.0.0.0 255.0.0.0 network-object 203.0.0.0 255.0.0.0 network-object 210.0.0.0 255.0.0.0 network-object 211.0.0.0 255.0.0.0 network-object 218.0.0.0 255.0.0.0 network-object 219.0.0.0 255.0.0.0 network-object 220.0.0.0 255.0.0.0 network-object 221.0.0.0 255.0.0.0 network-object 222.0.0.0 255.0.0.0 network-object 165.228.0.0 255.255.0.0 network-object 165.229.0.0 255.255.0.0 network-object 168.140.0.0 255.255.0.0 object-group network SIDTA description FR network-object 57.0.0.0 255.0.0.0 object-group network APNIC network-object 116.0.0.0 255.0.0.0 network-object 117.0.0.0 255.0.0.0 network-object 118.0.0.0 255.0.0.0 network-object 119.0.0.0 255.0.0.0 network-object 58.0.0.0 255.0.0.0 network-object 59.0.0.0 255.0.0.0 network-object 60.0.0.0 255.0.0.0 network-object 61.0.0.0 255.0.0.0 network-object 114.0.0.0 255.0.0.0 network-object 115.0.0.0 255.0.0.0 network-object 126.0.0.0 255.0.0.0 network-object 125.0.0.0 255.0.0.0 network-object 124.0.0.0 255.0.0.0 network-object 123.0.0.0 255.0.0.0 network-object 122.0.0.0 255.0.0.0 network-object 121.0.0.0 255.0.0.0 network-object 120.0.0.0 255.0.0.0 network-object 222.0.0.0 255.0.0.0 network-object 221.0.0.0 255.0.0.0 network-object 220.0.0.0 255.0.0.0 network-object 219.0.0.0 255.0.0.0 network-object 218.0.0.0 255.0.0.0 network-object 211.0.0.0 255.0.0.0 network-object 210.0.0.0 255.0.0.0 network-object 203.0.0.0 255.0.0.0 network-object 202.0.0.0 255.0.0.0 network-object 169.208.0.0 255.255.0.0 object-group network LACNIC network-object 200.0.0.0 255.0.0.0 network-object 201.0.0.0 255.0.0.0 network-object 190.0.0.0 255.255.255.0

Reply to
igotlotsofspace
Loading thread data ...

No, that is not possible on any device what-so-ever. There is no way to establish with certainty where an IP address originates. The closest you can come is to check the registrations for the block.

It is, for example, well known that there are hosts in the UK whose public IP address is registered in the USA. Traffic directed to those hosts reaches some network boundary in the USA and what happens after that to transport the packets to whatever country are internal details not for public consumption. Leased lines / fibre, private links, satellite, entire world-wide operations run on an MPLS whose public interfaces are channeled through tough security layers at a USA site... whatever. You can't prove where an IP is.

I've done similar things with that kind of equipment.

I don't see anything obviously wrong in the portion of your configuration that you provided. I would, of course, double-check that you have

access-group acl_outside in interface outside

Are you logging all denied connections and all successful connections? I believe you will need logging level 6 to get the successful connections (unless you fiddle with the level options on 'logging message' configuration lines.) If you have this information recorded, could you show a message header for a message that got through when it should not have (with your identifying details obscured, of course), together with the PIX log entries for that particular connection ?

Reply to
Walter Roberson

Thank you for help.

  1. I understand that there is no true way of identifying an IP's true location. However, all public IP addresses belong to a range managed by a group (i.e. APNIC, RIPE, LATNIC). With that being said, I want to block all IPs that belong to these groups.

  1. I confirmed the existance of entry "access-group acl_outside in interface outside"

  2. I am capturing within a log, the events occuring on the PIX itself through a syslog service (kiwi software). Here is an excerpt from a recent text file:

2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-302013: Built inbound TCP connection 33048672 for outside:58.239.54.108/4286 (58.239.54.108/4286) to inside:192.168.1.9/25 (70.46.74.229/25)

2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-302013: Built inbound TCP connection 33048673 for outside:195.3.96.91/20171 (195.3.96.91/20171) to inside:192.168.1.9/25 (70.46.74.229/25) 2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-302016: Teardown UDP connection 33048671 for outside:216.199.54.9/53 to inside: 192.168.1.9/3498 duration 0:00:01 bytes 156 2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-106015: Deny TCP (no connection) from 160.7.240.5/25 to 70.46.74.229/3492 flags RST on interface outside 2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-302016: Teardown UDP connection 33048670 for outside:216.199.54.9/53 to inside: 192.168.1.9/3497 duration 0:00:01 bytes 568 2008-05-25 00:02:53 Local4.Info 192.168.1.1 %PIX-6-302015: Built outbound UDP connection 33048674 for outside:216.199.54.9/53 (216.199.54.9/53) to inside:192.168.1.9/3499 (70.46.74.229/3499) 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302016: Teardown UDP connection 33048674 for outside:216.199.54.9/53 to inside: 192.168.1.9/3499 duration 0:00:01 bytes 460 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302015: Built outbound UDP connection 33048675 for outside:216.199.54.9/53 (216.199.54.9/53) to inside:192.168.1.9/3500 (70.46.74.229/3500) 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302014: Teardown TCP connection 33048659 for outside:160.7.240.5/45859 to inside: 192.168.1.9/25 duration 0:00:01 bytes 3340 TCP Reset-O 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-106015: Deny TCP (no connection) from 160.7.240.5/45859 to 70.46.74.229/25 flags RST on interface outside 2008-05-25 00:02:54 Local4.Warning 192.168.1.1 %PIX-4-106023: Deny tcp src outside:189.38.50.187/57455 dst inside:70.46.74.229/113 by access- group "acl_outside" 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302016: Teardown UDP connection 33048675 for outside:216.199.54.9/53 to inside: 192.168.1.9/3500 duration 0:00:01 bytes 129 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302013: Built inbound TCP connection 33048676 for outside:66.38.158.225/12132 (66.38.158.225/12132) to inside:192.168.1.9/25 (70.46.74.229/25) 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302013: Built inbound TCP connection 33048677 for outside:202.124.143.137/32910 (202.124.143.137/32910) to inside:192.168.1.9/25 (70.46.74.229/25) 2008-05-25 00:02:54 Local4.Warning 192.168.1.1 %PIX-4-106023: Deny tcp src outside:189.38.50.187/50837 dst inside:70.46.74.229/113 by access- group "acl_outside" 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-302014: Teardown TCP connection 33048676 for outside:66.38.158.225/12132 to inside: 192.168.1.9/25 duration 0:00:01 bytes 55 TCP Reset-I 2008-05-25 00:02:54 Local4.Info 192.168.1.1 %PIX-6-106015: Deny TCP (no connection) from 66.38.158.225/12132 to 70.46.74.229/25 flags FIN ACK on interface outside
Reply to
igotlotsofspace

Here is the log information from the MAIL SERVER that resides BEHIND the firwall. Notice the originating IP addresses that should have been blocked at the firewall level to begin with. How did it pass through the firwall!?

89.108.64.23 [1830] 23:59:59 > 221 2.0.0 webmail.getbinary.com closing connection SYSTEM [1830] 23:59:59 Disconnected 209.11.145.21 [1830] 23:59:59 Connected 209.11.145.21 [1830] 23:59:59 >>> 220 webmail.getbinary.com ESMTP Binary Solutions Mail Server; Sat, 24 May 2008 23:59:59 -0400 74.53.207.2 [1E1C] 23:59:59 Connected 74.53.207.2 [1E1C] 23:59:59 >>> 220 webmail.getbinary.com ESMTP Binary Solutions Mail Server; Sat, 24 May 2008 23:59:59 -0400 74.53.207.2 [1E1C] 23:59:59 > 250 webmail.getbinary.com Hello server.unimundi.com.br [74.53.207.2], pleased to meet you. 209.11.145.21 [1830] 23:59:59 > 250-webmail.getbinary.com Hello aragorn.webappcabaret.net [209.11.145.21], pleased to meet you. 74.53.207.2 [1E1C] 23:59:59 > 250 2.1.0 ... Sender ok 74.53.207.2 [1E1C] 23:59:59 > 250 2.6.0 2828 bytes received in 00:00:01; Message id FIG42158 accepted for delivery 209.11.145.21 [1830] 23:59:59 > 220 2.0.0 Ready to start TLS 74.53.207.2 [1E1C] 23:59:59 >>> 451 4.7.1 Please try again later 74.53.207.2 [1E1C] 23:59:59 > 221 2.0.0 webmail.getbinary.com closing connection SYSTEM [1E1C] 23:59:59 *** 0 0 00:00:00 WARNING SYSTEM [1E1C] 23:59:59 Disconnected 209.91.173.149 [1E58] 23:59:59 > 221 2.0.0 webmail.getbinary.com closing connection SYSTEM [1E58] 23:59:59 Disconnected 190.22.254.75 [1E58] 23:59:59 Connected 190.22.254.75 [1E58] 23:59:59 >>> 220 webmail.getbinary.com ESMTP Binary Solutions Mail Server; Sat, 24 May 2008 23:59:59 -0400 88.238.40.154 [1974] 23:59:59 > 250 2.1.0 ... Sender ok 189.42.253.137 [1E1C] 23:59:59 Connected 189.42.253.137 [1E1C] 23:59:59 >>> 220 webmail.getbinary.com ESMTP Binary Solutions Mail Server; Sat, 24 May 2008 23:59:59 -0400 209.11.145.21 [1830] 23:59:59 > 250-webmail.getbinary.com Hello aragorn.webappcabaret.net [209.11.145.21], pleased to meet you.
Reply to
igotlotsofspace

An interesting thing about the log extract you included is that it contains *no* denials to port 25 -- only denials to port 113.

That -looks- like a denial to port 25, but it is really just an entry dealing with the fact that the connection in question had already been closed down by the inside host.

My best guess at the moment is that the denials by IP are placed -after- a permit of 'any' to the smtp port in your access-list. Access lists are processed from top to bottom, and as soon as a hit is found, the processing stops. If you have a 'permit' entry and then later a 'deny' entry that overlaps, the 'deny' will not be looked at.

Reply to
Walter Roberson

Amazing, how the culprit is usually the most minor detail.

Sir, I thank you, praise you, and commend you. You have been of the most greatest assistance. The resolution, was in fact, having the DENY rules first and foremost BEFORE the ALLOW rules.

You are the man. Thank you again and again!

Reply to
igotlotsofspace

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.