[Dshield] Blocking Country Access
tonni at hetnet.nl
Thu Feb 22 02:54:41 GMT 2007
Tomas L. Byrnes wrote, on 21. feb 2007 19:16:
> It depends on what you are blocking, and why. The DShield lists are of
> port scanners, which is more akin to the coyotes coming into your yard
> and trying to get in the cat door to get at your cat. threatSTOP
> provides those, and the TQM lists, in a form that your firewall can
> block on.
> If you're blocking SPAM @ the MTA level, and you are using RBLs, then I
> don't see the difference in security effect or probability of collateral
> damage of having a rule that blocks the first SYN @ the firewall, where
> it costs you a 64 byte TCP SYN, as opposed to using an MTA block, where
> you have to accept the connection, do a DNS lookup, and then send the
> 500 message. It costs you a lot less CPU and BW, and the spammer doesn't
> typically try more than one connection, because they don't see port 25
> as open at all.
We do use RBLs when all other blocks (including greylisting) have been
passed. See my answer to Dave Hatz for one of these. We only use cidr
subnet blocks on networks we're pretty sure will never send us bona fide
mail and we *analyze each and very refused connection (including cidr
blocks)*, every day and several times per day, so that we get the chance
of unblocking/whitelisting clients that on reconsideration don't merit
blocking. We get to see the whole smtp conversation, namely.
If we were blocking at firewall level, we'd never get to see all this.
Hence my remark on "cutting the cat's throat".
> IOW: Dropping a connection that you are going to drop @ the MTA @ the
> firewall saves you bandwidth, and CPU on the MTA, for the exact same
> effect that you get with an MTA RBL.
The point of our using RBLs at all, is that they are dynamic. We are
relying on 4 carefully chosen authorities to judge for us; anyone on
their block lists can get off them again by repenting without us having
to lift a finger. We also use other, empiric blocks relating to client
behavior, specifically conformance to rfc2821.
Email: tonni at hetnet dot nl
More information about the list