FireHOL v1.x New User Tutorial

This is the recommended procedure to manually design a secure FireHOL firewall. It applies to FireHOL 1.x versions, which only understand IPv4.

1. Identify all network interfaces on your firewall host

Network interfaces are there for some reason. You have to do something about all the interfaces of your host. If you don’t do something at the firewall level with a network interface, then it depends of the firewall policy what will happen with traffic on this interface. By default FireHOL will drop all traffic coming in and going out via an undefined network interface, so the network interface will have no meaning to be up and running. This is a common mistake on some ADSL configurations, where users ignore the loop device that connects the Linux router with the ADSL device. To identify your network interfaces use the ip link show command. The example below shows my home router ip link show output:

[root@gateway /]# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:fc:21:9a:ab brd ff:ff:ff:ff:ff:ff
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3
    link/ppp

There are a few important thinks to always remember:

lo exists on all machines and is used for communication between programs running on this machine. FireHOL handles this automatically. You don’t have to do anything about lo.
Network interfaces (except the lo interface) are used for two purposes:
- By the firewall host for its own communication with the rest of the world. This is the case when the firewall host requests something from some other host (a DNS lookup maybe) for its own needs, or when some other host requests something from the firewall host, when the later is running some daemons (servers) too.
- By other hosts as gateways in order to reach other hosts behind the firewall host. In this case, the firewall host simply passes traffic from one of its network interfaces to another. This is also called routing.

In the above example, it is clear that I have two network interfaces (except lo): eth0 and ppp0.

One extra step is to identify if the network interfaces appearing here might dynamically change during run-time. For example my ppp0 might become ppp1 or ppp2 in certain cases. To overcome this problem, I can say that my link to the outside world is not ppp0 but ppp+. The plus character matches all the interfaces that begin with the text given before the plus sign. In this case, it matches all the possible network interfaces that start with ppp.

Keep in mind that FireHOL (and iptables) does not really care if the interface defined in a firewall actually exists or not. This means that you can setup firewalls on interfaces that might become available later or altered during run time. This also means that if you define an interface with a wrong name, FireHOL and iptables will not complain.

2. Give a role to each interface identified

Now I have to assign a role to each network interface, i.e. what is the function of each of those interfaces? For this, I create a table similar to the one below. It is important to focus on the requests; forget the replies.

interface	description	incoming requests	outgoing requests	routing requests in	routing requests out
`eth0`	My home LAN	Many services from my LAN workstations (i.e. dns, ftp, samba, squid, dhcp, http, ssh, icmp)	A few services my LAN workstations provide (i.e. samba, icmp)	All LAN workstations requests going to the internet	Nothing
`ppp+`	The Internet	I run a public mailer, a public web server and a public ftp server for my domain	All the services my Linux could ask from the internet	Nothing	All LAN workstations requests going to the internet

Keep in mind that:

incoming requests represent servers running on the firewall host.
outgoing requests represent clients running on the firewall host.
routing requests in represent clients on hosts at the network interface in question.
routing requests out represent servers on hosts at the network interface in question.

So, the above could also be presented as:

interface	name	servers provided	clients used	routing clients	routing servers
`eth0`	home	dns, ftp, samba, squid, dhcp, http, ssh, icmp	samba, icmp	all	none
`ppp+`	internet	smtp, http, ftp	all	none	all

This table can easily be transformed into FireHOL rules.

3. Create the FireHOL configuration structure

Now that you have a list of all the interfaces and their roles, it is time to start writing the FireHOL configuration file. First write one interface statement for each network interface you identified above:

version 5


interface eth0 home


interface ppp+ internet

Now, we can add the servers for each interface (based on the table above). Remember that these servers are all running on the firewall host:

version 5


interface eth0 home
    server dns   accept
    server ftp   accept
    server samba accept
    server squid accept
    server dhcp  accept
    server http  accept
    server ssh   accept
    server icmp  accept


interface ppp+ internet
    server smtp  accept
    server http  accept
    server ftp   accept

Now, we can add the clients for each interface. Remember that these clients are all running on the firewall host:

version 5


interface eth0 home
    server dns   accept
    server ftp   accept
    server samba accept
    server squid accept
    server dhcp  accept
    server http  accept
    server ssh   accept
    server icmp  accept

    client samba accept
    client icmp  accept


interface ppp+ internet
    server smtp  accept
    server http  accept
    server ftp   accept

    client all   accept

At this point, everyone should be able to inter-operate correctly with the firewall host, but still we don’t route any traffic. This means that the linux box can “see” all the workstations on the LAN and these workstations can “see” the linux box, also that the linux box can “see” the Internet and the Internet can “see” the servers of the ppp+ interface of the linux box, but the LAN workstations cannot “see” the Internet.

