mx | foxpa.ws

Having trouble sending e-mail to @hotmail or @live addresses? Trouble like:

Diagnostic-Code: SMTP; 550 SC-001 (BAY0-MC4-F36) Unfortunately, messages from xxx.xxx.xxx.xxx weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.

The irony of course is that the URL provided gives you less information than the error message:

550 SC-001 Mail rejected by Hotmail for policy reasons. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation. If you are not an email/network admin please contact your Email/Internet Service Provider for help.

Spam-like characteristics can mean anything but at least twice I’ve had this problem the issue was being on Hotmail’s internal IP blacklist. Like it said the first time.

First, you should check to see if you’re on any of the public RBLs: http://whatismyipaddress.com/blacklist-check. If you are, you have real problems and need to sort that out before bothering Microsoft. Chances are, however, you aren’t – especially if we’re dealing with a simple web server and not a dedicated mail server.

If you’re sure you’re really not spamming Hotmail fill out the Deliverability Issue Submission form at https://support.msn.com/eform.aspx?productKey=edfsmsbl2&ct=eformts. In a few hours the automated system will review your case and if successful you will receive an e-mail like this:

Dear Soey McSoandso

We have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.

Mitigated
xxx.xxx.xxx.xxx
The reported deliverability problem has been mitigated by the automated system. Mitigation may take 24 – 48 hours to replicate completely throughout our system. Please note that mitigating this issue does not guarantee that your email will be delivered to a user’s inbox.

Regardless of the deliverability status, Hotmail recommends that all senders join two free programs that provide visibility into the Hotmail traffic on your sending IP(s), the sending IP reputation with Hotmail and the Hotmail user complaint rates.

Junk Email Reporting program (JMRP) When a Hotmail user marks an email as “junk”, senders enrolled in this program get a copy of the mail forwarded to an address of their choice. It allows you to see which mails are being marked as junk and identify mail traffic you did not intend to send. To join, please visit http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts.

Smart Network Data Services program (SNDS) This program allows you to monitor the ‘health’ and reputation of your registered IPs by providing data about traffic such as mail volume and complaint rates seen originating from your IPs. To register, please visit http://postmaster.msn.com/snds/.

There is no silver bullet to maintaining or improving good IP reputation, but these programs help you proactively manage your email eco-system to help better ensure deliverability to Hotmail users.

Thank you,

Hotmail Deliverability Support Service

If not successful, being that the system is automated you may have to go hunting for a new subnet.

Both of the tools linked above are excellent sources of information if you administrate an ISP mail server or mail servers for third parties and JMRP is especially useful for tuning mass mail marketing campaigns.

To see how I actually solved this particular problem please see Thwarting the isc.org DDoS

It has long been held as best practice that one should use separate servers for authoritative (server) and recursive (client) domain name services. In some cases, this is not practical – for example I inherited one particular network at an ISP I do consulting for that has had its combined authoritative and recursive DNS servers on the same IP addresses for about a decade. Splitting up the roles of the servers would require either hundreds of clients with statically configured DNS to change their settings (imagine the load on tech support) or dozens of domain-holders to update their registrar glue, assuming their registrar even provides it (another load on tech support).

On this network I had – contrary to the gospel I know only too well – allowed recursive lookups from any source on the Internet for several years. I knew it was ideologically incorrect but have found it immeasurably handy to have a set of memorized nameserver IPs that you know will just work any time, anywhere in the world when you are tech supporting or trying to resolve an issue. No one seemed to notice for the years before and after I took on this client, and I couldn’t see the harm if a few folks started using them. It didn’t – and still doesn’t – make sense to me that a spammer would outsource their DNS operations to a vastly remote location (see updates at bottom, they are spammers but they’re actually trying to DDoS), at the cost of not only speed and latency but expensive bandwidth at all.

But today they did.

