LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-06-2008, 02:46 AM   #1
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Rep: Reputation: 15
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
 
Old 12-06-2008, 10:50 AM   #2
fordeck
Member
 
Registered: Oct 2006
Location: Utah
Posts: 520

Rep: Reputation: 61
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
 
Old 12-07-2008, 03:10 AM   #3
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by fordeck View Post
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
 
Old 12-07-2008, 03:54 AM   #4
repo
LQ 5k Club
 
Registered: May 2001
Location: Belgium
Distribution: Arch
Posts: 8,527

Rep: Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898
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.
 
Old 12-08-2008, 05:33 AM   #5
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
iptables survive reboot

Quote:
Originally Posted by repo View Post
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
 
Old 12-08-2008, 07:31 AM   #6
repo
LQ 5k Club
 
Registered: May 2001
Location: Belgium
Distribution: Arch
Posts: 8,527

Rep: Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898
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.
 
Old 12-08-2008, 09:14 AM   #7
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
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
 
Old 12-08-2008, 09:25 AM   #8
repo
LQ 5k Club
 
Registered: May 2001
Location: Belgium
Distribution: Arch
Posts: 8,527

Rep: Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898
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
 
Old 12-08-2008, 09:31 AM   #9
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by repo View Post
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
 
Old 12-08-2008, 09:45 AM   #10
repo
LQ 5k Club
 
Registered: May 2001
Location: Belgium
Distribution: Arch
Posts: 8,527

Rep: Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898Reputation: 898
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.
 
Old 12-09-2008, 08:09 PM   #11
fordeck
Member
 
Registered: Oct 2006
Location: Utah
Posts: 520

Rep: Reputation: 61
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

Last edited by fordeck; 12-09-2008 at 08:12 PM.
 
Old 12-15-2008, 11:48 PM   #12
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by fordeck View Post
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
 
Old 12-16-2008, 08:06 AM   #13
farslayer
LQ Guru
 
Registered: Oct 2005
Location: Willoughby, Ohio
Distribution: linuxdebian
Posts: 7,232
Blog Entries: 5

Rep: Reputation: 190Reputation: 190
Quote:
Originally Posted by keyboard1973 View Post
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.
 
Old 12-17-2008, 01:07 AM   #14
keyboard1973
Member
 
Registered: Jun 2008
Posts: 52

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by farslayer View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Debian iptables kingcomein Debian 4 10-31-2005 11:17 PM
iptables on Debian ujotne Linux - Security 4 09-16-2005 08:36 PM
Debian - IPTABLES czezz Linux - Security 6 06-20-2005 06:07 AM
Start DHCPd and configure iptables on boot (Debian Sarge) Qis Linux - Networking 6 03-02-2005 06:34 AM
debian and iptables? banana2 Linux - Security 5 01-12-2003 10:35 AM


All times are GMT -5. The time now is 10:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration