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."

- The above quote from http://www.postfix.org/POSTSCREEN_README.html#victory

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.

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

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/

Debian GNU/Linux based Firewall (FOSS)

Would You like to be in control of your own firewall?

Inspired by the "Ubuntu Firewall build" by Joff Thyer of Blackhills Information Security - please send some beer tokens his way - I wanted a Firewall built on FOSS whereever possible. While there's some driver blobs, if you choose the PC Engines APU system the BIOS is coreboot based moving the HW in the right direction too.

This is a companion blog post, the Bash shell script for a semi-automated installation of the Firewall is on my github

So what is in the build:

• Debian 10 (Buster): Install this yourself (Install on APU w serial)
• BIND9: For local Domain Name Resolution
• ISC-DHCP-SERVER: For providing DHCP to the internal network(s)
• NTP: It's worth your time. Installation should disable timesyncd but the script do some cleanup to make sure.
• DShield iptables client: Quote: "DShield provides a platform for users of firewalls to share intrusion information. DShield is a free and open service". We must give back when we can, and this is a good opportunity.
• Filebeat: Ingest logs into a local Elastic Stack setup (if you don't use it yet, you should :)

Using the APU4C4 with a wle900vx card* the NICs and their usage is as follows:

Connection	IP address	NIC
Internet	DHCP (ISP)	enp1s0
homenet	192.168.10.1	enp2s0
homenet	192.168.20.1	enp3s0
homenet	192.168.30.1	enp4s0
homenet	192.168.40.1	wlan0

The nets are all /24. the name "homenet" is used when configuring BIND9, but call it what you want :)

*There were only 2 cutouts for antennas in the case, but I just drilled a hole in the "lid" for the 3rd antenna. (Yes, that voided the warranty).

The hardware

Since 2016 this firewall setup has been running on different HW, starting with an Intel Atom based system, over a Intel Celeron based system, to the current setup with the PC Engines APU4C4. The shell scripts provided on github use those specific NIC names, however all I did for the new install was search and replace the previous names with the new ones, and everything worked after that.

PC Engines APU4C4

  

APU4C4

FAQ:

Q: Why didn't you just use PFSense or OPNSense?
A: Doesn't support the Wireless Card used & Debian is preferred distro

Q: Why DShield? Can they be trusted?
A: DShield does a lot of work for us in the community and we should give back. I believe they can be trusted, but do exclude other information than "just" the defaults from the iptables client.

Q: Is the shell script thoroughly tested?
A: Not really, it certainly need (way) more testing, and changes have been made that have only been tested in isolation, so please provide feedback/raise a bug or PR. I also changed the subnets and some settings of iptables for obscurity.

To honeypot or not to honeypot, that's the question

Sharing is caring. SANS / DShield provide a prebuilt Cowrie-based honeypot that's very easy to install.
You can find a tutorial here [1] as well as some old stuff here: [2]

So during the holidays/nights/weekends/whatever go install this - It runs well on a Raspberry Pi (and faster, stronger, fancier) so there's no longer any valid excuses not to honeypot!

Your home firewall can also easily be used for the purpose of honeypotting, just forward the relevant iptables/pf logs to DShield as well. Further details on configuring this can be found here [3]

[1] DShield Honeypot: https://isc.sans.edu/honeypot.html
[2] Peerlyst article "Are you submitting your logs to DSHIELD": https://www.peerlyst.com/posts/are-you-submitting-your-logs-to-dshield-martin-boller
[3] HowTo: Submitting logs to DShield https://isc.sans.edu/howto.html

Windows 10 Evaluation Build 1903 Download for testlab

Keep forgetting the download link to Windows Evaluation Versions?

Basically it's always available at https://software-download.microsoft.com/download/pr/ $ISO_NAME

For Windows 10 build 1903 (May 2019) it is:
https://software-download.microsoft.com/download/pr/18362.30.190401-1528.19h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-us.iso

sha256sum (or get-filehash filename -Algorithm SHA256 | Format-List) should produce:
"ab4862ba7d1644c27f27516d24cb21e6b39234eb3301e5f1fb365a78b22f79b3"

Specifically for Packer:

  "variables": {
    "iso_checksum": "ab4862ba7d1644c27f27516d24cb21e6b39234eb3301e5f1fb365a78b22f79b3",
    "iso_checksum_type": "sha256",
    "iso_url": "https://software-download.microsoft.com/download/pr/18362.30.190401-1528.19h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-us.iso",
    "autounattend": "./answer_files/10/unattend.xml",
    "disk_size": "61440"
  }

The easiest way to find the ISO filename is to register on https://www.microsoft.com/en-us/evalcenter/
Get the name from that download and calculate the hash, then automate the installation (Using Packer or whatever your favorite is).

The same principle apply for Windows Server.
Server 2016: 17763.379.190312-0539.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_en-us.iso
 is available at
https://software-download.microsoft.com/download/pr/17763.379.190312-0539.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_en-us.iso

It's about 5 years too late - But let us kill Internet Explorer

<RANT>

When even Microsoft doesn't support it anymore, there's a Window of Opportunity to get the funding to make it happen

Go prepare that presentation for management showing why anything requiring IE should go - NOW!

Any system that still require IE is outdated and thus likely a security risk, so identify those and do something about it. Identify the developer or vendor of those applications and have them updated.

If a vendor still only support IE or Flash or Silverlight, look elsewhere, they're not worth your time and money.

If you still require IE for some crappy internal application, blocking it from accessing the Internet (UserAgent "Mozilla/4.0 (compatible; MSIE*") will significantly lower your risk.

The upgrade recommendation on Github should be read from right-to-left if you want to protect your privacy too:

1. Firefox 
2. Google Chrome
3. Microsoft Edge

</RANT>


Worth reading too:
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-perils-of-using-internet-explorer-as-your-default-browser/ba-p/331732