Table of Contents
Linux Anti-Patterns
Return to Linux Best Practices, Best Practices, Anti-PatternsCloud Monk's Development PC DevOps Automation via Ansible-Chocolatey-PowerShell-Homebrew-DNF-APT
Anti-patterns Original author: Tommy Nguyen Linux
Whether you are a system administrator or developer, practicing good infosec hygiene is important. Downplaying the importance of security, whether due to apathy or simply thinking it’s too expensive, can be costly in the long run. This article is meant to briefly touch on some general practices you should follow and is not meant to be a comprehensive guide.
Not using HTTPS
There is no reason not to use HTTPS in 2019. Services like Cloudflare and Let’s Encrypt offer certificates for free and are easy to deploy SSL. For Cloudflare, the only thing that’s required is to add some DNS records and enable universal SSL (with some caveats if you intend on using CloudFlare Full (Strict)). Let's Encrypt has easy-to-use clients like certbot that will handle issuing SSL certificates, revocation of SSL certificates and renewal of SSL certificates with minimal interaction.
If you are concerned about SSL speed, see https://istlsfastyet.com. (TLS performance)
For a list of common complaints and rebuttals, see https://doesmysiteneedhttps.com.
If your complaint is that Let’s Encrypt doesn’t provide Extended Validation Certificates, see Extended Validation Certificates are Dead by Troy Hunt.
There are still some anti-patterns that can limit the usefulness of HTTPS:
Insecure requests
If your page redirects HTTP to HTTPS or if you are loading resources that are HTTP only, your page is still vulnerable. Ideally, you should combine HTTP Strict Transport Security and Content Security Policy. For example, a page which links to a form via HTTP (even if the final destination is HTTPS) is suspectible to a MITM attack. Mixed content (loading resources with HTTP even on a HTTPS site) is also an attack vector. Ensure that you do not allow HTTP requests and that you whitelist assets to mitigate the damage an attacker can do. At a minimum, your CSP should include upgrade-insecure-requests and disallow unsafe-inline.
Using insecure ciphers
Allowing insecure ciphers in your suite can expose your users to different types of attacks. There is a trade-off between security and compatibility (and the cipher suite shipped with nginx by the default enables some insecure ciphers). See Mozilla’s Server Side TLS article for a cipher suite that prefers strong ciphers while also taking compatibility into account.
Consider dropping support for obsolete platforms. badssl will test your browser for support for various features.
Consider scanning your server using a third party service like testssl.
Note
Password security
Password security: Some anti-patterns related to password security include:
Using deprecated hashing functions
Using deprecated hashing functions:
It goes without saying that you should not be using md5 and sha1 to hash your passwords. While sha256 and sha512 are superior, you should be using a strong hashing function or key derivation function that employs key stretching (the practice of iteratively applying a hashing function) and salting. Both properties will make password hashes more resistant to bruteforcing. For example, bcrypt does this out of the box without need for extra configuration, however key derivation functions like Argon2 and PBKDF2 are also popular choices. [1] [2]
For services like SMTP, XMPP or PostgreSQL, you should attempt to use SCRAM-SHA1. SCRAM uses PBKDF2 under the hood and is strongly preferred to DIGEST-MD5. The other advantage of this mechanism is that users do not have to store their passwords in plain-text locally.
Arbitrary password lengths
If you are storing passwords hashed (which you should), then there is little reason to limit the length of passwords. By definition, hash functions will take an input of arbitrary length and output a string of fixed length. If a site caps password length to a small value (usually something like 16 characters), there is a high probability they are storing passwords in plain-text. However, it is reasonable to cap the password length to something moderately high (like 512 characters) to mitigate denial-of-service attacks. [3]
Client-side hashing
It is our opinion that client-side hashing does not add any additional security. The hashed password simply becomes the new password. While one can argue that it obfuscates the original password (since password reuse is rampant), a more effective strategy is to educate users to use password managers and to not reuse passwords across services. There are a few problems with client-side hashing:
The user may have JavaScript disabled for security reasons. It requires that you trust the client (which is always a bad idea). The user or an attacker can simply modify the client side code to do what they wish. It also makes it easier for an attacker to impersonate the user. Note
Disabling mitigations
There’s a site (and general opinion) called https://make-linux-fast-again.com (noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off) making the rounds that recommends disabling all mitigations related to Meltdown, Spectre, MDS, et al. It is our opinion that you should not be following this advice. The kernel documentation has pages on L1TF and MDS that discusses these vulnerabilities in full, the available mitigations and the pros and cons of disabling them. In a nutshell, since some of the mitigations lead to performance degradation, some people are suggesting disabling all mitigations. This is very bad advice.
The most significant performance degradation results from disabling SMT. Due to the trade-off between the loss of performance and the low risk of most users being affected by these vulnerabilities, SMT is on by default. If you care about performance, no further action is needed. Disabling the other mitigations exposes yourself to unnecessary risk for little to no performance gain.
Disabling SELinux
Often you will find advice on setting SELinux to Permissive or Off. The majority of this advice either comes from antivirus vendors or people who do not want to deal with SELinux errors.
It is our opinion that disabling SELinux to allow an antivirus to work is an oxymoron. While SELinux will not prevent malware from running on your computer, it can mitigate privilege escalation vulnerabilities (for example, see CVE-2019-5736). Because anti-viruses require superuser privileges and conflict with SELinux, they ironically open you up to a whole class of vulnerabilities that anti-viruses will not mitigate.
If you receive an AVC denial, then you should either use audit2allow or report the bug for your distro so that the maintainers can fix the policy/module in question. Disabling SELinux wholesale to get an application to work is never the right answer.
Containers
Containers do not provide security, in fact, they can be quite insecure out of the box. Comments suggesting containers as a replacement for SELinux can be found in SELinux is unmanageable; just turn it off if it gets in your way.
In actuality, containers can be combined with SELinux. Similarly, seccomp profiles are often used to limit dangerous syscalls as well. Anyone with access to the daemon socket essentially has root privileges (hence why it’s an antipattern to mount the socket within a container) and Podman is rootless by default.
Footnotes
[1] See How to securely hash passwords?
[2] See AES: Why is it a good practice to use only the first 16 bytes of a hash for encryption?
[3] See What technical reasons are there to have low maximum password lengths?
Fair Use Source
KEEP THIS SHORT!
Continuous Deployment: Deployment with DevOps, IaC - Infrastructure as Code, GitOps, CI/CD, Deployment Pipeline, Installation, Containerization with Kubernetes-OpenShift-Docker, App Deployment on Kubernetes, App Deployment on OpenShift, Package Managers (Choco-Brew-apt-yum-dnf-Snapcraft), Configuration, Configuration Management (Ansible-Chef-Puppet-PowerShell DSC), YAML, Cloud Deployment, HCL-Terraform, Azure Resource Manager Templates (ARM Templates) - Azure Bicep, AWS CloudFormation, Google Cloud Deployment Manager, Configuration, Setup. (navbar_deployment and navbar_deployment_detailed)
Linux: Linux Fundamentals, Linux Inventor: Linus Torvalds says “ Linux just sucks less.”, Linux Best Practices - Linux Anti-Patterns, Linux kernel, Linux commands-Linux Shells-Linux CLI-GNU-Linux GUI-X11, Linux DevOps-Linux development-Linux system programming-Bash-zsh-Linux API, Linux package managers, Linux configuration management (Ansible on Linux, Chef on Linux, Puppet on Linux, PowerShell on Linux), Linux Distros (RHEL-Rocky Linux-CentOS (CentOS Stream)-Oracle Linux-Fedora, Ubuntu-Debian-Linux Mint-Raspberry Pi OS-Kali Linux-Tails, openSUSE - SUSE Linux Enterprise Server (SLES), Arch Linux-Manjaro Linux, Alpine Linux-BusyBox - Slackware - Android-Chrome OS); UNIX-UNIX Distros (FreeBSD-OpenBSD, BSD, macOS), Linux networking, Linux storage, Linux secrets, Linux security (Linux IAM-LDAP-Linux Firewall-Linux Proxy), Linux docs, Linux GitHub, Linux Containers, Linux VM, Linux on AWS, Linux on Azure, Linux on GCP, Linux on Windows (WSL), Linux on IBM, Linux on Mainframe (Linux on IBM Z mainframe - Linux for System z - IBM LinuxONE), Embedded Linux, Linus IoT-Linux on Raspberry Pi, LinuxOps-Linux sysadmin, systemd-userland-kernel space-POSIX-SUS-Linux filesystem-Linux architecture, Linux books-UNIX books, Linux courses, Linux Foundation, Linux history, Linux philosophy, Linux adoption, Linux glossary, Linux topics (navbar_linux and navbar_unix - see also navbar_fedora, navbar_rhel, navbar_centos, navbar_debian, navbar_ubuntu, navbar_linux_mint, navbar_freebsd, navbar_opensuse, navbar_manjaro, navbar_kali_linux, navbar_nixos, navbar_alpine_linux, navbar_tails_linux, navbar_slackware, navbar_rocky_linux, navbar_arch_linux, navbar_oracle_linux)
© 1994 - 2024 Cloud Monk Losang Jinpa or Fair Use. Disclaimers
SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.