Category Archives: UNIX & Linux How Tos and Tutorials

Configuring Interface Bonding on CentOS/RHEL/OEL 6.x

In my previous article I wrote about configuring configuring network interface bonding under Debian Wheezy. Here, I’ll briefly outline the steps required to get the same configuration running under recent RHEL-flavoured distributions - namely CentOS 6.4 in my case.

I will be bonding eth0 and eth1 into a bond named bond0. Ensure that you’re connected to your host via a console. I’ll be using active-backup (i.e. failover) bonding, but there are other options available - see the Debian article for links to reference material for those.

First, create the ifcfg-bond0 configuration file:

Substitute relevant values as appropriate for your setup. Next, edit/create the ifcfg-eth{0,1} files. Note that these are created as slave interfaces (SLAVE=yes) with bond0 as the master interface (MASTER=bond0):

Note - that if NM_CONTROLLED is set, you should strictly define your HWADDR entries too at this step, for each interface. Configure the bonding module. miimon is the MII link monitoring frequency in milliseconds, {down,up}delay are the times, in milliseconds, to wait before disabling or enabling an interface in the bond (to safeguard against flapping), and should be a multiple of the miimon value. Note that /etc/modprobe.conf is deprecated in CentOS 6.x so an appropriate file should be created under /etc/modprobe.d - in our case, bonding.conf:

To test, manually load the module (and appropriate options - I see many tutorials with a simple modprobe bonding here - you’ll end up with the default bonding mode which is round-robin - not what we want):

And restart networking:

Verify that all is well with ifconfig -a, or more suitably a cat on /proc/net/bonding/bond0:

Reboot the host at the earliest opportunity to verify that all is well after a reboot.

 

 

BIND 10: Upgrading from 1.0.0-rc to 1.0.0 - The Production Release

After many years in development, and many releases (development, alpha, beta, release candidate), ISC have announced the final Production release of BIND 10 1.0.0. My previous article covered the upgrade from 1.0.0-beta to 1.0.0-rc. Aside from a database upgrade (which was clearly logged for our attention) the upgrade was very straightforward.

Let’s see if the upgrade from 1.0.0-rc to 1.0.0 is as easy.

Continue reading →

Shells: ksh Tab Completion

If you are using the public domain version of the Korn Shell (pdksh), you can add the following line to your .kshrc and (providing ENV is set), you will have tab completion in vi mode:

You can see which shell options are currently set by running:

Please note, vi-tabcomplete is an option within the public domain Korn Shell only, and will not work with the “standard” ksh provided by many OS’s. In this case, you’ll have to make do with Esc-\ for filename completion.

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 →

BIND 10: How to Upgrade from 1.0.0-beta to 1.0.0-rc

Today, the first RC of BIND 10 was released. There are some new features that will change how you use my previous articles on this subject. Apart from a slew of bug fixes, there are some functionality changes that will affect both the installation and configuration of BIND 10. The BIND 10 Guide has also been updated to reflect these changes.

The major change of note is:

The previous versions of BIND 10 (I was using 1.0.0-beta previously) would have a master process - bind10. This Boss process was responsible for managing the state of other modules, restarting them when they fail, and so on. bind10 is now a shell script that fires up b10-init. This keeps the module names consistent, and we can now address the module as Init. Thus, a Boss shutdown now becomes Init shutdown, Boss show_processlist becomes Init show_processlist, config add /Boss/components b10-auth is now config add /Init/components b10-auth, and so on.

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 →

Secure MySQL Replication over SSL

MySQL is a popular open-source relational-database management system. One of its core features is replication, and in this article I will be showing how to configure a master and slave MySQL instance, and then configure replication from master to slave over SSL. Encryption will help protect the replication from snooping. This type of replication has many uses, for example: disaster-recovery scenarios whereby the slave can be switched to a master role in the case of a master outage, for performance where all reads can take place on the slave with writes and updates occurring on the master, and so on. Replication can be configured without encryption, but encrypting with SSL is preferred as part of a defence-in-depth strategy - it’s an extra layer of security.

This article already presumes a good working knowledge of MySQL. The master server is centosa with IP address 10.1.1.150, and is running a minimal installation of CentOS 6.4 x86_64. The slave, centosb, is running the same OS and has IP address 10.1.1.151. MySQL will be installed from the latest current stable RPMs available at dev.mysql.com, rather than using the upstream versions. The latest stable version available at the time of writing is 5.6.14.

This article will cover the configuration of an SSL-encrypted replicated environment from scratch - it does not cover the migration of an existing replicated configuration to an SSL-encrypted replicated configuration, or the migration of any existing data to a new slave.

Continue reading →

Knot DNS Server

Introduction

Knot DNS server is a high-performance authoritative-only DNS server which supports all of the key features of the domain name system including zone transfers and DNSSEC. It was developed by the CZ.NIC. Knot DNS is open-source and multi-threaded. Current features include:

  • Full and incremental zone transfers (AXFR/IXFR)
  • Dynamic DNS updates
  • EDNS0 and DNSSEC extensions, including NSEC3
  • Response Rate Limiting
  • NSID
  • TSIG
  • and all of the standard features you’d expect with an authoritative-only nameserver implementation

Knot used to require zone files to be compiled (like NSD), but this requirement was removed as of Knot 1.3.0.

For this article, I’ll be running the latest stable version of Knot, 1.3.3, on CentOS 6.4. The test environment will comprise two hosts - venus (master) on 192.168.122.12 and earth (slave) on 192.168.122.13.

Knot 1.4.0-rc1 was also available at the time of writing which supports experimental DNSSEC auto-signing, so that may be worth checking out if relevant to your needs.

Continue reading →

How to Network Solaris 11 Zones Under VMware or VirtualBox

Whilst playing around with the changes in zone virtualisation technology between Solaris 10 and Solaris 11, I found that all zones now use exclusive IP, not shared. There is a new anet interface type configured via zonecfg that handles this.

This will all be covered in detail in a future article, but for now take a look at this:

I boot my new testzone, and the vnic is automatically created over net0. But net0 is itself a virtual NIC (i.e. VMware or VirtualBox is virtualising this for us in the first place), whilst Solaris obviously sees it as a physical interface.

Inside the new zone, I was unable to ping anything. The zone was not on the network. The fix? Place net0 into promiscuous mode using snoop inside the global zone. This makes sense when you think about it, and will fix your zone networking allowing you to virtualise within your VM:

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: