* 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.