Tutorial: Linux

Linux Home Server HOWTO
Chapter 6 - Firewall Concepts

With all the possible security threats roaming around the Internet today, a security firewall should be considered a mandatory necessity for any computer systems connected to the Internet. A firewall is a networking device which is used to separate private networks from external access by providing a certain level of security rules and controls.

A simple firewall can be configured to block all access to certain networks, workstations and communication ports. A more complex firewall is capable of inspecting each individual packet that attempts to pass through it and ensures that they are correctly formatted and appropriate to the services provided for (or by) the internal network, this is called a packet filtering firewall.

This chapter will explain some of the concepts for iptables and packet forwarding which can be used to secure your private network. The example configurations provided in each section are only designed to provide an introduction into each of those specific sections, while an example firewall script has been included which will provide simple but effective security for your networked system.

Many of the newer broadband modems provide built-in firewall features that allow for stateful packet inspection and detailed network address translations, which are capable of providing a high security level for your internal network.

Packet Forwarding
Packet forwarding is a simple concept where the server allows data packets to pass from one network to another. As with the diagram below, packets from the private network are allowed to be forwarded through the server and out to the ISP and vice versa.

There are a few initial considerations. First, the server must have networks or gateways defined in its routing table so it can make an informed decision where the packet needs to be passed to. Second, the server must have packet forwarding enabled. Thirdly, if the routed packets came from an RFC1918 private subnet, they must be translated into globally routed IP addresses (NAT covered later) before they will be accepted out on the Internet.

Packet forwarding can be enabled either manually as required by the superuser, or automatically when the system starts the networking service. To manually enable or disable packet forwarding, use the respective commands listed below.

[bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# echo 0 > /proc/sys/net/ipv4/ip_forward

To enable automatic packet forwarding for whenever the network service is active, make the following changes in your /etc/sysctl.conf file.

[bash]# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

It is common practice for users to have manual control over packet forwarding, and to active or disable the function within their firewall control scripts. However setting packet forwarding to start automatically will be more suitable for a dedicated server.

Packet Filtering
Packet filtering is also a reasonably simple concept (true), however it can be very daunting for new users that don't fully understand how it works, so let's cover the basics first and build it up.

In packet forwarding the kernel is either allowed to move packets between different subnets or is not, and if it is, the decisions are made from the kernel's routing table. In packet filtering an application called iptables (http://www.netfilter.org/) stores a list of programmed rules which are individually tested against every packet that either tries to enter, pass through, or exit any of the system's network devices. Each rule is used to test the packet in a sequential order and if the packet matches any of the rules it is either accepted or rejected depending on the global policy and rule definitions. iptables is your firewall application and is one of the networking frameworks for your Linux kernel.

iptables essentially has this name because it stores the rulesets into a group of three tables which each provide different capabilities depending on the rules and the order they are applied. We will only examine the filter and nat tables here, the mangle table is used for specialised packet alteration which is beyond our scope. The following table displays the filter iptables and the three built-in chains.

Table Name	Chain Name	Chain Details
filter	INPUT	For any packet coming into the system
	FORWARD	For any packet that is being routed through the system
	OUTPUT	For any packet that is leaving the system

To list the filter table and its rules you can use the following command.

[bash]# iptables -t filter -nvL

The filter table is the default table when working with iptables, so there is no need to add '-t filter' at the command prompt.

[bash]# iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target - prot - opt - in - out - source - destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target - prot - opt - in - out - source - destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target - prot - opt - in - out - source - destination

You should see an output similar to above, if not then stop the iptables service and output the table again. From the listing you can see the three built in chains, and their default policies are all set to ACCEPT, which means the firewall is inactive.

[bash]# /etc/init.d/iptables stop

The output from the top listing does not provide much information, so let's populate the table with some of our own rules. Type the following commands at the prompt then output a listing of the table again.

01- [bash]# iptables -P INPUT DROP
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT DROP
04- [bash]# iptables -A INPUT -i lo -j ACCEPT
05- [bash]# iptables -A OUTPUT -o lo -j ACCEPT
06- [bash]# iptables -A INPUT -i ppp0 -p tcp --sport 80 -j ACCEPT
07- [bash]# iptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT
08- [bash]# iptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 3128 -j ACCEPT
09- [bash]# iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -p tcp --sport 3128 -j ACCEPT

[bash]# iptables -nvL

01-

04-
06-
08-

02-

03-

05-
07-
09-

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target  prot opt in  out  source          destination
    0     0 ACCEPT  all --  lo   *   0.0.0.0/0       0.0.0.0/0
    0     0 ACCEPT  tcp --  ppp0 *   0.0.0.0/0       0.0.0.0/0   tcp spt:80
    0     0 ACCEPT  tcp -- eth1 *   192.168.1.0/24  0.0.0.0/0   tcp dpt:3128

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target  prot opt in  out  source          destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target  prot opt in  out  source          destination
    0     0 ACCEPT  all --  *   lo   0.0.0.0/0       0.0.0.0/0
    0     0 ACCEPT  tcp --  *   ppp0 0.0.0.0/0       0.0.0.0/0      tcp dpt:80
    0     0 ACCEPT  tcp --  *   eth1 0.0.0.0/0    192.168.1.0/24 tcp spt:3128

The nine commands which you typed above have been numbered along with their output so they can be easily identified in the second table.

Lines 01-03: The first three commands set the default (-P) policy on all the chains to DROP everything, unless suitable rules inside the chain will ACCEPT them. This is the most secure method of filtering as any packet that is now to pass through any of the chains, must have a specific rule written for it.

Lines 04-05: These two commands have (-A) appended two ACCEPT rules. The OUTPUT rule (05) allows any packet to (-o) leave via the loopback device and the INPUT rule (04) allows packets to re-enter (-i) via the loopback.

Because the chains are using a default DROP policy, they restrict the server from accessing any of its own services running on the local host, like DNS. A basic rule like this allows the server to access all loopback services without restriction.

Lines 06-07: The next two (-A) appended rules are more specific, lets look at the outbound one first. The OUTPUT rule (07) specifies that any packet going out the (-o) ppp0 interface using (-p) protocol TCP is ACCEPTed if its going to port 80. The INPUT rule (06) specifies that any packet coming in the (-i) ppp0 interface using (-p) protocol TCP is ACCEPTed if its coming from port 80.

You should be able to pick this up, it says that we are allowed to access external web servers from our own server, but there are no forward rules for the internal network to surf the Internet. We should also allow our internal network the ability to access external web servers too shouldn't we? Let's look at the next rules then.

Lines 08-09: The last INPUT rule (08) which has been (-A) appended to the chain allows any packets from the (-s) source network of 192.168.1.0/24 if they enter through the (-i) eth1 device and if they are the TCP (-p) protocol and are going to the (--dport) destination port of 3128. The matching OUTPUT rule (09) has been (-A) appended to the chain and allows any packets that are going out (-o) the eth1 interface to (-d) destination network 192.168.1.0/24 using the TCP (-p) protocol if it came from the (--sport) source port of 3128.

These two are fairly detailed rules, they say that anyone on the internal network (192.168.1.0/24) is allowed to send packets to the squid proxy server (3128) through the internal eth1 interface and the results can be returned to the workstation.

If you use a strict DROP policy like above, its important to note that you may need two rules that complement each other in order for data to flow out and back in again.

A Walk Through

To better understand the above filtering example, its best to walk the configuration through the same way a packet would be subject to the filtering table's definitions, one rule at a time. Remember, every packet of data has certain attributes, source/destination addresses, source/destination ports, the interfaces they are coming in and out and the type of protocol being used, the filtering will reject any packet whose attributes dont match any of the rules in our chains.

A person using the workstation (in the network example below) wishes to access the resources of the web server located on the Internet, can a direct connection be established? No, all the policies are set to DROP and there is no FORWARD rules defined, so it simply can not occur.

Can the proxy server access the web server on the Internet? Yes, the proxy server has the rights to access anything which is TCP based operating at port 80 out through the ppp0 link, which is to a web server. Can you see the ACCEPT rules for the packet's attributes in the complementing INPUT and OUTPUT chains?

The only way now for the workstation to access anything, is via the proxy server application running at port 3128, which in turn can access any web server resources on the Internet and return the requested information to the workstation. Are the required rules in the table?

How does this work without any forwarding rules? Easy, the proxy server is an application that requests resources on behalf of a client, so the request comes into the proxy from the client, and now the request goes out to the web server from the proxy, as though it was requesting the information itself. This happens at the application layer, because its the proxy application which forwards the clients original request, so forwarding at the IP layer is not required here.

Hopefully you have been able to pick up the filtering concepts mentioned above, if you have, well done. The proxy server situation was a little tricky, but was introduced to give you an understanding that particular packets and resources can still be shaped to suit your security requirements by incorporating them into your network design.

Thats a brief introduction to packet filtering, the ability to write and chain together rules that selectively accept or deny any packets that do not meet the security requirements for your network.

What happens to the filter table when you type these following commands? View the table's output after each one and see if you can recognise the effects of the rules, and which direction the packets can pass (i.e., are they going to an internal or external resource). View "man iptables" for further assistance.

[bash]# iptables -I INPUT 2 -i ppp0 -p tcp --dport ftp -j ACCEPT
[bash]# iptables -I OUTPUT 2 -o ppp0 -p tcp --sport ftp -j ACCEPT

[bash]# iptables -D INPUT -i ppp0 -p tcp --sport 80 -j ACCEPT
[bash]# iptables -D OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT

[bash]# iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
[bash]# iptables -A OUTPUT -p icmp --icmp-type any -j ACCEPT

[bash]# iptables -I INPUT -m state --state INVALID -j LOG --log-prefix "INVALID Input: "
[bash]# iptables -I INPUT -m state --state INVALID -j DROP

[bash]# iptables -F
[bash]# /etc/init.d/iptables restart

Network Address Translation

Network Address Translation (NAT) is the ability to change a data packets destination or source IP address on-the-fly, so the packet looks like it came from (or is going to) a different address than the original (also works on port numbers).

There are many reasons why we should use NAT, here are a few:

Frees the requirement to use large amounts of 'real' IP addresses (cheaper),
Allows packets from a private (RFC1918) network to be globally routed out to the Internet,
Allows packets on the Internet to be routed into a private (RFC1918 network,
It masks the true amount of private workstations, as all external traffic appears to come from the one source,
It allows inbound traffic to be sent to different internal hosts (bastions) depending on the resources requested, and
It does not disclose any security details of the internal private network.

The iptables package also provides support for NAT and has a built-in nat table just for that purpose. Below is a listing of the default chains that are found in the nat table and an explanation of how they are applied.

Table Name	Chain Name	Chain Details
nat	PREROUTING	For altering packets as they are entering the system (before filter INPUT)
	POSTROUTING	For altering packets as they are exiting the system (after filter OUTPUT)
	OUTPUT	For altering packets before leaving the local system (before the routing table)

As the naming suggests, the PREROUTING and POSTROUTING chains are applied before or after any kernel routing decisions are made, so the packets can then be routed to match any new changes which have been made to the destination or source addresses. To list the contents of the nat table, issue the following command at the prompt.

[bash]# iptables -t nat -nvL

Source NAT Source NAT deals with changing the source address of any packets that pass through the NAT device, assuming they meet the criteria of the specified policies and chains. This allows workstations on a private network to send data packets through the NAT device which changes the source address in the packet's header before sending the packet onto the Internet. When the packet reaches its destination and is processed, the distant host returns the packet using the adjusted address as the new destination address, and delivers it back to the NAT device. The NAT device stores a list in memory of all the packets it adjusts, so when they are returned, the packets can be redirected to the real originator of the packets on the internal private network. Source NAT can be written for inbound and outbound packets, but are more commonly used for outbound. For a packet to be subject to SNAT, lets consider the following details:

The packet has meet at least one rule in all three filter chains (INPUT, FORWARD, OUTPUT),
The packet has been checked against the kernel routing table, and a decision on where to route has been made,
As the packet leaves the NAT device, the source address is changed to the NATs external IP address,
The NAT device remembers the real owner of the packet.

It all sounds rather confusing, so lets go straight to an example. Type the following rules at the command prompt and then display the contents of the filter and nat tables with the last command (typed as one line).

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
05- [bash]# iptables -A FORWARD -i ppp0 -o eth1 -d 192.168.1.0/24 -p tcp --sport 80 -j ACCEPT
06- [bash]# iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j SNAT --to-source 123.123.123.2
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target   prot opt in    out    source        destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in   out   source         destination
   0    0   ACCEPT tcp -- eth1 ppp0 192.168.1.0/24 0.0.0.0/0    tcp dpt:80
   0    0   ACCEPT tcp -- ppp0 eth1 0.0.0.0/0    192.168.1.0/24 tcp spt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out   source         destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out   source         destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out source         destination
   0    0   SNAT   all -- *   ppp0 192.168.1.0/24 0.0.0.0/0 to:123.123.123.2

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out source         destination

Line 06: This rule is our solution to the above problem. This rule is applied after the routing decisions have been made and the packet is about to depart for the web server out on the Internet. It says, any packet that goes (-o) out the ppp0 interface from the (-s) 192.168.1.0/24 network is to have the source address rewritten as 123.123.123.2. Now when the packet reaches the Internet web server, it can be processed normally and returned to 123.123.123.2 (the NAT device), where it will automatically be rewritten again and sent back to the original workstation on the internal private network. Line 07: This command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets. Some important points about SNAT to remember are:

SNAT is used in the POSTROUTING chain after the kernel routing decisions have been made,
Forwarding rules need to be suitable to allow packets in both directions,
The "--to-source" address should be the external IP address which will be visible on the packets return, and
SNAT should not be used for dynamic links where the IP address is likely to change (see masquerading, next).

IP Masquerading Put simply, masquerading is a form of SNAT which should be used for all dynamic interfaces where the IP address is likely to be different each time we connect. This is perfect for our dynamic IP broadband accounts, and saves having to rewrite large SNAT rules each time we connect to the Internet. SNAT remembers connection state information (to a degree) if a static connection was to drop, however using masquerading the connection state information is reset each time the interface is (de)activated. Masquerading automates SNAT for dynamic IP connections. Because masquerading is so easy (true) we are going to use some state tracking attributes in our rules. Type the following rules at the command prompt and display a listing of the filter and nat tables.

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
05- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
06- [bash]# iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out source          destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in   out source         destination
   0    0   ACCEPT all -- ppp0 *   0.0.0.0/0      0.0.0.0/0 state REL,ESTAB
   0    0   ACCEPT tcp -- eth1 ppp0 192.168.1.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out source         destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out source         destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target      prot opt in   out source         destination
   0    0   MASQUERADE all -- *    ppp0 192.168.1.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target      prot opt in   out source         destination

Lines 01-03: The first three commands have now defined the global policies for the three built-in chains for the filter table. To keep the example a little easier to understand, we are going to accept everything that is classed as INPUT or OUTPUT, and for security we are dropping anything trying to pass through (FORWARD) the NAT unless we explicitly allow it. Line 04: Rule 04 deals with the connection state and says, any packet that comes in the (-i) ppp0 interface must (-m) match a certain state, and the state must ensure the packet is in response to an already RELATED or ESTABLISHED connection. Basically only allow packets to be forwarded into the private network if the packet is in response to an already RELATED or ESTABLISH connection. This rule will not allow any NEW connections to be initiated from the external network a connection must already existed, so any packet coming inside will be in response to a current connection that could have only be initiated from the internal network. Line 05: This is a simple rule that will forward any packets from the (-i) eth1 interface and out the (-o) ppp0 interface if they are from the (-s) 192.168.1.0/24 source network. This is rule does not detail any connection state so it will allow all connection types, but most important is the NEW connection state that it can pass. This rule allows internal workstations to create new connections, and matches rule 4 which allow the packets to return. Line 06: This rule does the exact same as if it were a SNAT rule, however being a MASQUERADE rule means it will use the IP address that is currently assigned to the ppp0 interface when the packet passes through the NAT device. Any packets that now pass from the internal private network out into the Internet will have its source address rewritten as the external IP address of the NAT device. Line 07: This command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets. Remember, masquerading should always be used for dynamic IP connections. Dangerous Masquerading Rule Beware of this rule, it is too relaxed and does not specify which direction the packets should be masqueraded. In fact, this rule allows masquerading in BOTH directions. Always specify an (-o) out interface parameter to make the rule work in one direction only.

[bash]# iptables -t nat -A POSTROUTING
-j MASQUERADE

[IMG]http://i240.photobucket.com/albums/ff240/jagoanneon09/Tutorial/warning0.gif[/IMG]

WARNING: The above rule is dangerous, it allows masquerading in both directions.

Destination NAT Destination NAT deals with changing the destination address of any packets before they are subjected to any routing decisions. This allows specific traffic to be rewritten so it suits a particular rule and can then be redirected depending on the global policies and destinations required. In its most typical application, DNAT is normally used to change incoming packets that are destined for a particular service or host, and it rewrites the destination addresses so the packets can pass to a different host located inside the private network, normally a DMZ. When DNAT occurs, the original host (which is located external of the private network) is not aware the packets have been redirected and that the returning data is from a different server. It should be transparent to the originator. The following commands can be typed at the command prompt, and the filter and nat tables displayed using the last command.

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
05- [bash]# iptables -A FORWARD -i ppp0 -o eth1 -p tcp --dport 80 -j ACCEPT
06- [bash]# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target   prot opt in     out   source      destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target   prot opt in   out source         destination
   0    0   ACCEPT   all -- eth1 ppp0 192.168.1.0/24   0.0.0.0/0
   0    0   ACCEPT   tcp -- ppp0 eth1 0.0.0.0/0   192.168.1.0/24 tcp dpt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target   prot opt in   out source         destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target   prot opt in   out source    destination
   0    0   DNAT     tcp -- ppp0 *   0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.1.2:80

Chain POSTROUTING (policy ACCEPT 0
packets, 0 bytes)
pkts bytes target     prot
opt in     out
source
destination

Chain OUTPUT (policy ACCEPT 0 packets, 0
bytes)
pkts bytes target     prot opt
in     out
source
destination

More...

Sunday, November 15, 2009

Linux Home Server HOWTO
Chapter 4 - Network Configuration

In this chapter we will look at the configuration of ethernet networking devices, the procedures for starting and stopping the interfaces, and some basic routing principles. If you only have one computer which you are using for your server and workstation (not ideal, but possible), then you may not have a network device to configure if you are using a USB modem.

Loading the Drivers
An operating system needs to work effectively with the hardware on the host computer, to achieve this it communicates with the internal devices using custom software which details the device's operational parameters. This small piece of software is called the device driver, and it needs to be loaded into the kernel before the devices will function effectively.

To load the network drivers automatically, they are placed into the /etc/modprobe.conf file so the modprobe application can load the drivers into the kernel in an intelligent fashion as required; normally by starting the network service.

The example modprobe configuration below is loading two sets of Realtek drivers r8169 and 8139too. Both of the drivers have been assigned an alias called eth0 and eth1 respectively. It is common during manual system configuration, that the drivers may be accidentally allocated the incorrect aliases. This is a simple issue to fix by swapping which drivers are allocated to which "eth" alias.

[bash]# vi /etc/modprobe.conf

alias eth0 r8169
alias eth1 8139too

Device drivers may be added manually as extra devices are installed.

This HOWTO assumes the eth0 device will be located on the external (public) network.

You may also note that both IPv4 and IPv6 are fully active on your fresh Linux installation. If you want to disable IPv6 and only run IPv4, you can add the following entry to your "/etc/modprobe.conf" file (this will require a system reboot).

[bash]# vi /etc/modprobe.conf

alias net-pf-10 off

Internal Network Device
The configuration files and initialisation scripts for all of the networking devices are located in the /etc/sysconfig/network-scripts directory, and can easily be edited to adjust the parameters for each device.

The following configuration file for the eth1 device resembles a typical setup.

[bash]# vi /etc/sysconfig/network-scripts/ifcfg-eth1

# Internal Ethernet Device (STATIC)
DEVICE=eth1
TYPE=Ethernet
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
USERCTL=no
BOOTPROTO=static
PEERDNS=no
HWADDR=00:0D:61:67:D0:B2 <-- Adjust this, or leave MAC address blank.
IPV6INIT=no

This device is configured with the internal parameters used for the home network. Some minor points to note about the configuration file are:

ONBOOT	Specifies whether the devices should start when the system starts (depending on network service)
USERCTL	Directs that only root, or all system users can control the device
BOOTPROTO	The protocol type used to initialise the device (static \| dhcp \| none)
PEERDNS	Import the DNS nameserver settings into /etc/resolv.conf (careful if running own DNS)
HWADDR	Binds the physical MAC address of the device - see caution below

Using the HWADDR parameter may cause problems if the MAC address does not match the intended device. For example, changing the physical devices or the name of the alias in /etc/modprobe.conf file. Leave this parameter blank if problematic and adjust later as required.

Some of the older style parameters like NETMASK and BROADCAST have been deprecated because they can be calculated by the system with the ipcalc command.

The /etc/sysconfig/network file contains basic information about the network in general. The GATEWAYDEV variable should specify which network device will be the gateway to the Internet when the network is fully functional (this may even be the "ppp0" device if using a modem connected to your ISP as your gateway).

[bash]# vi /etc/sysconfig/network

# Network Details
NETWORKING=yes
HOSTNAME=galaxy.example.com
GATEWAYDEV=eth0

External Network Device

The system being used as the gateway server will require at least two networking devices if the internal (private) network is going to be separated from the Internet, this will maintain a level of security for the private network. The external device may be another network card, broadband DSL/Cable modem, or another capable device.

The following configuration details the eth0 device is bound to MAC 00:00:21:E0:B8:B9, will be using the dhcp protocol, will not import the peer DNS settings, and will start up as the system boots. This configuration may be typical of a broadband modem that supplies an IP address to an internal host.

[bash]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

# External Ethernet Device (DYNAMIC)
DEVICE=eth0
TYPE=Ethernet
IPADDR=
NETMASK=
ONBOOT=yes
USERCTL=no
BOOTPROTO=dhcp
PEERDNS=no
HWADDR=00:00:21:E0:B8:B9
IPV6INIT=no

Starting the Interfaces

After the networking devices have been configured on the server, its time to start the interfaces to test if they are functioning. Network devices can be brought to the 'up' (active) state by using either of the following two commands if assigned a static IP address.

[bash]# ifup eth0
[bash]# ifconfig eth0 up

Alternatively, the following two commands will activate a device that is configured with a dynamic IP address.

[bash]# ifup eth0
[bash]# ifconfig eth0 dynamic up

Be sure to check the system log /var/log/messages to see if the devices are functioning as expected.

[bash]# tail /var/log/messages

The devices can also be put in the 'down' (inactive) state using either of these two commands.

[bash]# ifdown eth0
[bash]# ifconfig eth0 down

To enable the networking service to start automatically at boot time, use the chkconfig command to specify which runlevels the network service will be active. The service should also be tested with the initscripts by restarting the network service.

You should not need to do this however, as the network service should already to configured to run at startup automatically.

[bash]# chkconfig --level 2345 network on
[bash]# chkconfig --list network
[bash]# /etc/init.d/network restart

All going well, the network cards that have been configured are working correctly and the configurations can be checked with the following commands. This will display general configuration details about the interface, like the IP address, netmask address, and various packet counters.

eth1 Link encap:Ethernet HWaddr 00:0D:61:67:D0:B2
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:4812 (4.6 KiB)
Interrupt:217 Base address:0xd000

Earlier on, the interfaces where configured using the setup files located in the /etc/sysconfig/network-scripts directory. The ifconfig command also allows the interfaces to be configured from the command line which allows quick initialisation if the configuration files are not available, or if the settings in the file need to be overridden for a short time, like in the following example.

[bash]# ifconfig eth1 inet 192.168.1.1 broadcast 192.168.1.255 netmask 255.255.255.0 up

Type 'man ifconfig' for more information on the interface configurator.

IP Routing Table

Before you send a letter to a colleague, you must write the destination address on the front of the envelope so that postal workers know where it needs to be sent. You also need to place your own address on the back of the envelope so the sender can reply to your letter, or in case it needs to be returned for some reason.

Sending packets of information across the Internet is based on the same principles; the packets need a destination and source address so the communicating entities can exchange data. When your local workstation sends a packet of information, it checks its local routing table to see if the packet's destination address is directly connected to any of its interfaces, if so it sends the packet directly out the correct interface and onto that host. If the packet is not destined for the local network, then the workstation searches the routing table for a routing device (gateway) that will take the packet for further processing; possibly outside and off to the Internet. If a gateway does not exist in the routing table, then the local workstation has no option but to reject sending the packet because it does not know where to send it.

Below is a basic diagram showing a server with two network devices, each connected to separate networks; eth1 to the private internal network, and eth0 to the ISP which is connected to the Internet.

If the server needs to send a data packet to address 192.168.1.15, it will deliver the packet out eth1 directly to the host in the private network. However, if the server now needs to send a packet to the 123.123.xxx.xxx network, then it can not decide which interface to send the packet, so it will be rejected.

By checking the routing table on the server, we can see there is no gateway device configured.

[bash]# route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.214.64.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1

This can be fixed by providing the routing table with a known gateway device using the following command.

[bash]# route add default gw 10.214.64.254 dev eth0

The server has now been configured with a gateway device, so any packet of information that will not be delivered locally, will be transferred to the ISPs router at 10.214.64.254 for further processing. The ISPs router will then check its routing table and so forth through the Internet until the packet reaches its final destination.

During the configuration of the global network settings, each attached device (ethernet, modem, etc..) can be configured to act as a default gateway when the device is in the active state.

ZEROCONF
Most Linux distributions utilise the Zero Configuration Network (ZEROCONF) automation suite. This is an IETF workgroup that planned and coordinated a series of dynamic configuration protocols to allow many operating systems to automatically configure themselves and communicate on a network without the need of DHCP or DNS servers. ZEROCONF utilises the 169.254.0.0/16 network address to autoconfigure using a series of unanswered "ARP" queries and then assumes an address if the queries yield an empty result.

A route to the ZEROCONF network is added to the routing table by the network initscripts.

[bash]# route -n

ZEROCONF can be turned off by adding the following entry to the "/etc/sysconfig/network" configuration file.

[bash]# vi /etc/sysconfig/network

NOZEROCONF=yes

The value for the "NOZEROCONF" parameter can actually be set to any value, the initscripts only check to determine whether the parameter has zero length. So setting "NOZEROCONF=no" will have the same effect as setting it to "yes". You will need to comment or remove the variable to reactive ZEROCONF.

The networking service will need to be restarted before the changes will take effect.

[bash]# /etc/init.d/network restart

Checking the network routing table again will identify the ZEROCONF route has been disabled and removed from the routing table.

[bash]# route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.214.64.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 10.214.64.254 0.0.0.0 UG 0 0 0 eth0

ZEROCONF is also commonly referred to as IPv4 Link-Local (IPv4LL) and Automatic Private IP Addressing (APIPA).

More...

Linux Home Server HOWTO
Chapter 3 - Installing Linux

This chapter has Fedora Core 5 specific installation information.

Pre-Installation Requirements (Checklist)

In the last chapter we identified some of the planning considerations needed before we even commenced with our server installation. Now we are ready to start configuring our system, we must make sure we have all the configuration settings available during the installation process, so it runs smoothly and is trouble free.

The following checklist can be used as a printable guide to document your configurations before you start your installation. It is intended as a guide only, but is typical of the information required during a system installation.

Server Settings	Example Values	Your Parameters (as applicable)
Kernel Parameters	Nil	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Install / Upgrade	Install	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Installation Type	Server	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Partitioning - Auto / Manual	Auto	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Hard Drive 0	/dev/hda	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Hard Drive 1	/dev/hdb	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Hard Drive 2	/dev/sda	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- DVD/CDROM	/dev/hdc	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- DVD/CD Burner	/dev/hdd	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
GRUB Boot Loader Installed	/dev/hda	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
External Network Device - eth0
- IP Address	Dynamic	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Subnet Mask	Dynamic	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Internal Network Device - eth1
- IP Address	192.168.1.1	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Subnet Mask	255.255.255.0	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Modem Settings
- IP Address	Dynamic	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
- Subnet Mask	Dynamic	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Fully Qualified Hostname	galaxy.example.com	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gateway	Nil	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Primary DNS	127.0.0.1	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Secondary DNS	Nil	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Internet Settings		Your Parameters (as applicable)
ISP Name		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ISP Account Name		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ISP Account Password		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Static IP / Subnet	Or DHCP	_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
DNS Server 1		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
DNS Server 2		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
DNS Server 3		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
NTP Server		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Helpdesk Phone Number		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Installation Procedure (Step by Step Guide)
Now that we've completed all of our system planning and our checklist has been prepared, we are now in a position to start installing the operating system and required packages on our server - finally some 'hands on' you say.

The following installation procedure has been written as a step by step guide to fulfil the configuration and package requirements needed in the HOWTO, some people may find it too basic and you are welcome to skip ahead. However please review the list of packages being installed below, this may save you installing them later because they were missed.

The step by step guide is written for Fedora Core 5 and may not be suitable for other Linux Distributions.

1. Once the bootable DVD/CD initialises and the installation process starts execution, you will be presented with the Fedora Core welcome page, and a "boot:" prompt will be located at the bottom of the screen. The boot prompt allows us to pass specific parameters about any hardware or configuration settings to the kernel. It also allows us to specify that we may have a driver disk for some type of hardware that is not yet supported by the kernel, like a network card or hard drive controller. You may also choose to upgrade an existing version of Fedora from the prompt.

boot: linux dd noprobe acpi=off

Example: The boot prompt with parameters being passed to the kernel.

If you are doing a clean installation of Fedora Core, you would most likely press the key at the "boot:" prompt to continue.

2. If you chose to install a driver disk, you will now be prompted for the diskette. Insert the diskette and follow the directions on screen to install the extra drivers if applicable.

3. You will now be presented with an option to check the integrity of the DVD/CD media you are using to conduct the installation. It is highly advisable to test the media at this point. If your media is scratched, or the integrity of the ISO image was corrupted during its download, then it is highly likely that the installation may stall or become unstable. If in doubt check your media, it only takes a few minutes, and may save you the anguish of having to conduct a second installation attempt.

You will be advised of any failed media checks during this stage, at which point you will need to correct the media problem before continuing.

4. Welcome to Fedora: The next stage in the installation is the loading of the Anaconda system installer, where you will be presented with installation options using an Xwindows frontend. We will continue to use the Anaconda interface throughout the entire installation process.

The release notes will be available for you to view if you choose, which is recommended. They identify what the minimum hardware specifications are for an installation of Fedora Core, and which applications have been added, changed, or removed from the previous version. They also identify and provide solutions to any known bugs which may affect certain hardware, or installation errors that may occur during or after the installation process.

After you have read the release notes, you may select to continue.

You can choose not to use Anaconda for your installation, or you may have difficulty loading the interface if your video card is not yet supported. If this is the case, you can continue your installation using the standard text mode.

The Anaconda installer provides documented help files for the remainder of the installation process. It is recommended you consult these help files when you are uncertain and require further clarification.

5. Language Selection: You will now be asked to choose the language you would like during the installation, make your selection and press to continue.

6. Keyboard Configuration: You are also presented with an option for keyboard, make your selection and press to continue.

7. If you had any previous installations of Fedora Core on the server, Anaconda will detect them and ask you if you would like to conduct a fresh installation, or you would like to upgrade your existing version of Linux. Make your selection and press to continue.

If you have an existing version of Fedora installed, choosing to install a fresh version will destroy the existing installation depending on your configuration choices.

8. Disk Partitioning Setup: As part of our server planning considerations we should consider how we are going to partition the filesystem. If you are an experienced installer or you are doing an upgrade of some type, you may choose to partition your system manually. Otherwise choose "Remove all partitions on the selected drives and create default layout" and press . WARNING - This will delete all partitions currently on your server.

Manual partitioning is outside the scope of this HOWTO, however you can select the "Review and modify partitioning layout" checkbox if you would like to manually configure or review your server's partitions; this is recommended.

9. Disk Setup: This page allows you to review your new partitions and the filesystem types that have been automatically chosen by the installer. There are many options available here to fully customise your hard drives with your filesystem requirements, but if you are not familiar with partitioning, then the automatic configuration should be fine.

Make any changes that you need and select to continue.

10. Boot Loader Configuration: To boot your system when its turned on, a small application needs to be installed in the Master Boot Record to tell the computer's BIOS where to continue loading the operating system files from, this is part of the bootstrap process. Fedora uses an application called GRUB (the GRand Unified Bootloader) for this process, and if you have a standard IDE hard drive configuration, the boot loader is normally installed on "/dev/VolGroup00/LogVol00".

As with step 1, the boot loader can pass extra parameters to the kernel during the boot process. If you need to pass any parameters at boot time and you would like to automate the process, then select "Configure advanced boot loader options". The GRUB configuration can be edited at a later time if needed.

11. Network Configuration: This page allows us to configure the networking requirements of our server.

Depending upon the network topology being implemented, we may either have one or two network devices to install. Remembering that eth0 is connected to the external "Internet" connection; the side where hackers and nasty people lurk.

Device: eth0	Parameters
- Activate on Boot	Yes
- Configure with DHCP	Yes
- IP/Netmask	DHCP

If there is a second network device (eth1), use the following parameters to configure the device.

Device: eth1	Parameters
- Activate on Boot	Yes
- Configure with DHCP	No
- IP Address	192.168.1.1
- Netmask	255.255.255.0

You now need to set the fully qualified hostname of the server and other miscellaneous settings, remembering to use the host and domain names applicable to your system.

Description	Value
- Hostname (manually)	galaxy.example.com
- Gateway	Empty
- Primary DNS
- Secondary DNS	Empty
- Tertiary DNS	Empty

You will get an error at this point because we have not set a gateway address for the server, this will be addressed during later configurations. If you are using a static IP address for your external device and you already know your gateway address, you can enter these details now.

12. Time Zone Selection: Use the image of the world map to select the required timezone in your nearest location. You may also choose (optional) to operate your server using the Universal Time Clock, however most people will operate using the time in the current location.

13. Set Root Password: It is important to select a secure password for the super user using a mixture of upper and lower case letters, numbers, and special keyboard characters. The stronger and more complex your root password is, the less chance your system will fall victim to a brute force type attack.

14. Default Installation: We are now going to select what programs and applications (packages) are going to be installed on our server, remove all checkboxes and select "Customise Now" to select individual packages. Select to continue.

15. Package Group Selection: This is the point where we can tailor the installation to our specific needs by adding or removing certain applications and packages. This HOWTO was written to cover specific applications and services that best suits a typical small network, and the installation requires the following additional customisations to meet the server's package requirements.

The following list details additions on top of the packages already chosen. Do not remove packages that are not listed.

Desktop Environments

GNOME Desktop Environment	Selected by default
KDE (K Desktop Environment)	Add Tick - Defaults are Suitable

Applications

CEngineering and Scientific	Add Tick - Defaults are Suitable
Graphical Internet	Add Tick
- Additional Packages	gftp
	thunderbird
Sound and Video	k3b
	xcdroast

Development

Development Tools

Add Tick - Defaults are Suitable

Servers

DNS Name Server	Add Tick - Defaults are Suitable
FTP Server	Add Tick - Defaults are Suitable
Mail Server	Add Tick
- Additional Packages	squirrelmail
MySQL Database	Add Tick
- Additional Packages	mod_auth_mysql
	php_mysql
Network Servers	Add Tick
- Additional Packages	dhcp
	openldap-servers
Server Configuration Tools	Add Tick
- Additional Packages	Select all (as required)
Web Server	Select all (as required)
Web Server	Add Tick
- Additional Packages	mod_auth_mysql
	mod_authz_ldap
	php_ldap
	php_mysql
Windows File Server	Add Tick - Defaults are Suitable

Base System

Base
- Additional Packages	authd
	anetconfig
- REMOVE PACKAGE	dhcpv6_client
System Tools	Add Tick
- Additional Packages	arpwatch
	gnutls-utils
	mrtg
	net-snmp-utils
X Window System
- Additional Packages	switchdesk

Languages - Select additional languages as required.

Once you are satisfied with your selections you may continue.

16. About to Install: If you have selected any additional packages and have triggered a "dependency error", select the option to install the required dependencies and continue the installation process.

17. Installation Stage: The system will now go through the process of formatting your partitions and installing the selected packages. This stage may take a few minutes and is a good time for a break. If you are installing from the CD set, you will be required to change CD during the installation.

18. Installation Complete: The DVD/CD will be automatically ejected from its drive once it has finished installing all the required packages, removed the media from the drive bay and select .

Congratulations, the majority of the installation has been completed and the server is almost ready for configuration.

Post Installation Tasks
Once the Fedora Core operating system has been installed and the system has been rebooted, there are some minor configurations required before you can log into and start using the system. The firstboot process will now guide you throught the following steps.

1. Welcome: Select to start the post installation process.

2. License Agreement: Read and accept the license agreement.

3. Firewall: Accept the default firewall settings here, we will configure a more detailed firewall configuration later in Chapter 6
4. SELinux: Select the appropriate SELinux settings for your server. If you are unsure here, select "permissive" and click .

5. Date and Time: Select the appropriate date and time for your server system, depending upon your earlier selection of either local or universal timezones.

Do not enable Network Time Protocol yet, it will be configured in more detail later in Chapter 9

6. Display: Configure the X Windows Server with the appropriate settings for your, monitor type, display resolution and colour depth. Being a dedicated server it does not need the latest video drivers for 3D graphics.

7. System User: Enter the details of your generic user account. It is recommended (and good practice) that you use a generic user account at all times, and only switch to the super user account when the higher privileges are needed for administrative tasks.

8. Sound Card: Make the required adjustments for your soundcard and continue. Being a dedicated server it does not need a sound card at all, however you may be able to configure some basic sound files to some of your administrative tasks or alerts to give you a warning when certain events occur.

9. Finish Setup: The entire installation process has now been completed, press to continue to the login screen.

Automated Installation

During the installation phase, the Anaconda system installer creates a "kickstart" configuration file containing all the settings used during your server's build phase. It details the partition types, network settings, packages to install, and pretty much everything that was covered throughout the last two sections. The kickstart file can be used to rebuild your entire system automatically, and is a good way to recover from a system failure.

Backup the configuration file to floppy disk, label it, and store the disk in a save location - hopefully you won't need to use it.

[bash]# mcopy /root/anaconda-ks.cfg a:

You need to be logged in as root (after installation) to backup the kickstart config file.

To later rebuild your system using your kickstart configuration, you need to pass the following kernel parameters at the boot prompt. This will start an automatic installation process using your previous settings, and will stop only to prompt for partitioning information.

boot: linux ks=hd:fd0/anaconda-ks.cfg

For further details on using kickstart and the different build options available, visit the Red Hat Kickstart Guide.

Setting Default X Windows
When you log into your new server for the first time, the initial X Windows Manager that loads will be the GNOME Window Manager. You can change the default X Windows Manager display at the login screen by selecting the session tab and changing to the appropriate Window Manager.

The Window Manager can also be changed at the command line interface after logging in, by typing one of the following commands at the prompt:

[bash]# switchdesk gnome

[bash]# switchdesk kde

Your default settings will now be saved, however you will need to restart the X Windows Server before the settings are applied. This can be done quickly by pressing CTRL+ALT+BACKSPACE.

More...

Thursday, November 12, 2009

Linux Home Server HOWTO
Chapter 8 - Domain Name System (BIND)
Version: - bind 9.3.2

The Domain Name System (or Service) provides a naming resolution service that makes it easy for us humans to use the Internet, among other tasks. Every computer located on the Internet that is publicly accessible uses an unique Internet address, but these Internet addresses are numerical in nature and difficult to remember. To download the latest Linux kernel I point my browser to http://www.kernel.org/, but the server is located at the Internet address of 204.152.191.5, I know which address I would prefer to remember.

The global DNS provides listings for publicly accessible addresses. If you need to access any computer resources inside your own network and your network is using RFC1918

This chapter will provide the steps necessary to configure your own DNS server to assist in internal name resolution and to provide a caching service for external domains. The Berkeley Internet Name Domain (BIND) software is installed on most Linux distributions, and is also available from the Internet Systems Consortium site.

If you are using a dynamic IP address and you would like to host your own website and email servers, then you will also need to review the Dynamic DNS details in Chapter 5.

Initial Configuration
For a Linux host to use DNS, the system resolver must be told which name servers to use. This information is stored in the /etc/resolv.conf file. As with any configuration, we should always backup the original configuration file before editing it.

[bash]# cp /etc/resolv.conf /etc/resolv.conf.original
[bash]# vi /etc/resolv.conf

The resolver on the new DNS server needs to be adjusted so it points to itself for name resolution. Be sure to substitute "example.com" for the domain(s) you are configuring.

search example.com
nameserver 127.0.0.1

The search parameter defines a list of domains that will be searched when doing hostname queries. The nameserver parameter lists the DNS servers that the host should use for name resolution, in this case itself.

For more information on the system resolver, type "man resolv.conf" at the command prompt.

Setting Daemon Options
The name of the DNS daemon in the BIND package is funnily enough called named, and the main configuration file is located in /etc/named.conf. The configuration can be quite daunting to the new, so lets back it up before making any changes.

[bash]# cp /etc/named.conf /etc/named.conf.original
[bash]# vi /etc/named.conf

The main configuration file is split into many sections. To configure named to only allow queries from the local server and internal network hosts, add the "listen-on" and "allow-query" options. This will restrict unwanted queries on your server.

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
//query-source address * port 53;
listen-on { 127.0.0.1; 192.168.1.1; };
allow-query { 127.0.0.1; 192.168.1.0/24; };
};

If your DNS server is located behind a firewall and is having difficulty with resolving names, you may need to uncomment this directive.

query-source address * port 53;

The "." zone below tells named to check this file for a list of the root name servers, so it knows where to send external queries. This enables the caching nameserver feature of BIND, by forwarding any unknown requests to the root nameservers listed in the file. This zone should already be listed in the configuration.

zone "." IN {
type hint;
file "named.ca";
};

You may find that sending every new DNS query to the root name servers will be a little slow. This can be improved by sending all of your queries to a quicker "upstream" DNS server which will process your request for you. An upstream DNS server (like the ones at your ISP) may already have the query you're after in its cache, or it will normally have a faster backbone link to the root name servers.

To use forwarders you need to have at least one upstream DNS server IP address. Forwarders are a configuration option which needs to be placed inside the "options" section (place under the "allow-query" option above).

#Place INSIDE 'options'

forward first;
forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; <-- Add your ISP's DNS servers in here (IP addresses ONLY)

Pay particular attention to the format of the configuration file, missing semicolons will cause the daemon to function irrationally, if at all.

Adding Your Domain
To provide resolution for the network and computer resources inside your own private network, you need to configure your DNS with your own master DNS zone. The examples below will now guide the configuration of a master zone. These examples are more designed to provide DNS for an internal private network (the home or small office user), and should be used only as a basis for a full authoritative zone. It is also suggested that you configure your domain externally for people to find you on the Internet, see DDNS Service Providers in Chapter 5 if you don't have external name resolution.

Firstly we need to set the zone information in the same named configuration file we used earlier, place the following configuration settings at the bottom of the "/etc/named.conf" file.

[bash]# vi /etc/named.conf

The "example.com" domain name must be substituted for your domain in the following examples.

zone "example.com" IN {
type master;
file "data/master-example.com";
allow-update { none; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "data/reverse-192.168.1";
allow-update { none; };
};

The "example.com" zone will be configured as a master using the file "master-example.com" to store all the details about the zone entities (inside the "/var/named/chroot/var/named/data" directory).

You should notice the configuration file is located inside a chroot() jail directory, this is a secure configuration typical of BIND installations. We will not cover chroot here, but be aware of the importance of the directory structure (some Linux versions may differ slightly though).

[bash]# vi /var/named/chroot/var/named/data/master-example.com

The following is an example FORWARD zone file for the "example.com" domain name, it is using private addressing for internal only name resolution.

;
; Zone File for "example.com" - Internal Use ONLY
;
$TTL 1D
@ IN SOA galaxy.example.com. sysadmin.example.com. (
10 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D ) ; Minimum
;
IN NS galaxy ; Name Server for the domain
IN MX 10 galaxy ; Mail Exchange
;
example.com. IN A 192.168.1.1 ; IP address for the domain 'example.com'
galaxy IN A 192.168.1.1 ; IP address for 'galaxy'
www IN CNAME galaxy ; 'galaxy' is also known as www
ftp IN CNAME galaxy ; 'galaxy' is also known as ftp
;
wkstn1 IN A 192.168.1.201 ; MANUAL IP address entry for 'wkstn1'
wkstn2 IN A 192.168.1.202 ; MANUAL IP address entry for 'wkstn2'

The forward zone file allows name resolution from NAME to IP address. To allow name resolution from IP address to NAME, we need to configure a REVERSE zone file.

[bash]# vi /var/named/chroot/var/named/data/reverse-192.168.1

The reverse zone file looks similar to the forward zone file, however you will note the IP addresses are listed first, with the names listed after the pointer directive (PTR).

;
; Reverse File for network "192.168.1.0/24" - Internal ONLY
;
$TTL 1D
@ IN SOA galaxy.example.com. sysadmin.example.com. (
10 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D ) ; Minimum
;
IN NS galaxy.example.com.
1 IN PTR galaxy.example.com.
;
201 IN PTR wkstn1.example.com. ; MANUAL entry for 'wkstn1' reverse delegation
202 IN PTR wkstn2.example.com. ; MANUAL entry for 'wkstn2' reverse delegation

When configuring the forward and reverse zone files, ensure the IP addresses and the host names are identical in both files. Also, DO NOT add DHCP names and addresses into the files, they will change over time - this can be resolved by using Dynamic DNS below.

The following are some of the common parameters (and definitions) required to configure our zone files.

Parameter	Definition
$TTL	Time To Live for the zone file
IN	The Internet system
SOA	Start Of Authority to administer zone
NS	Name Server for the zone
MX	Mail Exchange for the zone (needs a priority value)
A	Address records for hosts / network equipment
CNAME	Canonical name for an alias (points to "A" record)

This line specifies that the host galaxy.example.com is the SOA for the zone, and that sysadmin.example.com is the email address of the zone's technical contact (sysadmin@example.com). It is important to note that a period "." at the end of the domain names indicates they are fully qualified.

@ IN SOA galaxy.example.com. sysadmin.example.com.

The periods "." located at the end of fully qualified domain names are required. Failure to use periods for FQDNs will cause irregular name resolution.

The following entry specifies that galaxy.example.com is the mail exchange for the zone, which has been set to priority 10. Leave this as standard unless you know what you are doing, or remove it if you are not running your own email servers.

MX 10 galaxy ; Mail Exchange

That completes the configuration of named and the new forward/reverse zone files for our "example.com" domain name. The zone files now need to be chown'd to the named user account and a symbolic link created to the new chroot() jailed file.

[bash]# chown named.named /var/named/chroot/var/named/data/master-example.com
[bash]# ln -s /var/named/chroot/var/named/data/master-example.com /var/named/data/master-example.com

[bash]# chown named.named /var/named/chroot/var/named/data/reverse-192.168.1
[bash]# ln -s /var/named/chroot/var/named/data/reverse-192.168.1 /var/named/data/reverse-192.168.1

The file naming convention is typical of Fedora Core and may differ slightly between Linux distributions.

Checking Your Work
There are several small programs that are in the BIND package that allow integrity checking of the named configuration and zone files. These are great tools to maintain your sanity for testing purposes, as named can be quite particular about problems in the configuration and zone files.

[bash]# named-checkconf /etc/named.conf

The most common errors for misconfiguration in the named file are missing semicolons ";" after parameter settings.

The zone file should be checked for format consistency, and should resemble the above example.com zone file (substitutions should be made for the domain and hosts being configured).

[bash]# named-checkzone -d example.com /var/named/data/master-example.com

loading "example.com" from "/var/named/master-example.com" class "IN"
zone example.com/IN: loaded serial 10
OK

The reverse zone file should also be checked for any errors.

[bash]# named-checkzone -d 1.168.192.in-addr.arpa /var/named/data/reverse-192.168.1

loading "1.168.192.in-addr.arpa" from "/var/named/data/reverse-192.168.1" class "IN"
zone 1.168.192.in-addr.arpa/IN: loaded serial 10
OK

The most common errors for misconfiguration in zone files are missing periods "." at the end of fully qualified domain names - especially for the SOA line.

Starting BIND
After BIND has been configured and there are no errors being returned from the check applications, it is time to set the runlevels and start the service.

[bash]# chkconfig --level 2345 named on
[bash]# /etc/init.d/named restart

A manual check after setting the runlevels confirms that named should start properly after a system reboot.

[bash]# chkconfig --list named

Once the service has been started, check the system log to see if there are any runtime errors, and that your newly configured zone is being served successfully. The entries "zone example.com/IN: loaded serial 10" and "zone 1.168.192.in-addr.arpa/IN: loaded serial 10" confirms the zone load was successful and can now be queried.

[bash]# grep named /var/log/messages

galaxy named[19111]: starting BIND 9.3.2 -u named -t /var/named/chroot
galaxy named[19111]: found 2 CPUs, using 2 worker threads
galaxy named[19111]: loading configuration from '/etc/named.conf'
galaxy named[19111]: listening on IPv4 interface lo, 127.0.0.1#53
galaxy named[19111]: listening on IPv4 interface eth1, 192.168.1.1#53
galaxy named[19111]: command channel listening on 127.0.0.1#953
galaxy named[19111]: zone 0.in-addr.arpa/IN: loaded serial 42
galaxy named[19111]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
galaxy named[19111]: zone 1.168.192.in-addr.arpa/IN: loaded serial 10 <-- Successful load
galaxy named[19111]: zone 255.in-addr.arpa/IN: loaded serial 42
galaxy named[19111]: zone example.com/IN: loaded serial 10 <-- Successful load
galaxy named[19111]: zone localdomain/IN: loaded serial 42
galaxy named[19111]: zone localhost/IN: loaded serial 42
galaxy named[19111]: running

Testing The Server
Now that you have configured your Linux server to query itself for DNS and you have configured the caching server and added your own zone files, its time to test that everything we did was successful. Using the dig application we can check a name resolution for www.example.com, remembering that www in our configuration was an alias that really pointed to galaxy.example.com.

[bash]# dig www.example.com

; <<>> DiG 9.3.2 <<>> www.example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48535 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 86400 IN CNAME galaxy.example.com. galaxy.example.com. 86400 IN A 192.168.1.1 <-- Correct IP address returned

;; AUTHORITY SECTION:
example.com. 86400 IN NS galaxy.example.com.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
;; WHEN: Wed May 17 21:16:38 2006
;; MSG SIZE rcvd: 84

The above results return the true CNAME for www, and also the A record for galaxy.example.com being 192.168.1.1. In the footer area the query server is set as 127.0.0.1#53, this is the nameserver we originally set in the /etc/resolv.conf file, itself.

We can now check a complete listing of the whole zone file with the following command.

[bash]# dig example.com AXFR @localhost

; <<>> DiG 9.3.2 <<>> example.com AXFR @localhost
; (1 server found)
;; global options: printcmd
example.com. 86400 IN SOA galaxy.example.com. sysadmin.example.com. 10 28800 7200 2419200 86400
example.com. 86400 IN NS galaxy.example.com.
example.com. 86400 IN MX 10 galaxy.example.com.
example.com. 86400 IN A 192.168.1.1
ftp.example.com. 86400 IN CNAME galaxy.example.com.
galaxy.example.com. 86400 IN A 192.168.1.1
wkstn1.example.com. 86400 IN A 192.168.1.201
wkstn2.example.com. 86400 IN A 192.168.1.202
www.example.com. 86400 IN CNAME galaxy.example.com.
example.com. 86400 IN SOA galaxy.example.com. sysadmin.example.com. 10 28800 7200 2419200 86400
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
;; WHEN: Wed May 17 21:17:21 2006
;; XFR size: 9 records (messages 1)

The most important test is that we are able to successfully resolve domain names that are listed externally to our private network, and cached from the many Internet DNS servers.

[bash]# dig fedora.redhat.org

; <<>> DiG 9.3.2 <<>> fedora.redhat.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2193 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;fedora.redhat.org. IN A ;; ANSWER SECTION: fedora.redhat.org. 120 IN A 65.38.107.197 ;; AUTHORITY SECTION: redhat.org. 86400 IN NS ns1.ireithost.com. redhat.org. 86400 IN NS ns2.ireithost.com. ;; ADDITIONAL SECTION: ns1.ireithost.com. 156739 IN A 65.38.107.198 ns2.ireithost.com. 156739 IN A 65.38.109.156 ;; Query time: 395 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) <-- Query from local server
;; WHEN: Wed May 17 21:18:36 2006
;; MSG SIZE rcvd: 132

Our last test is to confirm that reverse name lookup is available by querying the reverse delegation zone.

[bash]# host 192.168.1.201

201.1.168.192.in-addr.arpa domain name pointer wkstn1.example.com.

Now that the DNS set up is complete, the rest of the workstations inside the private network must be configured to use DNS 192.168.1.1 as the primary name server. For Linux clients this should be listed in /etc/resolv.conf, for Windows clients this should be configured in network settings.

If your internal network is using DHCP to provide IP addresses to your workstations, then "option domain-name-servers 192.168.1.1;" should be set in your "/etc/dhcpd.conf" configuration file.

Configuring Dynamic DNS
As you would have noticed, configuring the forward and reverse zones for a single domain name can take some time to set up correctly and the information these zone files contain are pretty much static, ie they shouldn't change much. However when an IP address or name does change the information in the zone files also need to be changed otherwise the incorrect details will be returned from our DNS server when queried.

To automate this, we use Dynamic DNS. The Internet Systems Consortium corporation (ISC) write both of the BIND and DHCP server suites that are utilised within Fedora Core, when both of these server applications are utilised together, they are able to update themselves whenever details change between DHCP and DNS. This allows an easy method for the forward and reverse DNS zone files to be updated when a dynamic host is allocated an IP address from the DHCP server.

The following configuration adjustments assume you have already configured your ISC DHCP daemon in accordance with Chapter 10; please do this first.

To configure Dynamic DNS, we can generate a basic set of configuration files by running the rndc-confgen application. The first half of the output goes into the "/etc/rndc.conf" file, while the remaining half of the output goes into the "/etc/named.conf" file.

[bash]# rndc-confgen

key "rndckey" { <-- Insert first section into /etc/rndc.conf file
algorithm hmac-md5;
secret "rZvmZb1cOtvkUfacVZ6oKA==";
};

options {
default-key "rndckey";
default-server 127.0.0.1;
default-port 953;
}; <-- End of first section

key "rndckey" { <-- Insert second section into /etc/named.conf file
algorithm hmac-md5;
secret "rZvmZb1cOtvkUfacVZ6oKA==";
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndckey"; };
}; <-- End of second section

Ensure the "include /etc/rndc.key" directive is removed (or commented out) from both the /etc/rndc.conf and /etc/named.conf files, as you have now created a new configuration. Only ensure there is only ONE "controls" directive in /etc/named.conf.

To ensure that all zone updates are secure, the update requests and transfers are covered using a secure key (MD5 message hash algorithm) which can be generated easily with the dnssec-keygen application. This key then needs to be replicated and shared with the DNS and DHCP server configuration files.

[bash]# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DYNAMIC_DNS_KEY
[bash]# cat Kdynamic_dns_key*.private

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LBxD9REd0XAEwPYOTZMS0w== <-- Shared MD5 Algorithm

The "Kdynamic_dns_key*" file generated in the above step is safe to delete after the DNS and DHCP configuration files have been updated.

The DNS server configuration file needs to be updated with the secure key declaration, and the zone file settings will also need to be allowed to update if they are done so with the secure key.

[bash]# vi /etc/named.conf

key DYNAMIC_DNS_KEY {
algorithm hmac-md5;
secret LBxD9REd0XAEwPYOTZMS0w==; <-- Shared MD5 Algorithm };

zone "example.com" IN {
type master;
file "data/master-example.com";
allow-update { key DYNAMIC_DNS_KEY; }; <-- Allow "key" update
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "data/reverse-192.168.1";
allow-update { key DYNAMIC_DNS_KEY; }; <-- Allow "key" update
};

Now the DHCP server configuration file needs to updated with the same secure key declarations. The server is also told where the primary zone files are stored (on 127.0.0.1) so they can update the DNS server.

[bash]# vi /etc/dhcpd.conf

key DYNAMIC_DNS_KEY {
algorithm hmac-md5;
secret LBxD9REd0XAEwPYOTZMS0w==; <-- Shared MD5 Algorithm
}

zone example.org. {
primary 127.0.0.1;
key DYNAMIC_DNS_KEY; <-- Allow "key" update
}

zone 1.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DYNAMIC_DNS_KEY; <-- Allow "key" update
}

