The iptables package gives us advanced, granular control over our firewall, with important built-in features like filtering and limiting. This guide will cover a more advanced approach, leveraging the mentioned capabilities, the included conntrack module, and restrictive rules, while exploring potential security risks.
Every command we use in this guide (except man) needs elevated privileges, so I have prepended all commands with sudo to make copying everything — after careful checking, of course — easier.
We will be implementing a firewall that follows the principles laid out by the stateful firewall concept.
- .
Manual and documentation
Change default behavior to drop all other packets:
Danger! This may cause loss of access to your machine!
CODEsudo iptables -P INPUT DROP; \
sudo iptables -P OUTPUT DROP; \
sudo iptables -P FORWARD DROP
This will drop all traffic that do not match our previous rules and is a critical component of an effective firewall. Naturally we want to drop all FORWARD chain packets, since this is basically a resource provider and not a router. Under any circumstances there should be no forwarding going on, and if there is anything like that happening, it’s highly likely that there is some malicious activity going on, like tunneling.
Save the the configuration:
CODEsudo netfilter-persistent save
This will first save the rules we just set up to a file and update the configuration.
article available on cs.fyi.- Scripting — make a script that appends allow client HTTP/HTTPS rules after you log in, and deletes them after you’re done with your tasks. This can be automated, but can also be done manually.
- You’ve hardened the system by implementing a robust firewall.
- You’ve gained fundamental knowledge of how firewalls work.
- You’ve also gained insights into both general and specific security concerns (like tunneling, exfiltration, rate-limitting)
Preventing unwanted outgoing HTTP/HTTPS
Following up on the idea that the server itself should not be making new connections on itself (acting as a client), we should disable the potentially unsafe rules to lock our server down, while allowing the bare minimum it needs to serve web content.
As mentioned before, if you are calling any external APIs on the server side, which means in your PHP code (or on your server-side rendered JavaScript app), you will have to leave those rules in to avoid connectivity problems. Removing them will also prevent all packages that pull external data to your machine from working, most importantly apt/apt-get and curl.
Fortunately, at least for administrative purposes, there are solutions. The ones that I personally know of are:
In all cases there will be some overhead.
Use this code snippet to delete the client rules:
sudo iptables -D INPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT; \
sudo iptables -D INPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT; \
sudo iptables -D OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT; \
sudo iptables -D OUTPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
And this snippet to put them back in when you need them:
sudo iptables -A INPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT; \
sudo iptables -A INPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT; \
sudo iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT; \
sudo iptables -A OUTPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j
Congratulations! You have improved your server’s security.
Spotted a mistake? Let me know!
Thank you for reading. Hopefully this guide provided some value :)
SOCIAL SHARE CARD GENERATOR