Best Practices for iptables

Best Practices for iptables

[Gabby James]

Hi,

I want to allow everything on eth1 and be selective on eth0.  What is the 
best way of handling unwanted packets?

A) Change the policy of the chain to DROP then allow what I want.  Example:
iptables -P INPUT DROP
iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT


B) or leave the policy of the INPUT chain to ACCEPT but put REJECT rules at 
the end. Example:
iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
iptables -A INPUT -p tcp -m tcp -j REJECT
iptables -A INPUT -p udp -m udp -j REJECT
iptables -A INPUT -p icmp -j DROP

This will give me the same outcome won't it?

Thanks in advance!

_________________________________________________________________
Winterize your home with tips from MSN House & Home. 
http://special.msn.com/home/warmhome.armx

Re: Best Practices for iptables

[Ray Leach]

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

On Fri, 2003-12-05 at 16:01, Gabby James wrote:
> Hi,
> 
> I want to allow everything on eth1 and be selective on eth0.  What is the 
> best way of handling unwanted packets?
> 
> A) Change the policy of the chain to DROP then allow what I want.  Example:
> iptables -P INPUT DROP
> iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
> 
> 
> B) or leave the policy of the INPUT chain to ACCEPT but put REJECT rules at 
> the end. Example:
> iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
> iptables -A INPUT -p tcp -m tcp -j REJECT
> iptables -A INPUT -p udp -m udp -j REJECT
> iptables -A INPUT -p icmp -j DROP
> 
> This will give me the same outcome won't it?
No, none of your rules reference the interface, e.g -i eth0
So your rules allow/reject on all interfaces.

> 
> Thanks in advance!
> 
> _________________________________________________________________
> Winterize your home with tips from MSN House & Home. 
> http://special.msn.com/home/warmhome.armx
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Best Practices for iptables

[Michael H. Warfield]

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

On Fri, Dec 05, 2003 at 04:11:42PM +0200, Ray Leach wrote:
> On Fri, 2003-12-05 at 16:01, Gabby James wrote:
> > Hi,

> > I want to allow everything on eth1 and be selective on eth0.  What is the 
> > best way of handling unwanted packets?

> > A) Change the policy of the chain to DROP then allow what I want.  Example:
> > iptables -P INPUT DROP
> > iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT


> > B) or leave the policy of the INPUT chain to ACCEPT but put REJECT rules at 
> > the end. Example:
> > iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
> > iptables -A INPUT -p tcp -m tcp -j REJECT
> > iptables -A INPUT -p udp -m udp -j REJECT
> > iptables -A INPUT -p icmp -j DROP

> > This will give me the same outcome won't it?
> No, none of your rules reference the interface, e.g -i eth0
> So your rules allow/reject on all interfaces.

	One HUGE difference between A and B is what's not seen in there
at all.  Not all protocols are tcp, udp, or icmp.  There's also things
like AH, ESP, SIT (aka IPv6), and GRE.  All of these things would be
blocked by A and will pass straight through B unempeded.  SIT, especially,
could be problematical since an attacker could simply set up and IPv6 over
IPv4 tunnel that will pass straight through your firewall and route
entire subnets out to the Internet.  With 6to4 (6over4 using the 2002::/16
TLA) they don't even need static IPv6 configurations.  If you let that
pass through, your IPv4 iptables won't even see tcp or udp in that
tunnel, all it will see is IPv4 protocol 41 (SIT/ipv6).  Even if you have
iptables6 loaded, it wont see tcp or udp on IPv6, because it's IPv4
protocol 41 and not seen by the IPv6 iptables at all.  So, either way,
that protocol has to be stopped or you may end up with IPv6 on your network
and never realize it or successfully filter it.

	Always remember...  There's more riding on the next layer up than
just tcp, udp, and icmp.  A lot more.  And what you don't know can come
back to bite you.

> > Thanks in advance!

> > _________________________________________________________________
> > Winterize your home with tips from MSN House & Home. 
> > http://special.msn.com/home/warmhome.armx
> -- 
> --
> Raymond Leach <raymondl@knowledgefactory.co.za>
> Network Support Specialist
> http://www.knowledgefactory.co.za
> "lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
> Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
> --

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: Best Practices for iptables

[Gabby James]

Yep, I did forget to designate my interface.  So, assuming I do that, which 
is the best way of forming rules - example A or B?


>From: Ray Leach <raymondl@knowledgefactory.co.za>
>To: Netfilter Mailing List <netfilter@lists.netfilter.org>
>Subject: Re: Best Practices for iptables
>Date: Fri, 05 Dec 2003 16:11:42 +0200
>
>On Fri, 2003-12-05 at 16:01, Gabby James wrote:
> > Hi,
> >
> > I want to allow everything on eth1 and be selective on eth0.  What is 
>the
> > best way of handling unwanted packets?
> >
> > A) Change the policy of the chain to DROP then allow what I want.  
>Example:
> > iptables -P INPUT DROP
> > iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
> >
> >
> > B) or leave the policy of the INPUT chain to ACCEPT but put REJECT rules 
>at
> > the end. Example:
> > iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT
> > iptables -A INPUT -p tcp -m tcp -j REJECT
> > iptables -A INPUT -p udp -m udp -j REJECT
> > iptables -A INPUT -p icmp -j DROP
> >
> > This will give me the same outcome won't it?
>No, none of your rules reference the interface, e.g -i eth0
>So your rules allow/reject on all interfaces.
>
> >
> > Thanks in advance!
> >
> > _________________________________________________________________
> > Winterize your home with tips from MSN House & Home.
> > http://special.msn.com/home/warmhome.armx
>--
>--
>Raymond Leach <raymondl@knowledgefactory.co.za>
>Network Support Specialist
>http://www.knowledgefactory.co.za
>"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
>Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
>--
><< signature.asc >>

_________________________________________________________________
Our best dial-up offer is back.  Get MSN Dial-up Internet Service for 6 
months @ $9.95/month now! http://join.msn.com/?page=dept/dialup

RE: Best Practices for iptables

[Daniel Chemko]

Best practices:

WE ARE ALL HUMAN (I hope)

If you are looking for the best case, you'd want to cover your own
incompetence. Honestly, I work from this rule.
I policy block everything that I haven't allowed explicitly, simply
becausd if you try to build it in reverse, you're almost guaranteed to
miss a lot of important blocks / etc..

Re: Best Practices for iptables

[Antony Stone]

On Friday 05 December 2003 5:40 pm, Daniel Chemko wrote:

> Best practices:
>
> WE ARE ALL HUMAN (I hope)
>
> If you are looking for the best case, you'd want to cover your own
> incompetence. Honestly, I work from this rule.
> I policy block everything that I haven't allowed explicitly, simply
> becausd if you try to build it in reverse, you're almost guaranteed to
> miss a lot of important blocks / etc..

I agree.

Think of it like this:

If you block everything, allow what you want, and forget something, then 
either you or someone you're providing services for will say "this isn't 
working - can you fix it please?" and you can correct the ruleset to allow 
the missing service.

On the other hand, if you allow everything, and block the things you don't 
want, then anything you forget about is more likely to be discovered by 
somebody else on the Internet scanning and probing their way round your IP 
address/es, and if they find something you forgot to block, chances are they 
won't tell you :)

Therefore correcting mistakes is a whole lot easier if you start from the 
"deny everything except these..." approach.

Antony.

-- 
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.

 - William Gibson, Neuromancer (1984)

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Best Practices for iptables

[Ted Kaczmarek]

On Fri, 2003-12-05 at 13:09, Antony Stone wrote:
> On Friday 05 December 2003 5:40 pm, Daniel Chemko wrote:
> 
> > Best practices:
> >
> > WE ARE ALL HUMAN (I hope)
> >
> > If you are looking for the best case, you'd want to cover your own
> > incompetence. Honestly, I work from this rule.
> > I policy block everything that I haven't allowed explicitly, simply
> > becausd if you try to build it in reverse, you're almost guaranteed to
> > miss a lot of important blocks / etc..
> 
> I agree.
> 
> Think of it like this:
> 
> If you block everything, allow what you want, and forget something, then 
> either you or someone you're providing services for will say "this isn't 
> working - can you fix it please?" and you can correct the ruleset to allow 
> the missing service.
> 
> On the other hand, if you allow everything, and block the things you don't 
> want, then anything you forget about is more likely to be discovered by 
> somebody else on the Internet scanning and probing their way round your IP 
> address/es, and if they find something you forgot to block, chances are they 
> won't tell you :)
> 
> Therefore correcting mistakes is a whole lot easier if you start from the 
> "deny everything except these..." approach.
> 
> Antony.
Any good firewall implementation should implicitly deny everything on
the INPUT and FORWARD chains. If anyone tells you different they must
work for Microsoft.

Ted

Re: Best Practices for iptables

[Michael Gale]

What about OUTPUT ?

You should block everything in every direction and then allow what you want per interface.

Michael.


On Fri, 05 Dec 2003 14:29:59 -0500
Ted Kaczmarek <tedkaz@optonline.net> wrote:

