In this tutorial we are going to work on the firewall configuration of your machine. Some care must be taken when doing this, or you will suddenly find you can no longer log in!

In all these cases the easiest way to do the experiment is to CREATE an executable program in /home/alice called "firewall.nft". You should make the contents of this something like:

#!/usr/sbin/nft -f

flush ruleset

table inet myfirewall {
        chain INPUT {
                type filter hook input priority filter 
                policy drop
                ct state established,related accept
                ip saddr != 10.0.0.0/16 tcp dport {ssh,telnet} accept
        }
        chain FORWARD {
                type filter hook forward priority filter 
                policy accept
        }
        chain OUTPUT {
                type filter hook output priority filter 
                policy accept
        }
}

To execute this file, remember "chmod +x ./filewall.nft" and then just "sudo ./firewall.nft" or "sudo /home/alice/firewall.nft" to run it. Execute it once and they press the check button to make sure everything is set up ok.

After executing this file you can use "sudo nft list ruleset" to show you what rules have been stored in the kernel. The provided rule uses a default policy of ACCEPT for FORWARD and OUTPUT, just in case you make a typo and lock yourself out. Default ACCEPT is certainly weaker than a full firewall using DROP, but this is just to get you going. Later on we look more at the default policy of DROP.

NOTE: If at any time you mess up and can no longer connect via telnet or ssh, then you can either reboot or use VNC to fix the problem. The script is not reexecuted automatically when you reboot, and should still be there on the next boot. VNC is much faster. If you use VNC, once logged in, you can restore the default firewall by doing "sudo systemctl reload nftables.service".

Make the default policy of the FORWARD chain DROP. Leave the other chains as they are. Do this by editing the script appropriately, then rerunning the script. Just set the FORWARD chain default once in the script.

What is the device name for your primary network connection in your virtual machine. Hint: this is the one which is mentioned in your default route.

/dev/

Visit the firewall test page, which can be found as a link off the VM Management page, and run a test on 22,23,25, and 80. All will either be "open" (service there and no firewall) or "closed" (no service there and no firewall).

Add to the end the approriate chain in your file which, when an http packet (tcp) comes in from your main interface, jumps to ACCEPT. Execute the script to activate this change. Do not make this new rule stateful (so no conntrack).

Validate this with the firewall test (which should previously have said "filtered" and now say "open").

Add another rule to the script. This new rule jumps drops ALL TCP PACKETS which have a source address of 20.0.0.0/24 comes in from your main network device. Execute the script to activate this change. You will be marked wrong if your rule has more conditions than those listed in the question. Do not use connection tracking.

If any packet is passed through the FORWARD chain, reject the packet with the default settings.

Accept PING at a limit of 1 per second from any interface in the INPUT chain. Do not use connection tracking in the rule. DROP pings faster than the limit.

Warning. Even without conntrack specifically in the rule, you are still making us of connection tracking rules elsewhere in the file. Only the first ICMP ping is NEW, and the rest are RELATED. Therefore you MUST insert your new rules BEFORE the RELATED,ESTABLISHED test, and make sure that unwanted pings never reach the RELATED test (needs 2 rules).

Double check that this is working using the ping option of the firewall tests (via the "useful" tab in the control panel). You should see "limited,1/second" if you have done this correctly.

Continue on from the previous set of rules. Modify one of the new rules so that if you receive pings faster than 1 per second, those pings will be logged before being accepted. Note that things getting logged will appear at the end of /var/log/messages. Do not use a new chain to do this, and keep the rule as simple as possible. Do not use connection tracking.

Using the firewall tests, run a ping test and then look at the log information created in /var/log/messages or using the dmesg command. With this information, what is the ip of the source of all these ping requests?

Enter the ping ip source:

In this tutorial we are going to work on a strict firewall configuration of your machine. Extra-special care must be taken when doing this, or you will suddenly find you can no longer log in!

Create the following as a script called firewall2.nft in /home/alice, make it executable, and load the rules.

#!/usr/sbin/nft -f

flush ruleset

table inet myfirewall {
        chain INPUT {
                type filter hook input priority filter 
                policy drop
                ct state established,related accept
                ip saddr != 10.0.0.0/16 tcp dport {ssh,telnet} accept
        }
        chain FORWARD {
                type filter hook forward priority filter 
                policy drop
        }
        chain OUTPUT {
                type filter hook output priority filter 
                policy drop
                ct state established,related accept
        }
}

Your ssh and telnet connections are proxied from 10.200.0.1. Thus when you telnet or ssh into linuxzoo, a special program catches this traffic and forwards it on your behalf. This makes ssh and telnet traffic appear to arrive at your virtual machine from a single networked address, the proxy address of 10.200.0.1.

Insert a single rule using this script, inserting before any related/established state test at the start of the INPUT chain so that if someone tries to telnet to your machine from anywhere but 10.200.0.1 it is dropped. Leave the other rules shown above unchanged. Make this a stateful rule, and check the state is NEW before any other test.

Note that if you change one of the other rules, insert more than 1 rule, or do anything other than insert a single rule at the start of the chain, you will always be marked wrong!

Add a rule to the firewall so that if someone on your virtual machine tries to open an http connection to 10.200.0.1, the packet it ACCEPTED. Add this rule to the END of the appropriate chain. Do not change any of the existing rules. Use a stateful rule, and check for NEW state after any other tests.

Add appropriate rules so that, if this machine was a router, it would allow RELATED and ESTABLISHED traffic to flow in both directions (with just one rule), as well as permitting http and ping requests to an intranet machine 192.168.1.5. For your rules you can assume the intranet is on device eth9, and you should make sure that the NEW packets are restricted to be sent only on eth9. Do not change any rules or policy definitions from that of the previous question.

Note that in reality eth9 does not exist. However this should have no effect on the rules. Add only 1 rules for RELATED,ESTABLISHED testing, 1 rule for http, and 1 rule for ping (a total of 3 rules), and create them in that order. Make all rules stateful.