Lack Of Security Guides / Recommendations For Off-Chain Attacks

[bonedaddy]

Problem

The off-chain attacks section is pretty cool, and not something a lot of people consider. However the google sheets does not really mention any resources, guides, etc.. to combat against this. So I've provided some below:

Container Security

Docker has a number of features which can be used to help mitigate, and contain the damage from container escapes. This includes things like apparmor, seccomp, etc.. For example a really good thing to add to all your docker compose files is the following:

    read_only: true
    restart: always
    security_opt:
      - apparmor:docker-default
      - seccomp=/home/foobar/seccomp_default.json
      - no-new-privileges
    tmpfs:
       - /tmp

There more you can do, so i've listed some resources below:

• https://docs.docker.com/engine/security/rootless/
• https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#introduction
• https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
• https://docs.docker.com/engine/security/userns-remap/#enable-userns-remap-on-the-daemon

SSH Security

Somewhat a followup to #11, so some simple recommendations:

• disable root ssh access
• disable password ssh access
• enable public key ssh access
• enable 2fa based ssh

I use the following script to bootstrap 2FA ssh on all new servers, etc..

#!/bin/bash

# references
# https://www.digitalocean.com/community/tutorials/how-to-configure-multi-factor-authentication-on-ubuntu-18-04
# https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04

# we use nullok so that we dont brick ourselves if we havent configured 2fa before running this


sudo apt install libpam-google-authenticator

# enables 2fa for ssh
echo "auth required pam_google_authenticator.so nullok" | sudo tee --append /etc/pam.d/sshd
# enables 2fa for login and sudo requests
echo "auth required pam_google_authenticator.so nullok" | sudo tee --append /etc/pam.d/common-auth
echo "[WARN] if you want to enable 2fa for desktop environments make sure to edit '/etc/pam.d/gdm' or similar"
# this makes ssh aware of ssh
echo "AuthenticationMethods publickey,password publickey,keyboard-interactive" | sudo tee --append /etc/ssh/sshd_config
# enable challenge response
sudo sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
sudo systemctl restart sshd

echo "please comment out '@include common-auth' in /etc/pam.d/sshd to disable password prompts"
echo "[INFO] please run the google-authenticator command"

Beyond the above here are some resources

• https://www.ssh.com/academy/ssh/config
• https://linux-audit.com/audit-and-harden-your-ssh-configuration/
• https://man.openbsd.org/sshd_config

Developer Workstation Security

Developer workstation security is super important, if your workstation is compromised the ability to pivot to other attacks will be greatly increased.

Windows

💀

Mac OSX

🤷

Linux

• https://madaidans-insecurities.github.io/guides/linux-hardening.html

[sambacha]

Problem

The off-chain attacks section is pretty cool, and not something a lot of people consider. However the google sheets does not really mention any resources, guides, etc.. to combat against this. So I've provided some below:

Container Security

Docker has a number of features which can be used to help mitigate, and contain the damage from container escapes. This includes things like apparmor, seccomp, etc.. For example a really good thing to add to all your docker compose files is the following:

    read_only: true
    restart: always
    security_opt:
      - apparmor:docker-default
      - seccomp=/home/foobar/seccomp_default.json
      - no-new-privileges
    tmpfs:
       - /tmp

There more you can do, so i've listed some resources below:

• docs.docker.com/engine/security/rootless
• cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#introduction
• moby/moby@master/profiles/seccomp/default.json
• docs.docker.com/engine/security/userns-remap/#enable-userns-remap-on-the-daemon

SSH Security

Somewhat a followup to #11, so some simple recommendations:

• disable root ssh access
• disable password ssh access
• enable public key ssh access
• enable 2fa based ssh

I use the following script to bootstrap 2FA ssh on all new servers, etc..

#!/bin/bash

# references
# https://www.digitalocean.com/community/tutorials/how-to-configure-multi-factor-authentication-on-ubuntu-18-04
# https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04

# we use nullok so that we dont brick ourselves if we havent configured 2fa before running this


sudo apt install libpam-google-authenticator

# enables 2fa for ssh
echo "auth required pam_google_authenticator.so nullok" | sudo tee --append /etc/pam.d/sshd
# enables 2fa for login and sudo requests
echo "auth required pam_google_authenticator.so nullok" | sudo tee --append /etc/pam.d/common-auth
echo "[WARN] if you want to enable 2fa for desktop environments make sure to edit '/etc/pam.d/gdm' or similar"
# this makes ssh aware of ssh
echo "AuthenticationMethods publickey,password publickey,keyboard-interactive" | sudo tee --append /etc/ssh/sshd_config
# enable challenge response
sudo sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
sudo systemctl restart sshd

echo "please comment out '@include common-auth' in /etc/pam.d/sshd to disable password prompts"
echo "[INFO] please run the google-authenticator command"

Beyond the above here are some resources

• ssh.com/academy/ssh/config
• linux-audit.com/audit-and-harden-your-ssh-configuration
• man.openbsd.org/sshd_config

Developer Workstation Security

Developer workstation security is super important, if your workstation is compromised the ability to pivot to other attacks will be greatly increased.

Windows

💀

Mac OSX

🤷

Linux

• madaidans-insecurities.github.io/guides/linux-hardening.html

First, thank you for the thoughtful post.

A lot of what you are saying makes 100% sense. Though this also begs a question: should wreassesses our approach when given the context of properly configuring the application?

For example, we actually use a container os called Talos, you can read more about it here. There is no SSH. Its completely configured via API. It adopts the 'Least Functionality' approach.

Implementing a least functionality approach you can model the applications based on activities they should be performing and deny the activities they should not be performing. Read more about the 'Least Functionality' approach from Bedrock Systems blog post.

I will add your notes, I just need one thing from you, how you would like to be referenced for attribution? Email? GitHub user name?

Also, the google sheet is no longer updated, I am actually starting to refactor all of. this into the Open Source Vulnerability format. The only reason why I did not have it originally machine readable is because MITRE's ATTCK format is way to complicated. This can potentially also bleverageded fonotifyingng downstream subscribers ovulnerabilitieses / new CVEs relevant to them. Often if people know about a potential risk, they will be more likely to act on it.

If you have any recommendations / suggestions, would gladly welcome them!

Cheers!