Inline... > -----Original Message----- > From: Keith Whyte [mailto:keith@xxxxxxxxxxxxxxxxxx] > Sent: Monday, November 21, 2005 2:42 PM > To: Derick Anderson; netfilter@xxxxxxxxxxxxxxxxxxx > 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
