MAC algorithms recommended for Debian 10 (Buster)

[axi0m]

Scenario

I ran ssh_scan app against my own internal server and was presented withe the following suggestion:

"recommendations": [ "Add these MAC algorithms: hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com"

If you run this command to test your sshd configuration locally: sshd -T | grep macs:

This is the result: macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Versioning/Reproducing

OpenSSH_7.9p1 Raspbian-10+deb10u1, OpenSSL 1.1.1d 10 Sep 2019 Raspbian GNU/Linux 10 (buster) Linux LV-223 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux "ssh_scan_version": "0.0.42"

Expected Output

I'd expect that the ssh_scan program would grade the configuration as A and not recommend adding these MAC algorithms, given that those MAC algorithms are indeed enabled, the name for them in the sshd_config is just different (EtM suggests encrypt-then-MAC per OpenSSH release notes).

Note

I do realize that EtM MACs are different than the non-etm labeled MACs but I'd imagine if anything those are stronger than having just the non-etm MACs enabled.

[axi0m]

If this is useful, please take a look at this full ssh_scan output as well (minus some redacted details)

docker run -it mozilla/ssh_scan /app/bin/ssh_scan -t <IPv4>
[
  {
    "ssh_scan_version": "0.0.42",
    "ip": "x.x.x.x",
    "hostname": "",
    "port": 22,
    "server_banner": "SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u1",
    "ssh_version": 2.0,
    "os": "raspbian",
    "os_cpe": "o:raspbian:raspbian",
    "ssh_lib": "openssh",
    "ssh_lib_cpe": "a:openssh:openssh:7.9p1",
    "key_algorithms": [
      "curve25519-sha256@libssh.org",
      "diffie-hellman-group-exchange-sha256",
      "ecdh-sha2-nistp521",
      "ecdh-sha2-nistp384",
      "ecdh-sha2-nistp256"
    ],
    "encryption_algorithms_client_to_server": [
      "chacha20-poly1305@openssh.com",
      "aes256-gcm@openssh.com",
      "aes128-gcm@openssh.com",
      "aes256-ctr",
      "aes128-ctr",
      "aes192-ctr"
    ],
    "encryption_algorithms_server_to_client": [
      "chacha20-poly1305@openssh.com",
      "aes256-gcm@openssh.com",
      "aes128-gcm@openssh.com",
      "aes256-ctr",
      "aes128-ctr",
      "aes192-ctr"
    ],
    "mac_algorithms_client_to_server": [
      "hmac-sha2-512-etm@openssh.com",
      "hmac-sha2-256-etm@openssh.com",
      "umac-128-etm@openssh.com"
    ],
    "mac_algorithms_server_to_client": [
      "hmac-sha2-512-etm@openssh.com",
      "hmac-sha2-256-etm@openssh.com",
      "umac-128-etm@openssh.com"
    ],
    "compression_algorithms_client_to_server": [
      "none",
      "zlib@openssh.com"
    ],
    "compression_algorithms_server_to_client": [
      "none",
      "zlib@openssh.com"
    ],
    "languages_client_to_server": [

    ],
    "languages_server_to_client": [

    ],
    "dns_keys": null,
    "duplicate_host_key_ips": [

    ],
    "compliance": {
      "policy": "Mozilla Modern",
      "compliant": false,
      "recommendations": [
        "Add these MAC algorithms: hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com"
      ],
      "references": [
        "https://wiki.mozilla.org/Security/Guidelines/OpenSSH"
      ],
      "grade": "B"
    },
    "start_time": "2020-01-09 17:41:36 +0000",
    "end_time": "2020-01-09 17:41:36 +0000",
    "scan_duration_seconds": 0.3120125,
    "error": "could not settle on hmac_client algorithm"
  }
]

[claudijd]

@axi0m you are right, these should probably behave in a fuzzy match sort of situation when we end up with similar ciphers. Truth be told, the matching is still quite crude to be an exact string match against policy. So, in that respect, it's not as fluid or "smart" as I think I'd like it to be long term. That said, policy requirements can be provided in a custom way from the ssh_scan binary, though few people use that feature. I'll see if I an provide an example of how that would look shortly and you can tell me if that helps at all.

[claudijd]

The existing policy default is to use this policy config (https://github.com/mozilla/ssh_scan/blob/master/config/policies/mozilla_modern.yml) when running ssh_scan. However, you can basically make your own to match expectation. Admittedly, these features serve different target groups, where as the defaults are just a good start for say testers, but the custom policies are pretty good for places where you have a strong devops presence and you're mapping that to a known specific config and trying to hold it there. I'll work up an example policy.

[claudijd]

Ok, so here's an example of an etm mac only custom policy you could offer the ssh_scan binary at command-line...

https://github.com/mozilla/ssh_scan/pull/515

[claudijd]

./bin/ssh_scan -t ssh.mozilla.com -P config/policies/just_etm_macs.yaml

[axi0m]

@claudijd I forgot to consider just using my own policy!

Thanks for your quick response, example and PR'ing a new example policy. 🙇 👊

[axi0m]

I just ran the command you suggested after pulling the latest docker image and works like a charm.

[claudijd]

You also got me thinking we should do more of this to sort of keep the policies from stagnating and allow folks to contribute whatever examples they like so they can be shared and help support the defaults.

https://twitter.com/claudijd/status/1215647900077871104

[claudijd]

The reference element in the schema could also be used to back-ref to someone's blog or whatever to help justify the decisions that brought them to said policy. I think more open talk about this would really help and help spur things a bit.