I’d wager that many people have heard of Snort, and what it does. For those who aren’t familiar with it, it’s an open source intrusion detection system (IDS)/intrusion prevention system (IPS). In a normal configuration, Snort monitors traffic and alerts based on predefined rules for such things as port scans and maliciously-crafted HTTP requests. It’s an extremely powerful tool that is also highly configurable, and with an excellent community that provide custom rules for a wide variety of situations. But alerting is one thing – being able to make sense of those alerts is something else.

Prelude

Prelude is a security information management (or SIM) system – that is, it’s designed to aggregate and correlate events from tools like Snort and provide a centralised place to manage those events. On its own, this is useful, but coupled with a few additional tools it really becomes something else.

The main prerequisite for our setup is to MySQL, so if you don’t already have it installed, go ahead and do so. Most Linux distributions include Prelude in their repositories, so installing it should be pretty straightforward. I use Debian, so once MySQL is installed and working, installing the manager is a case of running the following:-

root@dev-vm-lnxd-01:~# apt-get install prelude-manager

Follow the on-screen debconf prompts regarding the database – one thing to note that I discovered on squeeze is that if I let debconf generate a password for the prelude database user, that password wasn’t written to the prelude configuration. Since debconf doesn’t output the password it’s generated, this means you’ll have no idea of the password. Therefore, I recommend picking a password yourself.

Next, it will generate a 2048-bit RSA key for the manager. This can take a while, and on a quiet server will take a few minutes at least. Generating disk I/O is how I usually increase the amount of entropy for the key generation – running find / >/dev/null works well in this situation I’ve found.

By default, prelude-manager will refuse to start, because it’s disabled in /etc/default/prelude-manager. Edit it, and change RUN=no to RUN=yes. Next make sure that the database configuration in /etc/prelude-manager/prelude-manager.conf is correct – especially regarding my note earlier about auto-generated passwords.

When you’re happy the configuration is correct, start prelude-manager:-

root@dev-vm-lnxd-01:~# /etc/init.d/prelude-manager start

If everything is okay, prelude-manager will start.

Putting it to work

We now have a running prelude-manager instance. But on its own, this is pretty useless – no events are being sent to it, so there’s nothing for it to do. Let’s fix that by installing a sensor – Snort.

Again, installing Snort should be straightforward:-

root@dev-vm-lnxd-01:~# apt-get install snort

As before, follow the debconf prompts. Unlike prelude-manager, snort will be started automatically after install. A quick glance at /var/log/snort will reveal a file named alert and possibly a number of tcpdump.log files. This is how Snort by default saves alerts, with the tcpdump.log files being captures associated with those alerts. But since we’re talking about Prelude, let’s get the alerts sent there.

The first step is to register Snort with prelude-manager, so that prelude-manager knows about it. We can do this with the prelude-admin command:-

root@dev-vm-lnxd-01:~# prelude-admin register "snort" "idmef:w" 127.0.0.1 --uid 106 --gid 106

You’ll notice that I passed the UID and GID of the snort to prelude-admin. By default, the snort has both a UID and GID of 106, but do check this before running it. The other options are the name of the agent (“snort”), the permissions (“idmef:w”) and the IP address of the server running prelude-manager. The name can be anything, as long as this matches the name used in the Snort configuration, and the ‘idmef:w’ refers to the Intrusion Detection Message Exchange Format, and that we want to give Snort write permissions. Finally, because we’re running Snort on the same server as the one running prelude-manager, we use 127.0.0.1 as the host.

root@dev-vm-lnxd-01:~# prelude-admin register "snort" "idmef:w" 127.0.0.1 --uid 106 --gid 106
Generating 2048 bits RSA private key... This might take a very long time.
[Increasing system activity will speed-up the process].
Generation in progress... X..+++++O.+++++O

You now need to start "prelude-admin" registration-server on 127.0.0.1:
example: "prelude-admin registration-server prelude-manager"

Enter the one-shot password provided on 127.0.0.1:

Once again, an RSA key is generated, but this time for the sensor, so now might be a good time to go and make a cuppa. Once the key has been generated, you’ll be prompted (as above) for a ‘one-shot password’ to authenticate it to prelude-manager. At this point, open a new session to the server running prelude-manager and run prelude-manager as directed by the above:-

root@dev-vm-lnxd-01:~# prelude-admin registration-server prelude-manager
The "8qovmgff" password will be requested by "prelude-admin register"
in order to connect. Please remove the quotes before using it.

Generating 1024 bits Diffie-Hellman key for anonymous authentication...
Waiting for peers install request on 0.0.0.0:5553...
Waiting for peers install request on :::5553...

Make a note of the password (in our example, 8qovmgff), switch back to our first session, and provide it at the prompt:-

Enter the one-shot password provided on 127.0.0.1: 8qovmgff
Confirm the one-shot password provided on 127.0.0.1: 8qovmgff

Connecting to registration server (127.0.0.1:5553)... Authentication succeeded.

Switch again to the second session, and accept the registration:-

Connection from 127.0.0.1:40123...
Registration request for analyzerID="2783582516549275" permission="idmef:w".
Approve registration? [y/n]: y
127.0.0.1:40123 successfully registered.

Snort is now registered as an sensor with prelude-manager.

The next step is to tell Snort to send its output to Prelude. Edit /etc/snort/snort.conf, and look for the following line:-

# output alert_prelude: profile=snort-profile-name

Uncomment it, and change the profile name to snort:-

output alert_prelude: profile=snort

Save the config, and restart snort:-

root@dev-vm-lnxd-01:~# /etc/init.d/snort restart
Stopping Network Intrusion Detection System : snort (eth0 ...done).
Starting Network Intrusion Detection System : snort (eth0 using /etc/snort/snort.conf ...done).

Making sense of it all

All being well, Snort should now be sending events to Prelude. But we still don’t have any visibility of these alerts… which is where Prewikka comes in.

Prewikka is a graphical front-end to Prelude – more specifically, to the database that prelude-manager uses. Again, there’s a package in Debian for this, so go ahead and install it:-

root@dev-vm-lnxd-01:~# apt-get install prewikka

As with prelude-manager, follow the debconf prompts regarding database setup. Once completed, Prewikka will have its own database, but you’ll also need to give it the details for prelude-manager’s database. Edit /etc/prewikka/prewikka.conf, and edit the settings under the [idmef_database] section. Save and exit the config, and start Prewikka:-

root@dev-vm-lnxd-01:~# prewikka-httpd &

By default, Prewikka listens on port 8000, so point your browser at http://<server>:8000/. The default username and password is admin and admin, so go ahead and log in. You’ll then be presented with the main event viewer, which should be similar to the screenshot to the right.

Running Prewikka in this way uses its own built-in webserver, but within the package a prewikka.cgi file is provided, which can be served by your favourite webserver of choice as a traditional CGI executable.

Now, before taking the screenshot to the right I cheated a little. I ran a quick nmap against the server to generate some events as an example, but in the absence of any events you can still check that snort is communicating with prelude-manager. Click on the Agents link in the menu, and there should be an entry for the server. Click on it once to expand it, and then on the Total box to expand the sensors. If everything is configured correctly, Snort should appear in the listing:-

Prewikka allows you to filter and sort the events displayed, so now would be a good time to have a play about with it. Clicking on an alert will let you view the details of that alert, and because the events at the moment are from Snort, all the relevant alert information that Snort would have logged to /var/log/snort/alert should be available.

Add logs, and sprinkle in a bit of correlation

So now we have working Prelude and Snort installs, with the two working together and a nice front-end to view them through. While nice to look at, we’re missing one of the things that all good IDS tools have, which is correlation.

Before going any further, let’s install two more Prelude packages – prelude-lml (Prelude Log Agent) and prelude-correlator:-

root@dev-vm-lnxd-01:~# apt-get install prelude-lml prelude-correlator

On my squeeze install, the post-install script for prelude-lml exits with an error because the service is initially disabled. This is fixed in a later version, but it’s something to look out for. For now, ignore the error – after we’ve configured it we can pacify dpkg…

Because prelude-lml and prelude-correlator are sensors themselves, we’ll need to register them with prelude-manager in the same way that we did for Snort with the prelude-admin command:-

root@dev-vm-lnxd-01:~# prelude-admin register "prelude-lml" "idmef:w" 127.0.0.1 --uid 0 --gid 0
...output from prelude-admin...
root@dev-vm-lnxd-01:~# prelude-admin register "prelude-correlator" "idmef:rw" 127.0.0.1 --uid 0 --gid 0
...output from prelude-admin...

As before, you’ll need to run prelude-admin registration-server prelude-manager in a second session for both sensors. Also, make sure that you correctly give prelude-correlator the ‘idmef:rw’ permissions – this is because it needs to both read and write events. Then, enable prelude-correlator in the same way as prelude-manager by changing RUN=no to RUN=yes in /etc/default/prelude-correlator. Finally, start prelude-correlator:-

root@dev-vm-lnxd-01:/etc/prelude/profile# /etc/init.d/prelude-correlator start
Starting prelude-correlator : prelude-correlator21 Jan 03:06:57 prelude-correlator (process:22339) INFO: [FirewallPlugin]: disabled on user request
21 Jan 03:06:57 prelude-correlator (process:22339) WARNING: SpamhausDropPlugin = PreludeCorrelator.plugins.spamhausdrop:SpamhausDropPlugin: No module named netaddr
21 Jan 03:06:57 prelude-correlator (process:22339) INFO: [BusinessHourPlugin]: disabled on user request
21 Jan 03:06:57 prelude-correlator (process:22339) INFO: 7 plugin have been loaded.
.

A word of warning at this point – initially, prelude-correlator failed to start for me. If this happens, make sure that /etc/prelude/prelude-correlator, /var/spool/prelude/prelude-correlator and /var/lib/prelude-correlator (plus any subdirectories) are owned by the prelude-correlator user, and then again try to start prelude-correlator.

If you had problems earlier with the dpkg post-install script for prelude-lml, running apt-get -f install here will tidy that up and start prelude-lml. If you didn’t, then start prelude-lml manually:-

root@dev-vm-lnxd-01:/etc/prelude/profile# /etc/init.d/prelude-lml start
Starting Prelude LML: prelude-lml.

Going back to our Prewikka browser window, if we click again on Agents and expand the nodes and sensors, we should see entries for prelude-lml and prelude-correlator.

To demonstrate what prelude-lml and prelude-correlator can do, let’s first add an iptables entry to log all TCP connection attempts on port 22:-

root@dev-vm-lnxd-01:~# iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j LOG

Opening another SSH connection to the server should result in a log message in /var/log/messages similar to the following:-

Jan 21 03:17:08 dev-vm-lnxd-01 kernel: [ 7981.313741] IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=192.168.xxx.aaa DST=192.168.xxx.yyy LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=1313 DF PROTO=TCP SPT=56168 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0

Next, purposefully fail an attempt to log into the server – for example, with an incorrect password. Then, check the events again:-

There’s a few things here, but the main thing to notice is that there are a number of new sensors listed in the Analyzer column. PAM, sshd, and netfilter have all been picked up by prelude-lml from the logfiles it monitors, and in the case of the first event, prelude-correlator has correctly identified – from the prelude-lml events – that a brute-force attack has occurred. In my example above, it’s also picked up that there was a successful login – this was me logging in with the correct password, but if this was a production system this may well be indicative of a brute-force attack resulting in a correctly-guessed password!

Where now?

This is just a quick overview of what’s possible with open-source IDS software. All the tools I’ve written about in this post are extremely configurable – prelude-lml for example can monitor many different types of logfile and can be configured with custom regular expressions to look for specific things. Many similar tools can be configured to send events to Prelude, which prelude-correlator can correlate as above. One thing I’ve not covered here is auditd, which has (via the audispd multiplexor) the ability to send to Prelude – something which I’ll cover in a future post.

]]> http://andys.org.uk/bits/2012/01/21/a-prelude-to-better-things-open-source-and-ids/feed/ 0 http://andys.org.uk/bits/2010/12/17/redhat-nfs-and-static-ports/ http://andys.org.uk/bits/2010/12/17/redhat-nfs-and-static-ports/#comments Fri, 17 Dec 2010 20:05:19 +0000 Andy Smith http://andys.org.uk/bits/?p=121 Using NFS between two machines on the same network is usually free of hassle, so the default behaviour – on Linux, at least – is fine and can be left as it is. However, in a commercial setting (such as the ones I manage in my day job) it’s often the case that the machines might not be on the same network – or even in the same location, for that matter. It’s likely that there’s a number of network devices in between the machines, and the way NFS uses portmap can sometimes make things frustrating.

Luckily, it’s really easy to fix.

On RedHat-based systems, it’s a case of editing /etc/sysconfig/nfs. In there, by default you’ll find quite a few <service>_PORT=<port> entries, but they’re hashed out. For example:-

# Port rpc.statd should listen on.
#STATD_PORT=662

You can go ahead and uncomment the line, or if you wish you can change the port. Repeat this for the other <service>_PORT entries as required – you’ll want to do LOCKD_TCPPORT (if you’re using TCP), LOCKD_UDPPORT (if you’re using UDP), MOUNTD_PORT and STATD_PORT.

Once you’re happy, restart the services:-

/sbin/service portmap restart
/sbin/service nfs restart

Running rpcinfo -p should show the various NFS services now running on the ports specified in /etc/sysconfig/nfs:-

[root@nfs-server ~]# rpcinfo -p
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
100011    1   udp    875  rquotad
100011    2   udp    875  rquotad
100011    1   tcp    875  rquotad
100011    2   tcp    875  rquotad
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100021    1   udp  32769  nlockmgr
100021    3   udp  32769  nlockmgr
100021    4   udp  32769  nlockmgr
100021    1   tcp  32803  nlockmgr
100021    3   tcp  32803  nlockmgr
100021    4   tcp  32803  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100005    1   udp    892  mountd
100005    1   tcp    892  mountd
100005    2   udp    892  mountd
100005    2   tcp    892  mountd
100005    3   udp    892  mountd
100005    3   tcp    892  mountd

Firewall rules should be somewhat easier to manage now.

For Debian and Ubuntu systems, you might find this link useful.

It’s often the case that there’s no easy way of installing a machine that doesn’t have any removable media. For instance, I have an old Compaq Deskpro EN that’s too old to support booting from USB, so using something like UNetbootin is out of the question. Luckily, there’s an an alternative, which is to PXE boot an installer over the network.

PXE (or Preboot eXecution Environment) is a means of booting a machine over a network,which conveniently removes any requirement for anything special on the machine that’s to be installed other than an network card. PXE boot (or network boot) support tends to be available in older machines that don’t support booting from USB, so it’s a very useful feature to be able to use.

There’s a very useful article on Debian Administration that covers configuring a Debian machine to act as a PXE boot server to serve out an etch installer. I personally run squeeze, so I’ve used the article as a basis for setting up a Debian squeeze machine to serve out a squeeze installer.

Installing the prerequisites

To start with, we need a TFTP server and a DHCP server. You might already have one (or both) of these installed already, but for the purposes of this we’ll assume that you haven’t. So, to get started, install the tftpd-hpa and dhcp3-server packages:-

apt-get install tftpd-hpa dhcp3-server

Configuring DHCPd

First, make sure that the tftpboot directory exists. This used to be /var/lib/tftpboot, but Debian now uses /srv/tftpboot. The installer should have created it, but just in case, check it exists and if create it if not.

The next step is to add a subnet declaration to /etc/dhcp3/dhcpd.conf for your network. A simple one will be something like this:-

subnet 192.168.51.0 netmask 255.255.255.0 {
       range 192.168.51.64 192.168.51.80;
       filename "pxelinux.0";
       next-server 192.168.51.1;
       option routers 192.168.51.1;
}

