* Help with iptables script
@ 2004-12-15 0:22 Jason Williams
2004-12-15 1:17 ` John A. Sullivan III
0 siblings, 1 reply; 5+ messages in thread
From: Jason Williams @ 2004-12-15 0:22 UTC (permalink / raw)
To: netfilter
Evening everyone.
I will be quick to the point. Need some help with IPTables. New to
IPTables, but not to firewalls. Right now, just getting my head wrapped
around the differences and syntax IPTables compared to other firewalls i've
used.
Anyway, working on just a very simple firewal script (for first time
learning) to do the following:
1) Block all incoming requests to firewall host and private LAN
2) Do NAT for my private LAN
3) Allow private LAN outbound on all ports.
So far, this is what i've come up with. Not sure if it is correct, but
thought i'd ask some of the experts on this list.
#External interface and IP info
INET_IP="1.2.3.4"
INET_IFACE="eth0"
#Private LAN macros
LAN_IP="192.168.1.0/24"
LAN_IFACE="eth2"
# IPTables Configuration.
IPTABLES="/usr/sbin/iptables"
# Set default policies for the INPUT, FORWARD and OUTPUT chains.
#
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
#
# Take care of bad TCP packets that we don't want.
#
$IPTABLES -N bad_tcp_packets
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
# Do some checks for obviously spoofed IP's
$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 192.168.0.0/16 -j DROP
$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 10.0.0.0/8 -j DROP
$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 172.16.0.0/12 -j DROP
#Simple NAT setup
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
# Accept the packets we actually want to forward
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "
# INPUT chain
$IPTABLES -A INPUT -p tcp -j bad_tcp_packets
# OUTPUT chain
$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
#
# Special OUTPUT rules to decide which IP's to allow.
#
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
I build this from reading some how-to's, sample scripts and now started
reading a book called "Red Hat Linux Firewalls" by Bill McCarty.
I appreciate any help.
Cheers,
Jason
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with iptables script
2004-12-15 0:22 Help with iptables script Jason Williams
@ 2004-12-15 1:17 ` John A. Sullivan III
2004-12-15 17:16 ` Jason Williams
0 siblings, 1 reply; 5+ messages in thread
From: John A. Sullivan III @ 2004-12-15 1:17 UTC (permalink / raw)
To: Jason Williams; +Cc: Netfilter users list
Welcome to netfilter/iptables - it's a fabulous product. You do indeed
seem to know what you are doing. I'll make some comments in your text.
On Tue, 2004-12-14 at 19:22, Jason Williams wrote:
> Evening everyone.
>
> I will be quick to the point. Need some help with IPTables. New to
> IPTables, but not to firewalls. Right now, just getting my head wrapped
> around the differences and syntax IPTables compared to other firewalls i've
> used.
>
> Anyway, working on just a very simple firewal script (for first time
> learning) to do the following:
>
> 1) Block all incoming requests to firewall host and private LAN
>
> 2) Do NAT for my private LAN
>
> 3) Allow private LAN outbound on all ports.
>
> So far, this is what i've come up with. Not sure if it is correct, but
> thought i'd ask some of the experts on this list.
>
> #External interface and IP info
> INET_IP="1.2.3.4"
> INET_IFACE="eth0"
>
> #Private LAN macros
> LAN_IP="192.168.1.0/24"
> LAN_IFACE="eth2"
>
> # IPTables Configuration.
>
> IPTABLES="/usr/sbin/iptables"
>
> # Set default policies for the INPUT, FORWARD and OUTPUT chains.
> #
>
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT DROP
> $IPTABLES -P FORWARD DROP
>
Very good start :-)
>
> #
> # Take care of bad TCP packets that we don't want.
> #
>
> $IPTABLES -N bad_tcp_packets
> $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG
> --log-prefix "New not syn:"
> $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
I would be interested to see some list discussion here. When I use
connection tracking, I generally do not drop NEW not SYN packets. NEW
packets initiated from untrusted sources are generally dropped anyway
whether they have the SYN bit flipped or not. On the other hand, you
may find legitimate NEW packets that are not SYN, e.g., if a session has
been interrupted (e.g., firewall reset), the sessions may still be alive
on the end points. Dropping the non-SYN packets will force a time out
or application hang and a call to the help desk. Letting those packets
through will renew the connection tracking state and keep the
application alive.
>
> # Do some checks for obviously spoofed IP's
>
> $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 192.168.0.0/16 -j DROP
> $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 10.0.0.0/8 -j DROP
> $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 172.16.0.0/12 -j DROP
We usually take anti-spoofing one step further in the ISCS network
security project (http://iscs.sourceforge.net). To be good Internet
citizens, we also want to make sure that only valid internal addresses
are sending traffic out. If you have and will alway have only one
protected network, one can do this with a single inverse rule, e.g.,
$IPTABLES -A bad_tcp_packets -i $LAN_IFACE -s ! $LAN_IP - j DROP
If you have multiple protected networks, you can do this with the RETURN
target and a separate chain, e.g.,
$IPTABLES -N SpoofChain
$IPTABLES -A bad_tcp_packets -i $LAN_IFACE -j SpoofChain
$IPTABLES -A SpoofChain -s $LAN_IP1 -j RETURN
$IPTABLES -A SpoofChain -s $LAN_IP2 -j RETURN
$IPTABLES -A SpoofChain -j DROP
>
> #Simple NAT setup
>
> $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
>
> # Accept the packets we actually want to forward
>
> $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG
> --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
>
> # INPUT chain
>
> $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
Since you're not accepting any packets on the INPUT chain, you don't
need to filter bad packets unless you want to log them. Are you sure
you don't want to accept RELATED,ESTABLISHED traffic on your INPUT
chain?
>
>
> # OUTPUT chain
>
> $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
Are you expecting bad packets on your OUTPUT chain?
>
> #
> # Special OUTPUT rules to decide which IP's to allow.
> #
>
> $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
> $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
I believe you can drop the -p ALL. What about traffic on lo?
>
> I build this from reading some how-to's, sample scripts and now started
> reading a book called "Red Hat Linux Firewalls" by Bill McCarty.
>
> I appreciate any help.
>
> Cheers,
> Jason
We do all of this and more automatically in the ISCS project
(http://iscs.sourceforge.net) although it is not yet production code.
Good luck and welcome again - John
--
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with iptables script
2004-12-15 1:17 ` John A. Sullivan III
@ 2004-12-15 17:16 ` Jason Williams
2004-12-15 18:21 ` Rob Sterenborg
2004-12-15 18:27 ` John A. Sullivan III
0 siblings, 2 replies; 5+ messages in thread
From: Jason Williams @ 2004-12-15 17:16 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netfilter
>Welcome to netfilter/iptables - it's a fabulous product. You do indeed
>seem to know what you are doing. I'll make some comments in your text.
Thanks for the welcome. I am quite intrigued with iptables. Definitely
different and a new thing to learn.
> > $IPTABLES -P INPUT DROP
> > $IPTABLES -P OUTPUT DROP
> > $IPTABLES -P FORWARD DROP
> >
>Very good start :-)
Alright...good to know. :)
> > $IPTABLES -N bad_tcp_packets
> > $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG
> > --log-prefix "New not syn:"
> > $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
>I would be interested to see some list discussion here. When I use
>connection tracking, I generally do not drop NEW not SYN packets. NEW
>packets initiated from untrusted sources are generally dropped anyway
>whether they have the SYN bit flipped or not. On the other hand, you
>may find legitimate NEW packets that are not SYN, e.g., if a session has
>been interrupted (e.g., firewall reset), the sessions may still be alive
>on the end points. Dropping the non-SYN packets will force a time out
>or application hang and a call to the help desk. Letting those packets
>through will renew the connection tracking state and keep the
>application alive.
I was thinking about this after you mentioned this. I may go back and look
further into the details of this, see if I can't find something better to
do. I am thinking, that this could be a good and bad thing, depending upon
the connection(s). I may rethink this set of rules.
> > $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 192.168.0.0/16 -j DROP
> > $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 10.0.0.0/8 -j DROP
> > $IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 172.16.0.0/12 -j DROP
>We usually take anti-spoofing one step further in the ISCS network
>security project (http://iscs.sourceforge.net). To be good Internet
>citizens, we also want to make sure that only valid internal addresses
>are sending traffic out. If you have and will alway have only one
>protected network, one can do this with a single inverse rule, e.g.,
>$IPTABLES -A bad_tcp_packets -i $LAN_IFACE -s ! $LAN_IP - j DROP
>
>If you have multiple protected networks, you can do this with the RETURN
>target and a separate chain, e.g.,
>$IPTABLES -N SpoofChain
>$IPTABLES -A bad_tcp_packets -i $LAN_IFACE -j SpoofChain
>$IPTABLES -A SpoofChain -s $LAN_IP1 -j RETURN
>$IPTABLES -A SpoofChain -s $LAN_IP2 -j RETURN
>$IPTABLES -A SpoofChain -j DROP
Thanks for the link and tips on rules. anything i can do to be a better
internet citizen, I am all for. :)
> > #Simple NAT setup
> >
> > $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
This should be correct for my NAT setup on my private LAN correct? Think
so, just want to double check.
> >
> > # Accept the packets we actually want to forward
> >
> > $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
> > $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> > $IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG
> > --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
> >
> > # INPUT chain
> >
> > $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
>Since you're not accepting any packets on the INPUT chain, you don't
>need to filter bad packets unless you want to log them. Are you sure
>you don't want to accept RELATED,ESTABLISHED traffic on your INPUT
>chain?
Hmm. Good point. Just to make sure I follow, even though I am not accepting
any packets on the input chain, traffic from the private LAN still should
traverse through the firewall and back correct? Assuming that is correct,
then the problems i would have then would be the loopback interface (stuff
like X windows, subsystems) and also when the host itself tries to call the
interent for patches, packages etc. Is that a correct assumption?
> >
> >
> > # OUTPUT chain
> >
> > $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
>Are you expecting bad packets on your OUTPUT chain?
> >
> > #
> > # Special OUTPUT rules to decide which IP's to allow.
> > #
> >
> > $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
> > $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
>I believe you can drop the -p ALL. What about traffic on lo?
Yep. Forgot the Loopback interface.
I will be pouring over my book and how-to's today.
just a quick question. Is there a website, other than the netfiler website
that has some sample table scripts? I'd like to see just a few examples of
simple iptable scripts so I can further wrap my head around this.
My intentions with this first script was to put a simple firewall script
that would block my private lan, do NAT and of course, pass out traffic to
and from the private LAN.
i appreciate the feedback. Nice product indeed. i like. :)
Cheers,
Jason
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Help with iptables script
2004-12-15 17:16 ` Jason Williams
@ 2004-12-15 18:21 ` Rob Sterenborg
2004-12-15 18:27 ` John A. Sullivan III
1 sibling, 0 replies; 5+ messages in thread
From: Rob Sterenborg @ 2004-12-15 18:21 UTC (permalink / raw)
To: netfilter
netfilter-bounces@lists.netfilter.org wrote:
...
>>> #Simple NAT setup
>>>
>>> $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source
>>> $INET_IP
>
> This should be correct for my NAT setup on my private LAN correct?
> Think so, just want to double check.
It should do, however you could add the network of your LAN to the rule
so you'll be sure that only IP's from your LAN will be SNAT-ed :
$IPTABLES -t nat -A POSTROUTING -s $LAN_IP -o $INET_IFACE \
-j SNAT --to-source $INET_IP
And further restrict the FORWARD chain (using -s in both chains should
be unnessecary ; look at it as a double guard :o) ):
$IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s $IP_LAN \
-j ACCEPT
(Right now you have "$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT".)
>>> # INPUT chain
>>>
>>> $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
>> Since you're not accepting any packets on the INPUT chain, you don't
>> need to filter bad packets unless you want to log them. Are you sure
>> you don't want to accept RELATED,ESTABLISHED traffic on your INPUT
>> chain?
>
> Hmm. Good point. Just to make sure I follow, even though I am not
> accepting any packets on the input chain, traffic from the private
> LAN still should traverse through the firewall and back correct?
No. LAN traffic routed to the internet (and vv) goes through the FORWARD
chain, not the INPUT or OUTPUT chain.
You'd accept RELATED,ESTABLISHED packets in your INPUT chain if you have
ACCEPT rules in the OUTPUT chain in which case the firewall itself is
able to send traffic : you have to accept the return packets.
> I will be pouring over my book and how-to's today.
> just a quick question. Is there a website, other than the netfiler
> website that has some sample table scripts? I'd like to see just a
> few examples of simple iptable scripts so I can further wrap my head
> around this.
I think you'll like Oskar Andreasson's IPTables Tutorial :
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Gr,
Rob
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with iptables script
2004-12-15 17:16 ` Jason Williams
2004-12-15 18:21 ` Rob Sterenborg
@ 2004-12-15 18:27 ` John A. Sullivan III
1 sibling, 0 replies; 5+ messages in thread
From: John A. Sullivan III @ 2004-12-15 18:27 UTC (permalink / raw)
To: Jason Williams; +Cc: Netfilter users list
On Wed, 2004-12-15 at 12:16, Jason Williams wrote:
> >Welcome to netfilter/iptables - it's a fabulous product. You do indeed
> >seem to know what you are doing. I'll make some comments in your text.
>
> Thanks for the welcome. I am quite intrigued with iptables. Definitely
> different and a new thing to learn.
>
> <snip>
> > > #Simple NAT setup
> > >
> > > $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
>
> This should be correct for my NAT setup on my private LAN correct? Think
> so, just want to double check.
Yes, that looks fine. You could further constrain it by -s $LAN_IP but
I don't think it's necessary.
>
> > >
> > > # Accept the packets we actually want to forward
> > >
> > > $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
> > > $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> > > $IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG
> > > --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
> > >
> > > # INPUT chain
> > >
> > > $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
> >Since you're not accepting any packets on the INPUT chain, you don't
> >need to filter bad packets unless you want to log them. Are you sure
> >you don't want to accept RELATED,ESTABLISHED traffic on your INPUT
> >chain?
>
> Hmm. Good point. Just to make sure I follow, even though I am not accepting
> any packets on the input chain, traffic from the private LAN still should
> traverse through the firewall and back correct? Assuming that is correct,
> then the problems i would have then would be the loopback interface (stuff
> like X windows, subsystems) and also when the host itself tries to call the
> interent for patches, packages etc. Is that a correct assumption?
Yes, exactly.
>
> > >
> > >
> > > # OUTPUT chain
> > >
> > > $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
> >Are you expecting bad packets on your OUTPUT chain?
> > >
> > > #
> > > # Special OUTPUT rules to decide which IP's to allow.
> > > #
> > >
> > > $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
> > > $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
> >I believe you can drop the -p ALL. What about traffic on lo?
>
> Yep. Forgot the Loopback interface.
>
> I will be pouring over my book and how-to's today.
> just a quick question. Is there a website, other than the netfiler website
> that has some sample table scripts? I'd like to see just a few examples of
> simple iptable scripts so I can further wrap my head around this.
> My intentions with this first script was to put a simple firewall script
> that would block my private lan, do NAT and of course, pass out traffic to
> and from the private LAN.
<snip>
I've always found Oskar Andreasson's tutorial very helpful and it
includes a number of scripts
(http://iptables-tutorial.frozentux.net/iptables-tutorial.html). I think
there are some sample scripts on the Shorewall site
(http://www.shorewall.net) and there are a few slide shows on
http://iscs.sourceforge.net
Good luck - John
--
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-12-15 18:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-15 0:22 Help with iptables script Jason Williams
2004-12-15 1:17 ` John A. Sullivan III
2004-12-15 17:16 ` Jason Williams
2004-12-15 18:21 ` Rob Sterenborg
2004-12-15 18:27 ` John A. Sullivan III
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.