coming in through the outgoing hole?

coming in through the outgoing hole?

[Keith Whyte]

here's a scenario
i have opened outgoing webserver requests and their resposes thus
(output from iptables -v -L)

INPUT
0     0 ACCEPT     tcp  --  eth0   any     anywhere
anywhere           tcp spt:http dpts:1024:65535
OUTPUT
0    0 ACCEPT     tcp  --  any    eth0    anywhere
anywhere           tcp spts:1024:65535 dpt:http

now, it occurs to me that i have opened access to ports 1024 to 65535,
as long as the source port is port 80, correct?
where as I only want it open for connections originating on the local
machine.

I presume the answer here is conntrack, could someone help me with the
command for the INPUT chain?
should it be --state RELATED or ESTABLISHED or both or something like !
NEW (if that can be done)?

as a hypothetical example of the problem:
let's say i run an admin type webserver for some app, listening on a
port above 1024, for example. if someone hacked a web client to use port
80 as the source port for it's connections,  (dunno, would you have to
hack the kernel too, or just be root?) , then they could bypass the
firewall part of the security, right? or with ssh, surely it would be
easy enough to hack an ssh client to use port 80 as it's source port.
ok, so you probably shouldn't run an ssh listener on a port above 1024,
but nevertheless, it's a good hole to close.

thanks!

Keith.

RE: coming in through the outgoing hole?

[Derick Anderson]

Response inline: 

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org 
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of 
> Keith Whyte
> Sent: Monday, November 21, 2005 12:59 PM
> To: netfilter@lists.netfilter.org
> Subject: coming in through the outgoing hole?
> 
> here's a scenario
> i have opened outgoing webserver requests and their resposes 
> thus (output from iptables -v -L)
> 
> INPUT
> 0     0 ACCEPT     tcp  --  eth0   any     anywhere
> anywhere           tcp spt:http dpts:1024:65535
> OUTPUT
> 0    0 ACCEPT     tcp  --  any    eth0    anywhere
> anywhere           tcp spts:1024:65535 dpt:http

You don't need the 1024:65535 bit in either rule once you use connection
tracking. If you're trying to restrict this particular machine from
connecting to web servers using a source port below 1024, this is
already done for you unless the user is root. If the user is root, then
OUTPUT filtering is meaningless (more so than if the user is not, which
is still quite a bit). Your OUTPUT filtering should really be egress
filtering in the FORWARD chain of your firewall. Hopefully you aren't
web surfing with your firewall.

Stick around and I'm sure someone else will mention the general
pointlessness of OUTPUT filtering.

> now, it occurs to me that i have opened access to ports 1024 
> to 65535, as long as the source port is port 80, correct?
> where as I only want it open for connections originating on 
> the local machine.

The INPUT and OUTPUT tables are only valid for traffic originating and
terminating at the local machine, so you've accomplished that goal.

> I presume the answer here is conntrack, could someone help me 
> with the command for the INPUT chain?
> should it be --state RELATED or ESTABLISHED or both or 
> something like !
> NEW (if that can be done)?

Yes - the solution is to allow all RELATED,ESTABLISHED connections. I'm
still assuming this is a workstation and not a firewall/router box.
You'll want to use these rules:

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

This will accept all incoming (server response) and outgoing (client
requests) traffic which is related to the original request (dport 80).
Notice the use of -I instead of -A: this places the rules at the top of
the chain because they will get hit the most.

In addition I would suggest something like this if you are really intent
on doing OUTPUT filtering (which I again will say is really not that
great) to replace your two rules above:

iptables -A OUTPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT

What happens is the first packet goes out (in the NEW state, you could
get even more restrictive and use the '--syn' or '--tcp-flags
SYN,RST,ACK SYN' to make sure it's a SYN packet) on port 80 and hits the
remote server. The return packet (now ESTABLISHED) hits the ESTABLISHED
match at the top of your INPUT ruleset there and goes on its merry way.
The next packet out from the machine (also ESTABLISHED) hits the
ESTABLISHED match in the OUTPUT chain and is accepted as well.
Everything else that happens until the connection is closed goes through
the RELATED,ESTABLISHED rules and not through the '--dport 80' rule.

