Re: Building a bastion host using Debian.
Henry Hollenberg speed@barney.iamerica.net
On Sun, 22 Feb 1998, Hubert Weikert wrote:
> On Sun, 22 Feb 1998, Henry Hollenberg wrote:
> > On 22 Feb 1998, Christian Leutloff wrote:
> > > Henry Hollenberg <speed@barney.iamerica.net> writes:
> > > > Has anyone written up a howto for stripping down a Debian system for
> > > > service as a bastion host?
> > > A firewall out of the box - great!!!!
> > A good start at one anyway.
>
> There is no HOWTO, which could seriously be called a FW-HOWTO.
> I like your concept very much, I am thinking about it since mid of 1997.
> But, there's no time to do it ;-)
>
> > If Debian folks felt like adding this information into an optional field
> > in there excellent pkg descriptor database....then alot of the setup of a
> > bastion host could be "automated". That is a partially stripped system
> > could be an installation option and the "firewall builder" could go
> > straight to work on setting up packet filters, and bastion services. Then
> > when things look good, they could invoke a purge that resulted in a fully
> > stripped system, removing the build tools.
>
> My concept looked like a super-package, with conflicts for packages to
> remove, and an override for the to be changed configuration files. I am
> not familiar enough with the details of packaging system to be sure that
> this is the right way to do it.
>
> > > > Firewall Architecture = screened subnet:
> > > You mean something like that:
> > >
> > > bastion
> > > |
> > > |
> > > internet - paket filter A ----------- paket filter B - LAN
> > >
> > Exactly.
>
> I would prefer a IMHO better configuration. Please make the bastion host
> dual homed. You could be able to use kernel packet filters, an the
> firewall modules. In addition this system does not need additional
> routers, and you could use masquerading (aka NAT, Network Address
> Translation).
The screened subnet architecture that I choose for our site as above is
the reccomended one for maximum security in the O'reilly book....it sets
up multiple "independent" layers of protection that have to be penetrated
to get to your internal network. That is the internal router (paket
filter B) does not trust the bastion or paket filter A so they can't be
used as they stand to penetrate the internal network....the hacker has to
beat all layers independently to gain access.
However for less stringent security requirements a dual-homed host is a
great idea.
Either way, starting out with a stripped down clean system is desirable
for any of these systems.
>
> > > The most difficult part is to make the setting of the filtering rules
> > > foolproof. This configuration should be made with the framework COAS
> > > provides.
>
> I saw a (browser based) tool to do it at
> http://www.fen.baynet.de/~ft114/FCT/firewall.htm
> It's impressive, the developer has preconfigured rules for nearly all
> services. He's missing real application proxies, but you should find
> filtering rules nearly for all protocols. This tool is IMHO a very good
> base to start with, and it should be ported to other management
> platforms (e.g. COAS).
>
> Another new feature I would to see in a firewall is the extension/rewrite
> of kernel-fw-code and a replacement for ipfwadm. See the page at
> http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html
> for informations about ipfw-chains.
>
> Another functionality for a firewall is the support for crypted VPN's, and
> the ability to support Mobile-IP.
>
> I think the best way could be to start with a firewall base system, which
> supports some topologies (like the proposed screened subnet and a dual
> home single box system for the beginning).
Exactly where I was headed.....got to walk before we can run.
> Based on this we could add
> additional modules like
> - VPN's,
> - several functions like transparent proxies,
> - remote, possibly centralized management and monitoring,
> - accounting systems based on fw-logs
> - user based authetication (S/Key or OPIE, other third party systems)
> - virus checking
> - blocking of unwanted contens, like SPAM or ActiveX/Java
> and so on.
Sounds intresting.... one more thing I would add is bomb-proof
logs....the first thing the hackers gonna do when they break in is erase
your logs....and according to "the experts" no matter how hard you try
they are going to get in. So, it's essential to preserve those logs so
that you can figure out:
1) how they got in....and plug that hole.
2) what damage has been done....have they broken into your internal
network?....used your system to launch attacks on others?
The best idea I've heard for this is a "drop-safe" system....a system
that is not on the network and listens to logging only from your bastion
and paket filters via serial connection. This system must be stripped
down too and allow no logins other than the console....that is no way in
thru the serial connection (ie don't use ppp). That way even if they
break in to everything your logs are preserved. This system could record
the logging data to hard disk, Zip drive, CDR, whatever....as long as they
can't get on the system the data should be safe.
>
> My main problem ist how this could be incorporated in the debian packaging
> system. The changes (only if really needed) should be minimal, prefered
> none.
It probably wouldn't have to be, just a thought.
>
> Regards,
> Hubert
>
> ------------------------------------------------------------------------------
> Hubert Weikert DB1MQ Member of DARC (www.darc.de) and FITUG (www.fitug.de)
> Email: weikert@cube.net weikert@compuserve.com http://www.cube.net/~weikert/
> Book: Kryptographie mit dem Computer (PGP Praxis) ISBN 3-7905-1503-5 DM 19,80
> Key = 21978C61 fingerprint = 99 38 A5 83 C8 76 F4 E1 A7 9C B9 70 9A A7 70 10
>
>
>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: