what filtering to do on the OUTPUT chain?

what filtering to do on the OUTPUT chain?

[Robert P. J. Day]

  i've had a number of people tell me that, while they put a
good deal of thought into their INPUT filtering, they simply
ACCEPT all outgoing traffic since, if their input filtering
is working properly, there's no reason to stop outgoing
packets.

  comments?  is there a FAQ that deals with what one should
filter on its way out?  i'm restricting this to the simple case
of firewalling a single host -- no routers, NAT, etc.

rday

Re: what filtering to do on the OUTPUT chain?

[Antony Stone]

On Tuesday 22 October 2002 7:57 pm, Robert P. J. Day wrote:

>   i've had a number of people tell me that, while they put a
> good deal of thought into their INPUT filtering, they simply
> ACCEPT all outgoing traffic since, if their input filtering
> is working properly, there's no reason to stop outgoing
> packets.

There's no reason to filter outgoing packets unless you don't trust the 
applications running on your machine.

If you don't trust what's running on your machine, then you should probably 
fix more than just what netfilter allows.

Antony

-- 

This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

Re: what filtering to do on the OUTPUT chain?

[Nick Drage]

On Tue, Oct 22, 2002 at 09:03:54PM +0100, Antony Stone wrote:
> On Tuesday 22 October 2002 7:57 pm, Robert P. J. Day wrote:
> 
> >   i've had a number of people tell me that, while they put a good deal
> > of thought into their INPUT filtering, they simply ACCEPT all outgoing
> > traffic since, if their input filtering is working properly, there's no
> > reason to stop outgoing packets.
> 
> There's no reason to filter outgoing packets unless you don't trust the 
> applications running on your machine.

You shouldn't trust the applications running on your machine.

> If you don't trust what's running on your machine, then you should
> probably fix more than just what netfilter allows.

Yes, but netfilter is a good start :)

-- 
FunkyJesus System Administration Team

Re: what filtering to do on the OUTPUT chain?

[Cedric Blancher]

Le mar 22/10/2002 à 20:57, Robert P. J. Day a écrit :
>   i've had a number of people tell me that, while they put a
> good deal of thought into their INPUT filtering, they simply
> ACCEPT all outgoing traffic since, if their input filtering
> is working properly, there's no reason to stop outgoing
> packets.
>   comments?

Once you have accepted the fact that your box can get compromised, you
easily understand why you should filter outgoing traffic. Moreover,
maximum security relies on the "lesser privilege rule" which specifies
that an object must not be allowed to do more than he has to. According
to this, you have to filter network output.

Consider you have a web server which is vulnerable to a 0day private
flaw. It is exploited, then cracker has a low privilege shell. If your
output is not filtered, he can just send any packet he wants which can
be bad for your environment, especialy when INPUT chain accepts all
ESTABLISHED packets. Well, if he gets root, you're lost unless you
harden your kernel with access control stuff like LIDS. But, in between,
it slows down the attacker and make its progression far more difficult.

If you plan to filter traffic on the box itself, than you have to do it
well. Not filtering in OUTPUT chain is just the same as if you set a
firewall up with no rule for returning packets, something like :

	iptables -A FORWARD -s $IN_NET -i $IN_IF -o $OUT_IF -j ACCEPT

which is, imho, truely bad.

You have, on one hand, to protect your box from the outside (that's
INPUT filtering). But on the other hand, you have to protect the rest of
your infrastructure (and also others) from this very box (this is OUTPUT
filtering).

Then it is just a matter of what security level you want to reach ;)

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security expert  - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: what filtering to do on the OUTPUT chain?

[Robert P. J. Day]

On 22 Oct 2002, Cedric Blancher wrote:

> Le mar 22/10/2002 à 20:57, Robert P. J. Day a écrit :
> >   i've had a number of people tell me that, while they put a
> > good deal of thought into their INPUT filtering, they simply
> > ACCEPT all outgoing traffic since, if their input filtering
> > is working properly, there's no reason to stop outgoing
> > packets.
> >   comments?
> 
> Once you have accepted the fact that your box can get compromised, you
> easily understand why you should filter outgoing traffic. Moreover,
> maximum security relies on the "lesser privilege rule" which specifies
> that an object must not be allowed to do more than he has to. According
> to this, you have to filter network output.

i understand that, for extra security, you should also filter on 
the OUTPUT chain.  but someone suggested to me that, if i get hacked
because someone gets through my INPUT filter rules, they have a good
chance of being able to change my ruleset anyway and remove the
filtering.  this is why this person suggested that i should concentrate
my efforts on hardening my INPUT filter, and not worry a whole lot
about the OUTPUT ruleset.  in other words, if i get hacked, i'm 
pretty much toast anyway, and can't trust *anything* about my
system anymore.

i realize it sounds like having sloppier security not worrying
about the OUTPUT ruleset.  i guess it would help me if someone
could provide *specific* examples of how OUTPUT filtering adds to
security beyond what would be provided by a well-designed INPUT
ruleset.  a pointer to an FAQ or some other link would be fine.

rday

Re: what filtering to do on the OUTPUT chain?

[Cedric Blancher]

Le mar 22/10/2002 à 22:10, Robert P. J. Day a écrit :
> On 22 Oct 2002, Cedric Blancher wrote:
> > Once you have accepted the fact that your box can get compromised, you
> > easily understand why you should filter outgoing traffic. Moreover,
> > maximum security relies on the "lesser privilege rule" which specifies
> > that an object must not be allowed to do more than he has to. According
> > to this, you have to filter network output.
> 
> i understand that, for extra security, you should also filter on 
> the OUTPUT chain.  but someone suggested to me that, if i get hacked
> because someone gets through my INPUT filter rules, they have a good
> chance of being able to change my ruleset anyway and remove the
> filtering.

This suppose attacker is able to gain superuser access to your box. This
is not always that easy.

> this is why this person suggested that i should concentrate
> my efforts on hardening my INPUT filter, and not worry a whole lot
> about the OUTPUT ruleset.  in other words, if i get hacked, i'm 
> pretty much toast anyway, and can't trust *anything* about my
> system anymore.

Yes you have to concentrate on your INPUT rule, it's true. But that does
not mean you do not have to harden OUTPUT, just to contain the attack.

> i realize it sounds like having sloppier security not worrying
> about the OUTPUT ruleset.  i guess it would help me if someone
> could provide *specific* examples of how OUTPUT filtering adds to
> security beyond what would be provided by a well-designed INPUT
> ruleset.  a pointer to an FAQ or some other link would be fine.

Simple. Consider this.

During a pentest, we broke into a box through vulnerable PHP scripts
(one to upload files, and another one to include them and have commands
executed). At this point, we are able to execute commands and upload
binaries, but we do not have a remote shell. So, we launched a netcat
piped to a shell to connect on, because input flows were not filtered
properly. Imagine they were, but output policy was to be accept
anything. We could just get our shell in having our "piped shell" netcat
connect to the attacking box. So, output stuff would have allowed our
remote shell just like if there were not much filtering.

This means, that with proper output filtering, we couldn't have achieve
this this easy, and must have find something else to gain our remote
shell. That would have make the intrusion far more difficult.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security expert  - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: what filtering to do on the OUTPUT chain?

[Antony Stone]

On Wednesday 23 October 2002 12:21 am, Cedric Blancher wrote:

> During a pentest, we broke into a box through vulnerable PHP scripts
> (one to upload files, and another one to include them and have commands
> executed). At this point, we are able to execute commands and upload
> binaries, but we do not have a remote shell. So, we launched a netcat
> piped to a shell to connect on, because input flows were not filtered
> properly. Imagine they were, but output policy was to be accept
> anything. We could just get our shell in having our "piped shell" netcat
> connect to the attacking box. So, output stuff would have allowed our
> remote shell just like if there were not much filtering.
>
> This means, that with proper output filtering, we couldn't have achieve
> this this easy, and must have find something else to gain our remote
> shell. That would have make the intrusion far more difficult.

The OUTPUT rules are always going to allow traffic to or from expected ports. 
53 is a good one to guess is going to be made accessible, so you simply set 
up netcat to contact your external system on port 53, and you can still do 
what you've outlined above even with pretty good OUTPUT filters in place.

The trouble is, netfilter only knows about IP addresses and TCP/UDP port 
numbers - it doesn't understand anything about the content of packets being 
sent on those ports, so it can't check that port 53 is being used only for 
DNS queries, port 80 is being used only for HTTP transfers etc.

My point is that if you can break into a machine, you can break out of it 
again, so OUTPUT filters are generally either not much use, or they get in 
the way of your normal applications.

Re the comment "--cmd-owner is your friend", I agree that this is worth 
adding to any OUTPUT rules you do choose to specify, but bear in mind that a 
compromised application or trojan is still going to be running under an 
expected user on the target machine, therefore --cmd-owner isn't necessarily 
going to see anything strange...

If you're concerned about this level of security (which you should be) then 
you need to deal with Operating System security and things like Host 
Intrustion Detection - netfilter is not going to do the job effectively for 
you.

Antony.

-- 

Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.

Re: what filtering to do on the OUTPUT chain?

[Cedric Blancher]

Le mer 23/10/2002 à 11:43, Antony Stone a écrit :
> The OUTPUT rules are always going to allow traffic to or from expected
> ports. 53 is a good one to guess is going to be made accessible, so
> you simply set up netcat to contact your external system on port 53,
> and you can still do what you've outlined above even with pretty good
> OUTPUT filters in place.

Yes you can. Even if you're facing a rule like 

	iptables -A OUTPUT -p udp -d $IN_DNS --dport 53 -j ACCEPT

You can use DNS tunnel stuff. But it makes things more difficult. And it
is just the point of security tools.

> If you're concerned about this level of security (which you should be) then 
> you need to deal with Operating System security and things like Host 
> Intrustion Detection - netfilter is not going to do the job effectively for 
> you.

Yeah sure, but it's an active part of the overall stuff, and, as such,
must be completly configured.

If I begin to admit the fact that because one tool does not all the job
for me, I can let it unconfigured, well, I do not see the point of
filtering INPUT with Netfilter ? My closed ports are closed, and open
ones can be wrapped, so what's the point adding packet filtering for
local applications that can provide address based access control through
tcpd or internal wrappers ? No tool can provide full security alone.
Each one is one brick of the wall. If bricks are missing, you wall is
shacky.

My point of vue is that you should use every security mecanism available
to enforce your security policy. You can say that it is too much work,
too much time or too much money to do ; I understand this kind of
reason. But doing nothing because what you can implement can be evaded
is not a valuable reason, imho. If you extend this, you would not set
security at all, as every security tool can be evaded.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security expert  - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: what filtering to do on the OUTPUT chain?

[Nick Drage]

On Wed, Oct 23, 2002 at 10:43:37AM +0100, Antony Stone wrote:
> On Wednesday 23 October 2002 12:21 am, Cedric Blancher wrote:

<snip>

> > This means, that with proper output filtering, we couldn't have achieve
> > this this easy, and must have find something else to gain our remote
> > shell. That would have make the intrusion far more difficult.
> 
> The OUTPUT rules are always going to allow traffic to or from expected
> ports.  53 is a good one to guess is going to be made accessible, so you
> simply set up netcat to contact your external system on port 53, and you
> can still do what you've outlined above even with pretty good OUTPUT
> filters in place.
> 
> The trouble is, netfilter only knows about IP addresses and TCP/UDP port
> numbers - it doesn't understand anything about the content of packets
> being sent on those ports, so it can't check that port 53 is being used
> only for DNS queries, port 80 is being used only for HTTP transfers etc.

Yes, but then, as someone else has already pointed out, you could
encapsulate malicious traffic within legitimate looking requests - so a
netfilter with an understanding of DNS traffic wouldn't help.  So even those
filters don't prevent any malicious outbound traffic, but think of the
effort and knowledge involved compared to just allowing anything outbound.

> My point is that if you can break into a machine, you can break out of it 
> again,

Eventually, possibly, it's all about making the time and effort involved so
great that it's not worth trying.

> so OUTPUT filters are generally either not much use, or they get in the
> way of your normal applications.

Depends if you write them, er, right.

> Re the comment "--cmd-owner is your friend", I agree that this is worth
> adding to any OUTPUT rules you do choose to specify, but bear in mind that
> a compromised application or trojan is still going to be running under an
> expected user on the target machine, therefore --cmd-owner isn't
> necessarily going to see anything strange...

Oh yeah, tis but another tool in the box.

> If you're concerned about this level of security (which you should be)
> then you need to deal with Operating System security and things like Host
> Intrustion Detection - netfilter is not going to do the job effectively
> for you.

"Host Intrusion Detection"?  For example..... ?

-- 
FunkyJesus System Administration Team

Re: what filtering to do on the OUTPUT chain?

[Antony Stone]

On Thursday 24 October 2002 10:31 pm, Nick Drage wrote:

> On Wed, Oct 23, 2002 at 10:43:37AM +0100, Antony Stone wrote:

> > If you're concerned about this level of security (which you should be)
> > then you need to deal with Operating System security and things like Host
> > Intrustion Detection - netfilter is not going to do the job effectively
> > for you.
>
> "Host Intrusion Detection"?  For example..... ?

