Re: SMTP AUTH attack possible on E2K7?
- From: "Rich Matheisen [MVP]" <richnews@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 02 Dec 2008 21:45:13 -0500
On 02 Dec 2008 19:25:17 GMT, Timothy Teapot
<timothyteapot@xxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 01 Dec 2008 21:04:50 -0500, Rich Matheisen [MVP] ate alphabet
spaghetti and softly excreted....
No, that wasn't what I said at all. If someone's getting an email from aSo are you saying *you* can't configure Exchange to offer a pop service -
"POP server" then they aren't getting it from Exchange.
or 'connector'? I guess
The point is that you don't need POP or IMAP protocols. That seems to
be what's eluding you.
If they aren't getting it from ExchangeWhich they could be if it is feeding into a POP connector/server - so the
rest of this is irrelevant and snipped.
Snip away. There's no need for any kludgy POP-to-SMTP software. Use
SMTP.
If they're using, as was suggested, OWA or Outlook (using
RPC-over-HTTPS), they they can send emal to wherever they wish because
they aren't going to be using SMTP to do the sending of the message from
their client to the Exchange server. If that's done then there's no need
to allow /any/ SMTP relay at the gateway servers (which, in my opinion,
shouldn't be Exchange servers anyway).
Cool idea! So when you've taken the performance hit that any flavour of
the SSL/TLS ciphers produce and wipe out anything trying to use SSLv2 you
can rest in the safe knowledge that SMTP Auth is no longer an attack
surface.
The use of SSL or TLS doesn't eliminate that problem, it just makes it
less likely to be used -- unless you're using the cert to authenticate
the sender and not just to encrypt the connection.
So it's back to the good 'ole fashioned bots running on clients
and the normal long list of vulnerabilities. But hey! It's a cool idea,
with enough clients that performance hit should be so bad nobody would
want to attack the Exchange server or even go near the network - so
you've kind of half fixed it by accident! Well done you!
There aren't that many 'bots that use TLS. If AUTH isn't accepted
except when using TLS then the number of attackers is reduced pretty
dramatically.
As for making _any_ SMTP MTA "safe" from someone using AUTH I'm still
waiting for your elaboration on the subject.
Firstly, I don't recall that I said that it was possible - perhaps you
could remind me just where *you* read me saying that it was?.
Sure. How about this? The emphasis on "you" sure makes it sound like
you have a way to make it possible:
"So you are saying *you* can't make Exchange safe to allow
SMTP auth and you need to rely on your ISP to do this for you."
Or have
*you* not read the post properly?
I think I'm reading it correctly.
I'm mocking you for assuming the whole
SMTP Auth gig is somebody else's problem.
Someone elses? No. The topic started off as an Exchange question. You
seem to have broadened it. I contend that SMTP relay isn't necessary
for Exchange. You think that without SMTP relay the usefulness of
Exchange is diminished.
However, you have posed a
question so I'll share what I do. Personally I make sure that anything
that can get as far as getting to send using SMTP Auth has passed an IP
based ACL first.
So you limit, by IP address/network, who can use your SMTP server to
relay. That's okay, but if you allow SMTP relay how to you deal with
someone who travels (or uses a dynamically assigned IP address) and
uses POP/IMAP? Or have you reduced the usefulness of your email system
by restricting access to it?
If something running on an IP can abuse such an MTA it's
not going to care which one it is, be it Postfix using SMTP Auth or a bot
on a windows client able to patiently wait and manipulate outlook or the
core client using RPC-over-HTTPS. The HTTPS only assures you the client
and server are who they say they are
I don't think HTTPS care one little bit who the client might be,
unless you use certificates to authenticate. It's still plain text in
the data being exchanged.
- it does not mean that the client
or server cannot still be compromised and make use of this 'secure'
communication.
There's no SMTP AUTH, which is the subject of this thread.
No matter how *I* send mail, I can chose to send good mail
or spam mail. I can download a bot by accident and run it to bomb out
loads of .yahoo.com.tw spam and it will happily use any method it can to
get out to the wild. I'm sure you covered all this on your course though
Rich.
My course? Oh, right! You're mocking me. How droll.
Why you have an answer I'll be happy to read it. --- Rich MatheisenI think you mean 'When you have an answer' and I draw your attention to
the opinions I have expressed above. Please read it carefully, if you
need any further help or training please let me know.
I guess the "training" I need is how to avoid trolls.
---
Rich Matheisen
MCSE+I, Exchange MVP
.
- References:
- Re: SMTP AUTH attack possible on E2K7?
- From: Timothy Teapot
- Re: SMTP AUTH attack possible on E2K7?
- From: Rich Matheisen [MVP]
- Re: SMTP AUTH attack possible on E2K7?
- From: Timothy Teapot
- Re: SMTP AUTH attack possible on E2K7?
- Prev by Date: Re: Maintenance Interval
- Next by Date: Re: allow authenticated relay?
- Previous by thread: Re: SMTP AUTH attack possible on E2K7?
- Next by thread: Virtual Machine-Exchange 2007 Server
- Index(es):
Relevant Pages
|