The secure key must match in both the "/etc/named.conf" and "/etc/dhcpd.conf" files otherwise Dynamic DNS will not work effectively.

The DHCP server must now be configured to allow client updates, make the following two changes to your "/etc/dhcpd.conf" file.

[bash]# vi /etc/dhcpd.conf

#
# DHCP Server Config File
#
ddns-update-style interim; <--- Change these in /etc/dhcpd.conf
allow client-updates; <--- Change these in /etc/dhcpd.conf

The DHCP daemon now needs to be configured for Dynamic DNS updates.

[bash]# vi /etc/sysconfig/named

OPTIONS=-4
ENABLE_ZONE_WRITE=yes
ROOTDIR=/var/named/chroot

For detailed information about named daemon, type "man named" at the command prompt.

Now that the Dynamic DNS configurations are complete, the services need to be restarted.

[bash]# /etc/init.d/dhcpd restart
[bash]# /etc/init.d/named restart

Allow your Dynamic DNS configuration a little time to run (enough for some DHCP clients to renew IP Addresses) and then check the syslog to see if your server is successfully updating the forward and reverse zone files with the new client information.

[bash]# grep dhcpd /var/log/messages

dhcpd: if wkstn3.example.com IN TXT "3168f50e8140ac8a1c8b84d809c6adbefe" rrset exists and wkstn3.example.com IN A 192.168.1.200 rrset exists delete wkstn3.example.com IN A 192.168.1.200: success.
dhcpd: if wkstn3.example.com IN A rrset doesn't exist delete wkstn3.example.com IN TXT "3168f50e8140ac8a1c8b84d809c6adbefe": success.
dhcpd: removed reverse map on 200.1.168.192.in-addr.arpa.
dhcpd: DHCPRELEASE of 192.168.1.200 from 00:13:d4:2e:3b:d6 (wkstn3) via eth1 (found)
dhcpd: DHCPDISCOVER from 00:13:d4:2e:3b:d6 via eth1
dhcpd: DHCPOFFER on 192.168.1.200 to 00:13:d4:2e:3b:d6 (wkstn3) via eth1
dhcpd: Added new forward map from wkstn3.example.com to 192.168.1.200
dhcpd: added reverse map from 200.1.168.192.in-addr.arpa. to wkstn3.example.com

The named daemon will also add entries to the syslog to identify correct/successful operation.

[bash]# grep named /var/log/messages

named: client 127.0.0.1#32769: updating zone 'example.com/IN': adding an RR at 'wkstn3.example.com' A
named: client 127.0.0.1#32769: updating zone 'example.com/IN': adding an RR at 'wkstn3.example.com' TXT
named: client 127.0.0.1#32769: updating zone '1.168.192.in-addr.arpa/IN': deleting rrset at '200.1.168.192.in-addr.arpa' PTR
named: client 127.0.0.1#32769: updating zone '1.168.192.in-addr.arpa/IN': adding an RR at '200.1.168.192.in-addr.arpa' PTR

A forward lookup can be checked against a known DHCP client to ensure a successful lookup.

[bash]# host wkstn3.example.com

wkstn3.example.com has address 192.168.1.200

A reverse lookup can also be done to ensure reverse delegation can also be confirmed.

[bash]# host 192.168.1.200

200.1.168.192.in-addr.arpa domain name pointer wkstn3.example.com

If you have got this far, you have done well - enjoy a fully automated Dynamic DNS solution.

More...