LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Debian iptables on boot (https://www.linuxquestions.org/questions/linux-newbie-8/debian-iptables-on-boot-688694/)

keyboard1973 12-06-2008 01:46 AM

Debian iptables on boot
 
Hello,

I am new to Debian with some experience on Centos. I am trying to configure iptables for Debian to start on boot. I have iptables intstalled and my iptables.rules file is located in /etc. I was reading several things about putting in softlinks in the init.d or rc3.d to get iptables to start on boot. Could someone point me in the right direction, everything I have tried so far I cannot get iptables to survive the reboot. Here is the rules I have listed.

# Written by Robert Penz <robert.penz@outertech.com>
# This script is under GPL 2 or above
#
# Ideas and parts from
# Christophe Grenier <grenier@cgsecurity.org>
# Olivier Boudeville <olivier.boudeville@online.fr>
#

# To debug this kind of firewall script, one may use :
# sh -x /path/to/this/file


# Useful with 'iptables --list' or 'iptables -L -n |more' to check
# whether rules are up-to-date :
rules_version=1


# full path of the programs we need - changed them to your needs
iptables=/sbin/iptables
modprobe=/sbin/modprobe
echo=/bin/echo

# Load appropriate modules.
$modprobe ip_tables

# we load that modules as we want to do statefull firewalling
$modprobe ip_conntrack
$modprobe ip_conntrack_ftp


# These lines are here in case rules are already in place and the script is ever rerun on the fly.
# We want to remove all rules and pre-exisiting user defined chains and zero the counters
# before we implement new rules.
$iptables -F
$iptables -X
$iptables -Z

# Set up a default DROP policy for the built-in chains.
# If we modify and re-run the script mid-session then (because we have a default DROP
# policy), what happens is that there is a small time period when packets are denied until
# the new rules are back in place. There is no period, however small, when packets we
# don't want are allowed.
$iptables -P INPUT DROP
$iptables -P FORWARD DROP
$iptables -P OUTPUT DROP

## ============================================================
## Kernel flags
# To dynamically change kernel parameters and variables on the fly you need
# CONFIG_SYSCTL defined in your kernel. I would advise the following:

# Enable response to ping in the kernel but we'll only answer if
# the rule at the bottom of the file let us.
$echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all

# Disable response to broadcasts.
# You don't want yourself becoming a Smurf amplifier.
$echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Don't accept source routed packets. Attackers can use source routing to generate
# traffic pretending to be from inside your network, but which is routed back along
# the path from which it came, namely outside, so attackers can compromise your
# network. Source routing is rarely used for legitimate purposes.
$echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

# Disable ICMP redirect acceptance. ICMP redirects can be used to alter your routing
# tables, possibly to a bad end.
$echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

# Enable bad error message protection.
$echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

# Turn on reverse path filtering. This helps make sure that packets use
# legitimate source addresses, by automatically rejecting incoming packets
# if the routing table entry for their source address doesn't match the network
# interface they're arriving on. This has security advantages because it prevents
# so-called IP spoofing, however it can pose problems if you use asymmetric routing
# (packets from you to a host take a different path than packets from that host to you)
# or if you operate a non-routing host which has several IP addresses on different
# interfaces. (Note - If you turn on IP forwarding, you will also get this).
for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
$echo "1" > ${interface}
done

# Log spoofed packets, source routed packets, redirect packets.
$echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

# Make sure that IP forwarding is turned off. We only want this for a multi-homed host.
$echo "0" > /proc/sys/net/ipv4/ip_forward



## ============================================================
# RULES

## First rule is to let packetes through which belong to establisted or related connection
# and we let all traffic out as we trust ourself.
$iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# ---------------- INPUT ---------------------


## Log some invalid connections :
$iptables -A INPUT -m state --state INVALID -m limit --limit 2/ -j LOG --log-prefix "[#$rules_version : invalid input : ]"
$iptables -A INPUT -m state --state INVALID -j DROP

## Avoid stealth TCP port scans if SYN is not set properly :
$iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcpflags ! ALL SYN -j DROP


## FRAGMENTS
# I have to say that fragments scare me more than anything.
# Sending lots of non-first fragments was what allowed Jolt2 to effectively "drown"
# Firewall-1. Fragments can be overlapped, and the subsequent interpretation of such
# fragments is very OS-dependent.
# I am not going to trust any fragments.
# Log fragments just to see if we get any, and deny them too.
$iptables -A INPUT -f -j LOG --log-prefix "[#$rules_version : iptables fragments ] : "
$iptables -A INPUT -f -j DROP


## auth/ident
#if we drop these pakets we may need to wait for the timeouts
# e.g. on ftp servers
$iptables -A INPUT -p tcp --dport 113 -m state --state NEW -j REJECT --reject-with tcp-reset

## http stuff
#$iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

## ftp
#$iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT

## ssh
# This rules allow to prevent brute-force SSH attacks by limiting the
# frequency of attempts :
# Logs too frequent attempts tagged with 'SSH' and drops them :
$iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j LOG --log-prefix "[#$rules_version : SSH brute-force ] : "
$iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

# Tags too frequent SSH attempts with the name 'SSH' :
$iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH

# Accepts nevertheless normal SSH logins :
$iptables -A INPUT -p tcp --dport 22 -j ACCEPT


## mail stuff
#$iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 143 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 993 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 995 -m state --state NEW -j ACCEPT

## DNS server
# Allow UDP&TCP packets to the DNS server from clients. (only needed
# if this computer is a DNS server)
#$iptables -A INPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p udp --dport 53 -m state --state NEW -j ACCEPT

## LOOPBACK
# Allow unlimited traffic on the loopback interface.
# e.g. needed for KDE, Gnome
$iptables -A INPUT -i lo -j ACCEPT
$iptables -A OUTPUT -o lo -j ACCEPT

# ---------------- ICMP ---------------------

# all can ping me - remove that line if no one should be able to ping you
$iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT

# ---------------- LOGGING -------------------

# log every thing else, up to 5 packets per min
#$iptables -A INPUT -m limit --limit 5/minute -j LOG

I just want to open ssh for the time being.

Thanks,

Keith

fordeck 12-06-2008 09:50 AM

You might try iptables-save and iptables-restore as a starting point. Here is a link that might be of some help:

http://iptables-tutorial.frozentux.n...#IPTABLES-SAVE

I believe on Debian there is a default setup file that has some useful information, I think this file is located as follows:

/etc/default/iptables

Read it for some helpful instructions.

Regards,

Fordeck

keyboard1973 12-07-2008 02:10 AM

Quote:

Originally Posted by fordeck (Post 3366391)
You might try iptables-save and iptables-restore as a starting point. Here is a link that might be of some help:

http://iptables-tutorial.frozentux.n...#IPTABLES-SAVE

I believe on Debian there is a default setup file that has some useful information, I think this file is located as follows:

/etc/default/iptables

Read it for some helpful instructions.

Regards,

Fordeck

Ok this is where I am at.

All I want open is ssh. I saved my rules in /root/iptables-save.out


# Generated by iptables-save v1.3.6 on Sun Dec 7 01:31:00 2008
*filter
:INPUT ACCEPT [9516:685061]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6712:445334]
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sun Dec 7 01:31:00 2008

I created a script and put it in the /etc/network/if-pre-up.d/iptables

My script is as such

#!/bin/sh

# Load iptables rules before interfaces are brought online
# This ensures that we are always protected by the firewall
#
# Note: if bad rules are inadvertently (or purposely) saved it could block
# access to the server except via the serial tty interface.
#

RESTORE=/sbin/iptables-restore
STAT=/usr/bin/stat
IPSTATE=/root/iptables-save.out

test -x $RESTORE || exit 0
test -x $STAT || exit 0

# Check permissions and ownership (rw------- for root)
if test `$STAT --format="%a" $IPSTATE` -ne "600"; then
echo "Permissions for $IPSTATE must be 600 (rw-------)"
exit 0
fi

# Since only the owner can read/write to the file, we can trust that it is
# secure. We need not worry about group permissions since they should be
# zeroed per our previous check; but we must make sure root owns it.
if test `$STAT --format="%u" $IPSTATE` -ne "0"; then
echo "The superuser must have ownership for $IPSTATE (uid 0)"
exit 0
fi


When I reboot I can ssh into the box from another location fine. When do iptables --list all I get is

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

My rules are not there but yet I can ssh into this box, I am confused?

Thanks again,

Keith

repo 12-07-2008 02:54 AM

Hi,
why don't you put your firewall script in /etc/rc.local?


Quote:

My rules are not there but yet I can ssh into this box, I am confused?
You can ssh to the box, because there is no firewall at all, so ssh is open.

keyboard1973 12-08-2008 04:33 AM

iptables survive reboot
 
Quote:

Originally Posted by repo (Post 3366923)
Hi,
why don't you put your firewall script in /etc/rc.local?




You can ssh to the box, because there is no firewall at all, so ssh is open.

Hello,

I have my rules saved at /root/iptables.rules.2

echo "#!/bin/sh" > /etc/rc3.d/iptables
echo "iptables-restore < /root/iptables.rules.2" >> /etc/rc3.d/iptables
chmod +x /etc/network/if-up.d/iptables


These were the instructions I was trying to follow to survive the reboot. I changed from /etc/network/if-up.d/iptables to /etc/rc3.d/iptables either way it does not work after reboot the rules are not loaded when iptables --list. Any suggestions would be appreciated.

Thanks again

Keith

repo 12-08-2008 06:31 AM

Hi,

Try to look for errormessages in /var/log/messages and dmesg
Perhaps the rules are loaded before the network is connected.
This could make the rules not to load.

keyboard1973 12-08-2008 08:14 AM

iptables script
 
Hello,

I over looked a very important fact which is I did not have a script to use for iptables so this is what I have now.

#!/bin/sh

# Load iptables rules before interfaces are brought online
# This ensures that we are always protected by the firewall
#
# Note: if bad rules are inadvertently (or purposely) saved it could block
# access to the server except via the serial tty interface.
#

RESTORE=/sbin/iptables-restore
STAT=/usr/bin/stat
IPSTATE=/etc/iptables.rules

test -x $RESTORE || exit 0
test -x $STAT || exit 0

# Check permissions and ownership (rw------- for root)
if test `$STAT --format="%a" $IPSTATE` -ne "600"; then
echo "Permissions for $IPSTATE must be 600 (rw-------)"
exit 0
fi

# Since only the owner can read/write to the file, we can trust that it is
# secure. We need not worry about group permissions since they should be
# zeroed per our previous check; but we must make sure root owns it.
if test `$STAT --format="%u" $IPSTATE` -ne "0"; then
echo "The superuser must have ownership for $IPSTATE (uid 0)"
exit 0
fi
# Now we are ready to restore the tables
$RESTORE < $IPSTATE


This script I placed in /etc/network/if-pre-up.d

My iptables.rules is in /etc/

Rules follow as such

# Generated by iptables-save v1.3.6 on Mon Dec 8 04:43:03 2008
*filter
:INPUT ACCEPT [2256:256923]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1063:171796]
-A INPUT -s 192.168.2.101 -d 24.24.5.73 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 172.34.5.8 -j DROP
-A INPUT -s 67.215.66.132 -d 192.168.2.103 -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 20:21 -j ACCEPT
-A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 127.0.0.1 -d 192.168.2.103 -j ACCEPT
-A INPUT -d 192.168.2.103 -p icmp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT

The script is chmod +x chown root.root

iptables.rules is owned by root also.

I know its something with the script or where im placing it, I can't figure it out.

Thanks again,

Keith

repo 12-08-2008 08:25 AM

Hi,

When you execute the script, does it work at that moment?

If yes, put a line like
/path-to-script/script
in /etc/rc.local

keyboard1973 12-08-2008 08:31 AM

Quote:

Originally Posted by repo (Post 3368076)
Hi,

When you execute the script, does it work at that moment?

If yes, put a line like
/path-to-script/script
in /etc/rc.local

Hello,

This is what I am getting when I try to execute the script.

./firewall: line 28: syntax error: unexpected end of file

1
2 #!/bin/sh
3
4 ruleset_dir=/etc
5 case â<9c>$1â³ in
6 start)
7 echo -n â<9c>Loading iptables active ruleset: â<9d>
8 /sbin/iptables-restore < $ruleset_dir/iptables.rules
9 echo â<9c>done.â<9d>
10 ;;
11 stop)
12 echo -n â<9c>Loading iptables inactive ruleset: â<9d>
13 iptables -F INPUT
14 iptables -F OUTPUT
15 iptables -F FORWARD
16 iptables -P INPUT ACCEPT
17 iptables -P OUTPUT ACCEPT
18 iptables -P FORWARD DROP
19 echo â<9c>done.â<9d>
20 ;;
21 force-reload|restart)
22 $0 stop
23 sleep 1
24 $0 start
25 ;;
26 save)
27 echo -n â<9c>Saving iptables [...]


Thanks again,

Keith

repo 12-08-2008 08:45 AM

Quote:

# Written by Robert Penz <robert.penz@outertech.com>
# This script is under GPL 2 or above
#
# Ideas and parts from
# Christophe Grenier <grenier@cgsecurity.org>
# Olivier Boudeville <olivier.boudeville@online.fr>
#

# To debug this kind of firewall script, one may use :
# sh -x /path/to/this/file


# Useful with 'iptables --list' or 'iptables -L -n |more' to check
# whether rules are up-to-date :
rules_version=1


# full path of the programs we need - changed them to your needs
iptables=/sbin/iptables
modprobe=/sbin/modprobe
echo=/bin/echo

# Load appropriate modules.
$modprobe ip_tables

# we load that modules as we want to do statefull firewalling
$modprobe ip_conntrack
$modprobe ip_conntrack_ftp


# These lines are here in case rules are already in place and the script is ever rerun on the fly.
# We want to remove all rules and pre-exisiting user defined chains and zero the counters
# before we implement new rules.
$iptables -F
$iptables -X
$iptables -Z

# Set up a default DROP policy for the built-in chains.
# If we modify and re-run the script mid-session then (because we have a default DROP
# policy), what happens is that there is a small time period when packets are denied until
# the new rules are back in place. There is no period, however small, when packets we
# don't want are allowed.
$iptables -P INPUT DROP
$iptables -P FORWARD DROP
$iptables -P OUTPUT DROP

## ============================================================
## Kernel flags
# To dynamically change kernel parameters and variables on the fly you need
# CONFIG_SYSCTL defined in your kernel. I would advise the following:

# Enable response to ping in the kernel but we'll only answer if
# the rule at the bottom of the file let us.
$echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all

# Disable response to broadcasts.
# You don't want yourself becoming a Smurf amplifier.
$echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Don't accept source routed packets. Attackers can use source routing to generate
# traffic pretending to be from inside your network, but which is routed back along
# the path from which it came, namely outside, so attackers can compromise your
# network. Source routing is rarely used for legitimate purposes.
$echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

# Disable ICMP redirect acceptance. ICMP redirects can be used to alter your routing
# tables, possibly to a bad end.
$echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

# Enable bad error message protection.
$echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

# Turn on reverse path filtering. This helps make sure that packets use
# legitimate source addresses, by automatically rejecting incoming packets
# if the routing table entry for their source address doesn't match the network
# interface they're arriving on. This has security advantages because it prevents
# so-called IP spoofing, however it can pose problems if you use asymmetric routing
# (packets from you to a host take a different path than packets from that host to you)
# or if you operate a non-routing host which has several IP addresses on different
# interfaces. (Note - If you turn on IP forwarding, you will also get this).
for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
$echo "1" > ${interface}
done

# Log spoofed packets, source routed packets, redirect packets.
$echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

# Make sure that IP forwarding is turned off. We only want this for a multi-homed host.
$echo "0" > /proc/sys/net/ipv4/ip_forward



## ============================================================
# RULES

## First rule is to let packetes through which belong to establisted or related connection
# and we let all traffic out as we trust ourself.
$iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


# ---------------- INPUT ---------------------


## Log some invalid connections :
$iptables -A INPUT -m state --state INVALID -m limit --limit 2/ -j LOG --log-prefix "[#$rules_version : invalid input : ]"
$iptables -A INPUT -m state --state INVALID -j DROP

## Avoid stealth TCP port scans if SYN is not set properly :
$iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcpflags ! ALL SYN -j DROP


## FRAGMENTS
# I have to say that fragments scare me more than anything.
# Sending lots of non-first fragments was what allowed Jolt2 to effectively "drown"
# Firewall-1. Fragments can be overlapped, and the subsequent interpretation of such
# fragments is very OS-dependent.
# I am not going to trust any fragments.
# Log fragments just to see if we get any, and deny them too.
$iptables -A INPUT -f -j LOG --log-prefix "[#$rules_version : iptables fragments ] : "
$iptables -A INPUT -f -j DROP


## auth/ident
#if we drop these pakets we may need to wait for the timeouts
# e.g. on ftp servers
$iptables -A INPUT -p tcp --dport 113 -m state --state NEW -j REJECT --reject-with tcp-reset

## http stuff
#$iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

## ftp
#$iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT

## ssh
# This rules allow to prevent brute-force SSH attacks by limiting the
# frequency of attempts :
# Logs too frequent attempts tagged with 'SSH' and drops them :
$iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j LOG --log-prefix "[#$rules_version : SSH brute-force ] : "
$iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

# Tags too frequent SSH attempts with the name 'SSH' :
$iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH

# Accepts nevertheless normal SSH logins :
$iptables -A INPUT -p tcp --dport 22 -j ACCEPT


## mail stuff
#$iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 143 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 993 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p tcp --dport 995 -m state --state NEW -j ACCEPT

## DNS server
# Allow UDP&TCP packets to the DNS server from clients. (only needed
# if this computer is a DNS server)
#$iptables -A INPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
#$iptables -A INPUT -p udp --dport 53 -m state --state NEW -j ACCEPT

## LOOPBACK
# Allow unlimited traffic on the loopback interface.
# e.g. needed for KDE, Gnome
$iptables -A INPUT -i lo -j ACCEPT
$iptables -A OUTPUT -o lo -j ACCEPT

# ---------------- ICMP ---------------------

# all can ping me - remove that line if no one should be able to ping you
$iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT

# ---------------- LOGGING -------------------

# log every thing else, up to 5 packets per min
#$iptables -A INPUT -m limit --limit 5/minute -j LOG

Did you use the above script?
Seems to me this is the firewall script.

fordeck 12-09-2008 07:09 PM

In your original post you had a script that began with the following lines:

# Written by Rober Penz <robert.penz@outertech.com>
# This script is under GPL 2 or above

Anyway I took that script and modified a couple of syntax errors in the INPUT section. The changes are noted below:

Code:

$iptables -A INPUT -m state --state INVALID -m limit --limit 2/sec -j LOG --log-prefix "[#$rules_version : invalid input : ]"
The --limit needed 'sec' added to it

and

Code:

$iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcp-flags ! ALL SYN -j DROP
The '--tcp-flags' did not have the hyphen in it. Then add the following to the top of the script:

Code:

#!/bin/bash
and save as iptables.sh

Anyway after making those changes I booted Knoppix 5.3.1 which is as close as I can get to your environment. If I then execute 'iptables.sh' then we have the firewall rules that you had originally been working with which only allows ssh or port 22 inbound. Now the way Knoppix 5.3.1 deals with your firewall rules with respect to being able to have them survive a reboot is it expects the following files to be in /var/lib/iptables:

active
inactive

because this directory and files do not exist you need to create them. Here is how I did it, first create the directory

Code:

mkdir /var/lib/iptables
Then create the active file by running the following command:

Code:

/etc/init.d/iptables save active
chmod 600 /var/lib/iptables/active

This saves the 'active' file to /var/lib/iptables directory

Note:
The above command would need to run after the rules are in affect by having executed your script 'iptables.sh'

Then to create the 'inactive' file you would run the following commands:

Code:

/etc/init.d/iptables clear
What this does is clear all the rules that were in affect by having run 'iptables.sh'. So basically your firewall at this point is accepting everything. Then to create the 'inactive' file:

