How to flush iptables perfectly on Ubuntu servers without any risks?.
I have some ubuntu cloud servers and I will access them via ssh. I enter my iptable rules in the file "/etc/iptables.rules" and I will apply these rules with the command "iptables-restore < /etc/iptables.rules".
cat /etc/iptables.rules
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state -i eth0 –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 10000 -j ACCEPT
COMMIT
My IT manager checked and found some ports listed as open ports with the tool "nmap" which I didn't include in /etc/iptables.rules file and I'm asked to fix this soon. So I just guessed(don't know exactly) that it might need flushing iptable rules and this was the ever big mistake of mine and I felt it's shame to the position 'Administrator'. I used "iptables -F" soon after my current ssh session got terminated and that cloud server was not even accessable directly. Then I started it in "Rescue Mode" and the default iptable rules were applied. From then I get tensed if it is regarding iptables.
This forum helped me a lot and I hope this risk will turn into easy.
- Proper way of flushing iptable rules and
- Only allowed ports should be listed as open ports
need help…
I have check the following on a local machine for flushing iptables and it worked:
/sbin/iptables –policy INPUT ACCEPT
/sbin/iptables –policy OUTPUT ACCEPT
/sbin/iptables –policy FORWARD ACCEPT
/sbin/iptables -F
I will be using 'iptables-apply /etc/iptables.rules' to avoid misconfiguration. So is it possible to place above entries in the file /etc/iptables.rules for flushing?.
i.e, placing the above entries into the iptables.rules file.
I have nmap monitoring tool installed. I used the following to check the open ports:
nmap -vv –sS -O –T2 –R –randomize_hosts -oA perpetual 192.168.2.101
It shows some ports(https,ftp…) as open ports which are not included in the above iptable rules. The following is the out put of the above namp commnad
NSE: Loaded 0 scripts for scanning.
Failed to resolve given hostname/IP: –sS. Note that you can't use '/mask'
AND '1-4,7,100-' style IP ranges
Failed to resolve given hostname/IP: –T2. Note that you can't use '/mask'
AND '1-4,7,100-' style IP ranges
Failed to resolve given hostname/IP: –R. Note that you can't use '/mask'
AND '1-4,7,100-' style IP ranges
Initiating Parallel DNS resolution of 1 host. at 15:36
Completed Parallel DNS resolution of 1 host. at 15:36, 0.02s elapsed
Initiating SYN Stealth Scan at 15:36
Scanning 192.168.2.101 [1000 ports]
Discovered open port 21/tcp on 192.168.2.101
Discovered open port 443/tcp on 192.168.2.101
Discovered open port 25/tcp on 192.168.2.101
Discovered open port 22/tcp on 192.168.2.101
Discovered open port 80/tcp on 192.168.2.101
Discovered open port 10000/tcp on 192.168.2.101
Discovered open port 8009/tcp on 192.168.2.101
Discovered open port 8081/tcp on 192.168.2.101
Completed SYN Stealth Scan at 15:36, 0.07s elapsed (1000 total ports)
Initiating OS detection (try #1) against 192.168.2.101
Retrying OS detection (try #2) against 192.168.2.101
Retrying OS detection (try #3) against 192.168.2.101
Retrying OS detection (try #4) against 192.168.2.101
Retrying OS detection (try #5) against 192.168.2.101
Host 192.168.2.101 is up (0.000096s latency).
Scanned at 2010-10-06 15:36:46 IST for 12s
Interesting ports on 192.168.2.101:
Not shown: 992 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
443/tcp open https
8009/tcp open ajp13
8081/tcp open blackice-icecap
10000/tcp open snet-sensor-mgmt
No exact OS matches for host (If you know what OS is running on it, see
http://nmap.org/submit/ ).
The output of ' netstat -an | grep "LISTEN " ' :
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp6 0 0 :::8081 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::8009 :::* LISTEN
Thank You!
Best Answer
If the default policy for the chains is
DENYthen all connections will be cut since there's no longer any way to communicate via TCP/IP. Set the default policies toACCEPTbefore flushing, and then back toDENYafter re-establishing the rules.