"Patrick D." <PatrickD@discussions.microsoft.com> wrote in message
news:EB1544D7-57DA-404D-B49E-983D24332A5B@microsoft.com...
> Hi,
>
> I would like to know, if it is good practise to change the usual ports (25
> /
> 110) of a mail-server to different ones, only for hiding (more or less)
> the
> existence of the mail-server:
> In this case during an external attack, checking the two common ports
> wouldn't give the expected result of mail-servers.
>
> Would this scenario show some new and unexpected problems on such a
> mail-server?
>
> Thanks for an answer.
>
> regards
> Patrick

> Would this scenario show some new and unexpected problems on such a
> mail-server?

"Sanford Whiteman" wrote:

> > Would this scenario show some new and unexpected problems on such a
> > mail-server?
>
> As Jeff mentions, you cannot have a public MX that runs on any port
> other than TCP 25. So publishing _all_ of your SMTP resources in this
> way is categorically out of the question.
>
> You can change the port of an SMTP server that is only used for
> authenticated submission (indeed, you should). With your submission
> server or your POP3 server, provided you closely control your userbase
> (you are a corporation, not an ISP), you can ensure that all of your
> client machines connect to an alternate port. All common MUAs support
> this.
>
> But mail servers, with a simple port change, still have distinct
> plain-text signatures (required by the RFCs). Even if you can get all
> your clients to get in line without a big support headache, it's an
> extremely light "security" measure in the long run.
>
> So you have to ask yourself what you're protecting against; by far,
> the biggest threat to modern mailserver security is not
> vulnerabilities within command processing (buffer overflows and so
> on), but _easily-guessed passwords_ that lead immediately to service
> hijacking. There are relatively few unique MTA vendors and a limited
> SMTP command set to implement and harden, so it is unlikely that
> anyone will see your mailserver primarily as a target to be fully
> owned (though DoSed, sure)... but spammers love to anonymize their
> spew by AUTHing and sending through your otherwise legit-looking
> server.
>
> Start by creating a password complexity requirement, if you haven't
> already -- and then make sure it is retroactive. If you can't do both
> parts of this, you will remain a sitting duck and need to be fully
> reactive.
>
> Continue by requiring non-plain-text authentication for all services.
> Encrypted mechanisms for SMTP AUTH are extremely well-established, but
> you may not be using them; to be fair, these uplevel mechanisms are
> usually automatically selected when available on both client and
> server, which is good. Chances are much lower that you are using
> encrypted POP3 APOP if you haven't made it a mandate. Use it. Anyone
> sniffing a plain-text connection will have a happy time with these
> easy-to-find usernames and passwords.
>
> Continue by getting an IDS/IPS. Some mail suites, unfortunately, have
> slim to no built-in intrusion-prevention measures, and only a few have
> hijack-detection out of the box. Matters are made worse by the fact
> that SMTP, POP3, and IMAP4 credentials are commonly shared across the
> services of any mail suite or integrated system, so an attack can
> theoretically range across all the services with the same eventual
> payoff. There is no simple way to reduce the number of individual
> accounts that can be tried, since by definition a mailserver exposes
> all mailbox-enabled user accounts. You must ensure that any
> administrative-level accounts are not accessible at all over these
> user-level services, so that any harvested credentials aren't _more_
> useful to someone whose goals are beyond spamming. Similarly, wherever
> your users and/or workload will accept it... my opinion here, surely
> not everyone's... I suggest that you _abandon_ single-sign-on across
> VPN and any other exposed user-level services, since the ability to
> use a set of credentials from one service on all others increases the
> potential consequences of password compromise (at the very least, it
> increases your immediate panic). OTOH, I understand that hindering SSO
> can lead to users demanding weaker passwords. [This is all kind of
> off-topic, so I'll get back to mail now.]
>
> Back on your original obscurity front, there indeed some more
> substantive things you can do, even with SMTP. Separate your SMTP
> servers into [1] a public MX, which _does not accept_ authentication
> of any kind and will not relay to unknown remote domains under any
> circumstances, and [2] a private submission server, which requires not
> simply encrypted authentication but a fully encrypted tunnel (SMTPS)
> or inline encryption (STARTTLS), or an initial IPSec or other VPN
> connection. All of these measures, with their key exchange
> requirements and so on, are much less likely to be compromised by
> simple harvesters that expect basic SMTP convos. Not that that a
> concerted and sharp human hacker can't attack these (although, for
> example, using a private CA and requiring client certs definitely
> takes SMTP out of the hacker's initial picture), but automated and/or
> inexperienced hackers will be slowed. Do the same for POP3. Note that
> both of these measures require that you have corporate-type control
> over your userbase (or that they are very technical... though if they
> were that hardcore, they likely wouldn't be using your service without
> these prerequisites).
>
> You should check out my recent posts involving TLS and so on.
>
> --Sandy
>
>
>
> ------------------------------------
> Sanford Whiteman, Chief Technologist
> Broadleaf Systems, a division of
> Cypress Integrated Systems, Inc.
> ------------------------------------