Re: safe default chain policies

Re: safe default chain policies

[Philippe Anctil]

> > May I ask what are your arguments in favor of putting filter output and
> > forward chains to drop?
>
>The secure attitude uses the same argument as for FORWARD - you block all
>traffic except that which you know you want and write ACCEPT rules for, and
>you can then be sure your machine isn't communicating in any other way than
>you want it to.

Yes I understand this attitude is the base of building a secure firewall. I 
was actually applying it abusively.

The thing is, traffic hitting the three filter chains have different origins 
and different purpose. Allow me to review the secure approach for each table 
individually.

I find setting up the INPUT chain to DROP unquestionable. This is because 
traffic hitting this chain gives direct access to services on the main gate.

Traffic hitting the OUTPUT originates from the firewall box itself. Why 
wouldn't we want a program to communicate outside? Because it is not 
authorized. What kind of unauthorized program could be installed on my box? 
Well this question does not exactly sounds like the right one. Who could 
install unauthorized programs on the box? Only those who have remote / 
physical access to the box. For an entreprise level filtering bug I'd 
probably go for a DROP. For my home network, I'll put it to ACCEPT. I may 
reconsider this, but my current ruleset does not make sense anyway:

iptables -P OUTPUT DROP
iptables -A OUTPUT -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s $internal_ip -j ACCEPT
iptables -A OUTPUT -s $external_ip -j ACCEPT

Now what about the FORWARD chain? Traffic hitting this chain has two 
possible origins and a corresponding destination.

A. Local network traffic going outside. For my home network, I am not 
restricting  outgoing traffic. This type of traffic does not justify a 
restricted policy.

B. Outside traffic heading back (or even towards?) to the local network. I 
think the origin of the traffic totally justifies this chain to be set to 
DROP. There is no limit to what wacked attempts outsiders may try.

But allow me to argue a little more on the FORWARD table subject. This table 
tends to have very loose restrictions. Mine's like this:

iptables -P FORWARD DROP
iptables -A FORWARD -s $network_addr -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Here I am trusting iptables entirely : in the hypothesis someone more clever 
than me finds a way of tricking the state machine, too bad for 'me home 
network. How much more would I trust iptables if I were to configure this 
table with a default ACCEPT policy? Iptable is good enough to identify 
established and related connections. How would a default ACCEPT policy would 
make it less good? I mean, if there is a way for an outsider to hit the 
FORWARD chain directly, outside of any legitimate connection process, what 
is the risk of having the chain set to ACCEPT? Shouldn't iptable discard the 
rubbish?

As I said above, I'll set FORWARD to DROP for my peace of mind. But I can't 
help thinking it does much of the work by itself.

Thank you very much for your helpful feedback! I hope you enjoyed the read 
;-)

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! 
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/

Re: safe default chain policies

[Antony Stone]

On Friday 02 April 2004 8:02 pm, Philippe Anctil wrote:

> >The secure attitude uses the same argument as for FORWARD - you block all
> >traffic except that which you know you want and write ACCEPT rules for,
> > and you can then be sure your machine isn't communicating in any other
> > way than you want it to.
>
> Yes I understand this attitude is the base of building a secure firewall. I
> was actually applying it abusively.

 !?

> I find setting up the INPUT chain to DROP unquestionable. This is because
> traffic hitting this chain gives direct access to services on the main
> gate.

Agreed.

> Traffic hitting the OUTPUT originates from the firewall box itself. Why
> wouldn't we want a program to communicate outside? Because it is not
> authorized. What kind of unauthorized program could be installed on my box?
> Well this question does not exactly sounds like the right one. Who could
> install unauthorized programs on the box? Only those who have remote /
> physical access to the box. For an entreprise level filtering bug I'd
> probably go for a DROP. For my home network, I'll put it to ACCEPT.

That is a reasonable distinction, and a reasonable conclusion, IMHO.

> I may reconsider this, but my current ruleset does not make sense anyway:
>
> iptables -P OUTPUT DROP
> iptables -A OUTPUT -s 127.0.0.1 -j ACCEPT
> iptables -A OUTPUT -s $internal_ip -j ACCEPT
> iptables -A OUTPUT -s $external_ip -j ACCEPT

I agree with you :)   This does not make sense - it is a totally open policy, 
because you have specified the only three source addresses a packet can 
possibly have, and decided to allow the traffic (which I do not necessarily 
disagree with).   You may as well just have iptables -P OUTPUT ACCEPT.

That is a reasonable thing to do on a home firewall IMHO.

> Now what about the FORWARD chain? Traffic hitting this chain has two
> possible origins and a corresponding destination.
>
> A. Local network traffic going outside. For my home network, I am not
> restricting  outgoing traffic. This type of traffic does not justify a
> restricted policy.

Okay, that's your choice, and it's a perfectly reasonable one.

> B. Outside traffic heading back (or even towards?) to the local network. I
> think the origin of the traffic totally justifies this chain to be set to
> DROP. There is no limit to what wacked attempts outsiders may try.

Agreed :)

> But allow me to argue a little more on the FORWARD table subject. This
> table tends to have very loose restrictions. Mine's like this:
>
> iptables -P FORWARD DROP
> iptables -A FORWARD -s $network_addr -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> Here I am trusting iptables entirely

Well, it is your firewall :)   Of course you must trust it.

> in the hypothesis someone more clever than me finds a way of tricking the
> state machine, too bad for 'me home network.

Agreed, but I do not believe such a trick has been discovered.

> How much more would I trust iptables if I were to configure
> this table with a default ACCEPT policy?

How *would* you configure this table with a default ACCEPT policy?   Or, to 
put it another way, if you had a default ACCEPT policy, what rule/s would you 
use for DROPping packets (as you say you do not want a totally open FORWARD 
chain from outside to inside....)?   I think it makes for a more complex 
setup.

> As I said above, I'll set FORWARD to DROP for my peace of mind. But I can't
> help thinking it does much of the work by itself.

The main reason I like setting a default DROP policy on FORWARD is that if I 
get one of the rules wrong, then something I want to work will not work, and 
I can spot it and correct it.   If I did it the other way round, with a 
default ACCEPT policy, then if I make a mistake, something I don't want to 
work will work, and it'll almost certainly be someone other than me who finds 
out and uses it :)

You can make a perfectly secure firewall with a default ACCEPT policy on 
FORWARD.   It's just harder to think of everything you need to DROP than it 
is to think of everything you want to ACCEPT under a default DROP policy.

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

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

Re: safe default chain policies

[Philippe Anctil]

> > May I ask what are your arguments in favor of putting filter output and
> > forward chains to drop?
>
>The secure attitude uses the same argument as for FORWARD - you block all
>traffic except that which you know you want and write ACCEPT rules for, and
>you can then be sure your machine isn't communicating in any other way than
>you want it to.

Yes I understand this attitude is the base of building a secure firewall. I 
was actually applying it abusively.

The thing is, traffic hitting the three filter chains have different origins 
and different purpose. Allow me to review the secure approach for each table 
individually.

I find setting up the INPUT chain to DROP unquestionable. This is because 
traffic hitting this chain gives direct access to services on the main gate.

Traffic hitting the OUTPUT originates from the firewall box itself. Why 
wouldn't we want a program to communicate outside? Because it is not 
authorized. What kind of unauthorized program could be installed on my box? 
Well this question does not exactly sounds like the right one. Who could 
install unauthorized programs on the box? Only those who have remote / 
physical access to the box. For an entreprise level filtering bug I'd 
probably go for a DROP. For my home network, I'll put it to ACCEPT. I may 
reconsider this, but my current ruleset does not make sense anyway:

iptables -P OUTPUT DROP
iptables -A OUTPUT -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s $internal_ip -j ACCEPT
iptables -A OUTPUT -s $xternal_ip -j ACCEPT

Now what about the FORWARD chain? Traffic hitting this chain has two 
possible origins and a corresponding destination.

A. Local network traffic going outside. For my home network, I am not 
restricting  outgoing traffic. This type of traffic does not justify a 
restricted policy.

B. Outside traffic heading back (or even towards?) to the local network. I 
think the origin of the traffic totally justifies this chain to be set to 
DROP. There is no limit to what wacked attempts outsiders may try.

But allow me to argue a little more on the FORWARD table subject. This table 
tends to have very loose restrictions. Mine's like this:

iptables -P FORWARD DROP
iptables -A FORWARD -s $network_addr -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Here I am trusting iptables entirely : in the hypothesis someone more clever 
than me finds a way of tricking the state machine, too bad for 'me home 
network. How much more would I trust iptables if I were to configure this 
table with a default ACCEPT policy? Iptable is good enough to identify 
established and related connections. How would a default ACCEPT policy would 
make it less good? I mean, if there is a way for an outsider to hit the 
FORWARD chain directly, outside of any legitimate connection process, what 
is the risk of having the chain set to ACCEPT? Shouldn't iptable discard the 
rubbish?

As I said above, I'll set FORWARD to DROP for my peace of mind. But I can't 
help thinking it does much of the work by itself.

Thank you very much for your helpful feedback! I hope you enjoyed the read 
;-)

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous !  
http://fr.ca.search.msn.com/

Re: safe default chain policies

[Philippe Anctil]

Hi Antony,

I will leave the nat chains open. In fact I already did that yesterday. I 
really makes my life better.

May I ask what are your arguments in favor of putting filter output and 
forward chains to drop?

As far as my understanding goes, the output chain is primarily important for 
traffic involving the firewall box itself. For example, you need rules in 
this chain if you want to ftp from the firewall to the outside. You need 
rules also if you want the firewall box to communicate freely with the local 
network. Why wouldn't we want the box to complete connections? Once traffic 
passed the input chain, why wouldn't I want it to cross the output chain as 
well?

My reasoning is similar with the forward chain. If traffic is allowed 
through the input  chain, it is very likely it is allowed to cross the 
forward chain too.

In other words, rules in OUTPUT and FORWARD appear redundant to me.

How a default accept policy in output and forward OUTPUT can compromise my 
network? Are there obvious cases I should know about?

Thanks for sharing!

>
> > I set all of input and nat chains to DROP.
>
>Do NOT set the nat table policies to DROP.   The nat tables are for address
>translation, not for filtering (DROP is a filtering operation).
>
> > I am thinking to set all chains to ACCEPT except the INPUT chain.
>
>No.   Set default DROP on INPUT, FORWARD and OUTPUT, then add rules to 
>allow
>the traffic you want.

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous !  
http://fr.ca.search.msn.com/

Re: safe default chain policies

[Antony Stone]

On Friday 02 April 2004 4:21 pm, Philippe Anctil wrote:

> Hi Antony,
>
> I will leave the nat chains open. In fact I already did that yesterday. I
> really makes my life better.

I bet it does :)

> May I ask what are your arguments in favor of putting filter output and
> forward chains to drop?

Forward is easy - you do not want your machine forwarding any traffic other 
than what you've decided you want to allow, therefore you set the policy to 
DROP and then write ACCEPT rules for the traffic you want.

If you do it the other way around, and have a default ACCEPT policy with DROP 
rules to block the traffic you don't want, you might (a) forget something, 
(b) not know about something new, (c) make a mistake which stops your script 
loading the rules part-way through....  all sorts of reasons why the firewall 
would be insecure as a result.

Output is a little more questionable - some people say "the only applications 
which will generate packets are the ones I run, therefore I'm going to allow 
all traffic out of my system with a default ACCEPT policy on OUTPUT".

This is okay so long as you really are in control of your machine and you 
really do know what all the applications you run are going to get up to.

The secure attitude uses the same argument as for FORWARD - you block all 
traffic except that which you know you want and write ACCEPT rules for, and 
you can then be sure your machine isn't communicating in any other way than 
you want it to.

> As far as my understanding goes, the output chain is primarily important
> for traffic involving the firewall box itself.

No need for the work "primarily" there.   The OUTPUT chain is *only* for 
traffic coming from the firewall box itself.

> Once traffic passed the input chain, why wouldn't I want it to cross the
> output chain as well?

This suggests to me that you're not quite sure about how netfilter works:

INPUT is for packets coming in the the firewall and terminating there.
OUTPUT is for packets going out of the firewall (having originated on it).
FORWARD is for packets going through the firewall (either way).

One packet will go through only *one* of these chains.   No single packet will 
go through INPUT and FORWARD, or through INPUT and OUTPUT

> My reasoning is similar with the forward chain. If traffic is allowed
> through the input  chain, it is very likely it is allowed to cross the
> forward chain too.

See above.

> In other words, rules in OUTPUT and FORWARD appear redundant to me.

Take a look at one of the excellent diagrams which have been created to show 
how packets traverse the netfilter chains and tables.

Regards,

Antony.

-- 
If at first you don't succeed, destroy all the evidence that you tried.

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

Re: safe default chain policies

[Antony Stone]

On Friday 02 April 2004 4:36 pm, Antony Stone wrote:

> Take a look at one of the excellent diagrams which have been created to
> show how packets traverse the netfilter chains and tables.

For example this one: http://www.aptalaska.net/~jclive/IPTablesFlowChart.pdf

Regards,

Antony.

-- 
Wanted: telepath.   You know where to apply.

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

safe default chain policies

[Philippe Anctil]

Hello list,

I've had quite a bit of trouble setting up nat rules on my iptables home 
network firewall. Machines behind my firewall box couldn't host games, use 
bittorrent efficiently, that type of thing. Not that nothing works. I've 
been surfing, playing games and ftp'ing happily for a while. My problems 
were nat-specific.

I have known for a while my problems were related to my default chain 
policies. I never wanted to compromise security, so I set all of input and 
nat chains to DROP. I left the mangle to accept (never took time to 
understand this table). Is this excessive security? I find such a firewall 
quite hard to maintain because you need to know exactly how chains are 
traversed.

I am thinking to set all chains to ACCEPT except the INPUT chain. Is this 
minimalist security? This is one chain I think I should not be open.

Where to draw the line for a home network?

Thanks for sharing your thoughts!

_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis !  
http://messenger.fr.msn.ca/

Re: safe default chain policies

[Antony Stone]

On Friday 02 April 2004 5:58 am, Philippe Anctil wrote:

> Hello list,
>
> I've had quite a bit of trouble setting up nat rules on my iptables home
> network firewall.

I'm not surprised, because...

> I set all of input and nat chains to DROP.

Do NOT set the nat table policies to DROP.   The nat tables are for address 
translation, not for filtering (DROP is a filtering operation).

> I am thinking to set all chains to ACCEPT except the INPUT chain.

No.   Set default DROP on INPUT, FORWARD and OUTPUT, then add rules to allow 
the traffic you want.

Set default ACCEPT on all nat and mangle tables, and *really* think hard if 
you ever find yourself wondering about putting a rule in one of those tables 
with a DROP target.

Regards,

Antony.

-- 
The words "e pluribus unum" on the Great Seal of the United States are from a 
poem by Virgil entitled "Moretum", which is about cheese and garlic salad 
dressing.

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