Tag Archives: security

User, Group and Password Management on Linux and Solaris

This article will cover the user, group and password management tools available on the Linux and Solaris Operating Systems. The specific versions covered here are CentOS 6.4 and Solaris 11.1, though the commands will transfer to many other distributions without modifications (especially RHEL and its clones), or with slight alterations to command options. Check your system documentation and manual pages for further information.

Knowing how to manage users effectively and securely is a requirement of financial standards such as PCI-DSS, and information security management systems such as ISO 27001.

In this article, I will consider local users and groups - coverage of naming services such as NIS and LDAP is beyond its scope but may be covered in a future article. This article also presumes some prior basic system administration exposure with a UNIX-like operating system.

Continue reading

Securing the Oracle Solaris 11 Operating System

Solaris 11 is the latest Operating System in the Solaris server OS range from Oracle, previously Sun Microsystems. It incorporates many features from Solaris 10 such as the Service Management Framework, but also pulls a lot from the now defunct OpenSolaris project including a new packaging system and a whole new suite of *adm administrative commands to configure the operating system.

This article will cover security configuration of the OS after a standard text-based installation. I’m using Solaris 11.1 x86_64 running as a VMware Fusion guest, but almost all of the steps will be applicable for the SPARC architecture too.

Continue reading

Securing and Hardening the Linux Operating System

Any application is only as secure as the operating system hosting it. Whilst most servers are protected behind firewalls with the main avenue of exploit being the application, if an application is exploited and the user did manage to obtain server access, we need to minimise the damage that can be done to the exploited machine and others. Running hardened systems is a requirement of certain data security standards such as PCI-DSS (PCI Application Data Security Standard), as well as mandated by many organisations. Plus, it is just good practice. Out-of-the-box, most modern OSes are configured to be secure. There is still a great deal we can do, however, to further harden the operating system to various vectors of attack.

This article will only cover the core aspects of Linux OS lockdown, and will focus on CentOS 6.4. Most of the concepts here should be able to be ported to other flavours, using the appropriate commands for your OS.

For further detail, consult the security benchmarks available at http://cisecurity.org. You should employ multiple layers of security within your architecture – for example, using network-based firewalls as well as host firewalls, writing secure code, ensuring that all aspects of the application stack are patched and up-to-date, etc. Hardening the OS is just one more layer of security.

Continue reading

Securing DNS and Web Servers

In this introductory article, I will present several methods for helping to secure DNS and Web Servers. I am using BIND 9.9.4 and Apache HTTPD 2.4.6 on CentOS 6.4. BIND and HTTPD are by far the most common DNS and Web Server platforms. I will show how to build the software from source, as well as perform an initial secure configuration. I will presume a minimal installation of CentOS 6.4. If you’re using another Linux or UNIX variant, you will need to adjust the procedures accordingly. This article presumes that the reader is already familiar with DNS and Web Servers, particularly BIND and HTTPD.

Fully hardening these services is a very complex subject and we only touch on the major aspects of configuration below.

Continue reading

Using rsync to Synchronise Two Directories Securely

rsync is a utility that provides fast incremental file transfer. This allows us to keep directories and files synchronised between servers whilst only transferring the minimum required data. This is often employed during code deployment scenarios from one environment to another.

It is preferable to use the -e option to specify a remote shell to use, namely ssh. This will ensure that the file transfers are encrypted and performed over SSH.

In our deployment scenario there are two servers, venus and earth. Both are webservers, and have content at /var/www/example.com/htdocs. venus is our test server, and earth is production. We’d like to deploy our content from venus to earth. This deployment could be automated (think continuous integration), or even scripted for simple deployments, but for the purposes of this tutorial we’ll just manually issue the commands as required. This is being performed on CentOS 6.4 with SELinux enabled.

I’ll start off by creating some simple “content” on venus:

On earth, I’ll just create the empty content directory:

Create a user/group on both servers that will be used for deployment. deploy@venus will allow interactive logins to push content to deploy@earth. deploy@earth will only allow the specific remote-side rsync command to run. This will be defined later in ~/.ssh/authorized_keys. For now, just create the users and groups:

Set ownership on our deployment directories. Do this on both servers:

It is obvious that any permissions set here should not interfere with the way your web server actually serves its content. You may need to set up ample group permissions for the deploy group, then add the webserver user to that group.

The first step in setting up our file syncronisation is to configure password-less SSH login from deploy@venus to deploy@earth. Having no passphrase on the SSH key we’re about to create is the reason for limiting command access via ~/.ssh/authorized_keys.

Start with key generation as deploy@venus:

As you can see, a 2048-bit RSA key has been generated.

Next, create ~/.ssh on earth, and copy the public key to deploy@earth:.ssh/authorized_keys:

On earth, we now need to fix SELinux contexts and permissions on deploy@earth:

We can now check that password-less SSH is working:

Next, we can use rsync to perform a dry-run of our deployment with the --dry-run option. Specifying the -v option twice shows the remote command that will be executed:

The remote command can be seen above - rsync --server -vvnlogDtprCze.iLs . /var/www/example.com/htdocs. We can populate deploy@earth:.ssh/authorized_keys with this command against deploy@venus‘s public key in the file, limiting deploy@venus to ONLY be able to execute the remote rsync command. We need to drop one of the -v‘s and -n (--dry-run) from the remote command too. Modify deploy@earth:.ssh/authorized_keys as appropriate:

Note that I also add the from= configuration parameter so that only connections from venus are permitted. Now, the password-less SSH configuration is locked down so that any connections from deploy@venus can only run the remote rsync command.

Test from deploy@venus:

Running the command again should not transfer any changes (as there haven’t been any):

And we can now verify that earth has the files:

 

Installing chroot()ed BIND - Ubuntu 12.04 Server

This HOWTO will cover how to configure chroot()ed BIND under Ubuntu 12.04 Server. We want to chroot() BIND for security reasons - having software operate out of chroot() jails closes an avenue for exploit. I will be configuring a chroot() of /var/chroot/named.

First, install the bind9 and dnsutils packages. The former will provide the BIND software itself, whilst dnsutils provides utilities such as dig and nslookup that can be used to perform queries or troubleshoot your installation:

This will give us BIND 9.8.1-P1 at the time of writing this article:

It will also start BIND - so shut it down before proceeding:

Modify /etc/default/bind9. This file contains an OPTIONS variable whose contents are passed as options to named when it’s started. Add the -t option - which specifies the path to the chroot() jail:

Create the appropriate directories for the chroot() tree:

Move the default BIND configuration files to the chroot(), maintaining a symlink to the original location:

Create the null and random devices under the chroot(), and fix permissions:

Change ownership of the chroot() to the appropriate user and group, in our case bind:bind:

libgost.so from openssl-1.0.0 needs to be available under the chroot(), so create a bind mount for it. Add the folllowing to /etc/fstab:

Create the mountpoint under the chroot(), and mount:

We’ll need to create a syslog socket inside the chroot() so that BIND can find /dev/log where it expects it to be. Create /etc/rsyslog.d/60-bind-chroot.conf as follows:

The final step is to update our AppArmor configuration to allow reads and mmap calls on libgost.so, and reads on the BIND configuration files. Update the local AppArmor configuration as follows:

Reload the AppArmor profiles:

Now, we can start our chroot()ed BIND

and test:

 

How to Generate a Hashed Password

Another OpenSSL related tip.

If you’ve ever wanted to generate a hashed password suitable for inclusion in the /etc/shadow file (for example, during post-install procedures such as sysidcfg), you can use the openssl passwd command:

Security: Replacing a Digital Certificate within a Java Keystore

Some notes I prepared whilst renewing a certificate stored in a Java keystore: