Re: home firewall philosophy govering outgoing traffic
On Saturday 16 June 2001 14:07, Filip Van Raemdonck wrote:
> On Fri, Jun 15, 2001 at 07:19:29PM +0100, Robert Davies wrote:
> > On Friday 15 June 2001 17:56, Eric N. Valor wrote:
> > > At 07:03 AM 6/15/2001 -0500, Bryan Walton wrote:
> > >
> > > For instance, I
> > > had a user-administered system sitting outside our firewall come up
> > > with an
> > > IRC robot due to a DNS-based crack.
> > >
> > >
> > > However, if I'd suddenly seen
> > > port 6667 traffic trying to leave the system (the usual IRC port) I'd
> > > have
> > > known something funny was going on. Only after the box was turned into
> > > skript-kiddie scanner and I received a few polite notifications did I
> > > realize there was a problem and take steps to rectify.
>
> <snip>
>
> > > Yes, having a default DENY on the output chain is a bit more work, but
> > > it also allows you to do a daily audit of possible problems. It all
> > > depends on your determined security stance.
> >
> > So are my assumptions innacurate? If not what real benefit does a policy
> > of deny on the output chain have for a home system (not commercial
> > firewall installation)?
>
> Just reread his explanation.
>
> If someone is able to get a program on a system inside your home network,
> they can have that initiate the connection and work from there. No incoming
> connections needed.
> Most common case are script kiddies with scanners or ddos trojans; they
> (usually) use an irc server to `command' their army.
But can't they just try to use a connection which you permit, to port 80 for
instance to make it look like HTTP, or use DNS port 53. I think you're
'hoping' they'll use a non-stealthy port, like an IRC DCC connection on the
default port for controlling something like an eggdrop bot, on ports you
don't usually use.
I see the point where you have lax input rules (and to allow all incoming is
too lax to protect againt the example you've made), but the output chains
are forced to be pretty liberal, as soon as you offer any tcp service from
your network, including active ftp. The connection you suggest is not one
way, but two way, so you can block the return packets, with source ports that
you don't want to be connected to (ie. you don't open them up for anything
but what you want to support). Then the 3-way handshake of the mooted tcp
connection fails, just as surely as if you blocked the output packet, and I
guess you can log that initial connection packet as suggested by others. It
still seems like a duplication of effort, to me.
What you're really showing here is that allowing Masquerading or Forwarding
(if you use assigned IPs, rather than private) and relying on packet
filtering is less secure than not permitting it at all, and using an
applicaton gateway eg) proxy.
Rob
Reply to: