Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 418
  • Last Modified:

My Security Scenario running Exchange 2k on Domain Controller (sorry but that's a given here)..please critic. Thanks.

#1 W2k w/ svc pack 3 on my domain controller.  IIS 6.0 no FTP, certs required for all access with basic password.  Symantec Anitvirus w/ latest updates and outlook protection.  W2k latest updates (all but svc pack 4).  

#2 Exchange 2000 svc pack 3 OWA and Public Folders SSL access only.

#3 Symantec Gateway 320 Firewall only allowing port 80, 443, pop3, SMTP to the server BUT IIS only accepting 443 (certs).

#4  I ran MS base-line security analyzer 1.2 and trying to weed out any bad stuff there without blowing up my server.

#5 Regular users are allowed logon locally as it is required for OWA but that is locked down tight and they can't do anything on the console.  But feel free to comment as I could be missing something.

Can I just allow 443 without allowing port 80?  Also, please add suggestions or comments.  Any holes?  I may have to split the points, I understand.  Thanks!!
 
0
Sp0cky
Asked:
Sp0cky
  • 11
  • 4
  • 4
  • +2
3 Solutions
 
dis1931Commented:
No reason why you need port 80 open if you ar using SSL.
0
 
Yan_westCommented:
No need to use open port 80 on your firewall. 443 is enough,

Also, people do not need to be allowed to log on locally to use OWA from their station. Giving access to normal users directly to the server is not a good idea, even if you think you are controlling everything.
0
 
Yan_westCommented:
I would also Install the IIS Lockdown tool using the OWA template, and after this, Install URLScan, and tweak it so it works with OWA
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as high-speed processing of the cloud.

 
Sp0ckyAuthor Commented:
Thanks all!  So far, I added svc pack 4.  I disbled port 80 and you were right SSL still works.  IIS lockdown I have heard of folks having blow up their exchange servers,..I am leary of it..anyone else install this?
0
 
Sp0ckyAuthor Commented:
BTW with port 80 disabled, what's the need for IIS lockdown anyway?
0
 
Yan_westCommented:
It secure your IIS server, since OWA is running on it, it is more secure after..there is alot of things that are changed by it (IIS setings, registry entry, etc..) that I cant describe you everything, but be very carefull before aplying it, and read as much documentation as possible.

URLScan would be a good idea too. You can remove it easily, and it's easy to configure. Read about 1st too.. especialy running it in conjontion with OWA
0
 
Yan_westCommented:
Check this page about IIS lockdown tool:

http://www.brienposey.com/kb/Securing_OWA_With_IIS_Lockdown.asp
0
 
ahoffmannCommented:
what are you afraid for when there is no port 80 but port 443?
Are you aware that SSL only secures transport, but not your server, nor the client from other attacks?
0
 
Sp0ckyAuthor Commented:
Thank you Yan.  ahoffman, please explain your comment.  I thought that you had to have a cert to get onto the server meaning without one you cannot.  Makes it difficult to get on the web access no?  One less port open is better no?
0
 
Sp0ckyAuthor Commented:
"Are you aware that SSL only secures transport, but not your server, nor the client from other attacks?"

Let me explain better.  I am not worried about the client in this scenario, ONLY the Server.  Secondly, considering  our IIS only uses IIS uses port 80 and 443  (to the best o my knowledge) Less ports= better security.  Therefore a safer server.  Second, if a potential hacker is not allowed into our site or IIS for that matter without a cert using https, he can't get into the site and perhaps even IIS.  I appreciate the comment but please elaborate.
0
 
ahoffmannCommented:
certs do not make your server secure (except if you have to confirm them with your mantra each time)
these certs just show the server that a well-know clients connects

If the client is infected with malware somehow (could be virii, trojans, or special crafted websites), and then connects to your server, does your server detect this malware? I don't think so.
For example think of cross-site scripting or SQL injection (a nightmare in particular with MS SQL), it's all valid *and* from the well-known client. And if there is a firewall or IDS in front of your servers, they're totally blind too, 'cause 443.
After reading this keep the current cross-zone and SSL bugs of for example IE in mind.

I'm not saying that SSL is unsecure, or that client certs are useless. You just need to know what they proof or protect: they encrypt traffic and they authenticate the client, that's all.
0
 
Sp0ckyAuthor Commented:
First of all ahoffmann, than you for your comments!  I will address them below and please post your take.  Anyone else is also welcome. :)

"certs do not make your server secure - these certs just show the server that a well-know clients connects"

Hold that thought.  If the firewall is ONLY allowing 443 and (maybe) port 80, then hackers cannot get in anywhere else (generally speaking).  Please comment, is that correct?  

Second, if the server REQUIRES CERTS not just accept, then the hacker MUST have an approved cert to even get in otherwise they get rejected.  It is NOT just a matter of showing they are well known clients, its a requirement.  Is this not correct? Anyone?

"If the client is infected with malware somehow (could be virii, trojans, or special crafted websites), and then connects to your server, does your server detect this malware?"  

I run malware detection at least once per day and now that you mention other variables, perhaps I will run it as a bat once per hour..  The server is also protected with realtime anti-virus which has already stopped on virus in it's tracks.  Am I missing something here?

"I'm not saying that SSL is unsecure, or that client certs are useless. You just need to know what they proof or protect: they encrypt traffic and they authenticate the client, that's all."

Hang on, if the client isn't encrypted, it doesn't get in.  That's not just trivial, that is a requirement.  They can't get in any other way.  Now, I am not sure if this works with client certs from cert authorities other than our server that issues.  Does anyone know this?





0
 
Sp0ckyAuthor Commented:
Ok, did some more research - here's how the authentication works guys:

Annonymous auth - dangerous to use for my application.

Basic Authentication - only use if you are using certificates because other wise the user logon credentials are totally hackable being sent in clear text.  Using SSL the credentials are encrypted as well as the entire session.

Digest Authentication - hashes the credentials and works better with firewalls.

Int Windows Auth - uses token encryption to encrypt credentials but harder to get throught the firewall.



0
 
ahoffmannCommented:
>  If the firewall is ONLY allowing 443 ...
   yes only those ports, and your cleint certs (hopefully) authentificate the client, but see my comment about malware

> ..  if the server REQUIRES CERTS not just accept, then the hacker MUST have an approved cert ..
  yes, but see my comment about malware again

> I run malware detection at least once per day ..
  do you do it against billion of websites?

> The server is also protected with realtime anti-virus  ..
   is your web application on the server secure (not vulnerable to XSS, SQL injection buffer overflows, session hijacking, etc. etc.)

>  Am I missing something here?
   XSS, SQL injection buffer overflows, session hijacking, etc. etc.)

> They can't get in any other way.
  yes they get get in with SSL only, but SSL encrypts the traffic, it does not proof the transfered data against malware (see last 2 comments)

> Digest Authentication ..
  I'd recommend that, but unfortunately less browsers support it proper

All in all, you see that my concerns are according web application security, which breaks all your firewall, IDS and SSL efforts.
Web application traffic goes stright through, and so does embeded malware.
This does not mean that your efforts are worthless, but you shuld know about it, that's why I mentioned it.
There're to much people who make you belief that SSL and authetication make something secure. That's wrong (others say BS:) when talking about http and https.
0
 
ErikPhilipsCommented:
I have port 80 open on my server just so my users don't have to do HTTPS (not all my users are smart).  For OWA i have my DNS set to mail.<mycompany>.com to point to OWA.  I have followed Microsoft's suggestion about redirecting HTTP to HTTPS (http://support.microsoft.com/default.aspx?scid=kb;en-us;279681).  Just an option I thought I would throw out there for ya.
0
 
Sp0ckyAuthor Commented:
First of all, thanks again everyone for comments.  I will be spliting up the points soon.  

"Web application traffic goes stright through, and so does embeded malware.
This does not mean that your efforts are worthless, but you shuld know about it, that's why I mentioned it."

Hmm... I see.  How does digest authentication not let malware through?  or, are you saying it does.. but my bat files will detect it?  Again, I appreciate your knowledgeable answers but you are leaving some details out and as a result I am not quite getting your answer.

Thanks for the re-direct comment Eric!
0
 
Sp0ckyAuthor Commented:
"XSS, SQL injection buffer overflows, session hijacking, etc. etc.)"

Any links or references that I can look at regarding this?  Thanks.
0
 
Sp0ckyAuthor Commented:
According to MS XSS is not a vulnerability with Exchange 2000:

http://www.microsoft.com/technet/security/bulletin/MS03-047.mspx

On arbitrary code execution - needed patch:

"What does this patch do?
For Exchange 2000 Server the patch removes the vulnerability by requiring that the authentication used between Exchange servers within an Exchange organization is used before an Exchange server accepts the SMTP extended verb requests. Additionally, this patch implements correct input validation in the affected buffer."

I only have 1 exchange server so some of these vulnerabilities do not apply - as far as I can tell with the info you are giving me..

SQL Injection is run against a database.  I have no database running on my Exchange Server.

Here is the link to eliminate potential "session hacks" on IIS 5.0:

http://www.microsoft.com/Windows2000/downloads/critical/q274149/default.asp


0
 
Sp0ckyAuthor Commented:
"SQL Injection is run against a database.  I have no database running on my Exchange Server."

And I have no database apps running in relation to that instance of IIS period.
0
 
ahoffmannCommented:
> And I have no database apps running in relation to that instance of IIS period.
ok, then SQL inection is not a potential problem for you ('til someone decides to use SQL servers of whatever brand in your IIS/Exchange environment)

Your first M$ link sounds like they fixed a XSS hole in Exchange, If there're other's remaining? I don't know, keep watching security bulletins like http://www.securityfocus.com/

The second one shows that OWA is vulnerable to session hijacking (you see, my buzz words aren't far away from reality:-)
But it's a vage description how to it is fixed. As I understand you need to patch each client, which sounds reasonable 'cause it's most likely a client problem (when the server has not a good concept of preventing such attacks).
0
 
Sp0ckyAuthor Commented:
"If there're other's remaining?"

Ahh, yes good point!  Just bec they found one doesn't necessarily mean it is the only one.  

Thanks for all of your responses ahoffmann!  I have learned a lot just in this one thread from your contribution.  

Thanks to everyone else with their participation and links also!:)
0

Featured Post

Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

  • 11
  • 4
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now