2

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.

  1. Proper way of flushing iptable rules and
  2. 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!

2 Answers 2

2

If the default policy for the chains is DENY then all connections will be cut since there's no longer any way to communicate via TCP/IP. Set the default policies to ACCEPT before flushing, and then back to DENY after re-establishing the rules.

3
  • Could you be more specific. Please place steps here.
    – user53864
    Oct 5, 2010 at 8:48
  • Just like the man page says, -P is used to specify a default policy for a chain. Oct 5, 2010 at 8:57
  • Is there any other way to check if iptable rules works fine as intended before applying them.
    – user53864
    Oct 5, 2010 at 14:38
0

In order to have a safety net during your firewall changes you could deploy a short script which - with the help of crontab - regularily opens your firewall. Only after having successfully finished all changes you then deactivate this cron. See here.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .