An example Iptables rules file for your Raspberry Pi (and have it applied after each reboot)

Having an Iptables firewall rule set applied onto Raspbian/Debian is fairly easy. I'm trying to build something that is easy to manage, has a certain degree of default security applied, yet will allow that I can easily apply it onto several Raspberry Pi devices.
When adding rules to your running Iptables, they become lost each time you'd reboot or restart your firewall. So, I'm trying to overcome that.

First, let's start with my basic rule set file, which is build around a number of services that I need on my Raspberry Pi:

• SSH server
• OpenVPN server
• HTTP(S) server
• DNS server
• Samba server
• Transmission server

Of course, you can add and customize as much as you want, but here's my example iptables.rules.v4 file:

# Generated by iptables-save v1.6.0 on Sun Feb 18 13:27:56 2018
*nat
:PREROUTING ACCEPT [485:82476]
:INPUT ACCEPT [24:2229]
:OUTPUT ACCEPT [192:15907]
:POSTROUTING ACCEPT [192:15907]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment "Allow OpenVPN routing from source 10.8.0.0 to eth0" -j MASQUERADE
COMMIT
# Completed on Sun Feb 18 13:27:56 2018
# Generated by iptables-save v1.6.0 on Sun Feb 18 13:27:56 2018
*filter
:INPUT DROP [67:11459]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [687:299583]
:f2b-openvpn - [0:0]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -m comment --comment "Block null packets" -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -m comment --comment "Block a syn-flood attack" -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -m comment --comment "Block Xmas packets" -j DROP
# localhost
-A INPUT -i lo -m comment --comment "Allow localhost traffic" -j ACCEPT
-A INPUT -i lo -p tcp -m tcp --dport 4711:4720 -m comment --comment "TODO" -j ACCEPT
# Established connections
-A INPUT -m state --state RELATED,ESTABLISHED -m comment --comment "Allow all established inbound connections" -j ACCEPT
# DNS server
-A INPUT -p udp -m udp --dport 53 -m comment --comment "Allow DNS to this host from anywhere" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m comment --comment "Allow DNS to this host from anywhere" -j ACCEPT
# OpenVPN server
-A INPUT -p tcp -m multiport --dports 1194 -m comment --comment "Allow OpenVPN to this host from anywhere" -j f2b-openvpn
# SSH server
-A INPUT -p tcp -m multiport --dports 22 -m comment --comment "Allow SSH to this host from anywhere" -j f2b-sshd
-A INPUT -p icmp -m icmp --icmp-type 8 -m comment --comment "Allow ping to this host from anywhere" -j ACCEPT
# HTTP server
-A INPUT -p tcp -m tcp --dport 80 -m comment --comment "Allow HTTP to this host from anywhere" -j ACCEPT
# SSLH multiplexer
-A INPUT -p tcp -m tcp --dport 443 -m comment --comment "Allow HTTPS to this host from anywhere" -j ACCEPT
# SSH server
-A INPUT -p tcp -m tcp --dport 22 -m comment --comment "Allow SSH to this host from anywhere" -j ACCEPT
# Samba server
-A INPUT -p tcp -m multiport --dports 139,445 -m comment --comment "Allow Samba to this host from anywhere" -j ACCEPT
-A INPUT -p udp -m multiport --dports 137,138 -m comment --comment "Allow Samba to this host from anywhere" -j ACCEPT
# Transmission server
-A INPUT -p tcp -m tcp --dport 9091 -m comment --comment "Allow Transmission to this host from anywhere" -j ACCEPT
# Reject rules
-A INPUT -m comment --comment "Reject all other inboud traffic, unless specified" -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m comment --comment "Reject all other inboud traffic, unless specified" -j REJECT --reject-with icmp-port-unreachable
-A f2b-openvpn -j RETURN
-A f2b-sshd -j RETURN
COMMIT
# Completed on Sun Feb 18 13:27:56 2018

Would you be wanting to be more specific on the rules (e.g. SSH access), you can easily add a source IP to the rule to further limit access.

# SSH server
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -m comment --comment "Allow SSH to this host from anywhere" -j ACCEPT

We will now be saving this file, so that Iptables can use if after each reboot or restart.

1. Make youself root:
   

   sudo -i

2. Go to the Iptables folder:
   

   cd /etc/iptables/

3. Create a backup of the default rule set:
   

   cp -rp rules.v4 rules.v4.ori

4. Edit the rules.v4 file with vi, remove all entries and paste the rule set listed above
   

   vi rules.v4

5. List your current Iptables rules:
   

   iptables -L

6. Import the new rule set:
   

   iptables-restore < /etc/rules.v4

7. List your Iptables rules again and you should see the new rule set applied:
   

   iptables -L

8. Make the rules survive a reboot by creating this pre-up file:
   

   vi /etc/network/if-pre-up.d/iptables

9. Add this content to the file:
   #!/bin/sh
   

   /sbin/iptables-restore < /etc/iptables.up.rules

10. Make the file executable:
    

    chmod +x /etc/network/if-pre-up.d/iptables

11. Reboot to test

If you later on want to add or change rules, you can change your rules.v4 file, or add them command line to your running configuration. Adding them to your rules.v4 file will make them persist. In the latter case, you'd have to dump the running configuration into your rules.v4 file by applying:

iptables-save > /etc/iptables/rules.v4

Installing SSLH onto Synology DSM6 or DSM7 for easy HTTPS, OpenVPN and SSH through corporate firewall

When you are in a corporate LAN, access to the outside is often restricted. HTTPS is allowed, yet other applications like SSH or OpenVPN might not be. As well, you want to run several of these services onto your Synology box. Choosing which one will use TCP port 443 could be a hard judgement to make. Luckily, there is SSLH to the rescue.