Tripwire - http://www.tripwire.org

Snare - http://www.intersectalliance.com/projects/Snare

Aide - http://www.cs.tut.fi/~rammer/aide.html

Lids - http://www.lids.org

Those sort of things.....

Antony.

-- 

There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

Re: what filtering to do on the OUTPUT chain?

[Nick Drage]

On Tue, Oct 22, 2002 at 04:10:46PM -0400, Robert P. J. Day wrote:
> On 22 Oct 2002, Cedric Blancher wrote:
> > > Le mar 22/10/2002 à 20:57, Robert P. J. Day a écrit :
> > >   i've had a number of people tell me that, while they put a good deal
> > > of thought into their INPUT filtering, they simply ACCEPT all outgoing
> > > traffic since, if their input filtering is working properly, there's
> > > no reason to stop outgoing packets.
> > >   comments?
> > 
> > Once you have accepted the fact that your box can get compromised, you
> > easily understand why you should filter outgoing traffic. Moreover,
> > maximum security relies on the "lesser privilege rule" which specifies
> > that an object must not be allowed to do more than he has to. According
> > to this, you have to filter network output.

Agreed.

> i understand that, for extra security, you should also filter on the
> OUTPUT chain.  but someone suggested to me that, if i get hacked because
> someone gets through my INPUT filter rules, they have a good chance of
> being able to change my ruleset anyway and remove the filtering.

Not true.  Compromising some user level application, or some chrooted
server, does not automatically allow the malicious third party to alter your
firewall rules.

> this is why this person suggested that i should concentrate my efforts on
> hardening my INPUT filter, and not worry a whole lot about the OUTPUT
> ruleset.

Security is achieved through strength in depth.  If you're running any kind
of server you will have to allow packets in, to a webserver say.  However,
not allowing that webserver to do anything but send replies, rather than
permitting it to do anything ( DoS the Net, download files to the local
system, and so on ) will greatly restrict the options at the malicious third
party's disposal.

> in other words, if i get hacked, i'm pretty much toast anyway,

Not true.

> and can't trust *anything* about my system anymore.

Not true.

> i realize it sounds like having sloppier security not worrying about the
> OUTPUT ruleset.  i guess it would help me if someone could provide
> *specific* examples of how OUTPUT filtering adds to security beyond what
> would be provided by a well-designed INPUT ruleset.  a pointer to an FAQ
> or some other link would be fine.

"--cmd-owner" is your friend, your close, personal, bestest friend.

-- 
FunkyJesus System Administration Team

Re: what filtering to do on the OUTPUT chain?

[Cedric Blancher]

Le mer 23/10/2002 à 01:31, Nick Drage a écrit :
> "--cmd-owner" is your friend, your close, personal, bestest friend.

--cmd-owner is, imho, not usable on its own for filtering purposes, such
as application based filtering.

I'll try to show why :

root@elendil:~# iptables -A OUTPUT -m owner --cmd-owner "nc" -j REJECT

So I should not be able to execute a netcat. I use a REJECT rule to give
a simple example.

cbr@elendil:~$ nc 192.168.1.10 22
(UNKNOWN) [192.168.1.10] 22 (ssh) : Connection refused

Fine. That's what I wanted.

cbr@elendil:~$ ln -s /bin/nc toto
cbr@elendil:~$ ./toto 192.168.1.10 22
SSH-2.0-Feydreiva SSH daemon

Well, a bit tricky... If you investigate a bit more and set a DROP
policy up with only allowed application, you'll discover you just can't
specify a command path, only a command name. That means if you allow
"ping" command, any command named ping will do the trick, would it be a
symlink named "ping" to another command or a binary named "ping". So, if
you want to do it well, you have to restrict your filesystem, forbiding
users to write in order to prevent them to create another "ping".

So --cmd-owner becomes useful when used with other matches, to restrict
ping command to ICMP echo requests as an exemple :

iptables -A OUTPUT -m owner --cmd-owner "ping" -m state --state NEW \
	-p icmp --icmp-type echo-request -j ACCEPT

Solution would be to match commands not on name, but on the exact binary
location (inode number, device number), but it is far out of my skills
to implement this. Moreover, it could affect performance (but you can
reduce it well using state match and only filter NEW packets using this
stuff).

By the way, owner match is very useful to me, especially --uid-owner and
--gid-owner.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security expert  - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE