Difference between revisions of "Security"

From ArchWiki
Jump to navigation Jump to search
m (→‎Firewalls: According to iptables#Installation, core/iptables is installed by default. Installation is described there anyway.)
Line 323: Line 323:
=== Firewalls ===
=== Firewalls ===
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall.
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.
*See [[iptables]] for general info.
*See [[iptables]] for general info.

Revision as of 07:02, 19 July 2015






Choosing secure passwords

When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or cracked using e.g. brute-force attacks. The tenets of strong passphrases are based on length and randomness. In cryptography the quality of a passphrase is referred to as its Wikipedia:Entropic security.

Insecure passwords include those containing:

  • Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)
  • Simple character substitutions on words (e.g., k1araj0hns0n)
  • Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., DG091101%)
  • Common phrases or short phrases of grammatically related words (e.g. all of the lights), and even with character substitution.

The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random. A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence. Take for instance “the girl is walking down the rainy street” could be translated to t6!WdtR5 or, less simply, t&6!RrlW@dtR,57. This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words (Wikipedia:Letter frequency).

A better approach is to generate pseudo-random passwords with tools like pwgen or apg: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.

It is also very effective to combine these two techniques by saving long, complex random passwords with a password manager, which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).

Also consider the Diceware Passphrase method, using a sufficient number of words.

See Bruce Schneier's article Choosing Secure Passwords or The passphrase FAQ for some additional background. Also, you can check entropy level of your chosen passphrase here, or consulting Wikipedia:Password strength.

Maintaining passwords

Once you pick a strong password, be sure to keep it safe. Watch out for manipulation, shoulder surfing, and avoid reusing passwords so insecure servers cannot leak more information than necessary. Password managers can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like .bash_history). Lastpass is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.



Password hashes

Warning: SHA512 is designed as a fast hash function, not for password hashing. An attacker can brute force a SHA512 hashed password far faster than bcrypt or scrypt allow.


See also Wikipedia:Key stretching.

Enforcing strong passwords using pam_cracklib

pam_cracklib provides protection against Dictionary attacks and helps configure a password policy that can be enforced throughout the system.

Warning: The root account is not affected by this policy.
Note: You can use the root account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.

If for example you want to enforce this policy:

  • prompt 2 times for password in case of an error
  • 10 characters minimum length (minlen option)
  • at least 6 characters should be different from old password when entering a new one (difok option)
  • at least 1 digit (dcredit option)
  • at least 1 uppercase (ucredit option)
  • at least 1 other character (ocredit option)
  • at least 1 lowercase (lcredit option)

Edit the /etc/pam.d/passwd file to read as:

password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow

The password required pam_unix.so use_authtok instructs the pam_unix module to not prompt for a password but rather to use the one provided by pam_cracklib.

You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.




Mount options


Relevant mount options


Potential usage

Partition nodev nosuid noexec
/var yes yes yes [1]
/home yes yes yes, if you do not code, use wine or steam
/dev/shm yes yes yes
/boot yes yes yes


Filesystem permissions


For example:



Disk encryption



Certain programs, like Dm-crypt, allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.

User setup


Lockout user after three failed login attempts




# pam_tally --user --reset


Restricting root


Use sudo instead of su


  • Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user alice access to a particular program:
# visudo
alice ALL = NOPASSWD: /path/to/program





To use nano instead of vi with visudo,

Defaults editor=/usr/bin/rnano


Editing files using sudo


export SUDO_EDITOR=rvim


Restricting root login


Allow only certain users

The PAM pam_wheel.so lets you allow only users in the group wheel to login using su. Edit both /etc/pam.d/su and /etc/pam.d/su-l, then uncomment the line:

auth		required	pam_wheel.so use_uid


Denying ssh login


Mandatory access control


Pathname MAC


  • AppArmor is a Canonical-maintained MAC implementation seen as an "easier" alternative to SELinux.

Role-based access control


  • Grsecurity RBAC has a learning mode like AppArmor for easy configureation
  • Grsecurity RBAC does not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.

Labels MAC



Access Control Lists



Kernel hardening

Restricting access to kernel logs

The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The kernel.dmesg_restrict flag was to forbid access to the logs without the CAP_SYS_ADMIN capability (which only processes running as root have by default).

kernel.dmesg_restrict = 1

Restricting access to kernel pointers in the proc filesystem

Enabling kernel.kptr_restrict will hide kernel symbol addresses in /proc/kallsyms from regular users without CAP_SYSLOG, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some perf commands when used by non-root users (but many perf features require root access anyway). See FS#34323 for more information.

kernel.kptr_restrict = 1

Keep BPF JIT compiler disabled

The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The net.core.bpf_jit_enable flag should be left at 0 for a maximum level of security.

This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.

Note: grsecurity includes JIT hardening for the BPF JIT compiler, greatly reducing the risk of exploitation.

ptrace scope

Arch enables the Yama LSM by default, providing a kernel.yama.ptrace_scope flag. This flag is enabled by default and prevents processes from performing a ptrace call on other processes outside of their scope without CAP_SYS_PTRACE. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.

Note: In grsecurity, this protection is toggled via the kernel.grsecurity.harden_ptrace flag instead.

Examples of broken functionality

Note: You can still execute these commands as root (such as allowing them through sudo for certain users, with or without a password), or enable ptrace selectively through setcap cap_sys_ptrace=eip /path/to/program.
  • gdb -p $PID
  • strace -p $PID
  • perf trace -p $PID
  • reptyr $PID


The kernel has the ability to hide other users' processes from unprivileged users by mounting the proc filesystem with hidepid=1 or hidepid=2. This needs some additional configuration because polkit and logind need to be exempt from hidepid.

gpasswd -a polkitd proc
mkdir /etc/systemd/system/systemd-logind.service.d

Then create the following file:


Then add the following line to /etc/fstab:

proc            /proc   procfs  hidepid=2,gid=proc 0    0


The grsecurity kernel provides many security-related improvements. It hardens both the kernel and userspace against common memory corruption vulnerabilities, along with providing many miscellaneous features and a role-based access control system. It is the only way to secure the kernel itself against exploitation, which is the most important improvement for a system already making good use of user isolation, containers/chroots and sandboxes.

Network and Firewalls



Kernel parameters



Avoid using Secure Shell without requiring SSH keys. This prevents brute-force attacks. Alternatively Fail2ban or Sshguard offer lesser forms of protection by monitoring logs and writing iptables rules but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.



See DNSSEC and DNSCrypt.

Authenticating packages


Physical security


Physical access to a computer is root access given enough time and resources. However, a high practical level of security can be obtained by putting up enough barriers.

An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[2] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.

#Disk encryption will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.

Locking down BIOS





Syslinux supports password-protecting your bootloader. It allows you to set either a per-menu-item password or a global bootloader password.


GRUB supports bootloader passwords as well. See GRUB/Tips and tricks#Password protection of GRUB menu for details. It also has support for encrypted boot partitions, which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, kernel and initramfs are encrypted.

Denying console login as root





Automatic logout

If you are using Bash or Zsh, you can set TMOUT for an automatic logout from shells after a timeout.

For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):

case $( /usr/bin/tty ) in




See also