13- IPFire

Installation

We will build a complete IPFire (2.11) 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-core57.iso). Yes, the entire .iso is 77 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 do not need a floppy drive; select it and remove it. 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. 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

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. 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:62:e0:a7"
ethernet1.generatedAddress = "00:0c:29:62:e0:b1"
ethernet2.generatedAddress = "00:0c:29:62:e0:bb"

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.

From the network configuration menu, next select Drivers and card assignments. For the GREEN interface, select the network card that you mapped to VMNet2 above. 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)- 192.168.1.0/24
• Private (Green)- 172.16.1.0/24
• DMZ (Orange)- 172.16.2.0/24

(My home network is built on 192.168.1.0/24; in class I would use the appropriate public space 10.0.x.0/24 and leave the others as listed.)

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

• Public (Red)- 192.168.1.2
• Private (Green)- 172.16.1.2
• DMZ (Orange)- 172.16.2.2

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 shades.cosc.tu on 192.168.1.60. 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:62:E0:B1  
          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:206 errors:0 dropped:0 overruns:0 frame:0
          TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:32564 (31.8 Kb)  TX bytes:147936 (144.4 Kb)
          Interrupt:19 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:73 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:7097 (6.9 Kb)  TX bytes:7097 (6.9 Kb)

orange0   Link encap:Ethernet  HWaddr 00:0C:29:62:E0:BB  
          inet addr:172.16.2.2  Bcast:172.16.2.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:0x2400 

red0      Link encap:Ethernet  HWaddr 00:0C:29:62:E0:A7  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:9826 errors:0 dropped:0 overruns:0 frame:0
          TX packets:584 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:779523 (761.2 Kb)  TX bytes:64598 (63.0 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 -c 2 192.168.1.1
PING 192.168.1.1 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.832 ms
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
round-trip min/avg/max/mdev = 0.832/1.207/1.582/0.375 ms

[root@ipfire ~]# ping -c2 192.168.1.60
PING 192.168.1.60 (192.168.1.60) 56 data bytes
64 bytes from 192.168.1.60: icmp_seq=0 ttl=64 time=4.176 ms
64 bytes from 192.168.1.60: icmp_seq=1 ttl=64 time=0.452 ms
--- 192.168.1.60 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
round-trip min/avg/max/mdev = 0.452/2.314/4.176/1.862 ms

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

Name:   shades.cosc.tu
Address: 192.168.1.60

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

To check the ORANGE interface, start a new box (BT5R2 is a nice choice). Set the network adapter to VMNet3. Assign the BT5R2 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.2.3 netmask 255.255.255.0
root@bt:~# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:98:20:34  
          inet addr:172.16.2.3  Bcast:172.16.2.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe98:2034/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:3330 (3.3 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:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1569 (1.5 KB)  TX bytes:1569 (1.5 KB)

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

From IPFire, ping the BT5R2 box at 172.16.2.3. From BT5R2, ping the IPFire box at 172.16.2.2. Verify that the BT5R2 box can also access the class network, by having it ping the class gateway and then your nameserver; it should also be able to perform name resolution.

root@bt:~# ping -c 2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=2.00 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=1.87 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.876/1.942/2.008/0.066 ms

root@bt:~# ping -c 2 192.168.1.60
PING 192.168.1.60 (192.168.1.60) 56(84) bytes of data.
64 bytes from 192.168.1.60: icmp_seq=1 ttl=63 time=1.58 ms
64 bytes from 192.168.1.60: icmp_seq=2 ttl=63 time=0.832 ms

--- 192.168.1.60 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.832/1.207/1.582/0.375 ms

root@bt:~# nslookup hargas.cosc.tu 192.168.1.60
Server:		192.168.1.60
Address:	192.168.1.60#53

Name:	hargas.cosc.tu
Address: 192.168.1.75

Checking the GREEN interface is similar. Start a new box- say another BT4R2. Set the network adapter to VMNet2. Set the BT5R2 machine to the static IP address 172.16.1.3 with netmask 255.255.255.0; also set the default route of the BT4R2 machine to 172.16.1.2. Then verify that you the BT5R2 can ping the ipfire and vice versa; also check that the BT5R2 can ping the class getway, the name server, and perform name resolution.

root@bt:~# ifconfig eth0 172.16.1.3 netmask 255.255.255.0
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

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=0.988 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=64 time=0.504 ms

--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.504/0.746/0.988/0.242 ms

root@bt:~# ping -c 2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=1.82 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.825/1.888/1.951/0.063 ms

root@bt:~# ping -c 2 192.168.1.60
PING 192.168.1.60 (192.168.1.60) 56(84) bytes of data.
64 bytes from 192.168.1.60: icmp_seq=1 ttl=63 time=1.62 ms
64 bytes from 192.168.1.60: icmp_seq=2 ttl=63 time=0.629 ms

--- 192.168.1.60 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.629/1.129/1.629/0.500 ms

root@bt:~# nslookup hargas.cosc.tu 192.168.1.60
Server:		192.168.1.60
Address:	192.168.1.60#53

Name:	hargas.cosc.tu
Address: 192.168.1.75

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.
• 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.

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, 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 vimes@shades.cosc.tu:/home/vimes
vimes@shades.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 vimes@shades.cosc.tu:/home/vimes/server.crt ./
vimes@shades.cosc.tu's password: 
server.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 either 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). Other add-on services can be installed. See http://wiki.ipfire.org/en/configuration/status/services for more details.

Connections

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.

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.

Set up IPFire to serve as a transparent web proxy. 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 vieiwing 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, you can go to a page that will allow you to 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, 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. 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.

In what follows, we will set up two additional aliases for the IPFire machine together with appropriate external DNS entries. In particular, we have

ipfire.cosc.tu = 192.168.1.2
webserver1.cosc.tu = 192.168.1.3
webserver2.cosc.tu = 192.168.1.4

where all of these names and addresses are on the external (RED) network.

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

Services Tab

Now we consider the entries under the Services tab.

IPSec

The IPSec entry in the side menu takes you to a web page to allow you to use IPSec to set up two types of VPN tunnels- either host-to-network tunnels (RoadWarrior tunnels) or a net-to-net VPN. Given the time constraints of class, I am not going to cover this topic. See http://wiki.ipfire.org/en/configuration/services/ipsec for details.

OpenVPN

The OpenVPN entry in the side menu takes you to a web page to allow you to set up VPN connections using TLS (SSL) rather than IPSec as above. Nope- we don’t have time for this either. It is cool though- even if the documentation online (especially the pictures) is occasionally in German. See http://wiki.ipfire.org/en/configuration/services/openvpn for details.

Time Server

The Time server entry in the side menu takes you to a page that you guessed it- will let you use IPFire as a time server. If you want to provide time to your local network, this must be enabled here. See http://wiki.ipfire.org/en/configuration/services/ntp for documentation, partially in German.

Snort

When using snort, be sure your system has sufficient memory. If you attempt to run snort with 256 MB of memory, the default amount allocated by VMWare to a new generic Linux 2.6 install, you will not even be able to start snort with the existing configuration file; it will fail with the error

ERROR: snort_stream5_tcp.c(906) Could not initialize tcp session memory pool.
Fatal Error, Quitting..

The intrusion detection entry in the side menu takes you to a page that lets you configure the snort intrusion detection system. Note that the installed version of IPFire does not come bundled with a set of snort rules; it also does not come with a
tuned configuration file. In the classroom environment, you have three options.

Option 1:. Copy your IPFire virtual machine to a computer with a functioning Internet connection. 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.

In this case, you will be able to use the web interface to configure and manage your rules.

Option 2. If you are unable to copy the IPFire virtual machine to a system connected to the Internet, then it is possible to manually rebuild the snort system directly on the IPFire box. However, this will disable the web interface for the intrusion detection system. Further, much of the existing infrastructure for the intrusion detection system needs to be modified. Whether you begin with the snort.conf file that comes with the IPFire machine, or begin with the snort.conf file that comes with the rule set, you will discover that both require significant modifications before they will be functional.

Option 3. Don’t use snort on the IPFire machine; given the use of VMWare in our network, you may be better served by simply creating dedicated intrusion detection systems.

I actually recommend this alternative.

Trying option 1 and using IPFire with an Oinkcode in my test environment, I found that the intrusion detection system would occasionally fail to start, but the GUI would not mention this fact back to the user. For example, some rules require the variable $FILE_DATA_PORTS to be set; it is not set in the default snort.conf file. The only way I found out that it had not started (in the GUI) was to go back to the services section of the status tab; this could be verified using ps from the command prompt. I discovered the underlying cause of the problem with the variable by simply running

[root@ipfire ~]# snort -c /etc/snort/snort.conf

and discovering that it fail, reporting back

ERROR: /etc/snort/rules/web-client.rules(47) ***PortVar Lookup failed on
'$FILE_DATA_PORTS'.
Fatal Error, Quitting..

This was simple enough to correct (Add an appropriate line to snort.conf) but it does serve to make me nervous- I would hate to have a key service die without letting me know of the problem.

Trying option 2, you will discover that it really does require a significant investment of time to build the IDS on IPFire. But- you can probably do it in much less time on a dedicated box. Despite spending more time, you would not be able to use the GUI from IPFire- so why do the extra work? Your stand alone box is probably also a bit easier to configure, and can be set up with Barnyard2, a database, and SnortReport.

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.

For example, suppose you have a two web servers located in your DMZ, one at 172.16.2.75 and the second at 172.16.2.120. Recall that earlier we set up two additional aliases for our external IP- 192.168.1.3 has the alias webserver1.cosc.tu and 192.168.1.4 has the alias webserver2.cosc.tu. We can then set up four port forwarding rules to send HTTP (TCP/80) and HTTPS (TCP/443) traffic aimed at webserver1.cosc.tu to 172.16.2.75 while HTTP & HTTPS traffic aimed at webserver2.cosc.tu is sent on to 172.16.2.120.

External Access

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?

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 have a MySQL database server in our internal (GREEN) network at 172.16.1.35. We want our web servers, located in the DMZ at 172.16.2.75 and 172.16.2.120 to be able to access that database. 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.

The Logs tab

The elements of the logs tab are self-explnatory.