It is now time to setup routing. To do this we will have to define a set of routers for all the interface combinations. This means that if we have two interfaces we will have to define two routers. If we have 3 interfaces, we will have to define 6 routers, and so on.

version 5


interface eth0 home
    server dns   accept
    server ftp   accept
    server samba accept
    server squid accept
    server dhcp  accept
    server http  accept
    server ssh   accept
    server icmp  accept

    client samba accept
    client icmp  accept


interface ppp+ internet
    server smtp accept
    server http accept
    server ftp  accept

    client all   accept


router home2internet inface eth0 outface ppp+


router internet2home inface ppp+ outface eth0

Remember that inface and outface match the requests, not the replies. This means that the router home2internet matches all requests originated from eth0 and going out to ppp+ (and of course their relative replies in the opposite direction), while the router internet2home matches all the requests from the Internet to the home LAN (and their relative replies back).

Now, based on the roles table of the previous section we see that we should route all requests coming in from eth0 and going out to ppp+, and not route any request coming from the Internet and going out to the home LAN. Here it is:

version 5


interface eth0 home
    server dns   accept
    server ftp   accept
    server samba accept
    server squid accept
    server dhcp  accept
    server http  accept
    server ssh   accept
    server icmp  accept

    client samba accept
    client icmp  accept


interface ppp+ internet
    server smtp accept
    server http accept
    server ftp  accept

    client all   accept


router home2internet inface eth0 outface ppp+
    route all accept


router internet2home inface ppp+ outface eth0

This is it. We are done! (for the filtering part of the firewall. Look below for setting up NAT too.)

4. Optimising the firewall

To save typing time, you can use this:

version 5


interface eth0 home
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet
    server "smtp http ftp" accept
    client all             accept


router home2internet inface eth0 outface ppp+
    route all accept

Note that we can remove any router statements not having any rules in them, so the internet2home router has been eliminated.

We might want to have extra checks on each interface to prevent spoofing. To find the IPs of your network interfaces use ip addr show and to find the IP networks behind each interface use ip route show.

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    server "smtp http ftp" accept
    client all             accept


router home2internet inface eth0 outface ppp+
    route all accept

UNROUTABLE IPS is a variable defined by FireHOL and contains all the IPs that should not be routed on the internet.

If home LAN did not have real IP addresses, we would have to add a masquerade command in our router:

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    server "smtp http ftp" accept
    client all             accept


router home2internet inface eth0 outface ppp+
    masquerade
    route all accept

The masquerade command sets itself up on the outface of a router.

We can now protect our ppp interface even further. For this we use the protection command:

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    protection strong 10/sec 10
    server "smtp http ftp" accept
    client all             accept


router home2internet inface eth0 outface ppp+
    masquerade
    route all accept

It could be nice if instead of dropping wrong packets originated from the Ethernet, to reject them so that our workstations will not have to timeout if we do something that is not allowed. To do this we use the policy command:

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    policy reject
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    protection strong 10/sec 10
    server "smtp http ftp" accept
    client all             accept


router home2internet inface eth0 outface ppp+
    masquerade
    route all accept

Some servers on the Internet try to ident back the client to find information about the user requesting the service. With our current firewall, such servers will have to timeout before accepting our request. To speed thinks up we could write:

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    policy reject
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    protection strong 10/sec 10
    server "smtp http ftp" accept
    server ident reject with tcp-reset
    client all             accept


router home2internet inface eth0 outface ppp+
    masquerade
    route all accept


router internet2home inface ppp+ outface eth0
    route ident reject with tcp-reset

Note that we now have added the router we eliminated above, since we need to add a service to it.

The whole routing schema could be rewritten as:

version 5

# The network of our eth0 LAN.
home_ips="192.0.2.0/24"

interface eth0 home src "${home_ips}"
    policy reject
    server "dns ftp samba squid dhcp http ssh icmp"        accept
    client "samba icmp"                                    accept


interface ppp+ internet src not "${home_ips} ${UNROUTABLE_IPS}"
    protection strong 10/sec 10
    server "smtp http ftp" accept
    client all             accept


router internet2home inface ppp+ outface eth0
    masquerade reverse
    client all   accept
    server ident reject with tcp-reset

Now we have elicited the first router, but we defined everything in the second. We have used the reverse keyword in masquerade to make it set up in inface this time.

We could use the first router (home2internet) to do everything, but then the client and server commands would need be reversed (server all, client ident) which would be confusing.