Re: Firewall software.

From: Rick Moen (rick_at_linuxmafia.com)
Date: 09/29/05 

Date: Wed, 28 Sep 2005 21:43:14 -0400

[Distribution snipped in followups.]

In comp.os.linux.setup TLOlczyk <olczyk2002@yahoo.com> wrote:

(You're deploying a Linux box for the first time, and want IP/port filtering.)

> Now the first thing, I want to clarify what I mean by firewall, since
> it seems that the way the term is used in the Windows world and
> the networking world in general is different.

Indeed.

> From what I've seen there appears to be only one true software
> firewall for Linux: ipchains.

As others have said, that's the old one, now somewhat obsolete. The
current implentation is iptables / netfilter: packet filtering at the
IP/port level, IP & port translation (NAT, implemented as "IP
Maquerading" -- which isn't useful in your context), and "other packet
mangling".

> 1) Dynamic control of ports.
> By this I mean that I want to be able to open or close a port
> without haviing to reboot or restart a daemon.

No sweat.

> 2) Control of both incoming and outgoing packets.

Ditto.

> 3) Application specific control.

And this one generally isn't done. When I encountered this during my
infrequent forays into the MS-Windows world, it was originally really
confusing, until I got my mind around the concept. I'd speculate that,
maybe, the reason it's not really part of the security smorgasbord on
Unix is that (1) the Unix world prefers to have clean abstraction layers
between levels of software. Having specific hooks from the application
to transport layers would be messy. (2) There isn't a history of rogue
applications that need to be coralled. (3) The Unix world tends to look
upon network services that don't have well-defined, fixed port
assignments (and that aren't thus easily controlled by port number) with
suspicion. E.g., NIS and NFS both rest on the Sun-invented RPC
portmapper, _but_ they're widely regarded as a security nightmare and to
be avoided where possible. That's in marked contrast to the NT/W2K/XP
system model, which uses RPC-based services with wild abandon, which in
turn has been its downfall in numerous "worm" outbreaks.

(4) Relevant to that point, if a port used by application A should be
blocked, then why shouldn't it be likewise blocked if addressed by
similar application B? The assumption behind that question, of course,
is that ports that have security ramifications will have standard
identity assignments, and that the convention that TCP/UDP ports under
1024 will be privileged. Those assumptions hold on (uncompromised) Unix
systems, but not on MS-Windows ones.

If I'm completely off-base or are missing something important, I hope
and trust that others will step in to address the matter. 

-- 
Cheers,             
Rick Moen                 Support your local medical examiner:  Die strangely.
rick@linuxmafia.com