If you’ve already got DHCPd installed and configured, the two lines highlighted in green are the ones you need to add to your existing subnet declaration. The filename option tells PXE clients which file they need to request via TFTP, and the next-server option tells the clients the TFTP server they should use to get it.

Creating the PXE boot environment

Before we pull down any of the installer files, we need to create somewhere for those files to go, along with the PXE boot configuration. So, create the pxelinux.cfg and debian/squeeze/i386 directories:-

mkdir -pv /srv/tftpboot/pxelinux.cfg
mkdir -pv /srv/tftpboot/debian/squeeze/i386

Next, create the config for pxelinux in pxelinux.cfg/default:-

DISPLAY boot.txt

DEFAULT squeeze_i386_install

LABEL squeeze_i386_install
     kernel debian/squeeze/i386/linux
     append vga=normal initrd=debian/squeeze/i386/initrd.gz  --
LABEL squeeze_i386_linux
     kernel debian/squeeze/i386/linux
     append vga=normal initrd=debian/squeeze/i386/initrd.gz  --
LABEL squeeze_i386_expert
     kernel debian/squeeze/i386/linux
     append priority=low vga=normal initrd=debian/squeeze/i386/initrd.gz  --
LABEL squeeze_i386_rescue
     kernel debian/squeeze/i386/linux
     append vga=normal initrd=debian/squeeze/i386/initrd.gz  rescue/enable=true --
PROMPT 1
TIMEOUT 0

Then, create boot.txt in pxelinux.cfg, which is our boot menu:-

- Boot Menu -
=============

squeeze_i386_install
squeeze_i386_linux
squeeze_i386_expert
squeeze_i386_rescue

Finally, download the installer parts from the Debian FTP mirror:-

cd /srv/tftpboot/
wget http://ftp.uk.debian.org/debian/dists/squeeze/main/installer-i386/current/images/netboot/debian-installer/i386/pxelinux.0
cd /srv/tftpboot/debian/squeeze/i386
wget http://ftp.uk.debian.org/debian/dists/squeeze/main/installer-i386/current/images/netboot/debian-installer/i386/linux
wget http://ftp.uk.debian.org/debian/dists/squeeze/main/installer-i386/current/images/netboot/debian-installer/i386/initrd.gz

Final steps

Make sure that tftpd-hpa and dhcp3-server are running:-

service tftpd-hpa restart
service dhcp3-server restart

You should now be able to network boot machines into the Debian squeeze installer.

I’ve also put this on the Bits Wiki as a guide – feel free to have a look and add any notes you feel may be useful!

iproute2 is a suite of tools developed to unify the functions provided by the traditional tools in one place under the ip command. Interface configuration, routing and tunnelling can now all be configured and managed using the ip command.

Interface configuration

Historically, interfaces are managed using the ifconfig command, and to get an overview of the interfaces you’d type ifconfig -a. With iproute2, interfaces addressing is managed through the address subcommand – which, like the rest of the subcommands for iproute2 can be shortened Cisco IOS-style, as long as it’s unique. In theory this means you can use ip a, but the manual page refers to it as ip addr, which I’ll use here for clarity. So, the equivalent of ifconfig -a is the self-explanatory ip addr show, which if we’re not specifying a specific interface can be shortened to simply ip addr:-

