Lucky readers: It's time for another service submission integration
marathon!
Out of the huge range of diverse protocols that Nmap users submit,
SMTP has to be one of my favourites. Since it is one of the oldest
protocols still in widespread use today, the protocol has had a lot of time to
develop, evolve, and have heaps of implementations written.
Here are some of the more interesting notes I made while processing the
latest batch of SMTP submissions:
qmail, and indeed any SMTP that can run with D. J. Bernstein's
tcpserver
can be "protected" with a program
rblsmtpd.
This program essentially blocks SMTP connections if they are
listed as abusive for some kind of reason (read: spammers).
Matching this service is a bit of pro/con situation.
- CON: Unfortunately, due to the design of rblsmtpd, we can't recognize the SMTP server
running behind rblsmtpd. But we can alert the user as to
the situation and offer a solution: if you want the version of the SMTP
server being "protected", try scanning from a different IP.
- PRO: We know this SMTP server is being "protected" by rblsmtpd -
a fact we probably wouldn't be able to ascertain otherwise.
This service is a good example of the dynamic nature of service
detection. There are so many variables that can affect the results
of a version scan. Anything from obscure configuration
options, minor tweaks between versions, overloaded servers,
and in this case, even the IP we are scanning from.
In order to combat spam a number of ISPs have elected
to block their customers' outgoing SMTP connections, forcing
them to use either their SMTP server or other mail transfer
protocols like webmail. I think this is probably a good thing.
Not because I have a problem with spam per se (anyone who
wants their email filtered can easily get it) but because
this will reduce the incentives for people to write
dangerous, costly worms.
ISPs have a couple different options for blocking this.
The first and, in my experience, most common method of doing
this is to simply drop all outgoing packets with a destination port
of 25. Nmap will then display scans to port 25 as filtered.
This is a correct report - the scan really is being filtered.
Unfortunatley, it might not be obvious to users that it is
in fact their ISP that is doing the filtering!
Another approach that some ISPs take is to fake an SMTP
connection to the destination server and serve up an SMTP
error along with some kind of message like "Please use our SMTP
server for outgoing mail". If we correctly service detect these cases
we can report exactly what is going on to the user! I got a service
submission that shows how the popular european ISP Wanadoo implements
this in the UK and added a match line to this effect. This is nice
because we can make exactly clear to the user that this is
their ISP responding and we really haven't one iota about
what smtpd, if any, their specified target is running.
This brings up a general technique for firewall or proxy
detection that intelligent users can make use of: unusual
network uniformity. In this case, if a user scanned a few
dozen IPs and they are all reported to be running the exact
same mail server this should raise a flag in his or her brain:
Something fishy might be going on!
A suprisingly large amount of software writers embed
off-the-wall "easter eggs" in their programs. As the author
of a few network programs, I understand
the temptation: Network protocol research can someties
be a dry and mundane activity. Anyone taking the time to
look this closely at my software deserves to smile a little.
One common place easter eggs are added in SMTP is in the
response to the HELP command. Since, I estimate, %99.99
of all SMTP transactions are done program to program,
the HELP command is very rarely used - except by Nmap
which uses it as one of its probes. Here are a couple
examples I found this time around:
I always love adding some really neat piece of information
to the "extra info" field. Something that will really make
an Nmap user's day. I was lucky in that I got to add a match
line identifying the PGP
Universal SMTP proxy. In its
SMTP banner it repeats the SMTP banner of the SMTP server
it is proxying mails to. In other words, we can generally detect
the version and hostname of the internal SMTP server. The
very one that they set up the mail proxy to protect!
|
