Sam Varshavchik wrote: >> 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.
Unfortunately, that cannot be done with netfilter queue: one invokes the userspace program with "iptables -A <cond> -j NFQUEUE". (<cond> is where one can decide about packet direction, SYN flag, and the like.) The userspace utility will only be able to say ACCEPT or DROP. Mine, ipqbdb, just looks up a bdb file to decide the verdict. Iptables also has a "recent" module, that can be specified in the <cond> in order to match a dynamic list of IPs. That allows to specify "-j REJECT" as the action. However, the dynamic list consists of plain files; they can be read and written from userspace programs by accessing /proc/net/ipt_recent/<name>, but it is not clear how synchronization with the kernel can be achieved. Any other ideas for blocking existing connections? >> I guess you mean more than a few minutes timeout... Hours? Days? > > A couple of hours, for starters. I'll try it. Thanks :-) > 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. Using smtpaccess is clever. However, its access is implemented generically and I'm not sure one can deploy, say, bdb's concurrent data store model. Does that imply using makesmtpaccess (and restarting couriertcpd) every time? "User unknown" can also be detected from the maildropfilter hook after a catchall in aliasdir. I use it for spamtraps. IMHO, it is more efficient than having additional regexes in the maillog parser. > 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. Yeah, in that case it would be better to use iptables. It is not a frequently seen behavior, though. What about using both smtpaccess an iptables, reserving the latter for higher error rates? ------------------------------------------------------------------------------ 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
