Re: coming in through the outgoing hole?

[Keith Whyte <keith@media-solutions.ie>]

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