Alessandro Vesely writes:
With Linux, you can insert an iptables rule that rejects *out*bound packets to the blacklisted IPs in a manner that the sender, in this case courieresmtpd, thinks that the connection is broken and exits out, releasing the socket. Meanwhile the sender still remains tarpitted, thinking that the socket is still alive.Hm... blocking outbound so as to induce tarpitting apparently only affects what the server inflicts in retribution. If I understand well, blocking just (future) sync requests from the same IPs would result in similar figures for the attempted connections to port 25. Correct?
On the iptables level, yes. The initial SYN still gets through, the resulting SYN/ACK should get blocked by iptables, clearing the socket entry.
The real value-added is when an existing connection gets blocked. Blocking the inbound packets causes the connection to stall until it times out. Blocking the outbound packets, with REJECT, rather than drop, should end up clearing the socket immediately on the server side.
That, and a lengthy timeout before the iptables entry gets removed, so that the iptables does not grow without bounds, should do the trick.I guess you mean more than a few minutes timeout... Hours? Days?
A couple of hours, for starters.
This is harmless. It means that the sender dropped the connection while Courier still had something to send it. Poorly written SMTP senders are sending you a QUIT command, but don't bother wait for Courier to acknowledge the QUIT and orderly shut down the socket.Does that mean one shouldn't block based on this error? (Well, blocking outbound packets should be a no-op at this point, but what about blocking future sync requests?)
There might be some value in blocking on this error if the threshold is set very high. Since legitimate (but buggy) clients can also cause that, the threshold should be set very high.
Finally, it looks like you use netfilter. May I ask what userspace program do you run to issue verdicts? I had been looking for such utility, but eventually had to roll my own one...
I don't use netfilter at the moment, not for SMTP. I use it with portsentry, which has convenient hooks. For SMTP I just have a script that parses the maillog, and drops all IPs that have logged more than ten "User unknown" errors into smtpaccess.
It slipped my mind, but I should've mentioned this possibility. It's low tech, but some may find it surprisingly effective. A typical spam zombie's first run will easily rack up at least ten "User unknowns'. So the first connection will spin, until it eventually times out. But, by then, the zombie's IP address will already be in smtpaccess, and all future connection attempts will be dropped by couriertcpd.
The only potential pitfall to watch out for are zombies that keep trying repeatedly and immediately. You may end up with them flooding your bandwidth, since couriertcpd will accept and drop their connection immediately, afterwards they'll try again without delay. Lather, rinse, repeat.
pgpksOBpR2BPF.pgp
Description: PGP signature
------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
