Forums

Resolved
0 votes
_sslv2-drown:
465/tcp open smtps
| ssl-dh-params:
| VULNERABLE:
| Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
| Transport Layer Security (TLS) services that use anonymous
| Diffie-Hellman key exchange only provide protection against passive
| eavesdropping, and are vulnerable to active man-in-the-middle attacks
| which could completely compromise the confidentiality and integrity
| of any data exchanged over the resulting session.
| Check results:
| ANONYMOUS DH GROUP 1
| Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: postfix builtin
| Modulus Length: 1024
| Generator Length: 8
| Public Key Length: 1024
| References:
https://www.ietf.org/rfc/rfc2246.txt
|
| Diffie-Hellman Key Exchange Insufficient Group Strength
| State: VULNERABLE
| Transport Layer Security (TLS) services that use Diffie-Hellman groups
| of insufficient strength, especially those using one of a few commonly
| shared groups, may be susceptible to passive eavesdropping attacks.
| Check results:
| WEAK DH GROUP 1
| Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: postfix builtin
| Modulus Length: 1024
| Generator Length: 8
| Public Key Length: 1024
| References:
|_ https://weakdh.org
| ssl-poodle:
| VULNERABLE:
| SSL POODLE information leak
State: LIKELY VULNERABLE
| IDs: OSVDB:113251 CVE:CVE-2014-3566
| The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
| products, uses nondeterministic CBC padding, which makes it easier
| for man-in-the-middle attackers to obtain cleartext data via a
| padding-oracle attack, aka the "POODLE" issue.
| Disclosure date: 2014-10-14
| Check results:
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_FALLBACK_SCSV properly implemented
| References:
| https://www.imperialviolet.org/2014/10/14/poodle.html
| http://osvdb.org/113251
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
|_ https://www.openssl.org/~bodo/ssl-poodle.pdf
|_sslv2-drown:
587/tcp open submission
| smtp-vuln-cve2010-4344:
|_ The SMTP server is not Exim: NOT VULNERABLE
| ssl-dh-params:
| VULNERABLE:
| Anonymous Diffie-Hellman Key Exchange MitM Vulnerability
| State: VULNERABLE
| Transport Layer Security (TLS) services that use anonymous
| Diffie-Hellman key exchange only provide protection against passive
| eavesdropping, and are vulnerable to active man-in-the-middle attacks
| which could completely compromise the confidentiality and integrity
| of any data exchanged over the resulting session.
| Check results:
| ANONYMOUS DH GROUP 1
| Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: postfix builtin
| Modulus Length: 1024
| Generator Length: 8
| Public Key Length: 1024
| References:
| https://www.ietf.org/rfc/rfc2246.txt
|
| Diffie-Hellman Key Exchange Insufficient Group Strength
State: VULNERABLE
| Transport Layer Security (TLS) services that use Diffie-Hellman groups
| of insufficient strength, especially those using one of a few commonly
| shared groups, may be susceptible to passive eavesdropping attacks.
| Check results:
| WEAK DH GROUP 1
| Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: postfix builtin
| Modulus Length: 1024
| Generator Length: 8
| Public Key Length: 1024
| References:
|_ https://weakdh.org
| ssl-poodle:
| VULNERABLE:
| SSL POODLE information leak
| State: LIKELY VULNERABLE
| IDs: OSVDB:113251 CVE:CVE-2014-3566
| The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
| products, uses nondeterministic CBC padding, which makes it easier
| for man-in-the-middle attackers to obtain cleartext data via a
| padding-oracle attack, aka the "POODLE" issue.
| Disclosure date: 2014-10-14
| Check results:
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_FALLBACK_SCSV properly implemented
| References:
| https://www.imperialviolet.org/2014/10/14/poodle.html
| http://osvdb.org/113251
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
|_ https://www.openssl.org/~bodo/ssl-poodle.pdf
|_sslv2-drown:
993/tcp open imaps
| ssl-dh-params:
| VULNERABLE:
| Diffie-Hellman Key Exchange Insufficient Group Strength
| State: VULNERABLE
| Transport Layer Security (TLS) services that use Diffie-Hellman groups
| of insufficient strength, especially those using one of a few commonly

