# Firewall practical exercises

## Setting up a basic infrastructure

### Questions

**Is this traffic visible on the firewall? If yes, what is the used bandwidth? If not, what is the reason?**

The traffic between the two Debian lite is in the same network so the communication is made directly from the client to the server without passing by the firewall.

**Are these structured the same as what we looked at in the course? If not, can you sketch what the tables' structure is?**

The steps are the same in this structure. (prerouting, input, output, forward, postrouting). We have four tables: NAT and mangle for the PREROUTING and POSTROUTING and row and filter with all the rules for the INPUT, OUTPUT, and FORWARD steps. We found this out with `cat /proc/net/ip_tables_names`

In the end, it is the same structure but with way more rules.


## Adding a DMZ - getting to the next level

### Questions

**running the iperf client on one of the machines in the GREEN network and the server in the DMZ, do you now see the traffic going through the firewall? Does one see the direction of the traffic?**

Now with the server in the orange zone, we can see the traffic on our firewall. In our firewall, we can see the incoming traffic graphic on the Green zone and the outgoing traffic on the orange zone. If we focus on the client and check the system monitor we can see that it is the client that sends the data. Now we know that the incoming traffic is the data entering the firewall and the outgoing traffic is the data exiting the firewall.


**run the web server showing the /var/log from the Debian server - make sure it is accessible - and then run a port scan with nmap -v -A -sV 10.10.10.11 or sudo nmap -vv -Pn -sS -p- -T4 --reason 10.10.10.11. What do you see? Did the scan influence the behavior of the web server? What is the difference between the 2 nmap commands?**

With the command nmap, we can see which port is open (in our case ssh and HTTP), and we can also see the server version for each port.

Since the nmap scans the free ports of the server. If we check the server during or after this scan we can the IP from the person that used the scan and which ports we tried to access.


* `-vv` : Increase verbosity level
* `-Pn` : Declare that the server is running (don't check if it's out)
* `-sS` : Technique used to do scanning (TPC SYN scan)
* `-p-` : Specify to scan ports from 1 through 65535
* `-T4` : Time max between two requests (time max per port 10ms)
* `--reason` : Show the reason each port is set to a specific state



**Can you name what type of firewall it is in the present configuration?**

IPFire employs a Stateful Packet Inspection (SPI) firewall [IPfire documentation](https://www.ipfire.org/features)

**Assuming you something went wrong and could not get the GREEN network accessing the firewall GUI. How would you change this from the command line? The solution does not need to survive a reboot (hint: this is prevented by a specific firewall rule, create one that will make this work)**

With the command line we can use `iptables -A CUSTOMINPUT -p tcp --dport 444 -j ACCEPT` but there's a little catch. Our GUI is now accessible from anywhere including in the red zone so we need to remove this rule after our green zone problem is solved.

To remove the rule, we use first `iptables -L CUSTOMINPUT --line-number` to find the number and `iptables -D CUSTOMINPUT lineNumber` (in our case 1)

**How could you add Intrusion Prevention to ipfire? How does this work?**

IPfire has an included Intrusion Prevention System (IPS). On our system, the daemon was not running so we referred to the [official documentation](https://wiki.ipfire.org/configuration/firewall/ips). IPS is an addition to the Filters and blocks traffic by IP address, protocol, and port. It is also able to do deep package inspection to gather additional information about the traffic allowing the system to detect potentially malicious behavior.

The IPS can be extended with a blacklist from different providers.

**Now, on one of the Debian servers, start a web server (hint: python3 -m HTTP.server) allowing you to see all files under /var/log. Once this is done, give access to this service from the RED network**

To do this, we created a new Firewall Rule to allow connections to our server. We do a port forward of port 8000 toward the IP address of the Debian server.

**You are as professional as one could get but still using a self-signed certificate. How could you replace it with one of your own? Namely, your work as CA in the previous lab**

As the UI is running over an Apache server, we could simply replace the certificates that are stored under `/etc/httpd/`. They use two types of certificates (RSA, and ECDSA). Both can be generated using OpenSSL. The configuration file is stored under ` /etc/httpd/conf/vhosts.d/ipfire-interface-ssl.conf`. Source: [community.ipfire.org](https://community.ipfire.org/t/ipfire-webgui-ssl-certificate-files/2974)

## Lessons learned

During this practical work, we learned how to work with IPFire. Even tho it's not a physical firewall we were able to learn a lot about how to configure a basic SPI firewall. We could also better understand the different rules to allow and block traffic between zones (RED = Public, ORANGE = DMZ, and GREEN = Private)