> as a hypothetical example of the problem:
> let's say i run an admin type webserver for some app, 
> listening on a port above 1024, for example. if someone 
> hacked a web client to use port 80 as the source port for 
> it's connections,  (dunno, would you have to hack the kernel 
> too, or just be root?) , then they could bypass the firewall 
> part of the security, right? or with ssh, surely it would be 
> easy enough to hack an ssh client to use port 80 as it's source port.
> ok, so you probably shouldn't run an ssh listener on a port 
> above 1024, but nevertheless, it's a good hole to close.
> 
> thanks!
> 
> Keith.

Once someone has rooted your machine, local firewalls and whatever else
are meaningless. Let's say though that only the service (Apache for
example) was compromised: You still have a legitimate service running,
accepting connections from port 80 (which by the way, is how the exploit
would have been launched in the first place) and sending information
back out on unprivileged ports. The result is the same, you can't block
the bad traffic with a firewall unless it's doing content inspection.

Derick Anderson

Re: coming in through the outgoing hole?

[Keith Whyte]

Derick Anderson wrote:

>>INPUT
>>0     0 ACCEPT     tcp  --  eth0   any     anywhere
>>anywhere           tcp spt:http dpts:1024:65535
>>OUTPUT
>>0    0 ACCEPT     tcp  --  any    eth0    anywhere
>>anywhere           tcp spts:1024:65535 dpt:http
>>    
>>
>
>You don't need the 1024:65535 bit in either rule once you use connection
>tracking. If you're trying to restrict this particular machine from
>connecting to web servers using a source port below 1024, this is
>already done for you unless the user is root.
>
no, i am trying to prevent a remote root user from making a connection 
to my machine.

> If the user is root, then
>OUTPUT filtering is meaningless (more so than if the user is not, which
>is still quite a bit). Your OUTPUT filtering should really be egress
>filtering in the FORWARD chain of your firewall. Hopefully you aren't
>web surfing with your firewall.
>
>Stick around and I'm sure someone else will mention the general
>pointlessness of OUTPUT filtering.
>
>  
>
I should have made it more clear in my original post. The machine in 
this scenario is neither a firewall, nor a workstation. It's a server, a 
co-located remote machine. As such it is a kind of a workstation, or a 
potential workstation.

 That doesn't take away from your agrument that OUTPUT filtering is 
pointless, but in this case, I decided to implement some OUTPUT 
filtering to be sure and avoid users (non-root of course) from using a 
shell account (or their php-enabled web account) to access certain services.

Thanks very much for the rest of your response, and I think it answers 
more or less my question about using conntrack, but to try and make it 
more clear, the situation I wanted to avoid is the initiation of a 
connection, from source port 80 (by root, of course) to port 7775 on the 
server machine. With the current rules this would pass the firewall.

>iptables -A OUTPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
>
>What happens is the first packet goes out (in the NEW state, you could
>get even more restrictive and use the '--syn' or '--tcp-flags
>SYN,RST,ACK SYN' to make sure it's a SYN packet) on port 80 and hits the
>remote server. The return packet (now ESTABLISHED) hits the ESTABLISHED
>match at the top of your INPUT ruleset there and goes on its merry way.
>The next packet out from the machine (also ESTABLISHED) hits the
>ESTABLISHED match in the OUTPUT chain and is accepted as well.
>Everything else that happens until the connection is closed goes through
>the RELATED,ESTABLISHED rules and not through the '--dport 80' rule.
>
>  
>
I'm also using the rules for traffic counters, so I don't want to do 
that, but yes, it would simplify things as lot.


