From: /dev/rob0 (rob0gmx.co.uk)
Date: Fri Nov 18 2005 - 17:26:03 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wednesday 2005-November-16 22:11, Ron Wheeler wrote:
> /dev/rob0 wrote:
> >On Tuesday 2005-November-15 23:57, Ron Wheeler wrote:
> >>>Ron Wheeler a écrit :
> >>>>Does anyone have a list of IP addresses used by the major spam
> >>>>houses. I would like to block them at the firewall to reduce the
> >>>>total mount of traffic.
> >snip
> >>I was thinking of giving them a place to send an e-mail through our
> >>www site if they can not get through to us otherwise.
> >
> >Pardon me if I am misunderstanding something, but if you are
> > blocking these hosts at the firewall, how will they get to your
> > HTTP server? If you're only blocking SMTP, there is little benefit
> > in that approach over reject_rbl_client.
>
> My thinking goes like this:
> If I just drop the packets going to port 25 of the mail server from
> the addresses
> a) There is no traffic on my DMZ
> b) I will only get dinged $ for the initial short packet not a
> whole e-mail header.

Yes, this is the "little benefit" to which I was referring. But "a" is
cheap (my biggest sites have Fast Ethernet which is nowhere near
saturation) and "b" is a slight misunderstanding. The SMTP dialogue
does not transfer headers; you might more accurately say that it
negotiates an envelope.

Your idea:
Firewall receives SMTP connection, and either drops it or sends ICMP
port unreachable. Small cost in down bandwidth, smaller or no cost in
up bandwidth.

reject_rbl_client:
SMTP goes through to Postfix server. Reverse DNS and RBL checks are
done. Client is rejected after a brief dialogue. Percentage wise you
may be looking at 2-3 times the up and down bandwidth usage, but in
absolute terms it is still very small.

Question to the group:
Do you think the bandwidth savings from the firewalling approach would
be significant? Especially considering that the spamming list of IP
addresses needs to be made available to the firewall, and that the
probable means of doing that would be an RBL lookup from there, I am
still thinking that the reject_rbl_client is better.

> c) The spammer will see a "dead" MX server which ties up his SMTP
> server and
> he will either drop me from his lists or at least pay a
> timeout price on each of the 60,000 e-mails each day
> which could benefit other victms by reducing his ability to
> get mail out.
> The timeout probably holds him up longer than a rejected
> e-mail which goes off his server in a few milliseconds.

These issues have bee discussed to a great extent many times. Real life
experience shows that most spammers do not prune their lists. Social
benefits of tarpitting spammers are questionable.

> My firewall probably has more time to look up IP addresses than
> my mail server.

How do you figure? A firewall has to make a real-time decision. It
cannot queue packets during RBL lookups. It has to know the RBL IP
addresses in advance.

OTOH smtpd(8) can make clients wait whilst it does its checking. Delays
of many seconds are commonplace and completely acceptable.

> I do not know how smart iptables is but I do have enough
> memory to hold a lot of addresses in memory and I have 512 MB sitting
> in a drawer that I could add.

It might work. I doubt it's worth the trouble. How often are you going
to fetch the list of addresses? I think that should more than offset
your small savings in bandwidth.

Comments and opinions to the contrary are solicited. My firewalling
knowledge is limited to Linux netfilter. Would this be a more viable
idea with other firewall implementations? What would be the effects of
a firewall doing a case-by-case RBL lookup on incoming SMTP?
--
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]