> On Fri, 2003-12-05 at 13:09, Antony Stone wrote:
> > On Friday 05 December 2003 5:40 pm, Daniel Chemko wrote:
> > 
> > > Best practices:
> > >
> > > WE ARE ALL HUMAN (I hope)
> > >
> > > If you are looking for the best case, you'd want to cover your own
> > > incompetence. Honestly, I work from this rule.
> > > I policy block everything that I haven't allowed explicitly, simply
> > > becausd if you try to build it in reverse, you're almost guaranteed to
> > > miss a lot of important blocks / etc..
> > 
> > I agree.
> > 
> > Think of it like this:
> > 
> > If you block everything, allow what you want, and forget something, then 
> > either you or someone you're providing services for will say "this isn't 
> > working - can you fix it please?" and you can correct the ruleset to allow 
> > the missing service.
> > 
> > On the other hand, if you allow everything, and block the things you don't 
> > want, then anything you forget about is more likely to be discovered by 
> > somebody else on the Internet scanning and probing their way round your IP 
> > address/es, and if they find something you forgot to block, chances are they 
> > won't tell you :)
> > 
> > Therefore correcting mistakes is a whole lot easier if you start from the 
> > "deny everything except these..." approach.
> > 
> > Antony.
> Any good firewall implementation should implicitly deny everything on
> the INPUT and FORWARD chains. If anyone tells you different they must
> work for Microsoft.
> 
> Ted
> 
> 


-- 
Michael Gale
Network Administrator
Utilitran Corporation

Re: Best Practices for iptables

[Ramin Dousti]

On Fri, Dec 05, 2003 at 12:43:10PM -0700, Michael Gale wrote:

> 
> What about OUTPUT ?
> 
> You should block everything in every direction and then allow what you want per interface.

In general, yes. This would be the best (although, a bit more work) solution.
Usually the inside endpoints are the clients connecting to the outside services
which leads you to do "-p tcp/udp -o EXT -sport 1023: -j ACCEPT" however,
a hacker might run services inside on a high port and regularly initiate
outgoing traffic to a wel-defined IP/port which makes the firewall add this
to its internal conntrack then they would come in from that IP/port. That's
why you need to do some sanity checks for syn packets in ESTABLISHED state
along with many more other checks.

Most of the time, however, the OUTPUT and the outgoing FORWARD is relaxed
just because of the (false) assumption that the harm comes from outside.

Ramin

> Michael.

Re: Best Practices for iptables

[Gabby James]

Thanks for all the replies.  I will set my chain policies to DROP then only 
accept what I want.

_________________________________________________________________
Wonder if the latest virus has gotten to your computer? Find out. Run the 
FREE McAfee online computer scan! 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

RE: Best Practices for iptables

[Daniel Chemko]

I don't know what either you or the parent are talking about.

The OUTPUT chain is ONLY useful for filtering when:

1. The machine runs services as an account other than root; in which
case, default-accept is still ok in my book, just filter the uid of the
service.
2. You don't know how to work with inbound packets
3. The machine is a multi-user access server
4. The machine is a workstation

INPUT and FORWARD should be you're gatekeepers. I would shy away from
filtering in PREROUTING as it gets messy to track before DNAT /
REDIRECTing.

My corp. firewalls: INPUT: 10-20 rules, FORWARD: 75-200, OUTPUT: 0
My Home firewall: INPUT: 7 rules, FORWARD, 8 rules, OUTPUT: 0

In conclusion, it is all up and fine to use OUTPUT filtering if you
really really want to, but I fail to see how enforcing OUTPUT filtering
helps to secure a network as long as the Linux firewall is stand-alone.

For a userspace tool like ZoneAlarm, and Norton Internet Security, there
is currently no mechanism to trap/query users based on outgoing packets.
When that technology is developed for Linux, you'll really see the
benefits of OUTPUT filtering.

Re: Best Practices for iptables

[Antony Stone]

On Friday 05 December 2003 8:54 pm, Daniel Chemko wrote:

> I don't know what either you or the parent are talking about.
>
> The OUTPUT chain is ONLY useful for filtering when:
>
> 1. The machine runs services as an account other than root; in which
> case, default-accept is still ok in my book, just filter the uid of the
> service.
> 2. You don't know how to work with inbound packets
> 3. The machine is a multi-user access server
> 4. The machine is a workstation

Situations 3 and 4 are probably common enough that output filtering should be 
considered by anyone implementing netfilter.

I don't understand 2 - if you can't get your inbound filtering right, how can 
you solve your problems using outbound filtering?

Number 1, however, is in my opinion so universally true that it means every 
box is worth performing outbound filtering on.   Most services, even if 
they're started by root-privilege scripts at boot time, drop privileges and 
run under other accounts.   A mail server, a web server, an ftp server, a 
file server - all these will be running services under non root accounts.

The reasons why output filtering is a good idea are numerous:

1. You can allow / prohibit access to destinations selectively.
2. You can prevent access to external services which should not normally be 
part of the software configuration on the machine, but which might be enabled 
by misconfiguration or 'creative' coding.
3. You can ensure that any applications which turn out to be Trojan (however 
strongly you wish to apply the term) cannot get access to other systems which 
you weren't expecting.
4. After all the rules allowing the traffic you expect, a LOGging rule will 
helpfully tell you what else is being tried on your machine which you might 
want to know about.

Antony.

-- 
Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

                                                     Please reply to the list;
                                                           please don't CC me.