>>as a hypothetical example of the problem:
>>let's say i run an admin type webserver for some app, 
>>listening on a port above 1024, for example. if someone 
>>hacked a web client to use port 80 as the source port for 
>>it's connections,  (dunno, would you have to hack the kernel 
>>too, or just be root?) , then they could bypass the firewall 
>>part of the security, right? or with ssh, surely it would be 
>>easy enough to hack an ssh client to use port 80 as it's source port.
>>ok, so you probably shouldn't run an ssh listener on a port 
>>above 1024, but nevertheless, it's a good hole to close.
>>
>>thanks!
>>
>>Keith.
>>    
>>
>
>Once someone has rooted your machine, local firewalls and whatever else
>are meaningless. Let's say though that only the service (Apache for
>example) was compromised: You still have a legitimate service running,
>accepting connections from port 80 (which by the way, is how the exploit
>would have been launched in the first place) and sending information
>back out on unprivileged ports. The result is the same, you can't block
>the bad traffic with a firewall unless it's doing content inspection.
>
>  
>
That's totally understood, I wasn't in anyway trying to use netfilter to 
protect the box from somebody who already has root!
I am trying to protect it from root user on a remote attacker machine, I 
was referring to that remote machine when I mentioned a potential web 
client making connections from port 80.

Keith

RE: coming in through the outgoing hole?

[Derick Anderson]

Inline... 

> -----Original Message-----
> From: Keith Whyte [mailto:keith@media-solutions.ie] 
> Sent: Monday, November 21, 2005 2:42 PM
> To: Derick Anderson; netfilter@lists.netfilter.org
> Subject: Re: coming in through the outgoing hole?
> 
> Derick Anderson wrote:
> 
> >>INPUT
> >>0     0 ACCEPT     tcp  --  eth0   any     anywhere
> >>anywhere           tcp spt:http dpts:1024:65535
> >>OUTPUT
> >>0    0 ACCEPT     tcp  --  any    eth0    anywhere
> >>anywhere           tcp spts:1024:65535 dpt:http
> >>    
> >>
> >
> >You don't need the 1024:65535 bit in either rule once you use 
> >connection tracking. If you're trying to restrict this particular 
> >machine from connecting to web servers using a source port 
> below 1024, 
> >this is already done for you unless the user is root.
> >
> no, i am trying to prevent a remote root user from making a 
> connection to my machine.

OK, this makes sense. 

> > If the user is root, then
> >OUTPUT filtering is meaningless (more so than if the user is 
> not, which 
> >is still quite a bit). Your OUTPUT filtering should really be egress 
> >filtering in the FORWARD chain of your firewall. Hopefully 
> you aren't 
> >web surfing with your firewall.
> >
> >Stick around and I'm sure someone else will mention the general 
> >pointlessness of OUTPUT filtering.
> >
> >  
> >
> I should have made it more clear in my original post. The 
> machine in this scenario is neither a firewall, nor a 
> workstation. It's a server, a co-located remote machine. As 
> such it is a kind of a workstation, or a potential workstation.
> 
>  That doesn't take away from your agrument that OUTPUT 
> filtering is pointless, but in this case, I decided to 
> implement some OUTPUT filtering to be sure and avoid users 
> (non-root of course) from using a shell account (or their 
> php-enabled web account) to access certain services.
> 
> Thanks very much for the rest of your response, and I think 
> it answers more or less my question about using conntrack, 
> but to try and make it more clear, the situation I wanted to 
> avoid is the initiation of a connection, from source port 80 
> (by root, of course) to port 7775 on the server machine. With 
> the current rules this would pass the firewall.

Yes, and this can be mitigated by using conntrack and only allowing
--dport 80 inbound to the server, along with RELATED and ESTABLISHED
connections to keep things running. This way only port 80 is open on
your server. Your server can respond on a higher port but wouldn't be
able to initiate a connection on that port (a compromise would have to
reverse-tunnel over the existing connection).

> >iptables -A OUTPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
> >
> >What happens is the first packet goes out (in the NEW state, 
> you could 
> >get even more restrictive and use the '--syn' or '--tcp-flags 
> >SYN,RST,ACK SYN' to make sure it's a SYN packet) on port 80 and hits 
> >the remote server. The return packet (now ESTABLISHED) hits the 
> >ESTABLISHED match at the top of your INPUT ruleset there and 
> goes on its merry way.
> >The next packet out from the machine (also ESTABLISHED) hits the 
> >ESTABLISHED match in the OUTPUT chain and is accepted as well.
> >Everything else that happens until the connection is closed goes 
> >through the RELATED,ESTABLISHED rules and not through the 
> '--dport 80' rule.
> >
> >  
> >
> I'm also using the rules for traffic counters, so I don't 
> want to do that, but yes, it would simplify things as lot.

If you want traffic counters you can always put rules above these with
no -j ACCEPT at the end. The rules will in effect do nothing other than
show up in an iptables -vnL. This way you keep the integrity of your
firewall and still get the traffic counted. 
 
> >>as a hypothetical example of the problem:
> >>let's say i run an admin type webserver for some app, 
> >>listening on a port above 1024, for example. if someone 
> >>hacked a web client to use port 80 as the source port for 
> >>it's connections,  (dunno, would you have to hack the kernel 
> >>too, or just be root?) , then they could bypass the firewall 
> >>part of the security, right? or with ssh, surely it would be 
> >>easy enough to hack an ssh client to use port 80 as it's 
> source port.
> >>ok, so you probably shouldn't run an ssh listener on a port 
> >>above 1024, but nevertheless, it's a good hole to close.
> >>
> >>thanks!
> >>
> >>Keith.
> >>    
> >>
> >
> >Once someone has rooted your machine, local firewalls and 
> whatever else
> >are meaningless. Let's say though that only the service (Apache for
> >example) was compromised: You still have a legitimate 
> service running,
> >accepting connections from port 80 (which by the way, is how 
> the exploit
> >would have been launched in the first place) and sending information
> >back out on unprivileged ports. The result is the same, you 
> can't block
> >the bad traffic with a firewall unless it's doing content inspection.
> >
> >  
> >
> That's totally understood, I wasn't in anyway trying to use 
> netfilter to 
> protect the box from somebody who already has root!
> I am trying to protect it from root user on a remote attacker 
> machine, I 
> was referring to that remote machine when I mentioned a potential web 
> client making connections from port 80.
> 
> Keith

Understood and glad to help out some.

Derick Anderson

Re: coming in through the outgoing hole?

[/dev/rob0]

On Monday 2005-November-21 13:41, Keith Whyte wrote:
> Derick Anderson wrote:
> >>INPUT
> >>0     0 ACCEPT     tcp  --  eth0   any     anywhere
> >>anywhere           tcp spt:http dpts:1024:65535
> >>OUTPUT
> >>0    0 ACCEPT     tcp  --  any    eth0    anywhere
> >>anywhere           tcp spts:1024:65535 dpt:http
> >
> >You don't need the 1024:65535 bit in either rule once you use
> > connection tracking. If you're trying to restrict this particular
> > machine from connecting to web servers using a source port below
> > 1024, this is already done for you unless the user is root.
>
> no, i am trying to prevent a remote root user from making a
> connection to my machine.

I don't see the value in this, myself. Whilst it certainly would seem 
odd to have a privileged port on the client end of your httpd, how is 
that a threat to you?

> > If the user is root, then
> >OUTPUT filtering is meaningless (more so than if the user is not,
> > which is still quite a bit). Your OUTPUT filtering should really be
> > egress filtering in the FORWARD chain of your firewall. Hopefully
> > you aren't web surfing with your firewall.
> >
> >Stick around and I'm sure someone else will mention the general
> >pointlessness of OUTPUT filtering.

Usually that would be me, but I think Derick did a fine job of it. :)

> I should have made it more clear in my original post. The machine in
> this scenario is neither a firewall, nor a workstation. It's a
> server, a co-located remote machine. As such it is a kind of a
> workstation, or a potential workstation.
>
>  That doesn't take away from your agrument that OUTPUT filtering is
> pointless, but in this case, I decided to implement some OUTPUT
> filtering to be sure and avoid users (non-root of course) from using
> a shell account (or their php-enabled web account) to access certain
> services.

Sometimes, I will admit, targeted OUTPUT filtering makes sense. But to 
rein in shell users, I am not sure. If you cannot trust these users to 
abide by your ToS and AUP, you don't want them in on shell accounts. :) 
Well, *I* wouldn't. I'd worry about them trying to root me.

> Thanks very much for the rest of your response, and I think it
> answers more or less my question about using conntrack, but to try
> and make it more clear, the situation I wanted to avoid is the
> initiation of a connection, from source port 80 (by root, of course)
> to port 7775 on the server machine. With the current rules this would
> pass the firewall.
>
> >iptables -A OUTPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
> >
> >What happens is the first packet goes out (in the NEW state, you
> > could get even more restrictive and use the '--syn' or '--tcp-flags
> > SYN,RST,ACK SYN' to make sure it's a SYN packet) on port 80 and
> > hits the remote server. The return packet (now ESTABLISHED) hits
> > the ESTABLISHED match at the top of your INPUT ruleset there and
> > goes on its merry way. The next packet out from the machine (also
> > ESTABLISHED) hits the ESTABLISHED match in the OUTPUT chain and is
> > accepted as well. Everything else that happens until the connection
> > is closed goes through the RELATED,ESTABLISHED rules and not
> > through the '--dport 80' rule.
>
> I'm also using the rules for traffic counters, so I don't want to do
> that, but yes, it would simplify things as lot.

I'm not sure what you mean, but I think I have a good suggestion 
nonetheless. :) Put your --state RELATED,ESTABLISHED rule in a chain 
all by itself, and call that as a target after your counter rules.

> >>as a hypothetical example of the problem:
snip
> That's totally understood, I wasn't in anyway trying to use netfilter
> to protect the box from somebody who already has root!
> I am trying to protect it from root user on a remote attacker
> machine, I was referring to that remote machine when I mentioned a
> potential web client making connections from port 80.

Again, I am not understanding the threat. If you're running services 
like file sharing, I can see where the presence of a hostile root user 
behind your firewall might be cause for worry. But I guess you have 
some other reason for worry ...
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: coming in through the outgoing hole?

[Keith Whyte]

/dev/rob0 wrote:

> no, i am trying to prevent a remote root user from making a
> connection to my machine.


>I don't see the value in this, myself. Whilst it certainly would seem 
>odd to have a privileged port on the client end of your httpd, how is 
>that a threat to you?
>
>  
>
1. i have a web based admin service running on port 7775, (for example)
2. I want to use iptables to restrict access to this web based admin 
service to certain hosts.
3. but i have added rules to iptables to allow outgoing web traffic by 
allowing all outgoing tcp packets to port 80 from ports > 1024
4. i have also added a rule to allow incoming tcp packets from port 80 
to ports > 1024
5. If a packet arrives from port 80 to port 7775 it gets through, that 
is (was) the threat, but using conntrack is better, my approach using 
ports was flawed.

>Sometimes, I will admit, targeted OUTPUT filtering makes sense. But to 
>rein in shell users, I am not sure. If you cannot trust these users to 
>abide by your ToS and AUP, you don't want them in on shell accounts. :) 
>
>  
>
and their php enabled web account? it should be locked down by other 
methods, i imagine you say.. but we irish like to be sure, to be sure, 
to be sure....

>>I'm also using the rules for traffic counters, so I don't want to do
>>that, but yes, it would simplify things as lot.
>>    
>>
>
>I'm not sure what you mean, but I think I have a good suggestion 
>nonetheless. :) Put your --state RELATED,ESTABLISHED rule in a chain 
>all by itself, and call that as a target after your counter rules.
>
>  
>
Derick suggested using one rule to allow related, established.. i was 
just pointing out that then i wouldn't have the traffic information 
divided by service.. but that's easily enabled again, like either you or 
Derick said.

>like file sharing, I can see where the presence of a hostile root user 
>behind your firewall might be cause for worry. But I guess you have 
>
>  
>
he he, seems like everyone here is thinking in terms of firewalls.. This 
is a co-lo box 100% exposed on the internet. there's no firewall to be 
behind. every other host on the entire internet is a potential hostile 
root user!

I want iptables to reject as much as is possible at the INPUT stage.

thanks!