A simple question

A simple question

[Sudheer Divakaran]

Hi,

In almost all IP Tables articles I've found that the default policy of 
all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as 
far as INPUT and FORWARD tables are concerned, but I do not understand 
why should we set the default policy of OUTPUT chain to DROP.  OUTPUT 
chain is responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

RE: A simple question

[Mark E. Donaldson]

 
In almost all IP Tables articles I've found that the default policy of all
tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as far as
INPUT and FORWARD tables are concerned, but I do not understand why should
we set the default policy of OUTPUT chain to DROP.  OUTPUT chain is
responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

What you say is indeed correct. Most of the articles on the subject do
recommend a default DROP on all three tables. However, I personally do set
my OUTPUT default to ACCEPT, while my FORWARD and INPUT are definitely set
to DROP. As you might expect, it is quite easy to DOS the firewall itself
when OUTPUT is set to DROP. And that is not a real good idea. However,
having said that, close scrutiny must be paid to what you allow out of the
firewall and the necessary rules must be in place.

RE: A simple question

[Torsten Luettgert]

On Don, 2004-08-19 at 06:18, Mark E. Donaldson wrote:
> As you might expect, it is quite easy to DOS the firewall itself
> when OUTPUT is set to DROP. And that is not a real good idea.

Please elaborate - why is it easy to DOS the firewall if the output
policy is DROP? You don't mean icmp/source-quench not getting
delivered or something?

> However, having said that, close scrutiny must be paid to what you
> allow out of the firewall and the necessary rules must be in place.

...which is why I personally use DROP as default policy for all
chains and explicitly allow everything I think necessary :-)

The only exception is in the mangle table, where I use ACCEPT
policies and just filter out the obvious spoofs, unclean frames
etc.

Greetings,
Torsten

Re: A simple question

[Dhananjoy Chowdhury]

Hi,
As far as my knowledge this is done so that the local processes on the
firewall machine itself cannot communicate with the outside world.
Mostly firewalls are set for FORWARDing so from security point of view
its better we set the OUTPUT chain to DROP.
But its again your choice waht you want to ACCEPT or DROP.


On Thu, 2004-08-19 at 08:06, Sudheer Divakaran wrote:
> Hi,
> 
> In almost all IP Tables articles I've found that the default policy of 
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as 
> far as INPUT and FORWARD tables are concerned, but I do not understand 
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT 
> chain is responsible for packets originating from the firewall itself.  
> Whay should we DROP it?
> 
> Thanks,
> Sudheer
> 

RE: A simple question

[Erick Sanz]

Sudheer,

I like to block all outgoing traffic in case that someone can take control
either from my firewall system or any other system in my network.

The firewall should be the most secure system in your network; however, like
any other system, it is still vulnerable to bugs and exploits.

If the firewall allows everything out, your system can turn out to be the
one used to attack other systems. It might bee too paranoid, but I like to
protect other people from having my systems attacking theirs.

Also, if you don't have a good system security policy, you might not realize
that your system was taken over until the gentleman with the nice black
suits
knock at your door  ....    =)

-- Just my two cents! maybe even less!




> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sudheer
> Divakaran
> Sent: Wednesday, August 18, 2004 9:37 PM
> To: Netfilter mailing list
> Subject: A simple question
>
>
> Hi,
>
> In almost all IP Tables articles I've found that the default policy of
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as
> far as INPUT and FORWARD tables are concerned, but I do not understand
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT
> chain is responsible for packets originating from the firewall itself.
> Whay should we DROP it?
>
> Thanks,
> Sudheer
>
>
>
> This email message has been scanned for viruses.
>



This email message has been scanned for viruses.

A Simple Question

[Robb Bossley]

I have been using Linux for quite some time, and I really enjoy the
power that is available with netfilter.  Thank you for all of your
input into the development and testing of it.

I have used other people's scripts to configure my firewall for a
number of years, though I usually rolled my own kernels for this.

I have been reading the mailing list posts and it seems that most of
you who are very knowledgeable with netfilter would propose a default
policy of DROP on both the INPUT and FORWARD chains.

iptables -P INPUT DROP
iptables -P FORWARD DROP
 
