[EMAIL PROTECTED] wrote:
>
> Well, Thank you all for the brainstorm! it was really elucidating.
> i'd like to share a synthesis and make some questions:
Wow. I was thinking about trying to summarizing this but it just
gave me a headache. Nice work :-)
On to your questions -- I think I can be of some help?
> a)is item 10 "why:" part right ?
> 10)Owa and exchange in internal net, separated NT domains, one-way
> trust to exchange domain [Brian Steele]
> why: owa can get to exchange, but exchange cant get anywhere ?
Yes, it's conceptually right. If the exchange box gets compromised,
you shouldn't be able to use the data on it to attack the rest
of the domain (at least not through NetBIOS/SMB, but this does
not address other weak protocols that may be accessible on
the internal network).
However, users connecting to the system reveal their identities.
If the attacker snarfs their credentials as they log on, they
may be used to attack the rest of the domain. So, it isn't
"bulletproof", but it's an added layer of security. With a host
IDS on the exchange and owa servers, you could hopefully catch
odd activity before an attacker gets setup to sniff or steal
incoming connections.
> b)is item 11 right ? if so, this is just a password security issue ?
> 11)Any vuln. in owa-ssl can only be executed by authd users [A.Hague]
Mainly yes. However, one needs to consider the problems with
SSL invalid certificate recognition that we've seen. It's probably
possible to setup a mirror of the OWA server somewhere else and
wait for people to log on, and then steal their passwords.
This makes it a technical issue aswell as a policy issue.
> c)how can protocol level fitering permit only valid http requests ?
If the filter gets to look at the data after it comes out of
the SSL tunnel. This means that you'd have to use a reverse proxy
in front of the exchange server to "translate" from encrypted
to plaintext.
However, as I said, I don't think that the biggest dangers in
this scenario lie in the HTTP layer. I might be wrong though.
I'm not saying that there aren't dangers in the HTTP layer.
I just believe that the dangers in the OWA scripts are higher?
This ofcourse is subject to the question: How much do the
black hats know about OWA? If they don't know anything about
OWA, they're likely to try to go for other exploits in IIS
first.
> d)is item 16 true yet ?
> 16)Owa in dmz = pain. open n ports and n-1 clients will be able to
> connect (nt4sp3) [K.Evangelinos]
Yes. As far as I know, it will stay true. Each connection
needs its own port at the RPC layer. ?
---8<---
To sum things up, I guess one could implement pretty much every
solution suggested. I don't really see any contradicitions.
BUT, then there's the golden old "Keep It Simple, Stupid" rule.
How much security do you need? If you attempt to overdesign
your security solution without the knowledge, time and funding
required, you're likely to create more security holes than
you plug.
Since you haven't stated what kind of security you need, it's
hard to give you a good recommendation.
Are we talking "mom and pop" shop style security here, or
are we talking defense / governament requirements?
In any case, there are a few points that apply to pretty much
everyone:
1) Require SSL. It's easy to setup, it's low cost, and provides
a good level of security.
2) Apply NT ACL restrictions on your OWA setup -- no anonymous
reads; only authorized domain users. This may or may not
mean that you should use the built-in "Domain Users" group.
Maybe you have another group that includes "known users"
that is better for this purpose?
3) HARDEN your OWA server!!! There's quite a lot of info on
how to harden IIS servers -- some is from Microsoft, some
is from other sources. A search in the list archives at
http://lists.gnac.net/firewalls ought to give you some
helpful pointers. (You might want to look for material
written buy Stefan Norberg - he's done some nice writeups
on how to harden NT servers in general.)
Above all: remember to delete ANY functionality in your
OWA server that you do not require. Especially everything
related to RDS (ODBC via HTTP), Index Server, samples,
etc etc. Delete virtual mappings in the MMC aswell as the
"physical" files.
With these three points, you have a level of security that
is "good enough" for most small and medium sized companies.
If you're more exposed, or have higher security requirements,
start looking at all the points you summarized :-)
Hope all of this helps you somewhat.
Regards,
Mikael Olsson
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
Phone: +46 (0)660 29 92 00 Direct: +46 (0)660 29 92 05
Mobile: +46 (0)70 66 77 636 Fax: +46 (0)660 122 50
WWW: http://www.enternet.se/ E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