Note: with DSM7, it is no longer possible by default to open port 443 (which is below 1024) with the provided user (sh-sslh). You will get a "0.0.0.0:https:bind: Permission denied" error when changing port 30000 to 443. The fix is to change your portforwarding in your router to NAS_IP:30000 instead. The below tutorial was making the SSLH service listen to port 443 with the other services running on localhost:443.

 As a consequence, changing the sslh.cfg file and the NGINX files is no longer needed, so everything below can be ignorred.

Caution! Playing around with your SSL port could possibly break the access to your DSM if nginx fails to restart. Therefore, I strongly recommend the following actions:

• Never put your SSH server to listen ONLY onto 127.0.0.1. Never.
• Never change all of your services (HTTPS, SSH, OpenVPN) at the same time, unless your 100% sure your config is correct.
• Open up temporarily the Telnet service, just in case
• Make sure you don't lock yourself out with your firewall rules onto your Synology
• Backup the original config files before starting making changes. cp -p config.file config.file.ori will do.

0. Make sure you have the Synocommunity repository installed under your Package Center. Open up an SSH connection to your Synology and make yourself root.
1. Download and install the SSLH package. By default, the configuration file is at /usr/local/sslh/var/sslh.cfg and needs to be adapted. Make a backup copy of the file first.
2. Go to your terminal and edit the file with vi
vi /usr/local/sslh/var/sslh.cfg
3. Change the IP address (under host: "0.0.0.0") to your IPv4 address of the Synology. Do NOT yet change the port. Leave it onto 30000 as default.
4. Check if the services listed are using the correct port numbers and adapt if needed. Save the file.
5. Now go to the Package Center of DSM again and stop and start SSLH.
6. Go to your terminal and verify if SSLH is running properly by running the command:
netstat -an | grep 30000
Expected output:

root@server:/# netstat -an | grep 30000
tcp        0      0 192.168.0.5:30000       0.0.0.0:*               LISTEN

7. Check if HTTPS is currently running and listening to the IPv4 address:

netstat -an | grep 443

Expected output:

root@server:/# netstat -an | grep 443
tcp        0      0 0.0.0.0:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN

This now means that nginx is still listening onto the IPv4 address for HTTPS. Let's change that.

8. Open your web browser and browse to your Synology IP for both HTTP as for HTTPS: http://yourip and https://yourip

Confirm that this is working properly.

9. Go to the nginx config directory (/usr/syno/share/nginx) and backup the following files: DSM.mustache, WWWService.mustache and server.mustache

10. Use vi to change nginx from listening to 0.0.0.0:443 to 127.0.0.1:443 only, by making it look like this:

listen 127.0.0.1:443

DSM.mustache

WWWService.mustache

server.mustache

Repeat this for all 3 files and save your changes.
11. Restart nginx from the command line:
synoservicecfg --restart nginx
You can monitor into /var/log/synoservice.log if things restarted properly. Typical output should be:

2017-01-10T19:04:33+01:00 server synoservicecfg: service_restart.c:21 synoservice: restart [nginx] ...
2017-01-10T19:04:34+01:00 server synoservicecfg: service_restart.c:52 synoservice: finish restart [nginx].

12. Verify that HTTPS is only listening onto localhost (127.0.0.1)

root@server:/usr/syno/share/nginx# netstat -an | grep 443
tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN

13. Refresh the browser screen for your HTTPS. It should not show any website anymore.

14. As a final step, change your SSLH config file and set the port to listen from 30000 to 443. Restart SSLH in the Package Center by doing a stop and start. Or do it command line:
synoservicecfg --restart pkgctl-sslh
15. Verify that SSLH is now listening onto your IPv4 address with port 443.

root@server:/usr/syno/share/nginx# netstat -an | grep 443
tcp        0      0 192.168.0.5:443         0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN

16. You can test your HTTPS, OpenVPN and SSH. All should perfectly route through the SSLH multiplexer.

Enable HTTPS for EmonCMS on Raspbian

Our EmonCMS installation at home currently runs only over HTTP, which is not secure at all. Enabling HTTPS is a must do. However, there's a small tweak needed for it to work at the AllowOverride option.
Tip: If you run into the issue where you have HTTPS enabled, but the logging in returns always the login screen with message 'undefined', follow the fix explained below.

Check if HTTPS is already enabled for your Apache installation:

root@raspi1:~# netstat -an | grep LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

As you can see, there is nothing running on port 443 (HTTPS) yet, so we'll need to enable the HTTPS configuration for Apache.

Enable the default HTTPS (SSL) configuration for Apache:

1. Check if the SSL module is already enabled for Apache.

root@raspi1:~# ls -l /etc/apache2/mods-enabled/*ssl*
root@raspi1:~#

If nothing is returned, the module is not enabled yet and needs to be linked from /etc/apache2/mods-available/

2. Make a symbolic link for the SSL module.

root@raspi1:~# cd /etc/apache2/mods-enabled/
root@raspi1:~# ln -s ../mods-available/ssl.conf ssl.conf
root@raspi1:~# ln -s ../mods-available/ssl.load ssl.load

3. Make a symbolic link for the SSL config file.

root@raspi1:~# cd /etc/apache2/sites-enabled/
root@raspi1:~# ln -s ../sites-available/default-ssl 000-default-ssl

4. Change two lines in the config file.

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                #Changed None to All on 18/11/2016
                AllowOverride All
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                #Changed None to All on 18/11/2016
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

5. Restart your Apache now.

root@raspi1:~# /etc/init.d/apache2 restart

This tip came from here.