The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.
Failed PCI Scan - Exchange 2010 OWA
Hi,
I ran a Trsutwave PCI scan on my environment after I had just implemented a new Exchange Certificate SHA-2. I have 2 CAS and 2 DAG Exchange 2010 Std servers. I noticed my 2 DAG and 1 CAS Exchange Servers have IE 9 and 1 of my CAS servers have IE 8. not sure if this is why the scan failed? Also, will upgrading my IE to 11 on all four Exchange servers affect anything?
Below are the details of the failed scan.
#1 Vulnerability SSLv3 Supported
Note to scan customer:
SSL v3.0 violates PCI DSS and is considered an automatic failing
condition.
Port: tcp/443
This service supports the use of the SSLv3 protocol. The SSLv3 protocol
has known cryptographic weaknesses that can lead to the compromise
of sensitive data within an encrypted session. Additionally, the PCI SSC
and NIST have determined that the SSLv3 protocol no longer meets the
definition of strong cryptography.
CVE: CVE-2014-3566
NVD: CVE-2014-3566
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#2 Vulnerability TLSv1.0 Supported
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database. TLS v1.0 violates PCI DSS and is considered an automatic
failing condition.
Port: tcp/443
This service supports the use of the TLSv1.0 protocol. The TLSv1.0
protocol has known cryptographic weaknesses that can lead to the
compromise of sensitive data within an encrypted session. Additionally,
the PCI SSC and NIST have determined that the TLSv1.0 protocol no
longer meets the definition of strong cryptography
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#3 Vulnerability SSL/TLS Weak Encryption
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database
Algorithms
Port: tcp/443
The SSL-based service running on this host appears to support the use
of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no
authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
Please note that this vulnerability CANNOT be disputed using a Risk
Mitigation and Migration plan. This is a separate finding and must be treated as such.
CVE: CVE-2013-2566, CVE-2015-2808
NVD: CVE-2013-2566, CVE-2015-2808
CVSSv2: AV:N/AC:M/Au:N/C:P/I:N/A:N
Service: microsoft:iis
Any suggestions on how to remedy this?
Thanks!
I ran a Trsutwave PCI scan on my environment after I had just implemented a new Exchange Certificate SHA-2. I have 2 CAS and 2 DAG Exchange 2010 Std servers. I noticed my 2 DAG and 1 CAS Exchange Servers have IE 9 and 1 of my CAS servers have IE 8. not sure if this is why the scan failed? Also, will upgrading my IE to 11 on all four Exchange servers affect anything?
Below are the details of the failed scan.
#1 Vulnerability SSLv3 Supported
Note to scan customer:
SSL v3.0 violates PCI DSS and is considered an automatic failing
condition.
Port: tcp/443
This service supports the use of the SSLv3 protocol. The SSLv3 protocol
has known cryptographic weaknesses that can lead to the compromise
of sensitive data within an encrypted session. Additionally, the PCI SSC
and NIST have determined that the SSLv3 protocol no longer meets the
definition of strong cryptography.
CVE: CVE-2014-3566
NVD: CVE-2014-3566
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#2 Vulnerability TLSv1.0 Supported
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database. TLS v1.0 violates PCI DSS and is considered an automatic
failing condition.
Port: tcp/443
This service supports the use of the TLSv1.0 protocol. The TLSv1.0
protocol has known cryptographic weaknesses that can lead to the
compromise of sensitive data within an encrypted session. Additionally,
the PCI SSC and NIST have determined that the TLSv1.0 protocol no
longer meets the definition of strong cryptography
CVSSv2: AV:N/AC:L/Au:N/C:N/I:P/A:N
Service: microsoft:iis
#3 Vulnerability SSL/TLS Weak Encryption
Note to scan customer:
This vulnerability is not recognized in the National Vulnerability
Database
Algorithms
Port: tcp/443
The SSL-based service running on this host appears to support the use
of "weak" ciphers such as:
- Ciphers suites that have key-lengths of less than 128 bits.
- Ciphers suites using anonymous Diffie-Hellman algorithms (no
authentication).
- Ciphers suites offering no encryption.
- Ciphers suites using pre-shared keys.
- Ciphers suites using RC4 or MD5.
Please note that this vulnerability CANNOT be disputed using a Risk
Mitigation and Migration plan. This is a separate finding and must be treated as such.
CVE: CVE-2013-2566, CVE-2015-2808
NVD: CVE-2013-2566, CVE-2015-2808
CVSSv2: AV:N/AC:M/Au:N/C:P/I:N/A:N
Service: microsoft:iis
Any suggestions on how to remedy this?
Thanks!
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Before you start making changes to the Exchange server, you need to read this article posted on the Exchange team blog.
http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx
It goes through exactly what you can and cannot disable for Exchange to work correctly.
You should install Internet Explorer 11 and then any subsequent updates for Windows and Exchange using Microsoft Update to keep the server secure. While you shouldn't browse from the server, the browser is so heavily integrated it needs to be kept up to date.
Simon.
http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx
It goes through exactly what you can and cannot disable for Exchange to work correctly.
You should install Internet Explorer 11 and then any subsequent updates for Windows and Exchange using Microsoft Update to keep the server secure. While you shouldn't browse from the server, the browser is so heavily integrated it needs to be kept up to date.
Simon.
way out is to disable sslv3 first (esp due to poodle vulnerability) but as of tls1.0, you may not want to disable that as there are many reported cases that after tls1.0 is disabled, the owa and errors may starts popping out. so kill off the sslv3 first and rescan to see remaining vulnerabilities surfaced first.
e.g. Exchange uses TLS 1.0 and doesn't support 1.1 and 1.2 http://support.microsoft.com/kb/2709167 According to the article here you can't use TLS 1.1 or TLS 1.2 with SMTP. Also if you enabled SSL 3.0 and it worked, disabled ssl 3 and enabled tls 1.0 and it worked with that. So it would work with either SSL 3.0 or TLS 1.0. SSL 3 was required by our Outlook 2011 clients, and TLS 1.0 was being used for EWS
using IISCrypto (like select the FIPS preset button) as stated is handy to use the best practice and go specific to disable the weak crypto. Note that any change you make to schannel (MS's crypto provider), needs a reboot to apply and until you reboot Exchange will be pretty broken. The tools is actually touching the schannel registries as stated in https://support.microsoft.com/en-us/kb/245030
In short, the weak encryption issue likely relates to SSL 2.0 or 3.0 being enabled, as they are for default Windows Server/IIS Installs. Exchange minimally relies on TLS 1.0, so that needs to be enabled and do disable tls1.0. Need to seek Trustwave to accepted and approved your dispute with a mitigation plan since appl breaking is not viable for running. Otherwise fronting a appl delivery controller such as F5, or haproxy in a way is virtual patching to get through trustware scan but not solving the actual problem..
e.g. Exchange uses TLS 1.0 and doesn't support 1.1 and 1.2 http://support.microsoft.com/kb/2709167 According to the article here you can't use TLS 1.1 or TLS 1.2 with SMTP. Also if you enabled SSL 3.0 and it worked, disabled ssl 3 and enabled tls 1.0 and it worked with that. So it would work with either SSL 3.0 or TLS 1.0. SSL 3 was required by our Outlook 2011 clients, and TLS 1.0 was being used for EWS
using IISCrypto (like select the FIPS preset button) as stated is handy to use the best practice and go specific to disable the weak crypto. Note that any change you make to schannel (MS's crypto provider), needs a reboot to apply and until you reboot Exchange will be pretty broken. The tools is actually touching the schannel registries as stated in https://support.microsoft.com/en-us/kb/245030
In short, the weak encryption issue likely relates to SSL 2.0 or 3.0 being enabled, as they are for default Windows Server/IIS Installs. Exchange minimally relies on TLS 1.0, so that needs to be enabled and do disable tls1.0. Need to seek Trustwave to accepted and approved your dispute with a mitigation plan since appl breaking is not viable for running. Otherwise fronting a appl delivery controller such as F5, or haproxy in a way is virtual patching to get through trustware scan but not solving the actual problem..
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
I tried IISCrypto and it broke my exchange. SSLv3 and TLS 1.0 are needed for exhange. I will dispute the case
tls1.0 minimally is needed for exchange as mentioned in my past post. hope it is running fine as of now
Hi,
Is there any outage or email flow disruptions when disabling the SSLv3 ?
As far as I know and have tried upgrading the IE on the OS doesn't affect the exchange server 2010 functionality.
Is there any outage or email flow disruptions when disabling the SSLv3 ?
As far as I know and have tried upgrading the IE on the OS doesn't affect the exchange server 2010 functionality.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
Run it and view what it says and then act on the recommendations.
Much better than trying to follow MS recomended settings!