iptables Basics : Chapter 1

We talked about a primitive guide on all step to get started with a blank server and SSH.Iptables, ip6tables are used to maintain packet filter rules in the Linux kernel. IPTables Basics Chapter 1 is Intended For the New Blank Cloud Server or Dedicated Server Users. It is Must to Read Before Executing Commands. We will not go towards to much complicated theoretical matters. Ubuntu has guide on iptables (you should read it as as additional iptables basics), however, what we are saying is not written in commonly known websites. Situation like getting flooded on SSH by attack like we described in this article is not uncommon. pam_unix(sushi:auth): authentication failure error can make the root user unable to run commands. We need precautions for not allowing it to easily happen.

Again – these ways are not substitute for nightly backup of whole FTP, database on some server or storage.

 

iptables Basics : Do Not Run Commands to Drop Everything Without Knowing

 

Quite commonly, new users run commands following the guides from various web hosts and end up locking up themselves. Know it quite well – system administrator of web host of any virtual server, cloud server i.e. server instance running on virtualization can reset or flush iptables on request regardless of the plan is managed or unmanaged. Complicated route to hack own server to reset rules out of wrong iptables rules is remotely possible, rather it can be impossible. For dedicated servers and colocation servers, it can be very difficult to reset iptables. In case you are under attack, instead of reading this guide you should approach in the way we described.

 

iptables Basics : Create an Automatic Default iptables rules Restore System While Testing

 

L is listing.
D is delete.
A is addition.
F is flush.
P is policy.
X is delete chain xxxxx

If you create an automatic default iptables rules restore system while testing to reset it back every 15 minutes or so, you can really play with iptables. Guides from various web hosts never say this basic. In case of Ubuntu, iptables rules are saved in /etc/iptables/rules.v4 file. Please find documentation about the location your server operating system saves the rules. We can run a cat on the file so see :

You will manually save the successful file at root’s home as backup with this command :

ONLY run the command when you are 100% sure about the settings. Else cat the current file :

Highlight, copy and paste on Github as gist. Now, open cron with the command :

If you add this at the end :

iptables will get flushed every 10 minutes with saved file from /root/rules.v4. That needs verification with change on iptables. Add a line on /etc/iptables/rules.v4 like this :

Make fully sure that your server operating system really saves on /etc/iptables/rules.v4. Use easy rules first. Take that 167.114.0.192 is your current dynamic IP of internet connection. If you block it :

You can not SSH from that server to your server under question for 10 minutes. ISP usually allocate dynamic IP address or you can SSH from other internet connection, blocking own self is safe to check rules than throwing stones at the others at the very beginning. When you will not need the automatic deletion, simply comment out that line from cron :

 

iptables Basics : Understand the Syntax and Order of Logics

 

These are quite dangerous commands to run at the beginning :

Unless you made our described Automatic Default iptables rules Restore System While Testing, you may start to cry if you already have not applied any allow rule to accept and continue using SSH. You will be kicked out of the session and just can not SSH.

If we run :

we will get the list of rules. To be very honest, everything written on :

and our previous guide for iptables and security will do the basic.

You should understand input, output and forward. Ingress and Egress are terminology for router or virtual router. Web server is not normally router. We say 3 types of matters – input, output and forward. You are reading this webpage as port 443 output is widely allowed. If you try to SSH to our server, that input request will be dropped or rejected to forward. Make terminal full screen and run this :

You will see line numbers. We can filter the output more with :

We can combine both :

The 1 in the above command is line number.

If I need to add a rule to block the IP 167.114.0.192 on line number 2, I will run :

Drop and Reject has difference. Drop means as if the server’s that port or function does not exist. Reject is softer Drop – it do acknowledge that server’s that port or fiction exists. Suppose if we Drop the port to ping, it will appear as 100% loss – many services need to understand that amount of loss to mark as server is up or online. With Reject, the loss will be 0%.

This is an example of correct order of policy written on /etc/iptables/rules.v4 file :

Why correct? First we are saying to accept port 22, port 80 etc. Thereafter we are saying -A INPUT -j DROP. That means – allow on mentioned ports, then disallow ALL OTHER ports.

But this is wrong order of logic :

We are saying to Drop all the ports on the first instance. Also we have not said to continue the current connection. Now to maintain the correct logical hierarchy, I need to run these first :

Before allowing the ports. Funnily, that will kick out me from SSH. But if we run cron to run the set of commands, that will not happen. Alternatively, we can copy-paste rules in correct order. Tutorials commonly begin with :

to make sure that the order is maintained. But, basically the kicking out is not really practical to prevent. To make ensure to allow all established connections and on-going sessions through the firewall, we need to run :

or, we can directly write to the file

More precisely, under Chain INPUT (policy DROP) we should have it :

Ready to use stuffs definitely available, next good guides and sources are :

It is really impractical idea today to use only few easy policies.

 

What We Learned From iptables Basics, Chapter 1

 

1. We should create an automatic default iptables rules restore system while testing to reset it back every few minutes
2. We can request web host to reset iptables in case of cloud server, virtual server
3. iptables saves rules in a file
4. iptables follow and order to read the rules from the file
5. We can directly run iptables commands or run via script with cron or copy paste from ready to use file

If you are done with this chapter, read iptables Basics : Chapter 2.