On 11/21/2012 7:01 PM, Alex wrote:
> I pulled the IPs out of the logs for these 'lost connection' errors
> over the last 24hrs, and it does appear that there are multiple IPs in
> the same network losing the connection. This also doesn't really prove
> much, but there are cases where there are dozens of consecutive 'lost
> connection' errors for a single IP.
>
> I'm sure by now it's in the PBL or SBL.
This is a bad assumption. The PBL lists dynamics/etc, not snowshoe IPs.
The SBL lists some snowshoe IPs, but you likely won't see a lot of
overlap with other IP based DNSBLs. Snowshoe is notorious for avoiding
traps that feed IP based DNSBLs.
> I searched for 198.41.120 and found hundreds of entries such as these:
>
> Nov 21 19:39:14 mail01 postfix/postscreen[9111]: PASS OLD
> [198.41.120.10]:47864
>
> They were later all tagged as spam, but it would definitely be nice to
> be blocking these outright with postscreen. I've now added an iptables
> rule manually, but I wish there was a way to build in some
> intelligence to automate it, such as with fail2ban.
Unfortunately fail2ban doesn't work for snowshoe. The rate is
intentionally low, which is why snowshoe avoids most trap driven DNSBLs
as well.
> Are you suggesting I increase the weight of the BRBL with postscreen?
I don't use postscreen. I block outright in SMTPD on any DNSBL hit.
I.e. I don't use weighting. With any of the reputable DNSBLs you should
probably outright block, not score. So set postscreen weighting so any
hit causes a rejection. If you are FP averse, simply duplicate your
postscreen DNSBL config in SMTPD with 'WARN_IF_REJECT' and do a log
comparison to see what additional clients would be rejected. If you're
not seeing warnings on ham, go live.
> postscreen_dnsbl_sites = myhost.zen.dq.spamhaus.net*2
> bl.spamcop.net*1 b.barracudacentral.org*1 psbl.surriel.com*1
>
> This IP is now listed in barracuda, but wasn't when it was received.
> It only hit the URIBL list.
Since Nov 18 I've blocked every connection from this /24 with a
combination of BRBL and DBL. The first attempt here from 198.41.120.10
(which you reference above) at Nov 21 17:38:30 was blocked by DBL. The
first attempt from this /24 was nailed by BRBL at Nov 18 16:57:41.
postscreen doesn't handle domains, only IPs. Your main.cf parameters
show you're not rejecting snowshoe domains via RHSBLs. You should be
using something like this
smtpd_recipient_restrictions =
...
reject_rhsbl_reverse_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.org
reject_rhsbl_helo dbl.spamhaus.org
...
And in fact you asked about DNSBLS in April 2010
http://comments.gmane.org/gmane.mail.postfix.user/208344
and were given all of this information then, by Ralf and myself. You
can also use multi.uribl.com and multi.surbl.org here, requiring a total
of 9 parameter entries.
I just noticed you don't require HELO. So you need this as well:
smtpd_helo_required = yes
And in fact, your current HELO based restrictions are having no effect
if clients don't send HELO/EHLO:
check_helo_access pcre:/etc/postfix/helo_checks.pcre
reject_invalid_helo_hostname
> Yes, I wish I had the resources for this.
Check out: http://dnsbl.invaluement.com/ivmsip/
> It sounds like I should at least be doing some QoS work with tc to
> throttle the number of connections from a single IP.
Your kernel is shutting down the SYN flood, which is what that kernel
message tells you, so Postfix isn't being affected, and it's probably
not doing any harm to your system, performance or otherwise. I simply
feel it would be better to shut this down at an upstream firewall.
> Yes, I definitely know that the disks in my configuration are a
> bottleneck. If I had to do it over I would use RAID10.
For gateway/AS appliance queue duty with no local mailboxes you should
seriously look at using two smallish good quality (Intel) SSDs mirrored
(with a hot spare) with a low end hardware RAID controller (allows boot,
/, and queue on the mirror device). It's cheaper and 100s of times
faster than rust in RAID10, and you simply never have to worry about an
IO bottleneck. Something like:
http://www.newegg.com/Product/Product.aspx?Item=N82E16816103229
http://www.newegg.com/Product/Product.aspx?Item=N82E16820167120
> There is some amount of CPU iowait, but the majority of the time the
> processors are more idle than fully utilized.
They always will be mostly idle. You have 8 cores and 8GB RAM for an
SMTP/filter workload. Such a system with a few SSDs or a very large
spindle count rusty RAID and a GbE connection could handle many hundreds
of msgs/sec, if configured properly. The performance key to the SMTP
workload has always been, and always will be, random IO throughput
to/from the queue directory and/or mailboxes.
> Thanks so much for your help. Really appreciate it.
Always glad to help "Alex". ;)
--
Stan
