Category Archives: Security

PAM authentication per application (Debian 8 Jessie)

PAM is the default authentication mechanism in Linux. It is very flexible and powerful, and even allows you to configure different authentication options for each application. In this example we will use the PAM module "pam_listfile" which is already included in the standard package "libpam-modules".

The application name has to match the name of the file under /etc/pam.d . So for example for application "abc" you have the following PAM configuration file /etc/pam.d/abc :

auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/group.allow
@include common-auth
@include common-account
@include common-password
@include common-session

The first line only authenticates users that are member of any group listed in /etc/group.allow. The contents of /etc/group.allow may only contain a single line and looks like this:

abc_group

This will allow only members of the group "abc_group" to login to application "abc". After adding the new configuration files, make sure to always test your PAM settings with pamtester:

# id bob
uid=1003(bob) gid=1003(bob) groups=1003(bob)
# pamtester abc bob authenticate
Password: 
pamtester: Authentication failure
# usermod -aG abc_group bobpamtester abc bob authenticate
Password: 
pamtester: successfully authenticated

First the user "bob" is not member of the group "abc_group". pamtester fails to authenticate the user even if you provide the right password. Then after adding "bob" to the group "abc_group" authentication succeeds.

 

Share

Certificate Authorities (CA) in Google Chrome / Chromium and Firefox on Linux

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is the list of all root CAs included in Firefox along with their fingerprints:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Builtin root CAs are hardcoded in /usr/lib/firefox/libnssckbi.so . You can see a list of all CAs in Firefox preferences (advanced settings).

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d $HOME/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:
https://www.chromium.org/Home/chromium-security/root-ca-policy

In Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so which is part of the package "libnss3". You should therefore update this package as soon as there is an update available to keep your builtin CA list up-to-date.

CAs that are not builtin and that you installed manually are stored in your home directory:
certutil -d sql:$HOME/.pki/nssdb -L

