Mailinglist Archive: opensuse-security (423 mails)

["Reckhard, Tobias" <Reckhard@xxxxxxxxxx>]

Re Daniel.

>     yes, your are right! getting compromised by a
>     client applications isn't good indeed...;-)
> 
It sure ain't. :-)

>     but that wasn't my hint about this topic.
>     my idea is to separate your system into two
>     ones:
>     first you have a hardened firewall-system without
>     any programm running on it.
>     second there is a proxy-server behind the wall with
>     "your" application proxies.
> 
So you mean a pure packet filter when you say 'hardened firewall-system'? I
call that a packet filter. :-)  Yes, it generally makes sense to have a
packet filter as the point of entry to your network. However, there are a
couple of possible architectures. Quoting from the book I named:
1. Single-box architectures: screening router, dual-homed host.
2. Screened host architectures
3. Screened subnet architectures
4. Architectures with multiple screened subnets: split-screened subnet,
independent screened subnet
5. Variations on firewall architectures

If what you're proposing is a packet filter up front and a proxy in the
internal network, then you have a screened host architecture. A screened
subnet architecture, in which the screened subnet is referred to as a DMZ,
is more common in the corporate world. Most Linux home users use a single
box, either as a screening router (if they only use ipchains) or, if they're
running (some) proxies on the box, as something you could term a hybrid
between a screening router and a dual-homed host, or a collapsed DMZ. The
latter is the setup described by the initiator of this thread. It is stupid,
yes, not to perform packet filtering on a proxy that is part of a firewall
system, if you can.

However, of course you'll have programs running on the packet filter as
well. First, there's the kernel. Then you've probably got syslogd and crond
running. Unless you're performing administration from the console only,
you'll probably have sshd running.

Cheers,
Tobias