Tuesday, March 3, 2020

Postfix/Postscreen using Blocklists and Deep Protocol tests

When configuring Postfix, it is worth considering using an 'aggressive" postscreen configuration thus saving valuable bandwidth and processing power.

However, some configurations may lead to issues with some mail providers. Specifically I've had issues with Google GMail and Microsoft Hotmail with blocklists and deep protocol tests respectively.


Microsoft Hotmail / Outlook / live

Initially postscreen was configured to use the following blocklists:
  1. zen.spamhaus.org
  2. bl.spameatingmonkey.net
  3. dnsbl.habl.org
  4. bl.spamcop.net
  5. dnsbl.sorbs.net
However sorbs.net appear to be a little too harsh on Microsoft, leading to rejects of Hotmail IP addresses, so if that is a problem for you, consider not using that list.

Google GMail

GMail use a large number of IPv4 and IPv6 addresses. That combined with the behavior of deep protocol tests:
"When any "deep protocol tests" are configured, postscreen(8) cannot hand off the "live" connection to a Postfix SMTP server process in the middle of the session. Instead, postscreen(8) defers mail delivery attempts with a 4XX status, logs the helo/sender/recipient information, and waits for the client to disconnect. The next time the client connects it will be allowed to talk to a Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the impact of this limitation by giving deep protocol tests a long expiration time."


As GMail does not resend from the same IP-address after the 4xx, this generates a lot of "reject noise" in the mail log (not least for IPv6). Instead of disabling deep protocol tests, instead just configure postscreen_dnsbl_whitelist_threshold with a negative value.

Given the above the postscreen section of /etc/postfix/main.cf now looks like this:
## Postcreen settings
#
postscreen_access_list =
       permit_mynetworks
       cidr:/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_blacklist_action = enforce

# Use selected DNSBLs
postscreen_dnsbl_sites =
        zen.spamhaus.org*3
        bl.spameatingmonkey.net*2
        dnsbl.habl.org
        bl.spamcop.net
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce
# Whitelist everything below threshold on BLs
postscreen_dnsbl_whitelist_threshold = -1

postscreen_greet_banner = Welcome, please wait...
postscreen_greet_action = enforce

# Deep protocol tests
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce

postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce

postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce
run - postfix reload - to activate any changes.

Before going full reject, read the howto from postfix http://www.postfix.org/POSTSCREEN_README.html and start with ignore instead of enforce, which is useful for testing and collecting statistics without blocking mail from the get go.

Thursday, February 20, 2020

Secure TLS Server Configurations



A few notes on configuring a web-server with secure TLS protocol versions and Ciphers. NGINX is used in the examples herein, but the protocols, ciphers and headers should be universal.



There's some good advice from Mozilla here [2] [3], and @rootsecdev wrote a Medium Post on configuring IIS on Windows Server 2019 [4].

TLS

Only TLSv1.2 and TLSv1.3 are considered secure, so start with configuring these as the only supported protocols.

Change the config file to:

ssl_protocols TLSv1.2 TLSv1.3;

If only modern clients are used you can get away with TLSv1.3 only.
ssl_protocols TLSv1.3;

Windows Server builds 1903 and newer support TLSv1.3 too, however enabling this is not covered in [4]. It can be found with some Google-fu, though.

Ciphers

Only protocols with Perfect Forward Secrecy (PFS) should be used, and CBC has some issues (see [1] for more information). That leaves us with the following ciphers configured in the NGINX conf-file: 
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384;
For compatibility with older stuff use the intermediate configuration use Mozilla's configurator [3]. Please note that the above ciphers will effectively remove access for Android 5 and 6, Firefox <= 47, Safari 6-8, and likely a few other legacy platforms.

HSTS Header

Strict Transport Security will ensure that everything is served over HTTPS, configure this as shown below for an age of a year:
    add_header Strict-Transport-Security "max-age=31536000" always;

In summary

  • Use TLSv1.3 and nothing else if you can get away with it. 
  • Enforce HTTPS using strict transport security.
  • If TLSv1.2 is needed limit the ciphers used as discussed above.

For all of the settings above, Mozilla has a pretty good configurator discussed here [2] and found here [3]
If you're running Citrix ADC (The artist formerly known as Netscaler), there's a recent (Jan 2020) post worth reading [5].


[1] Padding oracles and the decline of CBC-mode cipher suites: https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

[2] Security/Server Side TLS: https://wiki.mozilla.org/Security/Server_Side_TLS

[3] Mozilla's SSL Config generator: https://ssl-config.mozilla.org/

[4] Configuring secure cipher suites in Windows Server 2019 IIS: https://medium.com/@rootsecdev/configuring-secure-cipher-suites-in-windows-server-2019-iis-7d1ff1ffe5ea

[5] Citrix Networking SSL / TLS Best Practices: https://docs.citrix.com/en-us/tech-zone/build/tech-papers/networking-tls-best-practices.html

Thursday, January 16, 2020

Detecting CVE-2020-0601 Windows CryptoAPI Spoofing Vulnerability exploit attempts

After installation of the patch for CVE-2020-0601 Windows CryptoAPI Spoofing Vulnerability, the system will log EventID 1 in the application log to indicate an attempt to exploit the vulnerability.

The awesome Didier Stevens https://twitter.com/DidierStevens created a VBA script to generate that event [1] however in order to test the flow of this from several systems, Powershell was the way to go (Didier did all the heavy lifting). The oneliner goes like this:

Write-EventLog -LogName "Application" -Source "Microsoft-Windows-Audit-CVE" -EventID 1 -EntryType Warning -Message "[CVE-2020-0601] alert validation" -Category 0 -RawData 0xDE,0XAD,0xBE,0XEF


This should show up like this in Event Viewer



If You're selective in what logevents you forward (and you should), here's the XPATH query used to collect this:

<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">*[System[Provider[@Name='Microsoft-Windows-Audit-CVE' or @Name='Microsoft-Windows-UAC'] and (EventID=1)]]</Select>
  </Query>
</QueryList>
Filtering for it in Kibana:
event.code: 1 and event.provider: Microsoft-Windows-Audit-CVE

After ingesting into Elasticsearch, the alert (in Alerta [2]) looks like this


[1] Using CveEventWrite From VBA (CVE-2020-0601): https://blog.didierstevens.com/2020/01/15/using-cveeventwrite-from-vba-cve-2020-0601/
[2] https://alerta.io/