iptables scripts

iptables scripts

[Gilles Yue]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

Dear all,

 

What is the difference between saving iptables rules by typing
/sbin/service save and putting it in a script which executes when the pc
is restarted?

 

Secondly, if you were to put all your firewall rules in a script, where
(on which path) would you put it to have it executed when the machine
reboots.

 

Thanks & Regards

gy

 

 


[-- Attachment #2: Type: text/html, Size: 2462 bytes --]

Re: iptables scripts

[Chris Brenton]

On Fri, 2003-10-31 at 06:25, Gilles Yue wrote: 
> 
> What is the difference between saving iptables rules by typing
> /sbin/service save and putting it in a script which executes when the
> pc is restarted?

IMHO this is a personal preference thing. Some people prefer to use the
save/restore scripts. Some people (like myself) prefer to write their
own shell script. Its all a matter of personal preference.

For me, I just find working with a shell script easier. I typically
remotely manage my firewalls. I find it easier to vi a file rather than
work from the command line (you are also less likely to shoot yourself
in the foot by messing up your rules and blocking your remote session.
Been there, done that ;-). I also like being able to add in additional
functionality like variables, do loops, etc. Your mileage may vary.

> Secondly, if you were to put all your firewall rules in a script,
> where (on which path) would you put it to have it executed when the
> machine reboots.

Again this is somewhat personal choice. I create /root/firewall and
place all my firewall related scripts in there. You could put it in
something like /usr/local/sbin, but now you have a longer path to type
(ya I know, I'm *very* lazy ;-) and other unrelated files to contend
with in the same directory. 

HTH,
C

Re: iptables scripts

[Robert P. J. Day]

On 31 Oct 2003, Chris Brenton wrote:

> On Fri, 2003-10-31 at 06:25, Gilles Yue wrote: 
> > 
> > What is the difference between saving iptables rules by typing
> > /sbin/service save and putting it in a script which executes when the
> > pc is restarted?
> 
> IMHO this is a personal preference thing. Some people prefer to use the
> save/restore scripts. Some people (like myself) prefer to write their
> own shell script. Its all a matter of personal preference.
> 
> For me, I just find working with a shell script easier. I typically
> remotely manage my firewalls. I find it easier to vi a file rather than
> work from the command line (you are also less likely to shoot yourself
> in the foot by messing up your rules and blocking your remote session.
> Been there, done that ;-). I also like being able to add in additional
> functionality like variables, do loops, etc. Your mileage may vary.

that's the big bonus -- that you can do some preliminary setup in a
shell script like setting variables for convenience, setting kernel
parameters, loading modules and the like.

for the iptables tutorial i was talking about that i'm giving on monday,
here's the first part of my script, just to show folks what they can do:

--------------------------------------------

#!/bin/sh

# Commands.

IPT="/sbin/iptables"

# Interfaces.

INET_IF="eth0"
LOOPBACK_IF="lo"

# Addresses.

MY_IP="192.168.1.101"

# Special addresses.

LOOPBACK="127.0.0.0/8"
PRIVATE_CLASS_A="10.0.0.0/8"
PRIVATE_CLASS_B="176.16.0.0/12"
PRIVATE_CLASS_C="192.168.0.0/16"
CLASS_D="224.0.0.0/4"
CLASS_E="240.0.0.0/5"
BROADCAST_SRC="0.0.0.0"
BROADCAST_DEST="255.255.255.255"

# Ports.

PRIVPORTS="0:1023"
UNPRIVPORTS="1024:65535"

# Collective addresses.

BAD_SOURCE_ADDRS="$LOOPBACK $CLASS_D $CLASS_E $MY_IP"

ALLOWED_INCOMING_SERVICES="ssh http"
DISALLOWED_OUTGOING_SERVICES="telnet"

#######################################################
# Load necessary modules netfilter modules.
#######################################################

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state

#######################################################
# Set some /proc/sys settings to nail some bad stuff.
#######################################################

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

for f in /proc/sys/net/ipv4/conf/*/accept_source_route ; do
	echo 0 > $f
done

for f in /proc/sys/net/ipv4/conf/*/accept_redirects ; do
	echo 0 > $f
done

for f in /proc/sys/net/ipv4/conf/*/send_redirects ; do
	echo 0 > $f
done

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do
	echo 1 > $f
done

for f in /proc/sys/net/ipv4/conf/*/log_martians ; do
	echo 1 > $f
done

#######################################################
# Set the chain policies.
#######################################################

$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT	# Purists probably hate this.



... etc etc, you get the idea ...

shell scripts are indeed the way to go.

rday

Re: iptables scripts

[Chris Brenton]

On Fri, 2003-10-31 at 07:26, Robert P. J. Day wrote:
>
> for the iptables tutorial i was talking about that i'm giving on monday,
> here's the first part of my script, just to show folks what they can do:

This is *totally* cool. Thank you for sharing this with the list! :)

The only thing I would add would be:
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables --table nat --flush

or what ever you need. This way you can run it from the command line and
clear out all existing rules before you write everything back in.

HTH,
C

Re: iptables scripts

[Robert P. J. Day]

On 31 Oct 2003, Chris Brenton wrote:

> On Fri, 2003-10-31 at 07:26, Robert P. J. Day wrote:
> >
> > for the iptables tutorial i was talking about that i'm giving on monday,
> > here's the first part of my script, just to show folks what they can do:
> 
> This is *totally* cool. Thank you for sharing this with the list! :)
> 
> The only thing I would add would be:
> iptables -F INPUT
> iptables -F OUTPUT
> iptables -F FORWARD
> iptables --table nat --flush
> 
> or what ever you need. This way you can run it from the command line and
> clear out all existing rules before you write everything back in.

ah, grasshopper, i didn't show you the other two scripts i'm going
to demo.  first, there's the lockdown script, to be run if you realize
you've been hacked:
---------------------------------------------------------
#!/bin/sh

# PANIC!  Lock the machine down.

IPT="/sbin/iptables"

# Flush all chains.

$IPT -F			# by default filter
$IPT -t nat -F
$IPT -t mangle -F

# Delete all user-defined chains.

for table in filter nat mangle ; do
	$IPT -t $table -X
done

# Reset all policies to DROP.

for chain in INPUT OUTPUT FORWARD ; do
	$IPT -P $chain DROP
done

echo "System totally locked down."
-----------------------------------------------------------

  and then there's the "clear all" script, which you would run
if you made a total mess of your rules and just want to clear
them out:

----------------------------------------------------------
#!/bin/sh

# PANIC!  We've screwed up our tables.

IPT="/sbin/iptables"

# Flush all chains.

$IPT -F
$IPT -t nat -F
$IPT -t mangle -F

# Delete all user-defined chains.

for table in filter nat mangle ; do
	$IPT -t $table -X
done

# Reset all policies to ACCEPT.

for chain in INPUT OUTPUT FORWARD ; do
	$IPT -P $chain ACCEPT
done

echo "System totally open, you are now fair game."
-------------------------------------------------

  the tutorial will suggest that users can incorporate 
the above in their main script any way they want.

rday

Re: iptables scripts

[Alistair Tonner]

On October 31, 2003 08:22 am, Robert P. J. Day wrote:
> On 31 Oct 2003, Chris Brenton wrote:
> > On Fri, 2003-10-31 at 07:26, Robert P. J. Day wrote:
> > > for the iptables tutorial i was talking about that i'm giving on
> > > monday, here's the first part of my script, just to show folks what
> > > they can do:
> >
> > This is *totally* cool. Thank you for sharing this with the list! :)
> >
> > The only thing I would add would be:
> > iptables -F INPUT
> > iptables -F OUTPUT
> > iptables -F FORWARD
> > iptables --table nat --flush
> >
> > or what ever you need. This way you can run it from the command line and
> > clear out all existing rules before you write everything back in.
>
> ah, grasshopper, i didn't show you the other two scripts i'm going
> to demo.  first, there's the lockdown script, to be run if you realize
> you've been hacked:





	You might NOT want to run this from ssh sessions!!!
              *grin* ... sure to most of us this is obvious....not 
	however to everyone ... 