Code:

/etc/init.d/iptables save inactive
chmod 600 /var/lib/iptables/inactive

This saves the 'inactive' file to /var/lib/iptables directory

Now if you issue the following commad:

Code:

/etc/init.d/iptables stop
your inactive firewall rules will be in affect or in other words the same as if you had no firewall at all. To test this you could run the following command:

Code:

iptables -L
Chain INPUT (policy ACCEPT)
target    prot opt source              destination       

Chain FORWARD (policy ACCEPT)
target    prot opt source              destination       

Chain OUTPUT (policy ACCEPT)
target    prot opt source              destination

To reactivate your rules just run the following command:

Code:

/etc/init.d/iptables start
now your rules are active again. To test this you could run the following command:

Code:

iptables -L
Chain INPUT (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  anywhere            anywhere            state RELATED,ESTABLISHED
LOG        all  --  anywhere            anywhere            state INVALID limit: avg 2/sec burst 5 LOG level warning prefix `[#1 : invalid input : ]'
DROP      all  --  anywhere            anywhere            state INVALID
DROP      tcp  --  anywhere            anywhere            state NEW,RELATED tcp flags:!FIN,SYN,RST,PSH,ACK,URG/SYN
LOG        all  -f  anywhere            anywhere            LOG level warning prefix `[#1 : iptables fragments ] : '
DROP      all  -f  anywhere            anywhere           
REJECT    tcp  --  anywhere            anywhere            tcp dpt:auth state NEW reject-with tcp-reset
LOG        tcp  --  anywhere            anywhere            tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source LOG level warning prefix `[#1 : SSH brute-force ] : '
DROP      tcp  --  anywhere            anywhere            tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source
          tcp  --  anywhere            anywhere            tcp dpt:ssh recent: SET name: SSH side: source
ACCEPT    tcp  --  anywhere            anywhere            tcp dpt:ssh
ACCEPT    all  --  anywhere            anywhere           
ACCEPT    icmp --  anywhere            anywhere            icmp echo-request

Chain FORWARD (policy DROP)
target    prot opt source              destination       

Chain OUTPUT (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  anywhere            anywhere            state NEW,RELATED,ESTABLISHED
ACCEPT    all  --  anywhere            anywhere

At this point assuming that the Knoppix 5.3.1 environment is similar to yours you should be able to reboot and the rules will be in affect. I hope this helps, again the closest I could come to your Debian environment was to use Knoppix.

Let me know if this worked

Regards,

Fordeck

keyboard1973 12-15-2008 10:48 PM

Quote:

Originally Posted by fordeck (Post 3369818)
In your original post you had a script that began with the following lines:

# Written by Rober Penz <robert.penz@outertech.com>
# This script is under GPL 2 or above

Anyway I took that script and modified a couple of syntax errors in the INPUT section. The changes are noted below:

Code:

$iptables -A INPUT -m state --state INVALID -m limit --limit 2/sec -j LOG --log-prefix "[#$rules_version : invalid input : ]"
The --limit needed 'sec' added to it

and

Code:

$iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcp-flags ! ALL SYN -j DROP
The '--tcp-flags' did not have the hyphen in it. Then add the following to the top of the script:

Code:

#!/bin/bash
and save as iptables.sh

Anyway after making those changes I booted Knoppix 5.3.1 which is as close as I can get to your environment. If I then execute 'iptables.sh' then we have the firewall rules that you had originally been working with which only allows ssh or port 22 inbound. Now the way Knoppix 5.3.1 deals with your firewall rules with respect to being able to have them survive a reboot is it expects the following files to be in /var/lib/iptables:

active
inactive

because this directory and files do not exist you need to create them. Here is how I did it, first create the directory

Code:

mkdir /var/lib/iptables
Then create the active file by running the following command:

Code:

/etc/init.d/iptables save active
chmod 600 /var/lib/iptables/active

This saves the 'active' file to /var/lib/iptables directory

Note:
The above command would need to run after the rules are in affect by having executed your script 'iptables.sh'

Then to create the 'inactive' file you would run the following commands:

Code:

/etc/init.d/iptables clear
What this does is clear all the rules that were in affect by having run 'iptables.sh'. So basically your firewall at this point is accepting everything. Then to create the 'inactive' file:

Code:

/etc/init.d/iptables save inactive
chmod 600 /var/lib/iptables/inactive

This saves the 'inactive' file to /var/lib/iptables directory

Now if you issue the following commad:

Code:

/etc/init.d/iptables stop
your inactive firewall rules will be in affect or in other words the same as if you had no firewall at all. To test this you could run the following command:

Code:

iptables -L
Chain INPUT (policy ACCEPT)
target    prot opt source              destination       

Chain FORWARD (policy ACCEPT)
target    prot opt source              destination       

Chain OUTPUT (policy ACCEPT)
target    prot opt source              destination

To reactivate your rules just run the following command:

Code:

/etc/init.d/iptables start
now your rules are active again. To test this you could run the following command:

Code:

iptables -L
Chain INPUT (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  anywhere            anywhere            state RELATED,ESTABLISHED
LOG        all  --  anywhere            anywhere            state INVALID limit: avg 2/sec burst 5 LOG level warning prefix `[#1 : invalid input : ]'
DROP      all  --  anywhere            anywhere            state INVALID
DROP      tcp  --  anywhere            anywhere            state NEW,RELATED tcp flags:!FIN,SYN,RST,PSH,ACK,URG/SYN
LOG        all  -f  anywhere            anywhere            LOG level warning prefix `[#1 : iptables fragments ] : '
DROP      all  -f  anywhere            anywhere           
REJECT    tcp  --  anywhere            anywhere            tcp dpt:auth state NEW reject-with tcp-reset
LOG        tcp  --  anywhere            anywhere            tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source LOG level warning prefix `[#1 : SSH brute-force ] : '
DROP      tcp  --  anywhere            anywhere            tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source
          tcp  --  anywhere            anywhere            tcp dpt:ssh recent: SET name: SSH side: source
ACCEPT    tcp  --  anywhere            anywhere            tcp dpt:ssh
ACCEPT    all  --  anywhere            anywhere           
ACCEPT    icmp --  anywhere            anywhere            icmp echo-request

Chain FORWARD (policy DROP)
target    prot opt source              destination       

Chain OUTPUT (policy DROP)
target    prot opt source              destination       
ACCEPT    all  --  anywhere            anywhere            state NEW,RELATED,ESTABLISHED
ACCEPT    all  --  anywhere            anywhere

At this point assuming that the Knoppix 5.3.1 environment is similar to yours you should be able to reboot and the rules will be in affect. I hope this helps, again the closest I could come to your Debian environment was to use Knoppix.

Let me know if this worked

Regards,

Fordeck

Hello,

Everything has worked I thank everyone again for their help!!

Keith

farslayer 12-16-2008 07:06 AM

Quote:

Originally Posted by keyboard1973 (Post 3367915)
Hello,

I have my rules saved at /root/iptables.rules.2

echo "#!/bin/sh" > /etc/rc3.d/iptables
echo "iptables-restore < /root/iptables.rules.2" >> /etc/rc3.d/iptables
chmod +x /etc/network/if-up.d/iptables


These were the instructions I was trying to follow to survive the reboot. I changed from /etc/network/if-up.d/iptables to /etc/rc3.d/iptables either way it does not work after reboot the rules are not loaded when iptables --list. Any suggestions would be appreciated.

Thanks again

Keith

Just a pointer on this one..

Debian starts up in runlevel 2 - ALWAYS.. so adding a startup script in runlevel 3 would not do you much good. It would need to be added in rc2.d.

Either way, Glad you got it all worked out. just wanted you to be aware of this discrepancy.

keyboard1973 12-17-2008 12:07 AM

Quote:

Originally Posted by farslayer (Post 3377267)
Just a pointer on this one..

Debian starts up in runlevel 2 - ALWAYS.. so adding a startup script in runlevel 3 would not do you much good. It would need to be added in rc2.d.

Either way, Glad you got it all worked out. just wanted you to be aware of this discrepancy.

Thanks for the pointer I appreciate it.


All times are GMT -5. The time now is 08:20 AM.