I've inherited a botnet target
in [Postfix]
|
From: brian on 26 May 2010 21:28 On 10-05-26 09:03 PM, Stan Hoeppner wrote: > brian put forth on 5/26/2010 1:53 PM: > >> FWIW, aside from aliases for the usual postmaster, abuse, and webmaster >> addresses, this domain has just 2 actual addresses to be maintained. So, >> might a whitelist approach be the way to go? Or, is this something i >> should leave to iptables/fail2ban? > > Care to share some of the spammer IP address info? Is this botnet traffic or > snowshoe? If snowshoe, I might be able to provide you with a complete list of > netblocks to blacklist, solving your problem with a simple edit or two. > Here you go: http://pastebin.com/DMgZsNCc I dunno about snowshoe. That was the first I'd seen the term. But it looks like it could be, as I understand it. I'm really not knowledgable enough to say. http://www.spamhaus.org/faq/answers.lasso?section=Glossary#233 b
From: brian on 26 May 2010 21:32 On 10-05-26 06:27 PM, LuKreme wrote: > On 26-May-2010, at 14:12, brian wrote: >> >> I'll give all that a try. Does this order seem alright? > > No, not really. > >> smtpd_recipient_restrictions = permit_mynetworks, >> reject_unlisted_recipient, reject_invalid_hostname, >> reject_non_fqdn_hostname, reject_non_fqdn_recipient, >> reject_non_fqdn_sender, reject_unauth_destination, >> reject_unknown_recipient_domain, reject_unauth_pipelining > > smtpd_recipient_restrictions = reject_non_fqdn_sender, > reject_non_fqdn_recipient, reject_unknown_sender_domain, > reject_invalid_hostname, permit_mynetworks, [ � rest of restrictions > ] reject_rbl_client zen.spamhaus.org permit > > Even if someone is in your network, there is no reason to allow > unknown sender domains, invalid hostnames and (usually) non-fqdn, > though in some circumstances these two rules might not be desired. > Thanks, all, for the help. I'm going to carefully go over the various suggestions with the Postfix docs open and hopefully arrive at a decent setup. After a few hours, it does seem that the bogus MX record has helped. I still have a few REJECT entries but I suppose that's due to the DNS propagation. I'll check again in the morning. And I'm really happy to learn about postscreen. Thanks, all. b
From: Stan Hoeppner on 26 May 2010 21:52 brian put forth on 5/26/2010 8:28 PM: > On 10-05-26 09:03 PM, Stan Hoeppner wrote: >> brian put forth on 5/26/2010 1:53 PM: >> >>> FWIW, aside from aliases for the usual postmaster, abuse, and webmaster >>> addresses, this domain has just 2 actual addresses to be maintained. So, >>> might a whitelist approach be the way to go? Or, is this something i >>> should leave to iptables/fail2ban? >> >> Care to share some of the spammer IP address info? Is this botnet >> traffic or >> snowshoe? If snowshoe, I might be able to provide you with a complete >> list of >> netblocks to blacklist, solving your problem with a simple edit or two. >> > > Here you go: > > http://pastebin.com/DMgZsNCc > > I dunno about snowshoe. That was the first I'd seen the term. But it > looks like it could be, as I understand it. I'm really not knowledgable > enough to say. I checked out a sampling of those IPs. They're a combination of bot and snowshoe, mostly bot. Typical spam stream, but apparently at a higher rate than what your VPS can effectively handle via standard Postfix smtpd restrictions. As others have stated, Postscreen should be a big help to you given that most of this is bot spam--exactly what Postscreen was designed to address. -- Stan
From: Nataraj on 26 May 2010 23:47 Stan Hoeppner wrote: > brian put forth on 5/26/2010 8:28 PM: > >> On 10-05-26 09:03 PM, Stan Hoeppner wrote: >> >>> brian put forth on 5/26/2010 1:53 PM: >>> >>> >>>> FWIW, aside from aliases for the usual postmaster, abuse, and webmaster >>>> addresses, this domain has just 2 actual addresses to be maintained. So, >>>> might a whitelist approach be the way to go? Or, is this something i >>>> should leave to iptables/fail2ban? >>>> >>> Care to share some of the spammer IP address info? Is this botnet >>> traffic or >>> snowshoe? If snowshoe, I might be able to provide you with a complete >>> list of >>> netblocks to blacklist, solving your problem with a simple edit or two. >>> >>> >> Here you go: >> >> http://pastebin.com/DMgZsNCc >> >> I dunno about snowshoe. That was the first I'd seen the term. But it >> looks like it could be, as I understand it. I'm really not knowledgable >> enough to say. >> > > I checked out a sampling of those IPs. They're a combination of bot and > snowshoe, mostly bot. Typical spam stream, but apparently at a higher rate > than what your VPS can effectively handle via standard Postfix smtpd > restrictions. As others have stated, Postscreen should be a big help to you > given that most of this is bot spam--exactly what Postscreen was designed to > address. > > How does rate limiting work in conjunction with postscreen? Can the various rate limits be applied to postscreen or would rate limiting no longer be necessary? I run in a vmware virtual machine which used to fall on its knees from both bot and snowshoe attacks and since I added the rate limits that I previously posted, I haven't had any major problems (been running with the rate limits for several years). I often see attacks like the one below where it will log these rate limit exceeded messages over the course of several minutes before the attackers go away. And yes, I do see attacks that come from multiple IP's. May 26 15:55:42 aspen postfix/smtpd[19600]: warning: Connection rate limit exceeded: 22 from 74-218-134-95.pool.ukrtel.net[95.134.218.74] for service smtp May 26 15:55:42 aspen postfix/smtpd[19600]: disconnect from 74-218-134-95.pool.ukrtel.net[95.134.218.74] May 26 15:55:42 aspen postfix/smtpd[17267]: connect from 74-218-134-95.pool.ukrtel.net[95.134.218.74] May 26 15:55:42 aspen postfix/smtpd[17267]: warning: Connection rate limit exceeded: 23 from 74-218-134-95.pool.ukrtel.net[95.134.218.74] for service smtp May 26 15:55:42 aspen postfix/smtpd[17267]: disconnect from 74-218-134-95.pool.ukrtel.net[95.134.218.74] May 26 15:56:17 aspen postfix/smtpd[21694]: connect from 114-26-181-192.dynamic.hinet.net[114.26.181.192] Nataraj
From: Stan Hoeppner on 27 May 2010 00:32
Nataraj put forth on 5/26/2010 10:06 PM: > How does rate limiting work in conjunction with postscreen? Can the > various rate limits be applied to postcreen or would rate limiting no > longer be necessary. I run in a vmware virtual machine which used to > fall on its knees from both bot and snowshoe attacks and since I added > the rate limits that I previously posted, I haven't had any major > problems (been running with the rate limits for several years). I often > see attacks like the one below where it will log these rate limit > exceeded messages over the course of several minutes before the > attackers go away. And yes, I do see attacks that come from multiple IP's. I've not used postscreen yet myself. I can only speak to what's been said here on the list. Others will certainly correct any misconceptions I may have. Postscreen is a bot (primarily) spam "shield" daemon that sits in front of smtpd. My understanding is that the postscreen process does its own rate limiting and tarpitting as well as some other tricks. With the old (pre-2.8) Postfix rate limiting method alone and no postscreen, each simultaneous inbound smtp connection requires a separate smtpd process to handle the connection. Thus, if you have 50 simultaneous inbound connections, and 48 are spam, you're needlessly running 48 extra smtpd processes, eating up a potentially large amount of memory. With postscreen on 2.8, it handles all inbound connections in one process instance, and only passes on connections to smtpd processes once it determines they're likely not spam connections. Postscreen is a single process, and is optimized to deal with bot spam connections quickly and efficiently. It consumes far less cpu and memory resources dealing with bot spam than the "old" smtpd only method of accepting connections. Wietse wrote it specifically for sites which have very high connection volumes due to bot spam. If you are such a site, I'd definitely recommend giving postscreen a test run. As the name implies, it screens out most of the junk connections that would normally bog down servers. http://www.postfix.org/postscreen.8.html -- Stan |