Subject: [Asrg] host named "mail" that is not an MX

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Jun 2005 21:19:22 +0200

A customer of ours has a managed mailserver mail.example.com
that has been also MX for example.com. The customer restructured
and changed the MX for example.com to mail.someother.example.com.
mail.example.com still exists but doesn't accept any more mail and is
only used as an outgoing relay (customer uses submission, port 587).

Our watchdogs and stats show a very interesting phenomenon:
As soon as the MX was around in DNS and after the TTL of the old MX
records had expired from the caches mail.example.com started to get
attacked *heavily*. The domain had its attacks before and the usual
level of spam. The number of incoming messages per 5 minutes was around
50-100 but after the MX to mail.example.com expired from the caches
the number of incoming messages per 5 minutes raised to around 200.
They are all rejected with perm errors. I have also checked the logfiles
and I can find any evidence that it is some DNS cache problem. Most if
not all connections come from dialin space and hammer on the server.
There are even peaks of 800 incoming messages (more exactly RCPT TOs)
per second.

IMHO the spammers find it attractive to have found a potentially weak
point so it is their primary attack spot.

Anyone else seen this?

    \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 2 Jun 2005 12:42:35 -0700 (PDT)

> point so it is their primary attack spot.

First I heard of it, but it would sure explain some things as to why I
still receive on my mail server messages for old domains no longer there
that we're not even relaying for. I never kept any statistics though and 
don't think its significant (but maybe its just because those domains have 
always had less mail than active ones).

But since you started this experiment, can you change mail server 
behavior for period of time to not drop the messages but to store all
of them in some archive file and then take a look at what is coming?
If possible consider giving some of us access to that as well?
(strictly for research purposes, possibly it can be identified what
  spammer software or particular spammer is doing this and it can be
  useful to stopping them in the future)

P.S. This also gives an interesting anti-spam option to check, i.e. purposely
change MX to another name/ip and set old server to run daemon that accepts 
mail but really sends it all to /dev/null. Spammer who is using the trick 
with old mail system name thinks his emails are all still being accepted
and does not bother the new MX and the result is less spam :)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 3 Jun 2005 02:16:51 +0200

> always had less mail than active ones).

I've seen this on some of our central mailservers, too. IMHO this is
because of stale DNS entries in broken DNS caching software. But I have
always wondered why e.g. mail.space.net is spammed with mails for
@space.net even if it is not in the MX list. This is not because of stale
DNS entries (the MX has never been there).
IMHO spammers think that if a mail.example.com exists and accepts mails
(aka port 25 is connected) but is not the MX it may be a "shielded" weak
server and the official best MX runs antispam and antivirus software but the
hidden mailserver is an easy victim.

I have put a RRD image on the web that graphically shows what I am
talking about:
    http://www.space.net/~maex/nomx.png
The MX was changed around 9am on Tuesday and the domain configuration on
the mailserver was removed around the same time on Wednesday.
The reason for rejections upto that date were:
- HELO ip_of_destination
- HELO hostname_of_destination
- HELO domain RCPT TO @domain
- MAIL FROM @has_no_A_nor_MX
- virus infected message
the mailserver acted as part of a multi-hop gateway so there only
existed a catchall account.

> If possible consider giving some of us access to that as well?

I'll have to talk to the customer. Changing the behaviour involves more
traffic costs and a possible breach of trust and delivery for "legitimate"
mails still sent to the old address due to stale DNS records :/

But the "experiment" should be easy to reproduce. If there is a domain
that gets some spam and has mail.domain as MX and you have another
domain to work with, simply add a  mail.otherdomain with the same A
record as mail.domain, then change MX to mail.otherdomain and then
change the A record of mail.domain to some honeypot and see what
happens. I'll check some logfiles and see if I can setup a such a
honeypot with any of our/my other domains that receives enough spam to
make it at least slightly significant.

    \Maex

---

From: [email-masked] (Justin Mason)
Date: Thu, 02 Jun 2005 17:35:49 -0700

> hidden mailserver is an easy victim.

aha, that's it, you're right.  This is the Postini recommended
configuration, from what I've heard, so that probably explains it.
(handy to know, if you're running into Postini FP'ing on your mail ;)
e.g.:

: jm 358...; dig infoworld.com mx

; <<>> DiG 9.2.4 <<>> infoworld.com mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50691
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;infoworld.com.                 IN      MX

