Subject: Re: Securing NetBSD
To: None <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 02/28/2001 19:46:35
In message <20010228183137.A2007@rek.tjls.com>, Thor Lancelot Simon writes:
>On Wed, Feb 28, 2001 at 06:15:07PM +0100, email@example.com wrote:
>> > > since this is going to be a firewall. And of course don't give out
>> > > user accounts on your firewall. After that you should be set.
>> > I wouldn't even enable ssh. If it's a firewall, the only way to get to it
>> > should be via the console. Opening it up to any form of remote access
>> > gives rise to the possibility of something, somehow gaining access and
>> > comprimising the security of any networks or hosts involved.
>> > Just my $0.02
>> ssh is no problem. only access to firewall machine should be enabled only
>> for trusted machines
>Nonsense. Plenty of people who configure firewalls for a living consider
>any network login access to the firewall box, wherever from, to be a problem.
>Maybe that's not good advice _for you_, but it's absurd to suggest that your
>own advice applies to the general case -- there just about *is* no "general
>case" in firewall security.
The general case is "understand whwat your requirements are". For
corporate production systems, remote access generally is a requirement.
It's not always stated, which in practice tends to mean that *when*
(not "if") an emergency hits, someone deploys some quick-and-dirty ad
hoc solution that isn't secure.
Put another way, if something breaks on the firewall, can you afford to
be offline until a competent wizard can get there physically? For
corporate firewalls, the answer is almost certainly "no". That may be
the case for home firewalls, too, if there are other folks at home who
ssh isn't risk-free -- nothing is -- but it's a plausible approach.
IPsec might be another, though that's problematic from, say, hotel room
Ethernets that live behind NAT boxes.
--Steve Bellovin, http://www.research.att.com/~smb