shared groups, may be susceptible to passive eavesdropping attacks.
| Check results:
| WEAK DH GROUP 1
| Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| Modulus Type: Safe prime
| Modulus Source: RFC2409/Oakley Group 2
| Modulus Length: 1024
| Generator Length: 8
| Public Key Length: 1024
| References:
|_ https://weakdh.org
| ssl-poodle:
| VULNERABLE:
| SSL POODLE information leak
| State: LIKELY VULNERABLE
| IDs: OSVDB:113251 CVE:CVE-2014-3566
| The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
| products, uses nondeterministic CBC padding, which makes it easier
| for man-in-the-middle attackers to obtain cleartext data via a
| padding-oracle attack, aka the "POODLE" issue.
| Disclosure date: 2014-10-14
| Check results:
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_FALLBACK_SCSV properly implemented
| References:
| https://www.imperialviolet.org/2014/10/14/poodle.html
| http://osvdb.org/113251
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
|_ https://www.openssl.org/~bodo/ssl-poodle.pdf
|_sslv2-drown:
Monday, May 03 2021, 08:23 PM
Share this post:
Responses (10)
  • Accepted Answer

    Tuesday, May 04 2021, 04:54 PM - #Permalink
    Resolved
    0 votes
    Von Royce Wallace wrote:
    If I refuse messages from insecure email servers or clients that is fine

    As long as they don't fall back to plain text, in which case you will have shot yourself in the foot.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 04 2021, 03:36 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    What are you trying to achieve? You really also need to check your sources as some of your fixes are old and have been superseded. TLS1.0 and TLS 1.1 should be dead and buried now. Try a document such as https://wiki.mozilla.org/Security/Server_Side_TLS.

    I repeat again, in the e-mail stack all you are doing is stopping older clients connecting to you. If they are external and sending mail to you, depending on the sender's configuration, you will no longer receive it or they will fall back to plain text sending. If you want that, go for it. For all the clients you control, you will block any old ones, but that is your choice and you can upgrade any you have. If you don't have any then you have not achieved much as they will automatically negotiate the strongest cipher they can so they wouldn't be using the weak ones.

    With respect to apache/httpd, if you use websites configured through the Webconfig, then these have already been hardened (look at /etc/httpd/conf.d/flex-443.conf). They broadly use the intermediate cipher set recommended by Mozilla, but have one or two extra ciphers to allow all browsers in the test at https://www.ssllabs.com/ssltest/analyze.html. Note these values have also been applied to the sandboxed version of httpd used for the webconfig. All you have done is overwritten the default httpd configuration which is never used by ClearOS except to server a default page prior to initialising your default website.


    Thanks for your input nmap no longer finds security problems based on changes. And everything seems to work.

    I will also disable tls 1 and 1.1 thanks for that I was considering doing it.

    If I refuse messages from insecure email servers or clients that is fine
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 04 2021, 07:27 AM - #Permalink
    Resolved
    0 votes
    What are you trying to achieve? You really also need to check your sources as some of your fixes are old and have been superseded. TLS1.0 and TLS 1.1 should be dead and buried now. Try a document such as https://wiki.mozilla.org/Security/Server_Side_TLS.

    I repeat again, in the e-mail stack all you are doing is stopping older clients connecting to you. If they are external and sending mail to you, depending on the sender's configuration, you will no longer receive it or they will fall back to plain text sending. If you want that, go for it. For all the clients you control, you will block any old ones, but that is your choice and you can upgrade any you have. If you don't have any then you have not achieved much as they will automatically negotiate the strongest cipher they can so they wouldn't be using the weak ones.

    With respect to apache/httpd, if you use websites configured through the Webconfig, then these have already been hardened (look at /etc/httpd/conf.d/flex-443.conf). They broadly use the intermediate cipher set recommended by Mozilla, but have one or two extra ciphers to allow all browsers in the test at https://www.ssllabs.com/ssltest/analyze.html. Note these values have also been applied to the sandboxed version of httpd used for the webconfig. All you have done is overwritten the default httpd configuration which is never used by ClearOS except to server a default page prior to initialising your default website.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:59 PM - #Permalink
    Resolved
    0 votes
    Also did this (edit)

    Getting IMAP to work required this



    /etc/imapd.conf

    Changing the below
    tls_key_file: /etc/letsencrypt/live/domain.com/privkey.pem
    tls_cert_file: /etc/letsencrypt/live/domain.com/fullchain.pem

    to this

    tls_server_key: /etc/letsencrypt/live/domain.com/privkey.pem
    tls_server_cert: /etc/letsencrypt/live/domain.com/fullchain.pem
    tls_server_dhparam: /etc/ssl/private/dhparams.pem


    tls_cipher_list: kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES
    tls_prefer_server_ciphers: 1
    tls_versions: tls1_0 tls1_1 tls1_2

    #see previous post for creation of this file
    tls_server_dhparam: /etc/ssl/private/dhparams.pem


    Based on this

    https://access.redhat.com/articles/1470873
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:41 PM - #Permalink
    Resolved
    0 votes
    Also did this

    /etc/httpd/conf.d/ssl.conf and update following values like below after making changes restart Apache service.

    SSLProtocol all -SSLv3 -SSLv2

    Based on this

    https://tecadmin.net/poodle-sslv3-vulnerability-cve-2014-3566/
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:27 PM - #Permalink
    Resolved
    0 votes
    So that closed all the postfix holes

    The only one left is

    ssl-poodle:
    | VULNERABLE:
    | SSL POODLE information leak
    | State: LIKELY VULNERABLE
    | IDs: OSVDB:113251 CVE:CVE-2014-3566
    | The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
    | products, uses nondeterministic CBC padding, which makes it easier
    | for man-in-the-middle attackers to obtain cleartext data via a
    | padding-oracle attack, aka the "POODLE" issue.
    | Disclosure date: 2014-10-14
    | Check results:
    | TLS_RSA_WITH_AES_128_CBC_SHA
    | TLS_FALLBACK_SCSV properly implemented
    | References:
    | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
    | https://www.imperialviolet.org/2014/10/14/poodle.html
    | https://www.openssl.org/~bodo/ssl-poodle.pdf
    |_ http://osvdb.org/113251
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:25 PM - #Permalink
    Resolved
    0 votes
    Sorry, I misread the port number and thought you were talking about the web server which has been fixed.

    The problem with tightening up on these is that you may stop other less secure servers sending you e-mails and vice-versa. In this case, the only people using port 465 are your own. If you have old clients on your LAN then you will have stuffed them if they are using port 465. If no one on your LAN is using an old client, then you aren't vulnerable as your clients will automatically negotiate a stronger protocol.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:24 PM - #Permalink
    Resolved
    0 votes
    Okay here is what I did

    mkdir -p /etc/ssl/private
    chmod 710 /etc/ssl/private
    cd /etc/ssl/private
    openssl dhparam -out dhparams.pem 2048
    chmod 600 dhparams.pem

    /etc/postfix/main.cf

    smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
    smtpd_tls_dh1024_param_file = /etc/ssl/private/dhparams.pem

    smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
    smtpd_tls_protocols = !SSLv2, !SSLv3
    smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
    smtp_tls_protocols = !SSLv2, !SSLv3



    sudo systemctl restart postfix.service

    Based on this and this

    https://www.howtoforge.com/tutorial/how-to-protect-your-debian-and-ubuntu-server-against-the-logjam-attack/

    https://devopspoints.com/centos-7-securing-the-mail-server-using-ssl-tls.html

    Doing another scan now
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 09:08 PM - #Permalink
    Resolved
    0 votes
    7.8.1 or whatever the latest stable is

    Here is what I did to hopefully fix it

    Based on this

    https://devopspoints.com/centos-7-securing-the-mail-server-using-ssl-tls.html

    /etc/postfix/main.cf

    smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
    #smtpd_tls_dh1024_param_file = /etc/ssl/private/dhparams.pem (using letsencrypt so left this line out afraid it would mess something up)

    smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
    smtpd_tls_protocols = !SSLv2, !SSLv3
    smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
    smtp_tls_protocols = !SSLv2, !SSLv3


    sudo systemctl restart postfix.service
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 03 2021, 08:47 PM - #Permalink
    Resolved
    0 votes
    Are you still on ClearOS 6? If so, it is no surprise as there have been no updates for 20 months. There should not be any 3DES ciphers enabled in an up to date 7.x.
    The reply is currently minimized Show
Your Reply