Security Basics mailing list archives
RE: RPC over HTTPS security risks
From: <adisegna () siscocorp com>
Date: Wed, 8 Dec 2004 12:37:13 -0500
I had the same issues myself. It's very hard to give in and allow the common folk USERS access to your mail server from the outside world. I debated the scenario a lot before I gave in. In any case, it's inevitable with today's road warriors. The proper way to set this up is with a Front-End Exchange server in a DMZ connected through ISA server into the internal Back-End Exchange server. However, not all of us have the luxury of this solution. The combination of things that need to happen in order for this to work successfully are (without going into too much detail): Proper training of the USERS: Explain the need for updated virus protection on their home or roving machines. Explain Window Update and tell them to use it. Explain the fact that when accessing webmail from a public computer there is a chance that keyloggers and other malicious software could be installed. Explain the need to shut down all instances of the browser when finished checking email. OWA doesn't use cookies so closing the browser is all that is needed to log off. Just because they write down their passwords on a sticky note and put them under their keyboard at work doesn't mean they can do it on the road too. This is no longer an acceptable practice. Server Side Use SSL on the Server for everything exchange (public folders). Allow port 443 and 25 to enter the machine. There is no need for port 80 to be open. Use software like Symantec AntiVirus for Exchange or something similar to protect the inboxes. Restrict the number of recipients that one user can send to. Limit sending and receiving sizes to something manageable Limit the number of connections Create a mailbox quota to prohibit send and receive when mailbox limit has been reached. Keep up on the spam rules and block most attachments. Windows update of course. Be consistent with checking the logs Tweak IIS lock down to prevent any unwanted commands from being past to the webserver Don't trust the user to do the right thing. Lock the down the server the best you can. Thanks AD -----Original Message----- From: Tim Hanekamp [mailto:thanekamp () gmail com] Sent: Tuesday, December 07, 2004 2:44 PM To: security-basics () securityfocus com Subject: RPC over HTTPS security risks We have begun to implement RPC over HTTPS for Exchange 2003 at our corporate office. Before rolling this service out to our users, who then could possibly start using it on their home computers, which could easily be insecured, we are trying to evaluate the possible security threats that this poses. It would seem that if someone were able to own a machine that had this configured on it, it would be fairly easy for them to use the exchange server as a relay for mail and/or completely flood the system with viruses, especially if the computer were infected with a virus. Do you think this would be the case, and, if so, what measures do you think could be taken in order to mitigate this risk. The only thing we could come up with so far was requiring these clients to use digital certificates and only install these certificates on machines that have been inspected and will be used in the proper setting (not that we could ever really be certain of the latter idea). Thoughts?
Current thread:
- RPC over HTTPS security risks Tim Hanekamp (Dec 07)
- RE: RPC over HTTPS security risks James McGee (Dec 08)
- Re: RPC over HTTPS security risks xyberpix (Dec 09)
- <Possible follow-ups>
- RE: RPC over HTTPS security risks adisegna (Dec 08)
- RE: RPC over HTTPS security risks Depp, Dennis M. (Dec 08)