
Best
of the ISP-Lists
General
Mail From Brazil Isn't Welcome Here
Members of the ISP-Tech list contemplate the alternatives as one
ISP considers shutting off Brazil because of spammers with total access to the
ILEC's network.
On the ISP-Tech list in September, JN queried,
"I'm having problems blocking a spammer's network from cramming
our mail server. I can easily enter IP routes for his class Cs and send them
to null0, but this guy has access to 200.128/9, and I can't enter enough class
Cs to keep him off our network for more than a couple of minutes before he
finds a workable IP and brings our mail server to a crawl again. I'm tempted
to just direct all 200.x.x.x to null0: in fact, I even tried that, to no effect.
Am I doing something wrong?"
Some respondents considered blocking the source country as a whole:
[SS asked] "That's a huge number of addresses:
where's he coming from?"
[JN explained] "It's Telefonica,
the Brazilian ILEC. They've hit us on IPs ranging from 200.161 to 200.207. At
this point, I'm willing to lose all of Brazil, if I have to."
[BL offered] "Check out Blackholes.us.
They have blackhole listings for many spammer-friendly countries. Simply add
them to your sendmail.mc as follows:
FEATURE('dnsbl', 'brazil.blackholes.us','brazil.blackholes.us refused -
Mail from Brazil isn't welcome here')dnl
Then regenerate the cf files and restart sendmail. Blackhole sites that I
personally use include the following:
FEATURE('dnsbl', 'blackhole.compu.net')dnl
FEATURE('dnsbl', 'pacbelldsl.compu.net','Pacbell DSL refused - Dialup address
address use your local mail server')dnl
FEATURE('dnsbl', 'list.dsbl.org')dnl
FEATURE('dnsbl', 'opm.blitzed.org')dnl
FEATURE('dnsbl', 'dun.dnsrbl.net','dnsrbl refused - Dialup address use your
local mailserver')dnl
FEATURE('dnsbl', 'spam.dnsrbl.net')dnl
FEATURE('dnsbl', 'Dialups.relays.OsiruSoft.com','osirusoft refused - Dialup
address use your local mailserver')dnl
FEATURE('dnsbl', 'bl.spamcop.net')dnl
FEATURE('dnsbl', 'inputs.relays.osirusoft.com')dnl
FEATURE('dnsbl', 'relays.ordb.org')dnl
FEATURE('dnsbl', 'Spamsites.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'Spamhaus.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'Spews.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'flowgoaway.com')dnl
FEATURE('dnsbl', 'blackholes.intersil.net')dnl
The above blackholes catch 99.9 percent of the spam sent to users of my service.
I receive about one complaint about mail getting blocked every six months or
so. I just inform the user and ISP what happened, and how to get themselves
removed from the lists. This seems to settle most people's issues with the use
of the blackhole list."
[JN noted] "Fortunately, we have very good
blocking in place on our mail server: I was instantly able to deny the sending
of spam by Brazilian IPs. But that doesn't change the fact the server still
accepts the mail, and must generate the bounce back, creating both CPU load
and wasted bandwidth. I would prefer to just snip the connection from his network
to mine at will."
Others pointed out that it's crucial to block the right part of the traffic:
[DS observed] "If you blackhole his route
advertisements, the traffic back to him is all that's stopped. You will, in
effect, make him SYN flood your mail servers. Think about it: the frying pan
you are in now may be more agreeable than the fire."
[JN countered] "How would he SYN flood my
mail server, if his IP traffic never reaches it because the router throws it
away?"
[ED explained] "You null route his netblock,
meaning the traffic you send never reaches them. You still receive incoming
SYN attempts, but your SYNACK never reach their destination. They keep retrying
the SYN, and you suddenly are the proud recipient of a SYN flood."
[PH added] "The blackhole route throws away
traffic from your server back to his. The connection will never be made, but
your server will be trying to complete it, and his spamware will probably try
a few SYNs per connect attempt, and a few connect attempts per victim."
Still others suggested that an access control list (ACL)
may be the best solution:
[ED advised] "Don't null route. Use an ACL
to block based on source."
[PH agreed] "When using an access list, you
prevent the SYN from ever reaching the server (he'll still try to send them,
but at least you are not as much affected by it). Put the access list on the
interface of the LAN the mail server is on."
[JN contended] "ACLs are not preferable due
to processor intensiveness, but if it is the only way to stop it, then so be
it."
[DS explained] "While ACLs do increase your
CPU load on non-hardware forwarding platforms, the effects can be marginal.
The importance is to look at your average CPU load prior, pick the best switching
path to give you the most CPU headroom, and if you have a really long ACL, make
sure you are enabling TurboACLs (also known as compressed-ACLs)."
[PH added] "At least by putting ACLs on the
output interface, if things get slowed down due to big traffic flows, there's
better buffering that way. If it's a big LAN with lots of other servers, another
option is to use a second interface, route just the mail server address(es)
out to it, and put the ACL there. Or better yet, investigate how to ACL in the
mail server's OS."
End
|