At around 12:40 I was notified of the situation and began my investigation. Handy-dandy iftop told me it was coming from one IP and they were making DNS requests – good news! The server wasn’t hacked – it was just being DoSed as a side-effect of over-querying. In fact, named was performing exceptionally well for a ~5-mbit/s load on a tiny virtual machine used to 150kbit/s, it was only the upstream bandwidth throttling that was keeping the flow in check.

I ran a full port scan on the attacker and much to my surprise it didn’t respond to pings and all ports were filtered. I was growing suspicious that this wasn’t a typical zombie. I blocked the attacker at the gateway and for a moment the network settled down. Then out of nowhere another attacker from a completely different IP showed up – I gave them a full scan and they too were filtered and unresponsive to ICMP echo requests. The new attacker came from 173.1.52.117.reverse.gogrid.com but forward lookups didn’t work. I didn’t have to go to their website to realize this was a VPS provider, clearly I was dealing with someone who owned their own kit – an organized spammer. My suspicions confirmed, I knew I would have to give up my little “public” DNS service and implement an Access Control List for recursive lookups.

By the time the third and most aggressive (getting pissed off about the IPs I was blocking?) wave of queries rolled around I had collected a list of all the networks and public addresses which require recursive lookups. Regardless of whether you have your authoritative services separated from your recursive unless your recursive server is on a private network it is best practice (and even then I would recommend it) to implement an ACL.

Open your named.conf and before the global options section, define an ACL as shown below. Notice that address ranges can be specified with CIDR notation:

acl "trusted" {
 localhost;
 192.168.0.0/16;
 172.16.0.0/16;
 10.0.0.0/8;
 192.168.0.1;
 222.222.222.222;
};

Now we can call the trusted ACL with the allow-recursive directive in the global options section. You can define any number of ACLs with different names, we’re just going with trusted as an example. Make sure the ACL includes every network and IP address that should have permission to perform recursive lookups – ensure your private subnets, public networks and any stray uplinks or remote locations are included. Those hosts not in the ACL and not performing lookups on domains for which your server is authoritative or already has cached will fail.

options {
 version "fuck off, buddy";
 recursion yes;
 allow-recursion { trusted; };
};

Run rndc reload or restart BIND for the changes to take effect.

As you can tell from the bumps in my graph after the giant spike this guy (or these guys) is taking his time trying to figure out what I did, but the good news is he’s using less bandwidth and a whole whack of spam ain’t goin nowhere. Eventually they will realize that this server isn’t doing them any good and they’ll move on to greener pastures.

Finally, I got one of the attackers post-ACL to submit to a scan:

bzp ~ # nmap -P0 87.237.229.150

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-20 18:15 EDT
Interesting ports on 87.237.229.150:
Not shown: 990 closed ports
PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
23/tcp   open     telnet
25/tcp   filtered smtp
80/tcp   open     http
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
646/tcp  filtered ldp
2000/tcp open     callbook
8291/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 390.66 seconds

Well, that looks like any number of shared hosting servers, I wonder what’s on port 80:

Sweet, some sort of crazy European embedded linux routing solution. And their webconfig is wide open to cracking.

MikroTik RouterOS is the operating system of MikroTik RouterBOARD hardware.

It can also be installed on a PC and will turn it into a router with all the necessary features – routing, firewall, bandwidth management, wireless access point, backhaul link, hotspot gateway, VPN server and more.

RouterOS is a stand-alone operating system based on the Linux v2.6 kernel, and our goal here at MikroTik is to provide all these features with a quick and simple installation and an easy to use interface.

You can try RouterOS today, go to www.mikrotik.com and download the installation CD image. The free trial provides all of the features with no limitations.

If I had to guess I’d say this guy went the server route, or maybe he virtualizes his gateways like me. This distro has some neat stuff but it doesn’t have the balls and teeth of server-targeted ClearOS – and did they say free trial? I’ll have Nunuvut. This kind of explains why my port scans are being cut off though, a sufficiently advanced firewall like this probably has some sort of Intrusion Prevention mechanism and since I caught them with their web config (and telnet config for that matter) exposed and flapping in the breeze I’d say this is one of the installations my friend the spammer has not completed configuring, hence this one successful scan.

