HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=4)
-   -   flush iptables by accident, cannot remotely connect (http://www.howtoforge.com/forums/showthread.php?t=28525)

tiamsanit 8th November 2008 11:35

flush iptables by accident, cannot remotely connect
 
Hello, everyone

I have Internet server which locate at my office. Today I remote via ssh to do some maintainance but something really bad occured. I had accidentally excuse iptables -F command, which made connect to the server all cut.
Now I cannot even ping my server so my only solution is to go to the office and use console for repair, right?

My serious problem is I have no backup of IP rules so if anyone can help me to restore Iptable to its original state or default setting that suitable with ISPconfig server or any safe to deploy rules will be very appriciate.

Thanks in advance

falko 9th November 2008 15:10

Have you tried to reboot the system?

cbj4074 29th May 2013 20:32

Even though this thread is old, it is a) unresolved, and b) a very good question that deserves due attention.

We had someone do this by accident today (execute "iptables -F"); this is a worst-case, potentially-disastrous scenario. Fedora's iptables manual ( https://fedoraproject.org/wiki/How_t...Flushing_Rules ) warns of this scenario:

Quote:

Default chain policys care
Be aware of the default chain policy. For example, if the INPUT policy is DROP or REJECT and the Rules are flushed, all incoming traffic will be dropped or rejected and network communication broken.
As the OP suggested, the only way to fix this is to gain physical access to the server, log-in at the keyboard, and restore the iptables configuration.

If the server is a VPS, or you lack physical access to the server, the only option is to contact whomever manages the VPS (or server hardware, if a physical server) and request that they stop the iptables service for you so that you are able to log-in long enough to repair the problem.

Once able to log into the server via SSH, create a new configuration file that will be used during restore:

Code:

# vi /root/iptables.bak
Insert the following contents into the file and save it.

(Note that these rules are from my own configuration [which is fairly standard and common], and I don't know how closely these rules mimic the ISPConfig defaults [if ISPConfig does, in fact, define any default rules]).

Code:

# Generated by iptables-save v1.4.4 on Wed May 29 10:18:39 2013
*nat
:PREROUTING ACCEPT [23540:1430549]
:POSTROUTING ACCEPT [36001:2469714]
:OUTPUT ACCEPT [36001:2469714]
COMMIT
# Completed on Wed May 29 10:18:39 2013
# Generated by iptables-save v1.4.4 on Wed May 29 10:18:39 2013
*mangle
:PREROUTING ACCEPT [1954001:501799982]
:INPUT ACCEPT [1954001:501799982]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2800876:2841281138]
:POSTROUTING ACCEPT [2800876:2841281138]
COMMIT
# Completed on Wed May 29 10:18:39 2013
# Generated by iptables-save v1.4.4 on Wed May 29 10:18:39 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [118669:13503549]
:INT_IN - [0:0]
:INT_OUT - [0:0]
:PAROLE - [0:0]
:PUB_IN - [0:0]
:PUB_OUT - [0:0]
-A INPUT -d 127.0.0.0/8 ! -i lo -p tcp -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 224.0.0.0/4 -j DROP
-A INPUT -i eth+ -j PUB_IN
-A INPUT -i ppp+ -j PUB_IN
-A INPUT -i slip+ -j PUB_IN
-A INPUT -i venet+ -j PUB_IN
-A INPUT -i bond+ -j PUB_IN
-A INPUT -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j DROP
-A OUTPUT -o eth+ -j PUB_OUT
-A OUTPUT -o ppp+ -j PUB_OUT
-A OUTPUT -o slip+ -j PUB_OUT
-A OUTPUT -o venet+ -j PUB_OUT
-A OUTPUT -o bond+ -j PUB_OUT
-A INT_IN -p icmp -j ACCEPT
-A INT_IN -j DROP
-A INT_OUT -p icmp -j ACCEPT
-A INT_OUT -j ACCEPT
-A PAROLE -j ACCEPT
-A PUB_IN -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A PUB_IN -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A PUB_IN -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A PUB_IN -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A PUB_IN -p tcp -m tcp --dport 20 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 21 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 22 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 25 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 53 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 80 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 110 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 143 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 443 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 465 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 587 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 993 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 995 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 3306 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 8080 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 8081 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 8443 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 10000 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 24441 -j PAROLE
-A PUB_IN -p tcp -m tcp --dport 40110:40210 -j PAROLE
-A PUB_IN -p udp -m udp --dport 53 -j ACCEPT
-A PUB_IN -p udp -m udp --dport 3306 -j ACCEPT
-A PUB_IN -p icmp -j DROP
-A PUB_IN -j DROP
-A PUB_OUT -j ACCEPT
COMMIT
# Completed on Wed May 29 10:18:39 2013

Now, restore the rules from the file you just created using the following command:

Code:

# iptables-restore < /root/iptables.bak
Finally, start the iptables service, now that the configuration has been restored:

Code:

# service iptables start
What a nightmare! I hope this fixes the issue for those who stumble upon this thread in the future.

TiTex 30th May 2013 21:19

or you can just use a simple bash script ... like i do

reset_fw
Code:

#!/bin/sh

IPT="/sbin/iptables"

# Set default policies for all three default chains
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT

# Flush old rules, old custom tables
$IPT --flush
$IPT --delete-chain
$IPT -t nat --flush
$IPT -t mangle --flush



All times are GMT +2. The time now is 03:48.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.