Tag Archives: DHCP

Kickstarting CentOS using PXE

There are many tutorials online for kickstarting a linux server, but they all cover part of the whole process. I’ll attempt to cover it all here.

First off, I’ll tell you my setup. I wanted to use PXE, kickstart and a local mirror to be able to install a lot of computers simultaniously. However, to be able to do this I tested the installation in Virtualbox with a virtual machine. Both my server and client are virtual. Second I would like to say that I’m a debian minded person. However, CentOS was required for this setup, so here we go.

One of the things I encountered was a VM which did not do any DHCP. The key here was that you need to select the right network adapter for the VM. I used the network bridge adapter which was virtualised as a PCnet-Fast III. Some others might work, but this one did it for me.

On your server you will need some software packages to be installed:

yum install httpd system-config-kickstart dhcp tftp-server syslinux

It’s possible that some are already installed. system-config-kickstart installes a gui kickstart editor. When your server doesn’t have a gui it’s useless. However, if it does, it’s easier to make a kickstart file with it.

As I also wanted a local yum repository I needed to sync a remote repository. This is not really neccesary, but when using this setup in an offline environment you’ll need it. Bear in mind that a repository for a single release is about 25GB.

rsync -avrt --delete --exclude "local*" --exclude "isos" \
rsync://mirrors.rit.edu/centos/6.2 /usr/local/share/CentOS/

This is going to take a while, but while it is syncing you can continue with the other configuration tasks.

Continue reading

IPv6 Security part 1, Router Advertisements

This is the first part of a series on IPv6 security. As the IPv4 address space is nearly exhausted more and more companies are looking at IPv6. However, whenever a ‘new’ protocol is implemented there is a big chance of security issues arising. Moreover, as IPv6 is likely to be one of the most fundamental changes to the Internet and network world in the last 30 years and probably many years to come it is important to do it right.

IPv6 is not a new protocol. It has been defined in 1998 in RFC 2460. Back in 1998 some of the common attacks we see nowadays weren’t known. Therefore most of these attacks are applicable to IPv6 as well as IPv4.

In this first part I would like to discuss Router Advertisements (RA). To be able to understand the problem with RA you would first need to know what they are. A router advertisement is a message which is sent by the routers on the network. These messages contain vital information required by network hosts to be able to use the network. For example, a RA contains network information required by hosts to assign themselves an IP address. This is a method of configuring clients without the need for a DHCP server.

One of the most important features of a router advertisement is that it announces the router itself. Clients use this information to send data off-network, thus enabling them to participate in the bigger whole of the network and the Internet. In other words, a RA contains the default gateway for the network.

One of the biggest problems with router advertisements is that any host can send them, thus creating the possibility for a man-in-the-middle attack. When a bad person wants to inspect all the traffic you send over the Internet he can send a false router advertisement reconfiguring your computer to send all data to him. This is possible because router advertisements are not validated and the last received advertisement is assumed to be the correct one. (Note, this attack is nothing else than a rogue DHCP server on IPv4, with the exception that in the IPv4 case you need to be the first instead of the last)

So, what can we do about this? Well, the best way would be validating the router. When you can be sure the RA originated by the real and trusted router on the network you can trust it. In 2005 a standard was specified that achieves just that (among other things). It is called SeND (Secure Neighbor Discovery) and is defined in RFC 3971. It has been implemented by Cisco, but unfortunately nobody else. Another option is to implement the same techniques used to prevent rogue DHCP servers, configure on which switchport resides a router and allow router advertisements only from that specific port (called RA guard, documented in RFC 6105. This mitigates the possible attack on a wired lan and is currently implemented by most (but not all!) big network companies like Cisco.

However, this solution requires you to use a real switch with support for this option. Hubs are not allowed. This gives rise to another question, how do you protect wireless users from this attack? Unfortunately without SeND this becomes quite difficult. The thing you have to do is separating the clients from each other so that they can’t see each others traffic. However this is difficult in a wireless lan as it’s a shared medium. One could choose to create separate IPSec tunnels between the host and a trusted endpoint. In that case even if a hacker manages to insert itself as router in between the traffic flow, all traffic would be encrypted. Limiting the use the attacker has on the data.