Decrypt Exchange traffic

[mgusta]

Hi,

I´m trying out decrypting traffic to and from our Exchange server. When decrypting incomming traffic the application change from SSL to what ever is in there. ie ms-exchange, outlook-web, rpc-over-http etc. Now for clients to be able to connect I need to allow all theese applications instead of only SSL. Would this potentially present more of a risk than to not decrypt the traffic at all?

Please share youre thoughts on this.

//Mikael

[reaper]

Hi Mikael

Ideally you would create a security policy that not only allows the applications but also restricts the "tuples" eg. source and destination zones, ip's and ports

you could select to set a service to restrict all traffic to only the ssl ports used by your exchange (usually 443 and possibly 993 for imap ssl) which will limit the "cleartext" applications to connect to their ssl ports only. performing ssl decryption will allow you to detect attacks and infected traffic which will help protect your exchange far better than only allowing pure ssl

you'll want to manually create service objects instead of using "application default", as that would allow traffic on the default ports which you don't need in this scenario:

regards

Tom

[mgusta]

Hi,

Yes, I did set the zones and public IP of Exchange server. I did notice that using application default in our environment didn´t work since web-browing is only allowed on port 80 by default and we do a redirect to HTTPS. So for the test I used 'any' for service which I would restrict if I decide on implementing this. But you would say that decrypting this traffic and allowing those applications is better(=safer) than just letting it pass through as SSL?

Thank you for you input on this.

//Mikael

[reaper · Accepted solution]

Hi Mikael

yes, if you first restrict the service ports to a custom set of allowed ports (443 etc), this will restrict what kind of connections can be received.

The server should be configured to reject non-encrypted connections on these ports.

Decrypting the flow and allowing the applications will enable you to control application behavior through AppID (abnormal/unexpected behavior should cause the session to be dropped), it will also enable Threat Protection for this inbound flow, making sure no malicious code or files are being transmitted at your server, you can even apply URL filtering or DLP profiles.

If the flow is left encrypted the firewall cannot inspect for threats inside of the ssl tunnel and your server could be attacked. 

regards

Tom