However, I have noticed that a number of what I would consider to be
strong contenders in the market use default policies of ACCEPT and
then have a DROP rule at the end of the tables / chain.

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
...................................(other stuff here)..........................
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

I'm confused.  Which is preferred for security and why?  (Or is this
just six of one, half a dozen of another?)
-- 
As if you could kill time without injuring eternity.  The mass of men
live lives of quiet desperation.
- Henry David Thoreau

Re: A Simple Question

[/dev/rob0]

On Tuesday 2005-August-09 19:11, Robb Bossley wrote:
> I have been reading the mailing list posts and it seems that most of
> you who are very knowledgeable with netfilter would propose a default
> policy of DROP on both the INPUT and FORWARD chains.
>
> iptables -P INPUT DROP
> iptables -P FORWARD DROP

Yes, but ...

> However, I have noticed that a number of what I would consider to be
> strong contenders in the market use default policies of ACCEPT and
> then have a DROP rule at the end of the tables / chain.
>
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> ...................................(other stuff
> here).......................... iptables -A INPUT -j DROP
> iptables -A FORWARD -j DROP

... this is simply another means to the same end.

> I'm confused.  Which is preferred for security and why?  (Or is this
> just six of one, half a dozen of another?)

It all depends on the "other stuff" in the middle. At my most complex 
site, I went for default ACCEPT policies because I had multiple types 
of internal interfaces. Even those have varying needs. It just seemed 
that an ACCEPT policy would be the simplest way to get the job done. 
Everything we don't want is dropped (or rejected), everything we do 
want is accepted.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: A Simple Question

[Jan Engelhardt]

>iptables -P INPUT DROP
>iptables -P FORWARD DROP
>VS
>iptables -P INPUT ACCEPT
>iptables -P FORWARD ACCEPT
>...(other stuff here)...
>iptables -A INPUT -j DROP
>iptables -A FORWARD -j DROP
>
>Which is preferred for security and why?

Both equally work well. It's just a matter from which side you tackle the 
problem. Compare with 3d-engine editing:

A Quake2 map starts with "air" and you got to add walls -
  that's like -P ACCEPT and -j REJECT/DROP

An Unreal map starts with "everything filled" and you got to subtract rooms -
  like -P DROP and -j ACCEPT

In fact, sometimes it is wise to alternate between the two methods within the 
same table. I've got this in some ruleset:

-P INPUT DROP
-p tcp -m multiport --dport someservices -j ACCEPT
(denying all other traffic)

-P OUTPUT ACCEPT
-o $internal -j DROP
(allowing all other interfaces)


Just like Apache's "Order allow,deny" if you need another inspiration for 
comparison.


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: A Simple Question

[Grant Taylor]

Robb Bossley wrote:
> I have been using Linux for quite some time, and I really enjoy the
> power that is available with netfilter.  Thank you for all of your
> input into the development and testing of it.
> 
> I have used other people's scripts to configure my firewall for a
> number of years, though I usually rolled my own kernels for this.
> 
> I have been reading the mailing list posts and it seems that most of
> you who are very knowledgeable with netfilter would propose a default
> policy of DROP on both the INPUT and FORWARD chains.
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
>  
> However, I have noticed that a number of what I would consider to be
> strong contenders in the market use default policies of ACCEPT and
> then have a DROP rule at the end of the tables / chain.
> 
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> ...................................(other stuff here)..........................
> iptables -A INPUT -j DROP
> iptables -A FORWARD -j DROP
> 
> I'm confused.  Which is preferred for security and why?  (Or is this
> just six of one, half a dozen of another?)

IMHO both methods are just about equally as effective.  However I believe that by using the default policy of a chain you can save adding a rule that must be traversed and thus make the processing just slightly faster.  On the other hand you can only set default policies on built in chains and thus you must do your own ""policy equivalent at the end of user defined chains with the rules that you have noticed.  Thus for uniformity it may just be easier for some firewall authors to stick with the method that they know will work in EVERY chain than to have to remember which chain they are in.  To me this issue is really 5.5 of one dozen and 6.5 of another, close but not exactly the same.



Grant. . . .

RE: A simple question

[Hudson Delbert J Contr 61 CS/SCBN]

I think there has been a bit of loss of direction from the initial thread.

programatically speaking NO services which allow traffic of any kind s/be
running
'out of the box'...

the fewer and smaller amount of code the more secure.

i.e.,,,if it ain't running you cant attack it....common sense....

re: bellovin, cheswick, farmer, wiezste, et al...

console should be how one initally accesses the box unless
we are speaking of a centrally managed security enclave scenario.

why take needless chances...

~piranha


> Just my two cents on this:

My two pennies :)

> If your firewall is designed correctly, there shouldn't be any network
> available services running baring SSH.

If you're using IPTables as a seperate firewall then wouldn't you just
want SSHD listening on the internal interface?

> Because of this, if a hacker gets into your firewall I assume that
> 99.9999% of the time, they'll have root access. Any hacker that could
> hack into your Linux box will be able to disable any iptables rules in
> a second. Hence, blocking the OUTPUT chain on a firewall does NOT
> secure you against hackers.

You're presuming that IPTables isn't protecting a single host.  If
you're using it on a desktop or a server filtering on the OUTPUT chain
gives you a huge gain in security.

-- 
"I think a church with a lightning rod shows a decided lack of confidence"

RE: A simple question

[Daniel Chemko]

> If you're using IPTables as a seperate firewall then wouldn't you just
> want SSHD listening on the internal interface?

> 
> You're presuming that IPTables isn't protecting a single host.  If
> you're using it on a desktop or a server filtering on the OUTPUT chain
> gives you a huge gain in security.

Very true on both points. You should only bind SSH to your secured
channels. Even then you'll have to be careful of internal staff/wormed
PC's trying to exploit the service. Good audit logging and IDS traps for
SSH exploits would be a good start.

In the other case of a desktop Linux, you are very true that OUTPUT
filtering will become more and more prevailent as desktop Linux matures.
I was strictly speaking about gateway/firewalls, not end-user
protection. I wouldn't doubt that someone will develop a netfilter
module along the lines of zonealarm and other 'personal' firewalls.

RE: A simple question

[Daniel Chemko]

Hudson Delbert J Contr 61 CS/SCBN wrote:
> this should be a basic rule of netsec 101 ...
> 
> one should have to 'turn' on any allowed traffic out of the box.
> 
> i.e......the firewall should not allow ANY traffic by default until
> specifically
> 		TOLD TO DO SO BY THE ADMIN.
> 
> this is a good thing.


Just my two cents on this:

If your firewall is designed correctly, there shouldn't be any network
available services running baring SSH. Because of this, if a hacker gets
into your firewall I assume that 99.9999% of the time, they'll have root
access. Any hacker that could hack into your Linux box will be able to
disable any iptables rules in a second. Hence, blocking the OUTPUT chain
on a firewall does NOT secure you against hackers.

It does protect you against yourself if you really need it. For a
tightly regimented network with many admins of varying experience, this
might be a sane policy to implement. Beyond that, its simply beurocratic
overhead.

Re: A simple question

[Nick Drage]

On Thu, Aug 19, 2004 at 10:14:48AM -0700, Daniel Chemko wrote:
> Hudson Delbert J Contr 61 CS/SCBN wrote:
> > this should be a basic rule of netsec 101 ...
> > 
> > one should have to 'turn' on any allowed traffic out of the box.
> > 
> > i.e......the firewall should not allow ANY traffic by default until
> > specifically
> > 		TOLD TO DO SO BY THE ADMIN.
> > 
> > this is a good thing.

> Just my two cents on this:

My two pennies :)

> If your firewall is designed correctly, there shouldn't be any network
> available services running baring SSH.

If you're using IPTables as a seperate firewall then wouldn't you just
want SSHD listening on the internal interface?

> Because of this, if a hacker gets into your firewall I assume that
> 99.9999% of the time, they'll have root access. Any hacker that could
> hack into your Linux box will be able to disable any iptables rules in
> a second. Hence, blocking the OUTPUT chain on a firewall does NOT
> secure you against hackers.

You're presuming that IPTables isn't protecting a single host.  If
you're using it on a desktop or a server filtering on the OUTPUT chain
gives you a huge gain in security.

-- 
"I think a church with a lightning rod shows a decided lack of confidence"

RE: A simple question

[Hudson Delbert J Contr 61 CS/SCBN]

this should be a basic rule of netsec 101 ...

one should have to 'turn' on any allowed traffic out of the box.

i.e......the firewall should not allow ANY traffic by default until
specifically
		TOLD TO DO SO BY THE ADMIN.

this is a good thing.



####################################
# delbert.hudson@losangeles.af.mil #
#        61cs/scbn, 3-0182         #
####################################


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Mark E.
Donaldson
Sent: Wednesday, August 18, 2004 9:19 PM
To: 'Sudheer Divakaran'; 'Netfilter mailing list'
Subject: RE: A simple question


 
In almost all IP Tables articles I've found that the default policy of all
tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as far as
INPUT and FORWARD tables are concerned, but I do not understand why should
we set the default policy of OUTPUT chain to DROP.  OUTPUT chain is
responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

What you say is indeed correct. Most of the articles on the subject do
recommend a default DROP on all three tables. However, I personally do set
my OUTPUT default to ACCEPT, while my FORWARD and INPUT are definitely set
to DROP. As you might expect, it is quite easy to DOS the firewall itself
when OUTPUT is set to DROP. And that is not a real good idea. However,
having said that, close scrutiny must be paid to what you allow out of the
firewall and the necessary rules must be in place.

RE: A simple question

[Jason Opperisano]

> Hi,
>
> In almost all IP Tables articles I've found that the default policy of
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as
> far as INPUT and FORWARD tables are concerned, but I do not understand
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT
> chain is responsible for packets originating from the firewall itself.
> Whay should we DROP it?
>
> Thanks,
> Sudheer

two reasons i can think of:

1) your firewall is no better than any other machine in your network.  all of the machines behind it are only allowed out on specific ports to specific destinations, so why should the firewall be any different?

2) it helps lazy admins (i.e. me).  on more than one occasion i've found myself ssh'ed into a firewall and tried to go somewhere/do something and it didn't work; and i thought to myself "i probably shouldn't be doing this from the firewall."  it keeps you from treating the machine that is supposed to be the most locked down, tightly secured machine in the network like a common client.  for me anyways...

i only allow out ftp or http to the specific IP's of the machines that i update from (via apt or yum).

-j

A simple question

[Gianni Pucciani]

Hi all,
I'm new to the use of iptable. I set this script for my home 
workstation, but when I apply these rules anything stop functioning.
I guess I'm doing something stupid but this is my very first time with 
iptables, so sorry.
I use my workstation that is behind an adsl router. My workstation has a 
fixed ip, 192.168.1.2 and I'd like to use it for Tomcat server , ssh 
server and general client features.Can anyone give me some help?
Thanks

PS Comment are italian, but hope rules be quite clear...


#!/bin/sh
#G.P
#last update 050404
#Script di inizializzazione per settare un insieme di regole
#di packet filtering tramite iptables.

#definire le policy (comportamento di default)per le catene di default
/sbin/iptables -P INPUT DROP #ogni pacchetto in ingresso scartato
/sbin/iptables -P OUTPUT DROP #ogni pacchetto in uscita accettato
/sbin/iptables -P FORWARD DROP #ogni pacchetto di passaggio scartato

#flush di tutte le catene
/sbin/iptables --flush

#elimina le catene
/sbin/iptables -X miacatenain
/sbin/iptables -X miacatenaout


#creare una nuova catena
/sbin/iptables -N miacatenain
/sbin/iptables -N miacatenaout

#aggiungere una regola a INPUT e OUTPUT per passare
#dalle regole appena definite. Ogni pacchetto fa match e passa
#alla catena 'miacatena' corrispondente
/sbin/iptables -A INPUT -j miacatenain
/sbin/iptables -A OUTPUT -j miacatenaout

#######aggiungere le regole alla catena di ingresso#########

#ICMP
#Consentire traffico icmp
/sbin/iptables -A miacatenain -p icmp -j ACCEPT

#CUPS
#Consentire traffico cups in ingresso
/sbin/iptables -A miacatenain -p tcp --dport 632 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 632 -j ACCEPT


##EDONKEY
#Consentire traffico tcp alla porta 4663
/sbin/iptables -A miacatenain -p tcp --dport 4663 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 4663 -j ACCEPT

#SSH
#Consentire traffico ssh in ingresso

/sbin/iptables -A miacatenain -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 22 -j ACCEPT

#TOMCAT
#Consentire traffico web in ingresso x Tomcat da ufficio
/sbin/iptables -A miacatenain -p tcp --dport 8080 -d 192.168.1.2 -s 
131.114.136.26 -j ACCEPT

#Consentire traffico web in ingresso x Tomcat da rete locale
/sbin/iptables -A miacatenain -p tcp --dport 8080 -d 192.168.1.2 -s 
192.168.1.0/255.255.255.0 -j ACCEPT

#LOOPBACK
#Consentire tutto il traffico tramite l'interfaccia di loopback
#/sbin/iptables -A miacatenain -i lo -j ACCEPT

#######aggiungere le regole alla catena di uscita#######

#Consentire connessioni ftp in ingresso
#/sbin/iptables -A miacatena -p tcp --dport 2020 e 21 in uscita
#/sbin/iptables -A miacatena -p tcp --dport

##EDONKEY
#Consentire traffico tcp alla porta 4663
/sbin/iptables -A miacatenaout -p tcp --dport 4663 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 4663 -j ACCEPT

#DNS
#Consentire traffico dns in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 53 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 53 -j ACCEPT

#SMTP POP3
#Consentire traffico smtp
/sbin/iptables -A miacatenaout -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A miacatenaout -p tcp --dport 110 -j ACCEPT

#SSH
#Consentire traffico SSH in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 22 -j ACCEPT

#WEB
#Consentire traffico web in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 80 -j ACCEPT

#LOOPBACK
#Consentire tutto il traffico tramite l'interfaccia di loopback
#/sbin/iptables -A miacatenain -i lo -j ACCEPT


#########applica le modifiche#########
/sbin/service iptables save

/sbin/service iptables restart

Re: A simple question

[Antony Stone]

On Tuesday 06 April 2004 3:25 am, Gianni Pucciani wrote:

> Hi all,
> I'm new to the use of iptable. I set this script for my home
> workstation, but when I apply these rules anything stop functioning.
> I guess I'm doing something stupid but this is my very first time with
> iptables, so sorry.

The major problem with your ruleset is that you have no rules in either your 
INPUT or OUTPUT chains to allow reply packets.

My recommendation is to start simple, and add things bit by bit.   Then if 
something goes wrong, you only need to look at the (simple) thing you added 
most recently.

For a home workstation, try the following ruleset (which will allow more 
traffic than you say you want, but is still secure from the outside world).

You can add more specific rules to allow only the correct traffic, and to 
allow limited connections from the outside, as you want to.

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT

Regards,

Antony.

-- 
Most people have more than the average number of legs.

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

Re: A simple question

[Gianni Pucciani]

Ok Antony, thanks for the help and sorry for my second mail, I was a bit 
in a hurry yesterday ;-)
Maybe I have to review the TCP protocol...

Gianni
Antony Stone wrote:

>On Tuesday 06 April 2004 3:25 am, Gianni Pucciani wrote:
>
>  
>
>>Hi all,
>>I'm new to the use of iptable. I set this script for my home
>>workstation, but when I apply these rules anything stop functioning.
>>I guess I'm doing something stupid but this is my very first time with
>>iptables, so sorry.
>>    
>>
>
>The major problem with your ruleset is that you have no rules in either your 
>INPUT or OUTPUT chains to allow reply packets.
>
>My recommendation is to start simple, and add things bit by bit.   Then if 
>something goes wrong, you only need to look at the (simple) thing you added 
>most recently.
>
>For a home workstation, try the following ruleset (which will allow more 
>traffic than you say you want, but is still secure from the outside world).
>
>You can add more specific rules to allow only the correct traffic, and to 
>allow limited connections from the outside, as you want to.
>
>iptables -P INPUT DROP
>iptables -P OUTPUT DROP
>iptables -P FORWARD DROP
>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>iptables -A OUTPUT -j ACCEPT
>
>Regards,
>
>Antony.
>
>  
>