NETS1028

Lab 04 Firewalls and filters

This unit provides basic coverage of the tools and techniques for firewalling and filtering traffic on a Linux system.

Iptables Basics

This activity will familiarize you with the basics of creating rules for iptables chains and verifying whether your rules do what you wanted them to do.

1. connect to your server’s ssh service with a terminal window or with putty
2. Log into the student account
3. Since we are using a prebuilt VM that has ufw configured, save the existing ufw configuration ONLY DO THIS ONCE, EVEN IF YOU RESTART THE LAB

   sudo ufw show added >~/`date +%Y%m%d%H%M-ufw-rules-saved.$$`
   

4. Clear out the leftovers from iptables

   sudo ufw reset
   sudo iptables -F
   sudo iptables -X
   

5. Verify you can connect to your VM using a web browser
   • use the ip address of your ens33 interface (ip a s ens33)
   • access the cockpit service at http://W.X.Y.Z:9090 (W.X.Y.Z should be your VM’s ens33 IP address)
   • login to the cockpit service with the student login and password that used for ssh
6. Create a set of iptables rules to
   • allow any traffic on the loopback interface
   • allow ssh inbound traffic on your ens33 interface
   • log and count any input tcp traffic that is not destined for your ssh service
   • set the INPUT and OUTPUT policy to DROP

     iptables -A INPUT -i lo -j ACCEPT
     iptables -A OUTPUT -o lo -j ACCEPT
     iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
     iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
     iptables -P INPUT DROP
     iptables -P OUTPUT DROP
     

7. Is your cockpit web page still updating?
8. Does your ssh session still work?
9. See what is getting logged for your iptables rules

   sudo grep DENIED /var/log/kern.log
   

10. View your iptables rules using the -L and -S options

    sudo iptables -L
    sudo iptables -S
    

11. Which one is more useful to see your rules?
12. Reboot your VM
13. View your iptables rules again. Did the reboot change anything?

Iptables Persistence

1. Reinstall the iptables rules from the first part of the lab and verify they are present

   iptables -A INPUT -i lo -j ACCEPT
   iptables -A OUTPUT -o lo -j ACCEPT
   iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
   iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
   iptables -P INPUT DROP
   iptables -P OUTPUT DROP
   iptables -L
   

2. Install the iptables-persistent package, without agreeing to save the rules during installation of the package

   sudo apt install iptables-persistent
   

3. Save your IPV4 rules with the iptables-save command

   sudo iptables-save |tee /etc/iptables/rules.v4
   

4. Examine the contents of /etc/iptables/rules.v4 and compare it to the output of iptables-save
5. Reboot and verify your rules are automatically reinstalled

   reboot
   

6. Remove the iptables-persistent package

   sudo apt remove iptables-persistent
   

7. Reboot and check if your rules are still getting installed at boot

   reboot
   

Kernel Tuning with sysctl

1. Run sysctl -a to get an idea of the kernel parameters currently set up on your system
2. What are the security implications of being able to retrieve this type of information as an ordinary user?
3. https://www.kernel.org/doc/Documentation/sysctl/vm.txt has excellent sysctl documentation for kernel version 2.6 (still in use in production systems and embedded systems)
   • Find the swappiness parameter in that document to see what it can do for you
   • Check out the wikipedia article for more info

Performance tuning also affects resiliency, example references on tuning for performance include: http://wiki.mikejung.biz/Ubuntu_Performance_Tuning
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/
https://lonesysadmin.net/2013/12/19/account-bandwidth-delay-product-larger-network-buffers/

Iptstate

1. Install iptstate package

   sudo apt install iptstate
   

2. Clear your iptables rules and add back the rules we have been using, but with connection tracking turned on for new connections to the ssh service

   sudo ufw reset
   sudo iptables -F
   sudo iptables -X
   sudo iptables -A INPUT -i lo -j ACCEPT
   sudo iptables -A OUTPUT -o lo -j ACCEPT
   sudo iptables -A INPUT -i ens33 -p tcp --dport ssh -m conntrack --ctstate NEW -j ACCEPT
   sudo iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
   sudo iptables -P INPUT DROP
   sudo iptables -P OUTPUT DROP
   

3. Run iptstate and observe the various connections being tracked by iptables

   sudo iptstate -f
   

4. Use iptables -L -v to see the packet and byte counts being seen by the various rules you have in place

   sudo iptables -L -v
   

UFW

UFW is already installed on the lab VM.

1. Clear out the iptables rules we currently have, as well as any leftover ufw rules

   sudo ufw reset
   sudo iptables -F
   sudo iptables -X
   

2. Use ufw to allow ssh traffic

   sudo ufw allow ssh
   

3. Check your status with ufw, enable it, recheck your status

   sudo ufw status
   sudo ufw enable
   sudo ufw status
   

4. Run iptables -L -v with the ufw firewall tool in enabled state

   sudo iptables -L -v
   

5. Disable the ufw firewall tool and see what is left behind in your live iptables

   sudo ufw disable
   sudo ufw status
   sudo iptables -L
   

6. Clear out your tables for the next exercise

   sudo ufw reset
   sudo iptables -F
   sudo iptables -X
   

Ipkungfu

1. Install the ipkungfu package and check its state after installation

   sudo apt install ipkungfu
   sudo ipkungfu -c
   

2. Note the configuration files in /etc/ipkungfu
3. Modify ipkungfu.conf to set GATEWAY=0, DISALLOW_PRIVATE=0

   sudo vi /etc/ipkungfu/ipkungfu.conf
   

4. Modify services.conf to ACCEPT ftp and ssh traffic

   sudo vi /etc/ipkungfu/services.conf
   

5. Run ipkungfu –show-vars to see your current configuration with ipkungfu’s guesses and correct any settings you can see are not right for your VM

   sudo ipkungfu --show-vars
   

6. Run ipkungfu -t to test and install your new configuration

   sudo ipkungfu -t
   

7. Use iptables -L to see the new iptables configuration

   sudo iptables -L
   

8. Check /etc/default/ipkungfu to see if it is enabled on system startup (IPKFSTART setting) and make sure it is disabled before doing fail2ban

   sudo cat /etc/default/ipkungfu
   

Fail2ban

For this activity, you will want to have 2 separate terminals or putty windows running at the same time. Do the steps up to monitoring the log file in the first window, and then switch to the other window to cause the failed logins. Once you do that, the ip address that the failures are coming from will be banned, so be sure your second session isn’t coming from the same ip address as your first session.

1. Clear out your tables before starting the exercise

   sudo ufw reset
   sudo iptables -F
   sudo iptables -X
   

2. Install fail2ban

   sudo apt install fail2ban
   

3. Use fail2ban-client to see the default configuration that is running

   sudo fail2ban-client status
   

4. Check the status of default sshd jail that is installed

   sudo fail2ban-client status sshd
   

5. Start monitoring the fail2ban.log using tail -f to see what the service does for the next steps

   sudo tail -f /var/log/fail2ban.log
   

6. Use a second terminal/putty window to login to your VM from a different machine than your other ssh session, but give the wrong password 6 times in a row while watching the fail2ban log in your other ssh session
7. Once the service bans your ip according to the watched logfile, cancel the logifle monitoring using ^C (ctrl-c) and examine the ban with the following commands in the terminal window that is still working

   fail2ban-client status sshd
   fail2ban-client get sshd bantime
   

8. Clear the ban manually

   fail2ban-client set sshd unbanip w.x.y.z
   fail2ban-client status sshd
   

9. Verify your second terminal/putty window can connect using ssh again