For the interest of Googlers trying to figure out why so and so is blasting the shit out of their name server(s) one IP at a time, here’s a list of IPs and PTRs (where available) I’ve caught so far:

82.225.94.140   sju13-2-82-225-94-140.fbx.proxad.net
173.1.52.117    173.1.52.117.reverse.gogrid.com
74.208.164.54   something from schlund.de
87.237.229.150  RIPE says the block belongs somewhere in Dubai 194.8.74.227    hosted by dragonara.net, listed as comment spammer by project honeypot
75.125.150.106  hosted by ev1servers.net
173.1.52.117   173.1.52.117.reverse.gogrid.com
98.126.124.203 MOLECHART.com
88.191.89.71
74.208.149.208  hosted by schlund.de
78.129.202.96
78.129.202.142
74.208.166.146  hosted by schlund.de
74.198.4.87     Rogers (Wave ???)
174.36.42.115   Italian-show-passion-quality-hostserver.com (lol)
98.126.54.227   98.126.54.227.STATIC.CUSTOMER.KRYPT.COM
74.198.0.53     Rogers (Wave ???)
88.191.109.130
85.25.150.72
173.192.224.100 173.192.224.100-static.reverse.softlayer.com
209.11.242.123  server12.elnastalk.com

Update I found 87.237.229.150 spamming on a strange Iraqi forum that reveals posters’ IP addresses to the general public. Strange indeed, but now I know I’m dealing with web form spammers, not e-mail spammers. Here’s a sample of the spam found at http://www.iraqal7ob.com/vb/t710.html

The image at the top was hotlinked from a free hosting service, the exact URL was http://hosting.bearzddl.com/uploads/9b0b60d466.jpg. Bearzddl is itself a shady file site and at the time of writing http://hosting.bearzddl.com/uploads/ provides a directory listing of all sorts of spammy looking images that have been uploaded through their free file hosting feature:

Update This morning we were attacked once again, I took the following sample capture:

 11.695249 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.695449 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ams.sns-pb.isc.org NS ns.isc.afilias-nst.info NS ord.sns-pb.isc.org NS sfba.sns-pb.isc.org
 11.705516 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.705891 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ns.isc.afilias-nst.info NS ams.sns-pb.isc.org NS sfba.sns-pb.isc.org NS ord.sns-pb.isc.org
 11.723779 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.723787 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.723983 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.723989 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.724154 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS sfba.sns-pb.isc.org NS ams.sns-pb.isc.org NS ns.isc.afilias-nst.info NS ord.sns-pb.isc.org
 11.724333 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ord.sns-pb.isc.org NS sfba.sns-pb.isc.org NS ns.isc.afilias-nst.info NS ams.sns-pb.isc.org
 11.724495 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ams.sns-pb.isc.org NS ns.isc.afilias-nst.info NS sfba.sns-pb.isc.org NS ord.sns-pb.isc.org
 11.724648 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ams.sns-pb.isc.org NS ord.sns-pb.isc.org NS sfba.sns-pb.isc.org NS ns.isc.afilias-nst.info
 11.725244 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.725256 194.8.74.227 -> xxx.xxx.xxx.xxx DNS Standard query ANY isc.org
 11.725488 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS sfba.sns-pb.isc.org NS ord.sns-pb.isc.org NS ns.isc.afilias-nst.info NS ams.sns-pb.isc.org
 11.725645 xxx.xxx.xxx.xxx -> 194.8.74.227 DNS Standard query response RRSIG RRSIG DS DS NS ns.isc.afilias-nst.info NS ord.sns-pb.isc.org NS ams.sns-pb.isc.org NS sfba.sns-pb.isc.org