[root@example ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth0

Most of this should be self-explanatory, and everything you would see with ifconfig -a you’ll see with ip addr.

Bringing up eth0 on a Linux box would usually consist of doing the following:-

[root@example ~]# ifconfig eth0 up
[root@example ~]# ifconfig eth0 192.0.2.1 netmask 255.255.255.0

With iproute2, control of interfaces themselves – both physical and logical – is through the link subcommand. Bringing up eth0 can be done with:-

[root@example ~]# ip link set eth0 up

Managing the addresses on an interface is through the aforementioned addr subcommand, so using our example again, we’d do something like this to add an IP to eth0:-

[root@example ~]# ip addr add 192.0.2.1/24 dev eth0

I’ve used CIDR notation in this example, but you can use the normal dotted quad format for the netmask if you wish.

This also makes adding multiple IP addresses to interfaces really easy. To add 192.0.2.2 to our example eth0 interface, you’d just do:-

[root@example ~]# ip addr add 192.0.2.2/24 dev eth0

Showing the addresses on our eth0 interface only will show that both the addresses are now there:-

[root@example ~]# ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Removing an IP from an interface is also straightforward:-

[root@example ~#] ip addr del 192.0.2.2/24 dev eth0

Querying the interface again shows that 192.0.2.2 is no longer assigned to eth0:-

[root@example ~]# ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1

Routing

Using netstat -rn is pretty much burned into the brains of most UNIX engineers, but luckily the iproute2 method is just as snappy. Routing management is handled with the route subcommand, and in line with addr and link, it can be shortened – ip r will work, but I usually settle for ip ro. The full command for showing the routing table is ip route show, but as with ip addr you can drop the show if you want to show the entire routing table:-

[root@example ~]# ip ro
192.0.2.0/24 dev eth0  proto kernel  scope link  src 192.0.2.1
default via 192.0.2.254 dev eth0

Adding and removing routes is accomplished with ip ro add and ip ro del respectively:-

[root@example ~]# ip ro add 10.0.0.0/16 via 192.0.2.253
[root@example ~]# ip ro del 10.0.0.0/16 via 192.0.2.253

One useful feature of ip route is the get function, which we can use to query the routing table for a particular network or address. In our example, querying for an address not on our local network shows that the route to it goes via our default gateway:-

[root@example ~]# ip ro get 1.2.3.4
1.2.3.4 via 192.0.2.254 dev eth0  src 192.0.2.1
    cache  mtu 1500 advmss 1460 hoplimit 64

Neighbours

arp -na is the traditional way you’d query the ARP table on a UNIX machine. You can accomplish this with iproute2 using ip neighbor (or ip neighbour for us not from the US), with ip n being the shortened extreme:-

[root@example ~]# ip neigh
192.0.2.3 dev eth0 lladdr 00:02:a5:1f:cb:2d REACHABLE
192.0.2.254 dev eth0 lladdr 00:09:43:bc:aa:80 REACHABLE

I’ll skip the example for this, but needless to say you can add and remove entries with ip neigh add and ip neigh del respectively.

A little helping hand

If you’re stuck, then the help argument can come in handy. If you specify help as an argument to ip itself, or to one of the subcommands, it’ll give you a quick overview of the options available. For example, for ip neighbor:-

[root@example ~]# ip neigh help
Usage: ip neigh { add | del | change | replace } { ADDR [ lladdr
          LLADDR ] [ nud { permanent | noarp | stale |
          reachable } ] | proxy ADDR } [ dev DEV ]
       ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]

Not forgetting IPv6…

I’ve purposely neglected to show any configuration of IPv6 addresses in this post, not because iproute2 can’t handle it, but for the exact opposite reason – the iproute2 suite will handle IPv6 addresses in exactly the same way as IPv4 addresses. All the commands used above can be used for both IPv4 and IPv6 configuration without any issues.

If there’s a reason you want to force the behaviour one way or the other, you can use the -4 and -6 switches. This isn’t needed normally, because when adding or removing an address, for example, iproute2 will happily recognise an IPv6 address instead of an IPv4 one. Where it does come in useful is if you want to limit the data returned in a query to just IPv6, or just IPv4. A real-world example of this is on one of my Linux machines, where ip -6 ro shows:-

[root@daedalus ~]# ip -6 ro
2001:470:XXXX:1::/64 dev eth0  proto kernel  metric 256  mtu 1500
  advmss 1440 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440
  hoplimit 0
default via 2001:470:XXXX:1::1 dev eth0  metric 1  mtu 1500 advmss
  1440 hoplimit 0

…which comes in handy if you’re only interested in the IPv6 routing table.

What next?

This post only really scratches the surface of iproute2 – I’ve just covered the iproute2 equivalents of the most-used commands. It’s capable of much, much more, such as setting up tunnels, managing multiple routing tables and configuring interfaces for multicast to name a few. I’ll be covering some of these in more depth in future posts.

Further reading

• The Linux Advanced Routing & Traffic Control HOWTO, which is probably the definitive guide when it comes to iproute2
• iproute2 on Wikipedia
• The Linux Foundation’s iproute2 page

If you install Likewise Open on Debian Squeeze, you may notice that it doesn’t start on boot-up. The reason is because the new dependency-based boot sequence doesn’t like the init scripts Likewise provides.

Luckily, it’s pretty easy to fix. First, make sure you have chkconfig installed (apt-get install chkconfig if not), change into your /etc/init.d directory and do this:-

for INIT in lsassd lwiod eventlogd dcerpcd netlogond lwregd srvsvcd; do \
   echo "Fixing '${INIT}'..."; \
   sed -i -e 's/^#LWI_STARTUP_TYPE_SUSE#/#/g' \
      -e 's/Default-Start: 3 5/Default-Start: 2 3 4 5/g' \
      -e 's/Default-Stop: 0 1 2 6/Default-Stop: 0 1 6/g' ${INIT}; \
done

for INIT in lsassd lwiod netlogond eventlogd dcerpcd; do \
   echo "Disabling ${INIT}..."; \
   chkconfig -d ${INIT}; \
done

for INIT in dcerpcd eventlogd netlogond lwiod lsassd; do \
   echo "Re-enabling ${INIT}..."; \
   chkconfig -a ${INIT}; \
done

This uncomments the SUSE parts of the init scripts, which chkconfig wants. It then calls chkconfig to first delete each entry, and then re-add it to make sure everything’s okay. Reboot, and you should have working domain authentication without having to manually start it up.

If you’re one of the lucky ones, your ISP might provide native IPv6 connectivity (like AAISP), but for most of us, the main way to get connected to the rest of the IPv6 Internet is to use something we’ve already got – IPv4. And we’re going to tunnel over it.

The first thing we need to do is choose a tunnel broker, which is a fancy name for someone who’ll provide us with an IPv4 endpoint we can tunnel IPv6 over. Wikipedia has a list, but the main, globally available ones are Hurricane Electric and SixXS. Either of these will do, and some people prefer HE over SixXS, but that’s a purely personal choice – in my experience, both work equally as well. For this example, though, we’ll go with HE – so head on over to http://tunnelbroker.net/ and create an account.

My first tunnel

Once you’ve created your account, log in and create a tunnel. For some reason, it always seems to pick their New York POP, so you might want to manually choose one geographically closer (in my case – and for our example – London, UK)

Creating a tunnel

The IP address you use as your local end of the tunnel will need to be a public IP address. It’s possible to use a machine behind a NAT device if it’s in a DMZ-style setup where all the traffic destined for the public IP address gets forwarded by the NAT device to the machine behind it, but your mileage may vary.

Once created, view the tunnel details, which should look something like this:-

Editing the tunnel details

Our tunnel has been created! At the bottom of the page, you’ll notice a little drop-down that generates the commands needed to bring up the tunnel. For this example, we’re using iproute2, so the commands go something like this:-

ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local 192.0.2.1 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:810::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

The first command creates an IPv6-in-IPv4 tunnel between us and HE, and the second command brings up that tunnel. The third command adds our IPv6 address to our end of the tunnel, and finally the fourth command sets the IPv6 default route to be down our newly-created tunnel.

And that’s it – we’re now connected to the global IPv6 internet. To test it, let’s try pinging something:-

mordor:~# ping6 -c 3 www.he.net
PING www.he.net(he.net) 56 data bytes
64 bytes from he.net: icmp_seq=1 ttl=58 time=375 ms
64 bytes from he.net: icmp_seq=2 ttl=58 time=257 ms
64 bytes from he.net: icmp_seq=3 ttl=58 time=255 ms

--- www.he.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 255.562/296.218/375.628/56.158 ms

If you see something like the above, then give yourself a pat on the back, because it’s working!

Next steps

HE by default assigns you a /64 network, which is the smallest size intended to be allocated. This gives you 18,446,744,073,709,551,616 IPs, and whichever way you look at it that’s a lot of addresses. With this in mind, you might be wondering why HE will give you a /48 (that’s 1,208,925,819,614,629,174,706,176 IPs!). The reason is that each network is intended to have a /64, and a /48 allows you to carve up that space into a total of 65,536 separate /64 networks. Now this obviously sounds like overkill to the average user, but autoconfiguration tools such as radvd won’t work with networks smaller than /64, again because of the intentions mentioned previously. This means that if you have more than one network at home (say, a wired network and a wireless network, currently with separate IPv4 networks for each), you can assign a /64 to each one.

With this is mind, let’s ask HE for a /48 by clicking on Allocate in the ‘Routed /48′ section. After a few seconds, you’ll see something like this:-

Allocating our /48

In our example, we’ve been allocated 2001:470:90d3::/48, and now it’s time to plan our IP schema.

Laying it out

Taking my own home network as an example, I have three networks – one for general use (the ‘LAN‘), one for guest use over wireless (the ‘WLAN‘), and finally a DMZ (the… er, ‘DMZ‘). We could lay these out like this:-

• LAN – 2001:470:90d3:1::/64
• DMZ – 2001:470:90d3:2::/64
• WLAN – 2001:470:90d3:3::/64

Nice and simple, and easy to remember. Assuming all three networks are connected to the same gateway machine, we can give the gateway the first IP in the range – 2001:470:90d3:1::1, 2001:470:90d3:2::1 and 2001:470:90d3:3::1.

Routing things further

Before we start, we need to enable IP forwarding for IPv6:-

sysctl -w net.ipv6.conf.all.forwarding=1

You’ll probably want to add this somewhere so it gets activated on bootup – under Debian this would be in /etc/sysctl.conf (which already has the entry, albeit commented out).

One way to provide connectivity to machines on the individual networks is to manually give each machine an IPv6 address, and to route it through our gateway:-

ip addr add 2001:470:90d3:1::2/64 dev eth0
ip route add ::/0 via 2001:470:90d3:1::1 dev eth0

Again, all being well, you should now be able to route to the wider IPv6 Internet from our newly-configured IPv6 node. More importantly, this also means that the wider IPv6 Internet can route back to you – which brings us to…

Security, not obscurity

Don’t be fooled into thinking that because of the immense range of possible IPv6 addresses that securing your new IPv6 setup isn’t required – IPv6 is no exception when it comes to the Internet Bad Guys, so implementing firewall rules is of the utmost importance.

The problem with IPv4 and NAT is that it’s allowed people to become somewhat complacent about security, because machines behind a NAT device are naturally unreachable from the global Internet. IPv6 does not have NAT, which means you don’t have this (rather lazy) safety net, so we have to do it properly.

Luckily, if you’re familiar with iptables, you’ll be glad to know that there’s an IPv6 equivalent – and it’s called (predicatably) ip6tables. The syntax is identical, and in fact the only noticeable difference is that you’re using IPv6 addresses and networks instead of IPv4 ones.

A quick example would go something like this:-

# Clear our INPUT, OUTPUT and FORWARD chains
ip6tables -F INPUT
ip6tables -F OUTPUT
ip6tables -F FORWARD

# Allow packets related to existing connections
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow link-local (for neighbour discovery)
ip6tables -A INPUT -s fe80::/10 -j ACCEPT

# Allow SSH inbound to our gateway from our LAN
ip6tables -A INPUT -i lan -s 2001:470:90d3:1::/64 -p tcp
   -m tcp --dport 22 -j ACCEPT

# Allow all outbound from our networks
ip6tables -A FORWARD -i lan -s 2001:470:90d3:1::/64 -j ACCEPT
ip6tables -A FORWARD -i dmz -s 2001:470:90d3:2::/64 -j ACCEPT
ip6tables -A FORWARD -i wlan -s 2001:470:90d3:3::/64 -j ACCEPT

# Allow all outbound from our gateway
ip6tables -A OUTPUT -j ACCEPT

# Allow SSH and HTTPS inbound to our DMZ
ip6tables -A FORWARD -i he-ipv6 -d 2001:470:90d3:1::/64 -p tcp
   -m multiport --dports 22,443 -j ACCEPT

# Set the default policy to drop
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

So there you have it – IPv6 firewalling needn’t be difficult. If you want to make something more complex, you might want to take a look at my previous post about iptables and the ‘mark’ target, which also applies to ip6tables.

IPv6 – automatically

Just like DHCP for IPv4, there are autoconfiguration mechanisms for IPv6 – radvd and DHCPv6. Radvd is the older of the two, but both can be used for the same purpose. Configuration of radvd is relatively straightforward, and if we wanted to provide autoconfiguration on our example LAN, we can do something like this:-

interface lan
{
      AdvSendAdvert on;
      MinRtrAdvInterval 3;
      MaxRtrAdvInterval 10;
      AdvDefaultPreference low;
      AdvHomeAgentFlag off;

      prefix 2001:470:90d3:2::/64
      {
            AdvOnLink on;
            AdvAutonomous on;
            AdvRouterAddr off;
      };
};

Where next?

This only covers the start – there’s more involved in bringing an IPv6 network up to scratch, like setting up forward and reverse DNS, and configuring various daemons to talk over IPv6 as well as IPv4. If you’re interested, you might find some of the following links useful reading:-

• Peter Bieringer’s Linux IPv6 Howto
• IPv6 in the UK
• RFC 2460 – IPv6 Specification
• Deep Space 6

I’m from a UNIX (mostly Linux) background, so I’m more at home using UNIX-alike platforms. That said, there’s a few things that Microsoft do that are particularly useful, and in my opinion AD is one of them (quiet at the back, there). Handily, there’s a project that can marry the two, and it goes by the name of Likewise.

Likewise Enterprise is Likewise Software’s commercial offering, but they also provide an open-source edition in the form of Likewise Open, which is what I’m going to focus on here. Conceptually, using Likewise is equivalent to binding a Windows machine to a domain, and the method of doing it is similar. The code is somewhat related to Samba, so some parts of it may be familiar to anyone who’s meddled around with Samba in any depth.

Starting out

First off, you’ll need the Likewise Open installer, which you can get from here (signup required). Grab the installer for your particular distro or operating system – for this example I’m using a fresh Debian (lenny) GNU/Linux install, but the process is essentially the same for others, such as Solaris. One you’ve got it, installing it is just a matter of running it:-

adtest:~# chmod +x ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer
adtest:~# ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer

Follow the prompts, and after a few seconds you’ll be returned to a prompt. Assuming the install completed successfully, in the case of Debian (or Ubuntu), running ‘dpkg -l | grep likewise‘ will show a few new packages have been installed (for RedHat/CentOS, replace ‘dpkg -l‘ with ‘rpm -qa‘).

Before going any further, make sure your resolvers are set up correctly, and that the local machine’s time is synchronised – either against an external NTP source, or one of the domain controllers. You can check that DNS resolution is working correctly by running:-

adtest:~# host test.example.com

…and all being well, you’ll see something like this:-

test.example.com          A     10.1.1.1
test.example.com          A     10.1.2.1

If you’re okay so far, configuring the machine to use AD requires one command:-

adtest:~# /opt/likewise/bin/domainjoin-cli join test.example.com andys

After a few seconds, providing the local machine can see the domain controllers, you should be prompted for your domain password. As when binding a Windows machine to a domain, the account you use must have the right privileges, which usually means that it’s in the Domain Admins group or similar. So:-

Joining to AD Domain:   test.example.com
With Computer DNS Name: adtest.test.example.com

andys@TEST.EXAMPLE.COM's password: <domain password>

…wait a few seconds…

Warning: System restart required
Your system has been configured to authenticate to Active Directory
for the first time. It is recommended that you restart your system
to ensure that all applications recognize the new settings.

SUCCESS

Now, in my experience you don’t strictly need to reboot, however it’s a good idea to, so go ahead and reboot the machine.

The basics

Assuming the box rebooted, we can now test that AD integration is working. Log in, and at a prompt type:-

adtest:~# id TEST\\andys

…replacing ‘TEST\\andys‘ with your domain and username. The double backslash is important, because most UNIX shells use ‘\’ for escaping characters. If you want, you can also use the ‘user@domain‘ syntax. If all is well, you’ll see something like this:-

uid=2096628820(TEST\andys) gid=2096628225(TEST\domain^users)
groups=2096628225(TEST\domain^users),2096628224(TEST\domain^admins)

At this point I should offer a word of caution: Because the machine is now bound to the domain, it means users on the domain can log into it. Obviously this is the whole point, but it’s something to be mindful of, especially if the domain is used by many people.

The UIDs and GIDs may look ridiculously large, but don’t worry – UIDs under most UNIXen are 32-bit, so this will be fine. There’s also a good reason for it – Likewise guarantees that the IDs will be unique and consistent across all machines bound to the same domain. You’ll also notice that the user’s primary group is set to the primary group from AD, which is usually ‘Domain Users‘.

The domainjoin-cli command also makes some changes to /etc/nsswitch.conf and the PAM configuration. On my example Debian box, having a peek at /etc/pam.d/common-auth reveals:-

auth    sufficient    /lib/security/pam_lsass.so
auth    required    pam_unix.so nullok_secure try_first_pass

pam_lsass.so is the PAM shared library for the lsass – or Local Security Authority Subsystem Service – part of Likewise. The example above is simple enough, and accepts domain users, falling back to standard UNIX users if the given username isn’t a domain user.

Making changes

Likewise installs its configuration files in /etc/likewise. The one that’s probably of most interest is lsassd.conf, which controls how the lsass daemon lsassd handles users. Before going into any detail, you’ll notice that lsassd.conf is split into two sections – the first being for domain users (the [auth provider:lsa-activedirectory-provider] section), and the second being for ‘local’ users (under [auth provider:lsa-local-provider]). The local users are usually just ‘COMPUTER\Administrator‘ and ‘COMPUTER\Guest‘ (where COMPUTER is the name of the local machine), and are synonymous to the Administrator and Guest accounts on Windows machines. Chances are you won’t need to touch the local users section, so we can safely ignore it.

There’s quite a few options to play with in lssasd.conf, but the main ones we’re interested in are:-

• login-shell-template, which allows us to set the default shell for domain users. This is (by default) set to /bin/sh, so in many cases you might want to change it to /bin/bash.
• homedir-template, which specifies where domain users’ home directories will be created. The default for this is %H/local/%D/%U, which in our example would expand to /home/local/TEST/andys for my account. Personally, I prefer to drop the ‘local’ bit and use %H/%D/%U, which would change my home directory to /home/TEST/andys.
• require-membership-of, which lets us specify which groups are allowed to authenticate against this machine in a comma-separated list.

It’s important to note that if you use the last option, any domain user which isn’t a member of one of the specified groups will fail any PAM configuration that calls pam_lsass.so. This means that if you wanted to allow certains groups SSH access, whilst allowing a larger set of groups access to FTP, you don’t want to omit the FTP user groups from here. If you’re building this kind of setup, you’ll want to allow all the groups in lsassd.conf, and then build your PAM configuration to conditionally allow access based on group membership using pam_group.

Once you’ve finished making your configuration changes, you’ll need to tell Likewise to reload the configuration:-

adtest:~# /opt/likewise/bin/lw-refresh-configuration
Configuration successfully loaded from disk.

It also doesn’t hurt (and I’ve sometimes found it neccessary) to clear the local AD cache:-

adtest:~# /opt/likewise/bin/lw-ad-cache --delete-all
The cache has been emptied successfully.

…and that’s it! You should now have AD authentication working through PAM.

Useful commands

Likewise installs quite a few tools in /opt/likewise/bin (many of which are symlinks to lw-lsa), some of which come in handy for testing:-

• lw-refresh-configuration, which as mentioned above reloads the lsassd configuration from lsassd.conf.
• lw-ad-cache (also partly mentioned above), which lets us manipulate the local AD cache. For example, lw-ad-cache –enum-users will list the users’ details currently stored in the cache.
• lw-enum-users/lw-enum-groups, which predictably list all the users and groups in the domain.
• lw-get-status, which shows quite a bit of information about the domain itself.

These are just a few, so it’s useful to have a poke about in /opt/likewise/bin and see what there is.

Hints

Because Likewise integrates itself via PAM, pretty much everything which can work with normal UNIX users can cope fine with domain users. For instance:-

• You can use the tilde (~) shortcut to go to a domain user’s home directory, for example cd ~andys@TEST. For some reason, the backslash notation doesn’t work here, and you may also notice that tab completion doesn’t work either.
• With most things, you can refer to domain users as either TEST\\andys, TEST.EXAMPLE.COM\\andys, andys@TEST or andys@TEST.EXAMPLE.COM, including when logging in on the console or via SSH. There are exceptions (such as the previous point), but they’re few and far between.
• Sudo happily works with domain groups – just remember to double-backslash.
• You can use chown and chgrp in the ways you’d normally expect, using either the domain group names, or their GIDs.
• ACLs (under Linux) also work, so if you’ve mounted a partition with the ‘acl‘ option, you can use setfacl as normal.

If it all goes wrong…

Sometimes things go wrong. With Likewise, it’s usually straightforward. If you’re getting errors when binding to the domain with domainjoin-cli, it’s usually because it’s having problems connecting to the domain controller. If your domain controllers are on a different network, check that any firewalls inbetween aren’t dropping SMB traffic. The domainjoin-cli command should give you a definitive list of ports it needs open to communicate with the domain controller.

Once up and running, I’ve found Likewise Open to be very stable, but on the odd occasion that something has gone awry, it’s often enough to just restart the lsassd daemon. Failing that, try emptying the cache (with lw-ad-cache –delete-all). If you’re still getting odd errors, it might be worth checking out the documentation or the forums.

Where to from here?

Because the PAM magic happens with pam_lsass, in theory anything which uses PAM can be made AD-aware. I’ve personally used it with Pure-FTPd to provide company-wide access to an fileserver, and it works flawlessly with gdm, so you can use it on your desktop. Again, because it’s PAM-based, it can be stacked with other modules such as pam_securid (for RSA’s SecurID tokens) or pam_opie (for one-time password sets).

Ironically, one thing that does require a little bit more configuration is Samba – something I’ll cover in a future post.

Update: Yvo van Doorn comments below with a handy hint if you only need access to one domain, which should save on keyboard wear for some users