> ---------------------------------------------------------
> #!/bin/sh
>
> # PANIC!  Lock the machine down.
>
> IPT="/sbin/iptables"
>
> # Flush all chains.
>
> $IPT -F			# by default filter
> $IPT -t nat -F
> $IPT -t mangle -F
>
> # Delete all user-defined chains.
>
> for table in filter nat mangle ; do
> 	$IPT -t $table -X
> done
>
> # Reset all policies to DROP.
>
> for chain in INPUT OUTPUT FORWARD ; do
> 	$IPT -P $chain DROP
> done
>
> echo "System totally locked down."
> -----------------------------------------------------------
>
>   and then there's the "clear all" script, which you would run
> if you made a total mess of your rules and just want to clear
> them out:
>
> ----------------------------------------------------------
> #!/bin/sh
>
> # PANIC!  We've screwed up our tables.
>
> IPT="/sbin/iptables"
>
> # Flush all chains.
>
> $IPT -F
> $IPT -t nat -F
> $IPT -t mangle -F
>
> # Delete all user-defined chains.
>
> for table in filter nat mangle ; do
> 	$IPT -t $table -X
> done
>
> # Reset all policies to ACCEPT.
>
> for chain in INPUT OUTPUT FORWARD ; do
> 	$IPT -P $chain ACCEPT
> done
>
> echo "System totally open, you are now fair game."
> -------------------------------------------------
>
>   the tutorial will suggest that users can incorporate
> the above in their main script any way they want.
>
> rday

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

Re: iptables scripts

[Robert P. J. Day]

On Fri, 31 Oct 2003, Alistair Tonner wrote:

> 	You might NOT want to run this from ssh sessions!!!
>               *grin* ... sure to most of us this is obvious....not 
> 	however to everyone ... 

oh, come on ... i have to leave *something* as a lesson for
the student.

rday

Re: iptables scripts

[Achim Dreyer]

On Fri, 31 Oct 2003, Robert P. J. Day wrote:

[..]
> ah, grasshopper, i didn't show you the other two scripts i'm going
> to demo.  first, there's the lockdown script, to be run if you realize
> you've been hacked:
> ---------------------------------------------------------
> #!/bin/sh
> 
> # PANIC!  Lock the machine down.
> 
> IPT="/sbin/iptables"
> 
> # Flush all chains.
> 
> $IPT -F			# by default filter
> $IPT -t nat -F
> $IPT -t mangle -F
> 
> # Delete all user-defined chains.
> 
> for table in filter nat mangle ; do
> 	$IPT -t $table -X
> done
> 
> # Reset all policies to DROP.
> 
> for chain in INPUT OUTPUT FORWARD ; do
> 	$IPT -P $chain DROP
> done
> 
> echo "System totally locked down."
> -----------------------------------------------------------


I shurely would set the default lockdown policy _before_ flushing the 
tables as there is no matching rule forcing a drop of packets between
the flush and the policy set ->  packets could slip through!



>   and then there's the "clear all" script, which you would run
> if you made a total mess of your rules and just want to clear
> them out:
> 
> ----------------------------------------------------------
> #!/bin/sh
> 
> # PANIC!  We've screwed up our tables.
> 
> IPT="/sbin/iptables"
> 
> # Flush all chains.
> 
> $IPT -F
> $IPT -t nat -F
> $IPT -t mangle -F
> 
> # Delete all user-defined chains.
> 
> for table in filter nat mangle ; do
> 	$IPT -t $table -X
> done
> 
> # Reset all policies to ACCEPT.
> 
> for chain in INPUT OUTPUT FORWARD ; do
> 	$IPT -P $chain ACCEPT
> done
> 
> echo "System totally open, you are now fair game."
> -------------------------------------------------


in this case it doesn't matter as the end result will open all gates ;-)





Regards,
Achim Dreyer
--
A. Dreyer, Senior SysAdmin (UNIX&Network) / Internet Security Consultant