ACL to block SPAM sources
Sam
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 (http://iana.org/assignments/ipv4-address-space) 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?
Trendkill
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?
Doug McIntyre
>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 (http://iana.org/assignments/ipv4-address-space) and
>blocked all address spaces, that weren't on the ARIN list, from
>accessing my mail server.
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...
Barry Margolin
<33f6af0c-092f-4118...@25g2000hsx.googlegroups.com>,
Trendkill <jpm...@gmail.com> wrote:
> On May 17, 3:40 am, Sam <talons...@yahoo.com> wrote:
> > 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 (http://iana.org/assignments/ipv4-address-space) 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).
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.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Sam
ACL entry:
access-list 101 deny 25 88.0.0.0 0.255.255.255 host 192.168.1.10
Email Header:
Received: from 38.Red-88-1-10.dynamicIP.rima-tde.net ([88.1.10.38]) by
mydomain.com with Microsoft SMTPSVC(6.0.3790.3959);
It seems to be the /8 address blocks ACLs that aren't having any affect.
Sam
Oh, and the list is applied to my external interface on the input side.
Walter Roberson
>ACL entry:
>Email Header:
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
Sam
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
News Reader
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.
Your ACE:
access-list 101 deny 25 88.0.0.0 0.255.255.255 host 192.168.1.10
... means deny "protocol 25" source destination (no port specification)
Walter's ACE:
access-list 101 deny tcp 88.0.0.0 0.255.255.255 any eq 25
... means deny "protocol TCP" source destination eq "port 25" (i.e.: SMTP)
Best Regards,
News Reader
Walter Roberson
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.