In message <20010228183137.A2007@rek.tjls.com>, Thor Lancelot Simon writes:
>On Wed, Feb 28, 2001 at 06:15:07PM +0100, wojtek@wojtek.from.pl 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 
aren't wizard-rated.

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