13- IPFire 2.11 Core 65

Installation

We will build a complete IPFire (2.11, Core 65) virtual machine directly from the install .iso. This assumes that you have a functioning DNS server on your network.

Creating the VM

Create a new Virtual Machine, using the VMWare New Virtual Machine Wizard. For the .iso image, use the .iso image provided on the labshare- ipfire-2.11.i586-full-core65.iso. Yes, the entire .iso is 78 MB.

Set the operating system as Linux; for the version select “Other Linux 2.6 kernel”. Set the host name of your virtual machine; also set the location for the VM files. The hard drive size can be kept fixed at 8 GB. If you do not specify “Split the virtual disk into multiple files” you will find that you may be unable to copy the VM onto drives formatted with FAT32, like many portable hard drives.

You need to customize the hardware prior to finishing the wizard.

For memory, if you want to use IPFire as an intrusion detection system then select at least 512 MB; otherwise 256 MB should be sufficient. You will need more than one network adapter; in this example we will set up three.

The first network adapter should be set to “Bridged”
The second network adapter should use the virtual network VMNet2
The third network adapter should use the virtual network VMNet3

At this point, you can complete the wizard and begin installing the system.

Initial Configuration

Once the system boots, simply hit enter to begin the install process. Select your language preference- but remember if you don’t select English, then I am not going to be helping you much, am I? The system is distributed under the GPL; you need to accept the license before proceeding.

The system will be installed on the root directory of the virtual disk, device /dev/sda. You do need to partition that drive. All of the file systems suggested (Ext2, Ext3, Ext4, ReiserFS) are reasonable; we will use Ext4.

Installation is quick, but does require a reboot. After the first reboot, you will be presented with a sequence of configuration screens. For the keyboard, I recommend US. For the timezone- go ahead and choose something appropriate- e.g. America/New York. Set the name of the host- this is ONLY the name of the host, not the name of the (DNS) domain. In this example, I will keep the default (ipfire). Next select the (DNS) domain name. Following other examples, I will use “cosc.tu”; then the fully qualified domain name will be ipfire.cosc.tu

Select a password for the root user on the system. The installer does not echo back a “*” or the like as the password is entered. Next, select a password for the admin account which is used to log on to the web interface to administer the system. It is not a good idea to use the same password for both accounts.

From the Network Configuration Menu, select Network configuration type

Modify the Network configuration type to select “GREEN + RED + ORANGE”. Traditionally in this context, RED is the external interface, ORANGE is the DMZ, GREEN is the internal interface, and BLUE is used for wireless.

Setting up the drivers and networking is a bit more challenging. To start, leave the VM for a moment, and go back to the host. Open the file IPFire.vmx (or TheNameYouChose.vmx) from the host directory for the virtual machine in a text editor. Find the three lines of the general flavor

ethernet0.generatedAddress = "00:0C:29:E6:14:CE"
ethernet1.generatedAddress = "00:0c:29:e6:14:d8"
ethernet2.generatedAddress = "00:0C:29:E6:14:E2"

Note that these lines may be widely separated in the actual .vmx file. These settings tell us the MAC address of each virtual network card. You are going to want to write these down, as we will need these in a few moments. The first of these (ethernet0) should correspond to the first network adapter you selected, while the second (ethernet1) to the second adapter, and the third (ethernet2) to the third adapter.

We want the GREEN interface to connect to our internal trusted network. Our VM has two networks (besides bridged), VMNet2, and VMNet3. Let’s use VMNet2 for the trusted network; this will save VMNet3 for the DMZ.

Earlier, we set the first network adapter to bridged, the second to VMNet2, and the third to VMNet3. Since we want the GREEN network to map to VMNet2, we want the second adapter, which we see has MAC address 00:0c:29:e6:14:d8. Thus, we set the GREEN interface to use that MAC address.

For the RED interface, select the network card that is set to bridged. For the ORANGE interface, select the remaining network card; it should be set to VMNet3.

Next, from the network configuration menu, select Address Settings. You will now have three networks- the external network, the internal network, and the DMZ. These need to have separate IP address ranges. You can select these however you please. Note that the private and the DMZ addresses on one host do not need to be different that the private and DMZ addresses on another host. In this example, I am going to use

Public (Red)- 10.0.2.0/24
Private (Green)- 192.168.1.0/24
DMZ (Orange)- 172.16.1.0/24

In this example, the IP addresses of the IPFire machine will be:

Public (Red)- 10.0.2.23
Private (Green)- 192.168.1.2
DMZ (Orange)- 172.16.1.2

The public address matches the name (ipfire.cosc.tu) in the public DNS I am using in this example. Yours should also match.

Set these IP addresses. Notice that for the RED interface (only) the IP address can be set via DHCP; for GREEN and ORANGE the IP address must be static.

Set the DNS and gateway information. This information is for the public network. In my home network for this example, I have the DNS server aurora.cosc.tu on 10.0.2.2. If your team is running a DNS server on e.g. 10.0.x.y, then that is the IP address you use for DNS.

Similarly, the gateway is the gateway for the public network. On my home network (for this example) it is located at 192.168.1.1 In the classroom laboratory, this is located at 10.0.x.254

You can set up IPFire to serve as a DHCP server for your internal (GREEN) network. Though convenient, this is not required. For now, we leave this turned off; we can enable it later.

At this point, a reboot is required.

If you ever need to return to this setup menu, you can do so from the command line after the system boots and running the setup command.

When complete, your network should look something like the following:

[root@ipfire ~]# ifconfig
green0    Link encap:Ethernet  HWaddr 00:0C:29:E6:14:D8  
          inet addr:192.168.1.2  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:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:16 Base address:0x2080 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2054 (2.0 Kb)  TX bytes:2054 (2.0 Kb)

orange0   Link encap:Ethernet  HWaddr 00:0C:29:E6:14:E2  
          inet addr:172.16.1.2  Bcast:172.16.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:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:17 Base address:0x2400 

red0      Link encap:Ethernet  HWaddr 00:0C:29:E6:14:CE  
          inet addr:10.0.2.23  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:54 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9285 (9.0 Kb)  TX bytes:5004 (4.8 Kb)
          Interrupt:19 Base address:0x2000

Notice that the names of the interfaces are not the traditional eth* that we have seen.

Validating the Network

Now we need to verify that our network works as intended. If you correctly identified the RED interface, you should be able to ping the class gateway from the IPFire command line, ping your DNS server from the IPFire command line, and perform an nslookup of a FQDN from the IPFire command line.

[root@ipfire ~]# ping -c2 10.0.2.254
PING 10.0.2.254 (10.0.2.254): 56 data bytes
64 bytes from 10.0.2.254: icmp_seq=0 ttl=128 time=0.504 ms
64 bytes from 10.0.2.254: icmp_seq=1 ttl=128 time=0.430 ms
--- 10.0.2.254 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.430/0.467/0.504/0.037 ms

