Weblog entry #7 for muondude
See all weblog entries made by muondude.
... 2007-12-24 10:06:01 verify failed for SMTP recipient aaborkar@filemakerauction.com from <> H=web6.ci06.de (ci06.de) [193.143.122.10] 2007-12-24 10:06:02 verify failed for SMTP recipient harald@filemakerauction.com from <> H=(scmgateway1.reviewjournal.com) [12.9.217.24] 2007-12-24 10:06:04 Connection from 62.190.15.43 refused: too many connections 2007-12-24 10:06:04 Connection from 62.190.15.43 refused: too many connections 2007-12-24 10:06:05 verify failed for SMTP recipient eifmanl@filemakerauction.com from <> H=(mail2.e-servicesgroup.com) [65.183.1.213] 2007-12-24 10:06:05 Connection from 67.90.241.200 refused: too many connections 2007-12-24 10:06:05 Connection from 70.84.16.194 refused: too many connections ...And netstat gives:
... Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1 192.168.2.2:3050 148.245.120.60:113 SYN_SENT tcp 0 0 192.168.2.2:25 148.245.120.60:31146 ESTABLISHED tcp 0 1 192.168.2.2:3049 148.245.120.60:113 SYN_SENT tcp 0 0 192.168.2.2:25 148.245.120.60:31144 ESTABLISHED tcp 0 1 192.168.2.2:3047 209.82.14.94:113 SYN_SENT tcp 0 0 192.168.2.2:25 209.82.14.94:30136 ESTABLISHED tcp 0 0 192.168.2.2:25 213.201.175.98:1574 TIME_WAIT tcp 0 1 192.168.2.2:3045 217.154.210.139:113 SYN_SENT tcp 0 0 192.168.2.2:25 217.154.210.139:43850 ESTABLISHED tcp 0 1 192.168.2.2:3044 217.154.210.139:113 SYN_SENT tcp 0 0 192.168.2.2:25 217.154.210.139:43231 ESTABLISHED tcp 0 1 192.168.2.2:3043 217.154.210.139:113 SYN_SENT tcp 0 0 192.168.2.2:25 217.154.210.139:43160 ESTABLISHED tcp 0 1 192.168.2.2:3042 80.219.58.34:113 SYN_SENT tcp 0 0 192.168.2.2:25 80.219.58.34:1605 ESTABLISHED tcp 0 1 192.168.2.2:3039 62.80.22.166:113 SYN_SENT tcp 0 0 192.168.2.2:25 62.80.22.166:2006 ESTABLISHED ... snip... 48 total connections on tcp & smtp. Ugh!I've tried googling for help, but nothing I could 'grok' or figure out. Also, it seems that exim4 might have some features to handle this, but I'm unsure about this and frankly afraid to break the server with the update doing on my own (yes I know it is hosed so how much more could I screw it up ;-) ). Any suggestions would be greatly appreciated. If there is a kind person willing to help I can contact you on a side channel (phone or IM). Thanks.
Comments on this Entry
What I do to combat backscatter when it's getting out of hand like that is to parse my syslog file with a quick 'n' dirty perl script looking for "no such user" responses. When I find two or more from the same remote host within one hour, I just drop all packets from it for the next several days. My q&d perl script is tailored to my own environment (Courier MTA, shorewall firewall) but it shouldn't be too hard to do the same thing in any reasonably flexible environment.
Good luck with it!
[ Parent | Reply to this comment ]
[ Send Message | View muondude's Scratchpad | View Weblogs ]
2007-12-25 08:22:24 verify failed for SMTP recipient eye.site@filemakerauction.com from <> H=65-42-65-137.ded.ameritech.net (smtp1.primaxrecoveries.com) [65.42.65.137] 2007-12-25 08:22:28 verify failed for SMTP recipient angela.mckay@filemakerauction.com from <> H=65.105.32.245.ptr.us.xo.net (server-csc.scrap.local) [65.105.32.245]
I have several domains (filemakerauction.com being one of them) parked on the same IP.
Is there a way for me drop or reject all attempts for just this domain (filemakerauction.com)? I was looking at my firewall (D-Link DFL-700) to see if I can do it there as the mail server is in the dmz. But I'm stumped. -- Sam
[ Parent | Reply to this comment ]
Notice that most of the connecting IP's reverse to host names that sound a lot like they belong to mail servers, names like 'mail.something', 'mx.something', or 'smtp.something'. That's the hallmark of backscatter. Some spammer has chosen your domain as the lucky one to be in his spoofed From: headers, and brain-dead MX's (such as qmail) are initially accepting all mail to any known domain, only to deliver bounce messages to the uninvolved innocents later.
If you're not intentionally accepting mail in that domain, you might try updating the DNS MX entry so it points at a loopback address (e.g. 127.0.0.1). That'll stop the brain-dead remote hosts from finding you. I assume you can configure exim so it won't accept mail for that domain, also. Then in a week or so (after the spam run has ended and the brain-dead MX's have given up trying to backscatter at you) you just return the MX record and exim configuration to their original states and that's that.
[ Parent | Reply to this comment ]
[ Send Message | View muondude's Scratchpad | View Weblogs ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I'd recommend that in addition to getting the server behind the firewall, something like the shorewall firewall (or some other easy iptables front-end) be installed to make it easier to fend off unwelcome traffic. I kinda sorta alluded to this in an earlier response. I'd be, well, not lost but very busy without it.
[ Parent | Reply to this comment ]
Thanks for the feedback.
Unless I completely misunderstand how the DFL-700 works, the "dmz" for that firewall is "behind" the firewall. The DFL-700 let's you configure traffic between the WAN and DMZ, as well as between the WAN and LAN (I think of this as LAN-1 and LAN-2). So I have my mail server isolated from my LAN, etc. So in this instance the server is behind the firewall - but very likely I could add some rules to limit these attacks. The DFL documentation isn't going to win any awards. Given that the backscatter is coming from just about any random IP (and my domains are parked on the same IP) I'm open to suggestions about possible firewall rules that might drop these bounces.
The DFL interface let's me configure the rules for WAN-LAN, WAN-DMZ, LAN-DMZ, etc. separately, so I have a fair amount of control of what makes it to the DMZ from the WAN.
I have been trying to understand this attack and my options regarding: (1) configuration changes to exim3; (2) upgrading to exim4; (3) changes to the firewall rules; (4) and other options - liking just drinking lots of beer!.
I'm trying to understand my option and Arthur's comments about backscatter were helpful as I wasn't aware of that interpretation from the data.
From my recent reading I'm thinking it might be time to upgrade my MTA (either exim4 or Postfix).
[ Parent | Reply to this comment ]
[ Send Message | View muondude's Scratchpad | View Weblogs ]
that last comment was from me. I forgot to login!
-- Sam
[ Parent | Reply to this comment ]