[Dshield] New spammer tactic...
Jon R. Kibler
Jon.Kibler at aset.com
Thu Mar 13 21:29:39 GMT 2003
Yesterday I noticed that we were being repeatedly open proxy checked... at least a dozen times over the period of about 36 hours. Then I discovered that we were doing the checking on ourselves. Now I became really concerned.
Tracing back the problem, I actually found three problems:
1) I did not have self proxy checking blocked. (Shame on me.)
2) Because I had assumed that we would never check ourselves, our IPs were not being entered in the 'do not test again' database. (Well, once again, I learned what ass-u-me means.)
3) The reason that we were being checked in the first place was even more serious... forged reverse IP lookups to make foreign hosts appear to be members our our domain. (The real problem!)
Checking the sendmail log, I found several entries along the lines of:
> Mar 11 12:09:00 asethost sendmail: h2BH8wu7021805: proxy######.asetgate.aset.com [218.x.x.x] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Mar 12 10:48:55 asethost sendmail: h2CFmru7005305: proxy1######.asetgate.aset.com [218.x.x.x] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
It was immediately obvious what the attacker/hacker/spammer was trying to do. Such 'port scans', if associated with an open proxy server, are usually a good indication of someone is about to use that proxy server to spam us. Only this time, I suspect that they were going to try to force us to act as an open relay should we have configured our MTA's relay permissions based upon domain instead of IP address. For example, if we had an entry in our access database of:
then, since 'the connection originated from aset.com' (domain name from DNS lookup), the relay would have been successful. Thus, spammers could have used our system to send mail to anyone and make it appear that it originated from our system.
Our automated sendmail log analysis program picked up on the fact that we had been scanned, and scanned from IPs that were not know open proxies. Therefore, it determined that the IP and host in question should be open proxy tested. The reverse lookup of the IP address definitely gave the hostname in question, but the hostname returned would not resolve. Since we had an unresolved hostname, the program whacked off the left part and checked if the remainder would resolve, and it did... to our firewall. Thus, we tested the IP in question and the assumed host -- ourselves.
Thus, mail admins... check how you have RELAY control defined. Relay control should be based up IP address only, NOT domain or host name. If you relay based on domain or host name, you may be subject to spoofing as described above.
Hope this info helps save someone's behind before they get trapped by this new relay exploit.
Jon R. Kibler
Charleston, SC USA
More information about the list