Important things to note:

  • The security of SSL encrypted websites (https://...) depends on the root CA which is used to sign the website certificate. These CAs are stored locally on your device in different locations based on the browser you are using.
  • There are 2 kinds of CAs:
    1. Builtin CAs that ship with your browser or linux installation. They are stored in shared object files. There is probably no easy way to edit this list unless you change the source files and recompile the package. Nevertheless in both browsers you can remove all trust from a builtin certificate which is basically the same as deleting it.
    2. Manually added CAs are stored in your home directory. You can easily edit that list within the settings of the browser or on the command line.
  • Both Firefox and Chromium / Google Chrome use NSS certificate databases to store manually added CAs that are not builtin. But they use different directories. Maybe you could use symbolic links to point both directories to the same database. That way both browsers would be using the same manual CA list.Currently Firefox uses by default the legacy dbm database version (cert8.db, key3.db) and Chromium / Google Chrome uses by default the new SQLite database version (cert9.db, key4.db). There seems to be an environment variable NSS_DEFAULT_DB_TYPE that makes Firefox use the new SQLite database version as well (s. https://wiki.mozilla.org/NSS_Shared_DB_Howto).
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".
Share

Password encryption in OpenLDAP

Passwords in OpenLDAP are SSHA encrypted by default (Salted SHA1).

Changing it to SHA512 (salted with 16 Bytes):

olcPasswordHash: {CRYPT},{SSHA}
olcPasswordCryptSaltFormat: "$6$%.16s"

Or if you want to increase the number of rounds:

olcPasswordHash: {CRYPT},{SSHA}
olcPasswordCryptSaltFormat: "$6$rounds=2000000$%.16s"

This will still accept already existing passwords that are SSHA encrypted. New or changed passwords will be SHA512 encrypted. The max. number of rounds is 9 999 999. This increases computational time to create a password hash in order to prevent brute force attacks.

For this to work, the GNU C library has to support SHA512:
- /etc/login.defs: ENCRYPT_METHOD SHA512
- man pam_unix (should include sha512)

Also OpenLDAP has to be compiled with crypt support (--enable-crypt).

SHA512 passwords for LDAP can be generated with slappasswd:

slappasswd -c '$6$%.16s'

Important things to note:

  • OpenLDAP provides its own native SHA-2 password module supporting SHA512, but that one lacks support for modifying rounds.
  • OpenLDAP also provides a module for the key derivation function PBKDF2. Currently there are no reliable sources on the internet which suggest that PBKDF2 is more secure than salted SHA512 with rounds.
  • The next step up would be using key derivation function scrypt or Argon2 because they impose much higher requirements on memory.

Share

Secure download of RHEL ISO installation images

You will probably download the RHEL ISO image from within the Red Hat Customer Portal and therefore use an encrypted HTTPS connection (download URL is https://access.cdn.redhat.com/...). The SHA-256 checksums for the ISO images are on the download page.

Red Hat also provides a page with all GPG keys they use for signing their software packages. In Customer Portal, go to "Security" -> "Product Signing (GPG) Keys)" (https://www.redhat.com/security/team/key/)

There are download links for the public keys (https://www.redhat.com/...). The keys are also available on the keyserver pgp.mit.edu . So you can use the following command to import the main Red Hat key into your GPG keyring:

# gpg --recv-keys fd431d51
# gpg --fingerprint -k fd431d51

Compare the fingerprint of the Red Hat public key with the fingerprint on the Customer Portal website. You cannot use the GPG key for verifying the ISO files, but it is useful for e.g. verifying RPM package updates that you can download directly from Red Hat websites and that are not installed the usual way via an official yum repository.

 

Share

HSTS with Apache and Chrome

  • HSTS (HTTP Strict Transport Security) prevents your browser from visiting a website over an unencrypted "http://..." url. Instead you have to use the encrypted "https://..." url, otherwise your browser refuses to load the website.
    Either the webserver of the website you are visiting suggests the use of HSTS to your browser by sending an additional HTTP header, or you manually configure a certain website yourself in your browser.
  • Apache requires the module mod_headers to make the necessary changes to the HTTP headers.
  • Add this to your Apache vhost configuration:
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    For a description of all options see RFC: https://tools.ietf.org/html/rfc6797#section-6
    The "preload" option is not part of the RFC. It just signals that you want your site to be added to the browser builtin list of HSTS sites (see below). If you do not plan to get listed, you may omit this option.
  • Visit the site at least once using HTTPS in your Chrome browser ("trust on first use"). The HSTS configuration of the site (provided by the Apache STS header) will be added to an internal Chrome list. HSTS really depends on this internal browser list. Webservers only send an additional HTTP header that webbrowsers may or may not honor.
  • Add, delete or check websites in your Chrome browser:
    chrome://net-internals/#hsts
    Changes take place immediately without having to restart Chrome.
    You can add sites even if they don't send the special STS header.
    You can combine those entries with PKP (Public Key Pinning) by providing fingerprints for all accepted public keys of a website.
  • Chrome ships with a builtin list of sites that require HSTS. If you run a large public website, you might want to get included in that list: https://hstspreload.appspot.com/
    These builtin sites get listed as "static_..." in your internal Chrome browser list. All other sites (added manually or by honoring the STS header) get listed as "dynamic_...".
  • You cannot delete site entries from the builtin list (assuming that you use the official Chrome browser and that it has not been manipulated).
  • This is the message you get in Chrome when HSTS is violated on a website (in this case the certificate of www.rolandschnabel.de has expired and therefore Chrome refuses to establish the HTTPS connection):
You cannot visit www.rolandschnabel.de right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

Important things to note:

  • Even for HSTS enabled sites, you may still be able to type in the "http://..." URL in the browser address bar. Chrome automatically recognizes the URL and redirects you to the corresponding "https://..." URL.
    This is different from traditional HTTP redirects, because no unencrypted traffic is sent over the network. The redirection already takes place in the browser.
    The downside of this behaviour is that it makes it hard for people to identify if a website is using HSTS or simply redirects all traffic from HTTP/port 80 to HTTPS/port 443 (HTTP status codes 3xx).
  • Many browser plugins now offer the same functionality (redirect some or all website addresses to HTTPS URLs).
  • Maybe some day HTTPS URLs become the default in webbrowsers. If you type a URL in the address bar, or select a URL without the leading "http(s)://", the browser first redirects you automatically to the HTTPS URL. Only if there is no connection possible, you will receive a warning message and get redirected to the HTTP URL. Let's make HTTPS the default in browsers and accept HTTP only for a small number of exceptions.
    No green lock icon for SSL encrypted websites, just red unlock icons for unencrypted websites.

 

Share

Secure download of Ubuntu ISO installation images

Please follow the instructions on this page:
https://help.ubuntu.com/community/VerifyIsoHowto

There is another website, but it doesn't use SSL / HTTPS:
http://www.ubuntu.com/download/how-to-verify

The procedure is the same as I have already described for CentOS or Debian in my previous posts:

  1. Import the GPG-key and verify its fingerprint.
  2. Download the checksum file and verify its signature with the GPG-key.
  3. Check the iso file with the checksum file.

Again the fingerprint of the GPG-key is on a SSL encrypted website where you have to check the website certificate and its root CA.

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is a list of all root CAs included in Firefox along with their fingerprints:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Builtin root CAs are hardcoded in /usr/lib/firefox/libnssckbi.so

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d ~/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:
https://www.chromium.org/Home/chromium-security/root-ca-policy

On Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so which is part of the package "libnss3".

Important things to note:

  • Verification of ISO images is based on GPG-keys which have to be checked by its fingerprints. You can get that fingerprint from a SSL secured website.
  • The security of a website depends on the root CA which is used to sign the website certificate. These CAs are stored locally in different locations based on the browser you are using.
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".
Share

Secure download for CentOS 7

The basic idea  for downloading a CentOS 7 installation image in a secure way is this:

  1. Download the CentOS public key from a public keyserver.
  2. By using that key you can verify the signature of the checksum file of the CentOS ISO image.
  3. With the checksum file you check the downloaded ISO image to see if it is the original file and has not been changed or tampered with.

[CentOS Public Key]  ->  [Signature of checksum file]  ->  [ISO image]

Here are the steps to take:

0. Most important: Make sure to follow this procedure on a computer that is secure and that you fully trust. Otherwise all of the following steps are pretty much useless.

1. Download the CentOS 7 public key:
gpg --search-keys --keyserver-options proxy-server=http://proxy.local.example:8080 F4A80EB5
(or without using a proxy server: gpg --search-keys F4A80EB5)
Accept the key by typing "1". If there was no key found, try using a specific keyserver with the "--keyserver" option". By default gpg uses "keys.gnupg.net".

Make sure the key has really been imported into your public gpg keyring
gpg --fingerprint -k

The "--fingerprint" option shows the fingerprint of the just imported key. Compare it with the fingerprint on the official CentOS website: https://www.centos.org/keys/
Make sure to double check the SSL certificate of that website in your browser.

2. Download the checksum file for the DVD image. It contains checksums for a large variety of CentOS ISO images:
wget http://buildlogs.centos.org/rolling/7/isos/x86_64/sha256sum.txt.asc

Check the validity of the checksum file:
gpg --verify sha256sum.txt.asc

3. Check the validity of the downloaded ISO image file:
sha256sum -c centos-sha256sum.txt.asc

Share

Security check for Apache 2.4 webserver (TLS)

You can use nmap to show what kind of ciphers your webserver is supporting.

List all supported protocols and ciphers of a webserver:
nmap --script=ssl-enum-ciphers -Pn -p 443 www.local.example

Set the following configuration options in you Apache server config:

SSLEngine on
SSLOptions +StrictRequire
SSLHonorCipherOrder on
SSLProtocol all -SSLv3

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache "shmcb:/..."   (requires mod_socache_shmcb)
SSLSessionTickets off

SSLStrictSNIVHostCheck on

To get a list of all protocols and ciphers that your webserver supports you can use nmap:
$ nmap --script=ssl-enum-ciphers -Pn -p 443 mailserver.local.example

Share

Create a self-signed certificate for ip address

openssl.conf:

[req]
default_bits = 4096
distinguished_name = req_distinguished_name
req_extensions = v3_ca
x509_extensions = v3_ca

[req_distinguished_name]
countryName = Country
countryName_default = GB
countryName_min = 2
countryName_max = 2
localityName = Locality
localityName_default = London
organizationName = Organization
organizationName_default = Roland Ltd.
organizationalUnitName = OU
organizationalUnitName_default = Roland-OU
commonName = CN
commonName_default = 192.168.12.122
commonName_max = 64
emailAddress = Email
emailAddress_default = postmaster@local.example
emailAddress_max = 40

[v3_ca]
extendedKeyUsage=serverAuth
subjectAltName=IP:192.168.12.122

# openssl req -newkey rsa -config openssl.conf -days 32 -x509 -out new.cert -keyout new.key

Add the option "-nodes" to avoid having to type in a password for the private key. You will need this e.g. if you use the certificate for Apache and do not want to type in the private key password every time you restart your webserver.

You also might want to add "-sha512" to make the signature algorithm use the SHA512 digest. Otherwise a reasonable default will be used. For Ubuntu 14.04 (OpenSSL 1.0.1f) the default has already been set to SHA256.

Share