[root@ipfire ~]# ping -c2 10.0.2.2
PING 10.0.2.2 (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: icmp_seq=0 ttl=64 time=1.297 ms
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.623 ms
--- 10.0.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.623/0.960/1.297/0.337 ms

[root@ipfire ~]# nslookup nexon.cosc.tu
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	nexon.cosc.tu
Address: 10.0.2.5

Be sure you pass all of these checks before moving on!

To check the ORANGE interface, start a new box (BT5R3 is a nice choice). Set the network adapter to VMNet3. Assign the BT5R3 machine the static IP address 172.16.2.3 with netmask 255.255.255.0, and set the default route to pass through the IPFire machine at 172.16.1.2:

root@bt:~# ifconfig eth0 172.16.1.3 netmask 255.255.255.0
root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:0f:bd:93  
          inet addr:172.16.1.3  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe0f:bd93/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:2862 (2.8 KB)
          Interrupt:19 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:22 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2941 (2.9 KB)  TX bytes:2941 (2.9 KB)

root@bt:~# route add default gw 172.16.1.2
root@bt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.1.2      0.0.0.0         UG    0      0        0 eth0
172.16.1.0      *               255.255.255.0   U     0      0        0 eth0

Now check that you can ping the IPFire system (172.16.1.2), a system on the birdged network, say the DNS server at 10.0.2.2, and that you can perform a name query to that nameserver.

root@bt:~# ping -c2 172.16.1.2
PING 172.16.1.2 (172.16.1.2) 56(84) bytes of data.
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=1.19 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=64 time=0.771 ms

--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.771/0.985/1.199/0.214 ms

root@bt:~# ping -c2 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=63 time=2.61 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=63 time=0.836 ms

--- 10.0.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.836/1.723/2.610/0.887 ms

root@bt:~# nslookup smyrna.cosc.tu 10.0.2.2
Server:		10.0.2.2
Address:	10.0.2.2#53

Name:	smyrna.cosc.tu
Address: 10.0.2.17

Checking the GREEN interface is similar. Start a box- say another (or the same!) BT5R3. Set the network adapter to VMNet2. Set the BT5R3 machine to the static IP address 192.168.1.3 with netmask 255.255.255.0; also set the default route of the BT5R3 machine to 192.168.1.2. Then verify that you the BT5R3 can ping the ipfire and vice versa; also check that the BT5R3 can ping the class getway, the name server, and perform name resolution.

root@bt:~# ifconfig eth0 192.168.1.3 netmask 255.255.255.0
root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:0f:bd:93  
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe0f:bd93/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:820 (820.0 B)  TX bytes:8793 (8.7 KB)
          Interrupt:19 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:87 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:22645 (22.6 KB)  TX bytes:22645 (22.6 KB)

root@bt:~# route add default gw 192.168.1.2
root@bt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.2     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

root@bt:~# ping -c2 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.942 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.511 ms

--- 192.168.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.511/0.726/0.942/0.217 ms

root@bt:~# ping -c2 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=63 time=2.34 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=63 time=0.921 ms

--- 10.0.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.921/1.635/2.349/0.714 ms

root@bt:~# nslookup solaria.cosc.tu 10.0.2.2
Server:		10.0.2.2
Address:	10.0.2.2#53

Name:	solaria.cosc.tu
Address: 10.0.2.12

Configuring the IPFire machine.

To access the configuration screen, start a machine on the GREEN network (VMNet2). Be sure that it is correctly configured, so that it can connect both to the ipfire machine and to the class network. Also be sure to configure the machine to use the external nameserver.

Navigate your browser to https://ipfire.cosc.tu:444 or whatever name you have selected for your ipfire machine.

Notes:

You should be able to already ping the host by hostname, after all you did verify your network settings. (You don’t want to use IP addresses!)
Note the use of https rather than http; this is required.
The service is running on the non-standard port 444.
This will work only from machines on the GREEN network- it will not work from other subnets.
If it fails, here are some quick things to check:
- Is your browser on the GREEN network?
- Is your nameserver working?
- Did you use https instead of http in the URL?
- Did you specify the proper port (444)?

Once you arrive at the web site, you will discover that the connection is untrusted, as you do not have the corresponding certificate for the server. As security professionals, we are not in the habit of of bypassing these sorts of security warnings, so we need to find and import the server’s certificate. The good news is that it is located on the server, in the file /etc/httpd/server.crt. To move it from the server though, will take a moment.

Suppose for example, that your DNS server is running an SSH server; mine is. Then from ipfire, we simply copy the certificate to the DNS server:

[root@ipfire ~]# scp /etc/httpd/server.crt seldon@aurora.cosc.tu:ipfire.crt
seldon@aurora.cosc.tu's password:
server.crt                                    100%  635     0.6KB/s   00:00

Then we can pull it back to the machine on the GREEN network using the same process:

root@bt:~# scp seldon@aurora.cosc.tu:ipfire.crt ./
seldon@aurora.cosc.tu's password: 
ipfire.crt                                    100%  635     0.6KB/s   00:00

There are, of course, other ways to to this.

Import the certificate into your browser, and once again visit https://ipfire.cosc.tu:444. Log in using the admin user and the password you specified during the installation process.

Doing so, you will be presented with a screen like the following:

System Tab

From the system tab on the configuration web page you can see the basic network configuration, including the IP addresses of the IPFire interfaces. From the side menu on this page, you can enable SSH access to the IPFire machine. By default, this is on port 222 rather than port 22. Access is via the internal (GREEN) network or the external (RED) network. In the latter case, the firewall must be configured to allow that access; see External Access below. For details, see http://wiki.ipfire.org/en/configuration/system/ssh

Status Tab

Services

From the Services entry on the side menu, you can go to a page and view all of the services avialble in IPFire; these include a DHCP server (for the GREEN network), a DNS Proxy, a snort intrusion detection system, an NTP server, VPN servers, the SSH server, and a Web Proxy (Squid).

We will discuss some of these services in detail later when we get to the services tab, but to get you started, by selecting the NTP Server URL, you will be directed to a page where you can tell IPFire who to synchronize its time. You can set it to synchronize with a timer server, even an internal one like exercise control at trantor.cosc.tu. You can also set it so that it provides time services to its internal networks.

Other add-on services can be installed. See http://wiki.ipfire.org/en/configuration/status/services for more details.

Connections

Returning to the status tab, from the Connections entry on the side menu, you can go to a page that shows all of the connections to and through your IPFire system. See http://wiki.ipfire.org/en/configuration/status/connections for more details.

Can you guess what is happening here?

Network Tab

DHCP

From the DHCP Server entry on the side menu, you can go to a page that will let you configure IPFire to serve as a DHCP server on the GREEN interface. You can set the DHCP server up to only serve some addresses; this way you can reserve some addresses to be given to machines with static IP addresses (e.g. log servers). You can also use this page to set up fixed leases by MAC address.

Test this system by enabling the interface and starting another machine on the GREEN interface (VMNet2). For details, see http://wiki.ipfire.org/en/configuration/network/dhcp

Web Proxy

From the Webproxy entry on the side menu, you can go to a page that will allow you to configure IPFire to serve as a proxy for web traffic. One advantage of proxies is that they allow for faster responses on large networks because they can cache commonly visited web pages. Another advantage is that, by passing all web site connections through a single point, you can enable content filtering, access restrictions, and the logging of all outbound web requests. Proxies can be set up through a proxy port (on IPFire, the default is 800) which then needs to be appropriately set in the browser. You can also set the proxy to run transparently; in this case no changes need to be made to the client browsers.

If you enable the proxy, you probably want to change the error message language to something appropriate.

Set up IPFire to serve as a transparent web proxy; don’t forget to re-start (at the bottom of the page). From a machine on the GREEN network, visit the web page of a host on the RED (external) network. Be sure to enable logging on the proxy. Verify that the proxy functioned correctly by viewing the proxy logs. [You can access those from the logs tab, and selecting Proxy Logs and then Proxy Reports from the side menu. For more details, see http://wiki.ipfire.org/en/configuration/network/proxy.

Content Filter

From the Content Filter entry on the side menu for the network tab, you can configure IPFire to block various types of web traffic- by categories, by domain, by URL, by file extension and by other traffic characteristics. The Web proxy service must be running to use the content filter. See http://wiki.ipfire.org/en/configuration/network/url-filter for more details.

Edit Hosts

From the Edit Hosts entry on the side menu for the network tab, you can go to a page that will allow you to specify names for hosts on your internal network. Your internal hosts are not likely to have their own names in an external DNS server, and you may not wish to run a separate internal (or split) DNS server. This page allows you to set host names using the IPFire DNS Proxy server (dnsmasq) for the various machines with static addresses on your internal & DMZ networks.

Suppose we set up two hosts on the GREEN internal network- an Windows 7 host on 192.168.1.50 and a CentOS host on 192.168.1.51. We also have a host on the DMW, a CentOS system at 172.16.1.4. We make the appropriate changes on the Edit Hosts page.

Then when we set up these hosts, we give them the appropriate static addresses, and point them to the internal address for ipfire as their DNS server- 192.168.1.2. Then each can play all of the usual nameserver games.

This is a convenient way to set up a private DNS infrastructure for systems behind the firewall.

One note. Though you can give names to systems on both the GREEN (internal) network and on the ORANGE (DMZ) network, the name service only provides these names to systems on the GREEN (internal) network. Thus, an external (RED) system cannot use this service to determine your internal addresses; it also means that DMZ systems cannot perform hostname lookups of internal systems. On the other hand, internal systems can address internal and DMZ systems by name in this fashion.

See http://wiki.ipfire.org/en/configuration/network/hosts for more detail.

Aliases

From the Alias entry on the side menu, you can go to a page that will allow you to specify additional aliases- IP Addresses- for your external (RED) interface. Aliases allow you to set up more comple topologies; for example suppose that you want to place two web servers in your DMZ. If IPFire has just one external IP address, then there is no way that the two servers can be visible to the external network, as incoming traffic to IPFire on port 80 can be forwarded to only one of the servers. By using an alias, your IPFire machine can have two (or more) public IP addresses, and port 80 traffic to the first IP address can be forwarded to the first web server and port 80 traffic to the second IP address can be forwarded to the second web server.

So far in this example, we have set up the ipfire.cosc.tu with address 10.0.2.23 on our public DNS system. Let’s add other entries to that DNS server, for arcturus.cosc.tu with address 10.0.2.24, and getorin.cosc.tu with address 10.0.2.25. Then we set up aliases for each address:

If you go back to the IPFire system itself and take a look at the provided interfaces, you will see the same aliasing occurring that we saw in Notes 6.

[root@ipfire ~]# ifconfig -a
green0    Link encap:Ethernet  HWaddr 00:0C:29:E6:14:D8  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18411 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28887 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2432675 (2.3 Mb)  TX bytes:25301012 (24.1 Mb)
          Interrupt:16 Base address:0x2080 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:428 errors:0 dropped:0 overruns:0 frame:0
          TX packets:428 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:49106 (47.9 Kb)  TX bytes:49106 (47.9 Kb)

orange0   Link encap:Ethernet  HWaddr 00:0C:29:E6:14:E2  
          inet addr:172.16.1.2  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:134 errors:0 dropped:0 overruns:0 frame:0
          TX packets:104 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9158 (8.9 Kb)  TX bytes:39704 (38.7 Kb)
          Interrupt:17 Base address:0x2400 

red0      Link encap:Ethernet  HWaddr 00:0C:29:E6:14:CE  
          inet addr:10.0.2.23  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:17347 errors:1 dropped:4 overruns:0 frame:0
          TX packets:10199 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:22839512 (21.7 Mb)  TX bytes:820170 (800.9 Kb)
          Interrupt:19 Base address:0x2000 

red0:0    Link encap:Ethernet  HWaddr 00:0C:29:E6:14:CE  
          inet addr:10.0.2.24  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          Interrupt:19 Base address:0x2000 

red0:1    Link encap:Ethernet  HWaddr 00:0C:29:E6:14:CE  
          inet addr:10.0.2.25  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          Interrupt:19 Base address:0x2000

Later, we will show how to set up the firewall so that traffic aimed at arcturus.cosc.tu / 10.0.2.24 gets sent to one particular DMZ host, while traffic aimed at the getorin.cosc.tu / 10.0.2.25 gets sent to a different DMZ host entirely.

For details on the use of the page, see http://wiki.ipfire.org/en/configuration/network/aliases

Services Tab

We have already discussed how to set up IPFire to serve as a time server; now we consider some of the other services it can provide.

Snort

If you don’t want to set up a separate intrusion detection system, you can instead use the IPFire system for that purpose. However, you will need to copy your IPFire system on to an Internet connected network first. Start by navigating to the Intrusion Detection sidemenu item in the Services tab. Register with Snort, and get an Oinkcode from Snort. Enter that code into the appropriate text box, and watch the system download an appropriate ruleset and install it for you.

Once selected, instruct IPFire to download the rules; it will do so happily:

When the rules are downloaded, you can then navigate farther down the page to determine which (if any) of the rules you wish to enable. The rules themselves are stored in the usual place (/etc/snort/rules). To test your install, you may want to add a testing rule like we did in Notes 8 to one of the files that you have enabled in your configuration. You can check that the IDS is properly catching the results by looking under the IDS logs side menu item under the log tab to see if your rule is firing as you expect:

I would recommend that you use a separate system for your IDS instead of relying on the IPFire system, as by doing so you can take full advantage of storing the results in an external database and using other tools like Snort Report to view the results.

Firewall Tab

Port Forwarding

All traffic from the external network (RED) to a host on the internal network (GREEN) or the DMZ (ORANGE) must be explicitly allowed via a port forwarding rule. Traffic not permitted is blocked by default. See http://wiki.ipfire.org/en/configuration/firewall/portforwarding.

Suppose that you have a web server, mars.cosc.tu on your DMZ with address 172.16.1.4 that has been set up with the internal name mars.cosc.tu. Remember- we set this up earlier in the network tab, using the edit hosts side menu. Remember also that this system can be addressed by name, but only by hosts in the GREEN (internal) network, not by systems on the DMZ or externally.

We also earlier set up two additional aliases for the ipfire system; on the external network we can refer to it as ipfire.cosc.tu at 10.0.2.23, as arcturus.cosc.tu at 10.0.2.24, and as getorin.cosc.tu at 10.0.2.25.

Now suppose that we decide to set up a port forwarding rule, so that all web traffic (TCP/80 and TCP/443) aimed at arcturus.cosc.tu / 10.0.2.24 is sent on to mars.cosc.tu / 172.16.1.4.

Now if an external system visits the web page http://arcturus.cosc.tu, they will be given the web page served by the internal system mars.cosc.tu.

This is simultaneously very powerful, and very confusing.

Why confusing? Questions that used to be quite simple now become much more complex. For example, what is the IP address of the web server? Now the answer is- it depends. Are you looking at in from the DMZ? Then it is at the local address 172.16.1.4. Of course, that address is not even routable in our internal class network, which is limited to 10.0.0.0/8. From that network, the web server is located at 10.0.2.24. But wait another minute- isn’t 10.0.2.24 one of the IP addresses of the IPFire machine? Indeed, it is!

If you think that was fun, what would happen if we forwarded TCP/22 aimed at arcturus.cosc.tu / 10.0.2.24 to a different system, say venus.cosc.tu at 172.16.1.5? Then from the point of view of the external network, arcturus.cosc.tu / 10.0.2.24 can be one of three different systems- the ipfire host, the DMZ system mars.cosc.tu, or the DMZ system venus.cosc.tu, depending on the port and protocol of the packet!

No longer can we assume that a single IP address means a single host; it can mean different hosts depending on the traffic.

We have already seen how a single system can have multiple IP addresses and multiple DNS names- our ipfire system currently has three names (ipfire.cosc.tu, arcturus.cosc.tu, getorin.cosc.tu) and five IP addresses (10.0.2.23, 10.0.2.24, 10.0.2.25, 172.16.1.2, 192.168.1.2)!

From now on, you need to distinguish the system, its name(s), and its IP Addresses(s). Further, when reporting on a systems network properties, you need to specify your point of view. If you want to say in a report that the host arcturus.cosc.tu is located at 10.0.2.24, then you should state that this is the case when viewed from the external 10.0.0.0/8 network. Often the reader can determine this implicitly from context, but now with the more complex networks you can build, you will often need to state explicitly what is occurring.

External Access

Returning to the firewall tab, any traffic destined for the IPFire machine itself from the external network (RED) must be explicitly allowed via an external access rule. Any traffic not expliticly permitted is prohibited. See also http://wiki.ipfire.org/en/configuration/firewall/externalaccess.

By default, only TCP/113 traffic is allowed to communicate directly with the IPFire host from the outside. Do you remember what service uses TCP/113? You do know why I asked this question!

DMZ Pinholes

Any traffic from the DMZ (ORANGE) to the internal network (GREEN) must be explicitly allowed through a DMZ Pinhole. See also http://wiki.ipfire.org/en/configuration/firewall/dmzpinholes.

Suppose that we want our web server mars.cosc.tu / 172.16.1.4 in the DMZ (ORANGE) to be able to communicate with a MySQL server in the internal (GREEN) network at africa.cosc.tu / 192.168.1.51. To permit this, we create a DMZ Pinhole.

Outbound Traffic

Outbound traffic can be controlled via the settings for the external firewall configuration. See also http://wiki.ipfire.org/en/configuration/firewall/outgoingfirewall.

By default, all traffic is allowed out. You can specify a set of rules so that only connections on the list are allowed (Mode 1) or that connections not on the list are allowed (Mode 2). Be careful though- if you are using your nameserver, and it is out of your internal network, then you can cut yourself off from the nameserver, and hence from your configuration page, in the middle of making these changes.

Don’t ask how I found that out. Twice. Even though I knew it could be a problem after the first time I got stuck trying to debug the oddest errors. Let’s just say that this setting has cost me a few hours on more than one occasion.

The Logs tab

The elements of the logs tab are self-explanatory.

Connecting Multiple Systems

One advantage of using IPFire is that we can set up IPSec tunnels between different internal (GREEN) and DMZ (ORANGE) subnets. We can then effectively set up a single internal network and a single DMZ, even though they are spread out across multiple hosts.

To do this, start with the original IPFire system on 10.0.2.23; it has an internal GREEN network on 192.168.1.0/24 and an ORANGE DMZ on 172.16.1.0/24.

We set up a second IPFire system, but with a different external name and IP address- say ipfire2.cosc.tu at 10.0.2.26. When setting up this system, we think ahead though, and decide to use different internal and DMZ network spaces; we set up the GREEN on 192.168.2.0/24 and the ORANGE on 172.16.2.0/24. If we are only using the IPFire systems as firewalls without the VPN connection, we could re-use the address space behind the firewalls; however since we are planning to connect these networks together with an IPSec VPN tunnel, we need to be sure that they are in different subnets.

With the two systems configured, visit the admin page for the first system; from the Services tab select the IPSec side menu item. Begin by setting and saving the global settings, which includes the IP address of the public (RED) interface.

Hit Save.

From the section "connection status and control" select Add, then choose Net-to-Net Virtual Private Network

Select a name for the network; in this example I am calling it Green12 to emphasize that I am connecting the GREEN network behind the first host (ipfire.cosc.tu / 10.0.2.23) to the GREEN network behind my second system (ipfire2.cosc.tu / 10.0.2.26). Select the local subnets behind each network; fortunately we already ensured that these were different. You can select your own Local ID’s, but they should start with an "@".

There are a number of ways to provide authentication, but the simplest perhaps is to set up a pre-shared key- effectively just a password.

With these steps completed on the first host, you then repeat the process on the second host. Here I name the connection GREEN21 to emphasize that now we are going from the second (ipfire2.cosc.tu) back to the first (ipfire.cosc.tu). The network settings are modified in the expected fashion as well.

When both sides have been configured, return to "connection status and control"; under status you should see the connection listed as "disconnected" in red. Hit the restart icon, and wait a few moments. It should change to green.

At this point you should be able to connect directly from systems on one GREEN network to the other. In a simple example, you may have something like

ipfire.cosc.tu 10.0.2.23
   GREEN Subnet 192.168.1.0/24
         ipfire.cosc.tu 192.168.1.2
         asia.cosc.tu 192.168.1.50
         africa.cosc.tu 192.168.1.51
   ORANGE Subnet 172.16.1.0/24
         ipfire.cosc.tu 172.16.1.2
         mars.cosc.tu 172.16.1.4
 
ipfire2.cosc.tu 10.0.2.26
    GREEN Subnet 192.168.2.0/24
          europe.cosc.tu 192.168.2.50
    ORANGE Subnet 172.16.2.0/24
           ipfire2.cosc.tu 172.16.2.2
           venus.cosc.tu 172.16.2.4

Then, when after we have built the IPSec VPN Tunnel, we can ping directly from europe.cosc.tu to africa.cosc.tu, even through they are behind separate firewalls, and neither has a public IP address:

C:\Users\seldon>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::1d89:754f:de71:db4c%11
   IPv4 Address. . . . . . . . . . . : 192.168.2.50
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.2.2

Tunnel adapter isatap.{3E270F32-CEBD-4E39-93D5-8FAD0A1F0238}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

C:\Users\seldon>ping -n 3 192.168.1.51

Pinging 192.168.1.51 with 32 bytes of data:
Reply from 192.168.1.51: bytes=32 time=1ms TTL=62
Reply from 192.168.1.51: bytes=32 time=1ms TTL=62
Reply from 192.168.1.51: bytes=32 time=1ms TTL=62

Ping statistics for 192.168.1.51:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

If you set up the aliases on each ipfire system, you can even use hostnames:

[seldon@africa ~]$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:29:02:37:93  
          inet addr:192.168.1.51  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe02:3793/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16485 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4798122 (4.5 MiB)  TX bytes:4785994 (4.5 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)

[seldon@africa ~]$ ping -c3 europe
PING europe.cosc.tu (192.168.2.50) 56(84) bytes of data.
64 bytes from europe.cosc.tu (192.168.2.50): icmp_seq=1 ttl=126 time=1.69 ms
64 bytes from europe.cosc.tu (192.168.2.50): icmp_seq=2 ttl=126 time=1.56 ms
64 bytes from europe.cosc.tu (192.168.2.50): icmp_seq=3 ttl=126 time=1.77 ms

--- europe.cosc.tu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 1.561/1.674/1.773/0.099 ms

Note however that because africa.cosc.tu is behind ipfire.cosc.tu, it only uses named provided by ipfire.cosc.tu for name resolution- it will not also ask ipfire2.cosc.tu for names. Thus the set of aliases has to be repeated on both ipfire hosts for all to work as you wish. Here is the now expanded set of aliases set up on ipfire.cosc.tu; note that it has entries for all of the systems behind either ipfire.cosc.tu or ipfire2.cosc.tu.

A note about versions….

When I began writing these notes, I used the latest version of IPFire 2.13, Core 67. Over the course of two days, I completed the writing for everything, save the last section on IPSec tunnels. At that point, to my chagrin, I discovered that I could not get the Net-to-Net VPN tunnels to work in IPFire 2.13. Whatever I tried, the connections just simply would not work. Logs, Google, whatever- I just couldn’t get it figured out. [BWT- anyone who can explain what I am doing wrong will receive my hearty thanks!] To get everything ready for class this week, I decided to go back to the older 2.11 version, where everything was smoooth as silk. Though I went through and checked everything, it may be possible that there may be some variation between what I have written (most of which was done on 2.13) and what actually occurs (on 2.11)> I think I have everything right, but I just wanted to warn the reader. If you see an error, please just drop me a line.

Comments (0) Trackbacks (0) Leave a comment Trackback

No comments yet.

No trackbacks yet.

CyberOperations