[Dshield] Blocking Country Access
Tomas L. Byrnes
tomb at byrneit.net
Fri Feb 23 08:06:53 GMT 2007
I think this, and other things in the thread point out some basic
1: "First, do no harm" is a great idea, but isn't always practical. It's
hard to block spam and other malicious traffic without some collateral
damage, or letting too much garbage through (choose one).
2: In a small volume environment, you can tolerate a lot more false
negatives/load on the MTAs that you aren't going to actually accept, and
can also deal with the overhead of sending the 550 reason.
3: In a large volume environment, if you don't bin early, you may never
be able to process the volume of mail you receive.
There are many approaches to this. The one I developed tools to enable
is the one I have found works best for me: Bin all the most generally
accepted complete wastes of time @ the firewall, and do more
fine-grained filtering afterwards. The secondary advantage of this is
that, with the reduction of traffic the MTA has to process by 80%, I can
use much more CPU intensive filtering on the traffic that does get
through, which results in higher accuracy, with less reduction in
performance than if I processed ALL traffic @ content, in the secondary
Your mileage may vary. The beauty of not having the government run our
firewalls for us is that we can choose the policy, and tools, that make
sense for our environment.
> -----Original Message-----
> From: list-bounces at lists.dshield.org
> [mailto:list-bounces at lists.dshield.org] On Behalf Of Scott Melnick
> Sent: Thursday, February 22, 2007 9:20 PM
> To: General DShield Discussion List
> Subject: Re: [Dshield] Blocking Country Access
> Oh I hear you there. While my company does an extremely large
> amount of email traffic and does business in the USA only; I
> chose to do both. I stick Access Lists on my Border routers
> with the top 10 spam countries (except the US of course) and
> it lightens the load on my RBL/Antivirus processes and puts a
> bit of CPU on my border routers which can handle it.
> But this model works for me. It might not work for everyone.
> I'm not interested in being a spam trap unfortunately. To
> each his own eh?
> Scott Melnick
> On 2/22/07, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
> > On Wed, 21 Feb 2007 20:18:37 MST, Andrew Willy said:
> > I'm not Tony, but I'll just comment that most performance
> curves for
> > this sort of thing is usually not a smooth curve - it may work fine
> > for 70 users, and require no additional hardware for 700, or 7,000,
> > but it totally falls over if you try to put 70,000 people on it.
> > Doing RBL lookups for 4,000 messages a day is trivial -
> trying to do
> > RBLs for 4 million msgs/day without getting totally killed by the
> > additional latency is a major challenge. And I can't tell
> you where
> > the curve bends, because it's highly site dependent (on things like
> > network topology, the RBLs in use, and even what order you
> check the
> > RBLs
> > in...)
> > Actually, this would be *trivial* to do, except we have users that
> > want the million or so *legitimate* messages we handle a day to be
> > delivered in a timely fashion as well. Damned users - always being
> > the monkey wrench in the design. ;)
> > _________________________________________
> > SANS 2007 March 29 - April 6 in San Diego, CA offers 52
> Courses taught
> > by our top rated instructors plus a huge vendor tools expo.
> > Register Today! http://www.sans.org/info/2501 (BROCHURECODE: ISC)
> SANS 2007 March 29 - April 6 in San Diego, CA offers 52
> Courses taught by our top rated instructors plus a huge
> vendor tools expo.
> Register Today! http://www.sans.org/info/2501 (BROCHURECODE: ISC)
More information about the list