Re: [Exim] vulnerabilities

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Lorens Kockum
Dátum:  
Címzett: exim-users
CC: 
Tárgy: Re: [Exim] vulnerabilities
On exim-users marc.peiser@??? wrote:
>We had some guys test the security on our network and this is what they
>said:
>
>"SMTP daemons on your machine supports features (such as EHLO, RCPT, VRFY
>and EXPN) which my enable hackers to gain information which could be used
>to exploit other vulnerabilities."


Well.

VRFY and EXPN are commonly disabled for that reason, which
others have noted.

There are two possibilities: expanding an address to some
internal representation, and verifying the existence of an
address.

The argument for disabling the expansion is easy.

The argument for disabling verification is harder. If VRFY is
disabled, the next step is to start sending mail to the address,
and see if the address is rejected. there are three ways a mail
can fail because the recipient is invalid:

at the RCPT. Same effect as authorizing VRFY, except that
you've forced the "spy" to invent a MAIL FROM address.

After the DATA is terminated. Means that mail to invalid
addresses will travers your bandwidth once. I seem to
remember that some brain-dead MTAs don't really grok this.

After the mail is accepted. This means sending a bounce.
The mail will use up your bandwidth at least twice. If it's
spam, it will probably end up in the postmaster's mailbox,
leading to a lot of mail in the postmaster's mailbox, leading
to the postmaster not seeing more important errors.

If you don't want outsiders trawling around for valid addresses,
you have three options.

Rejecting after DATA will force the outsider to compose
a mail, which will be accepted for valid addresses, thus
bringing his activites to light relatively quickly.

Accept everything, and send a bounce. This is qmail's way
of doing it, although I don't think that was the reason.
This means that to know whether an address is valid or not,
the "spy" must provide a valid address of his own. Or at
least (I get paid for being paranoid, after all) provide an
address whose MX is a server on which he has access to the
mail logs ... Sending a bounce will probably expose much more
of your internal network architecture than a measly "user
unknown", but that's your problem.

Not sending bounces at all. That means you accept
everything, and assign a person to go over all mail that is
addressed to non-existent accounts. Possible if you're not
only paranoid, but have the money to put where your mouth is.
Actually it shouldn't be that hard a workload, unless you
have thousands of valid users.

I like none of them. If you're paranoid in a corporate
environment, assign non-trivial user ids to your users (not
composed of their names in any way), and then people who have
the ID can be assumed to already know that the ID exists.

Monitor the server for trawling, and shut off IPs who do lots of
it. Should be easy.

On to EHLO.

EHLO could be disabled, forcing exim to speak basic SMTP instead
of ESMTP. This would disable some useful features though. The
information let out without the "spy" sending a mail would be
things like your maximum spool size, I believe that's possible.

Disabling RCPT, on the other hand, means that the server will
not accept any mail, which is probably not what you want. If
you want to do that (such as an output-only server), it would be
better to filter access on the network level.

Of course, the day management decides that the list of
collaborators should be available on the net, you've wasted a
lot of time :-)

HTH, HAND.