Hi,
>>> Nov 19 20:39:03 mail01 postfix/smtpd[19820]: lost connection after
>>> CONNECT from listserver.translateplanmulti.info[198.41.120.7]
>>
>> Your server is too slow, so that connections pile up in front of
>> it.
>
> translateplanmulti.info is a snowshoe domain, 198.41.120.0/24, and
> everyone should be blocking it. Postscreen by default stops bots, not
> snowshoe ratware. Alex' smtpds and amavis/SA may be getting hammered by
> snowshow connections, though this one log entry alone doesn't prove such.
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.
> Before expending the effort on full bottleneck analysis, I'd recommend
> Alex should first concentrate on blocking more spam outright before it
> reaches his smtpds and thus his content filters. My logs back to the
> 18th show the same snowshoe spammer, with BRBL blocking every connection:
>
> Nov 18 16:57:41 greer postfix/smtpd[9352]: NOQUEUE: reject: RCPT from
> listserver.translateplanmulti.info[198.41.120.7]: 554 5.7.1 Service
> unavailable; Client host [198.41.120.7] blocked using b.barracudacentral.org
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.
Are you suggesting I increase the weight of the BRBL with postscreen?
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.
> filters. Reducing that load will likely help this delay issue. This
> can also be done with a local block list such as a CIDR table for
> subnets, or an indexed table for domains, though this involves much more
> labor than getting DNSBLs to do the work for you.
Yes, I wish I had the resources for this.
> In addition, the Linux kernel SYN flood warning indicates Alex needs a
> firewall in front of this host, or a better configuration on it, or that
> he should implement packet filtering, or better packet filtering, on the
> host itself, via iptables rules.
It sounds like I should at least be doing some QoS work with tc to
throttle the number of connections from a single IP. This looks like a
good article to read through before a turkey dinner tomorrow:
http://www.techrepublic.com/blog/10things/10-iptables-rules-to-help-secure-your-linux-box/539
> If due to policy most spam needs to go through the content filters for
> flagging, a 4x1TB 7.2K RAID5 setup may be insufficient to sync the load
> due to parity RAID's horrible random write throughput.
Yes, I definitely know that the disks in my configuration are a
bottleneck. If I had to do it over I would use RAID10.
There is some amount of CPU iowait, but the majority of the time the
processors are more idle than fully utilized.
Thanks so much for your help. Really appreciate it.
Alex