;; ANSWER SECTION:
infoworld.com.          86400   IN      MX      300 infoworld.com.s8b1.psmtp.com.
infoworld.com.          86400   IN      MX      400 infoworld.com.s8b2.psmtp.com.
infoworld.com.          86400   IN      MX      100 infoworld.com.s8a1.psmtp.com.
infoworld.com.          86400   IN      MX      200 infoworld.com.s8a2.psmtp.com.

;; AUTHORITY SECTION:
infoworld.com.          40465   IN      NS      ns1.infoworld.com.
infoworld.com.          40465   IN      NS      ns1.infoworldtestcenter.com.
infoworld.com.          40465   IN      NS      ns2.infoworld.com.
infoworld.com.          40465   IN      NS      ns3.infoworld.com.

;; ADDITIONAL SECTION:
ns1.infoworld.com.      20056   IN      A       64.95.97.72
ns1.infoworldtestcenter.com. 98495 IN   A       207.217.205.3
ns2.infoworld.com.      32907   IN      A       206.14.107.138
ns3.infoworld.com.      32907   IN      A       206.14.107.135

;; Query time: 31 msec
;; SERVER: 204.127.198.19#53(204.127.198.19)
;; WHEN: Thu Jun  2 17:34:44 2005
;; MSG SIZE  rcvd: 346

: exit=0 Thu Jun  2 17:34:44 PDT 2005; cd /home/jm/ftp/spamassassin/t
: jm 359...; telnet mail.infoworld.com 25
Trying 64.95.97.93...
Connected to mail1.infoworld.com.
Escape character is '^]'.
220 mail1.infoworld.com ESMTP Postfix (Debian/GNU)
^]
telnet> q
Connection closed.

- --j.

---

From: der Mouse <[email-masked]>
Date: Thu, 2 Jun 2005 23:56:45 -0400 (EDT)

["william(at)elan.net" <[email-masked]>]
> P.S. This also gives an interesting anti-spam option to check, i.e.
> purposely change MX to another name/ip and set old server to run
> daemon that accepts mail but really sends it all to /dev/null.

$DAYJOB has something similar in place right now: the no-longer-valid
MX accepts mail and, when addressed somewhere valid, sends it on - but
it logs a copy of *all* mail, even mail addressed to totally bogus
addresses.  (It wasn't done as an anti-spam measure, or it would be
devnulling all the mail....)

[Markus Stumpf <[email-masked]>]
> But I have always wondered why e.g. mail.space.net is spammed with
> mails for @space.net even if it is not in the MX list.  This is not
> because of stale DNS entries (the MX has never been there).

Okay, I've just set myself up to test this theory.  I found a domain I
run the mailer for, one that has never had a host named "mail".  I
created a "mail" name for one of the hosts and set up a simple
log-everything SMTP daemon on it.  We'll see what happens.

Hmm, I wonder what would happen if I border-router-blocked any host
sending mail to that host?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Fri, 3 Jun 2005 00:32:38 -0400 (EDT)

I wrote

> I found a domain I run the mailer for, one that has never had a host
> named "mail".  I created a "mail" name for one of the hosts and set
> up a simple log-everything SMTP daemon on it.  We'll see what
> happens.

Fascinating.  It's already gathered eight messages.  (Of course, I
don't know whether they arrived because it's named "mail" or because
the sender simply poked around looking for open SMTP ports - I think
I'll set up the same program on a third machine....)

All of them appear to be malware infection attempts; they bear
application/octet-stream portions and use MIME boundary strings of a
very stereotyped pattern:

	boundary="----=_NextPart_000_0004_31ED834D.12855CEA"
	boundary="----=_NextPart_000_0005_770651AE.3F9BA93E"
	boundary="----=_NextPart_000_0011_7A649EC3.62B66C6C"
	boundary="----=_NextPart_000_0008_08462B50.63CB8E4A"
	boundary="----=_NextPart_000_0009_265953B0.C3E25E5E"
	boundary="----=_NextPart_000_0007_238C62AF.E231B9BF"
	boundary="----=_NextPart_000_0012_D1E7736C.AE765B18"
	boundary="----=_NextPart_000_0011_4EEF7698.3C9C812C"

They also were sent to easily guessable local-parts @ the domain in
question (ray@, bob@, mary@, robert@, jane@, smith@, jim@, and david@)
and most of them were sent from admin-looking local-parts forged @ the
same domain (admin@, administrator@, register@, support@, and
webmaster@).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign