Re: Building a bastion host using Debian.
From---->Henry Hollenberg speed@barney.iamerica.net
On Mon, 23 Feb 1998, Hubert Weikert wrote:
> On Sun, 22 Feb 1998, Henry Hollenberg wrote:
> > > 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.
>
> Agreed. But, what about router, dual-homed bastion, router?
> A screned subnet has the disadvantage, that both types of traffic
> (internal and external) runs over the same cable. We have some trouble on
> a 10 MBit Ethernet to feed a 2 Mbit/s internet connection.
>
> But, how do you want to communicate between bastion and an internal host
> if your internal router does not allow packets from bastion to go in?
> And: the internal router should only trust the bastion, no other external
> ip-address should be allowed to come in. The exterior router must not
> allow any packet to go thru (both directions) with ip numbers (sender or
> receiver) from the internal net. All externenal connections must be feeded
> thru the bastion, prefered a dual homed bastion. This may be maximum
> security.
For some purposes letting certain types of packets thru is "OK" at least
according to my O'reilly book. That is telnet out requires you allow ACK
telnet packets in, same with passive ftp. They consider this OK.
Incoming telnet would be disallowed. incomming http requests would be
allowed thru the outer router but not the inner router....
I'll write up the detailed policy and rules and email it to you....I'm not
sure the rest of the developers list is intrested though.....maybe all
that is appropriate for the list is the discussion regarding setting up
the base bastion host system. What do you think?
>
> > However for less stringent security requirements a dual-homed host is a
> > great idea.
>
> See above.
>
> > Either way, starting out with a stripped down clean system is desirable
> > for any of these systems.
>
> Agreed.
> I will send you comments about your package list for stripped down system.
great!
>
> > 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?
>
> One solution may be ssyslogd, a cryptographic secured syslogd. You are
> able to detect a manipulation on the log. The URL is
> http://www.core-sdi.com/ssyslog/
Cryptographic is good....but if they get root access couldn't they just
erase the files? The O'reilly folks had problems with logging over the
network also, since the usual method (UDP) is "unreliable" and the logs
are CRUCIAL!!!
>
> > 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.
>
> One proxy-firewall with 1000 Users could produce about 80 Meg of
> syslog-logs per day. How about an real-time analysis of the logs? One tool
> for this could be logsurfer:
> ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer
> Logsurfer could page you, if you want ;-)
>
That sounds like a big plus.
> 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: