Ok, So I finally got fed up with all the spam I have been seeing lately and decided to put a 3640 between the cable modem and network with some ACLs in place to block the source IP addresses.
I have noticed, though, that the spam is somehow still getting through the ACLs.
The method I went with was to use a nuke to kill a fly approach. I went to this website
formatting link
and blocked all address spaces, that weren't on the ARIN list, from accessing my mail server.
What I have been seeing is that there are some that are listed in the ACL that should match, but the router still allows it to pass. Am I missing something on how these are supposed to work?
You are using a ACL to block spam email? Your email server is external to your network is it not, aka hotmail or something? Your ACL wouldn't block anything, as the mail is sent to your mail server, which you then connect to to download via outlook (smtp, pop3, etc).
Presuming you are talking about spam traffic (never heard that term before, but I'll go with it since using a router to block spam email doesn't really make sense), paste us your ACLs. Which interface did you apply it to, and which direction is the ACL blocking?
95% of my SPAM comes from within ARIN's IP space, so I'm not sure how well you expect this to work..
How about posting a small portion of your ACL list (preferably the one line that should have matched the failure), where it is applied, and an example of a false positive that made it through...
He's running his own mail server, not using a third party like hotmail. He said "block ... from accessing MY MAIL SERVER".
As someone else said, this ACL is not likely to be very effective. Spammers mostly use zombies that have been compromised with viruses, and they have these machines on all continents. Probably most of them are in the US, simply due to our population and high rate of computer ownership.
There are much better solutions, like having your mail server consult an RBL to recognize valid client addresses.
An ACL applied against an outside interface needs to be written in terms of public IP addresses for the destination, as the ACL will be evaluated -before- NAT translation is done.
The above ACL entry appears to be acting to block IP protocol 25, "Leaf-2" (what-ever that is) rather than blocking TCP port 25.
For simplicity, I am going to assume that there are no internal hosts that you *do* want these people to be able to send email to:
access-list 101 deny tcp 88.0.0.0 0.255.255.255 any eq 25
Ok, I see what you mean. So if I wanted to allow http to a host, it would be better to place and ACL on the internal facing interface after the NAT has occured and have it look something like this:
access-list 102 permit tcp any host 192.168.1.10 eq 80
It doesn't look like you grasped the two points Walter was making.
Point 1: The ACL applied inbound on your external interface references a "private" destination address (192.168.1.10). He was indicating that the ACL should reference the "inside global" address of the mail server (i.e.: globally-routable ISP assigned address that is NAT'd to the internal private address)
Point 2: He was identifying an issue with the protocol and port definitions in your ACE.
More of my experiece is with the PIX, which only allows ACLs to be applied "in" an interface (that is, traffic reaching the device via that interface.) If you were to apply the above ACL "in" your internal interface, you would be permitting your inside hosts to access port 80 on the public IP 192.168.1.10, which would not be what you would want. But as you are not using a PIX, you have the option of applying an ACL "out" an interface.
I haven't paid a great deal of attention to ACLs "out" interfaces. Historically they were an invitation to Cisco IOS routers to punt all the packets to the processor path; I imagine the higher end devices have remedied that by now. When last I looked (4-ish years ago) there were some Cisco IOS devices that omitted "out" ACLs from their capabilities, as not matching the hardware packet flow model. ACLs "out" an interface require that the entire packet be processed through the "in" interface ACL, NAT done, any broadcasting done, and then at the last moment before actually releasing the packet on the wire, check to see if it is permitted. That's bad news for DoS attacks and times that hosts aren't actually trying to DoS you but have been botnet'd into probing your defences: generally speaking it is most efficient to stop packets as close to the periphery of your network as is practical, rather than letting the packets take up limited routing and stateful resources before denying them.
What comes to mind after these years is that about the only "legitimate" use for ACLs "out" interfaces had to do with with blocking certain routing protocols or failover-triggering packets from going where they weren't wanted; I -think- I remember seeing some examples in the High Availability Networking With Cisco Equipment book that relied on those kind of subtle interactions.
In short... No, *I* wouldn't do it the way you suggest, but it could work if you had set everything else up properly.
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.