[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    RE: Remote management of firewalls internationally
From:       "McMahan, Peg" <PMcMahan () v-one ! com>
Date:       1997-07-02 15:53:58
[Download RAW message or body]

Simple solution: If remote administration is a necessary component, buy
a firewall that has the functionality to it. One has to understand,
however, that there is always the possibility of problems that
absolutely require a user at the console. If considerations aren't made
for incidences in which user intervention is required, then you have to
rethink things.

It's all well and good to have remote admin, it's a nice feature....
however it is silly to think that you can rely on it in all situations. 

Adam, you make a good point. 

Our support staff has been receiving a good number of calls lately from
people whose firewalls got messed up during recent severe storms... It's
no fun explaining to a person that they can't reach their firewall
remotely if it's sitting in a closet in a remote location, at a single
user prompt needing to be fsck'd because the UPS didn't last as long as
the power outage did.

> -----Original Message-----
> From:	Adam Shostack [SMTP:adam@homeport.org]
> Sent:	Wednesday, July 02, 1997 7:18 AM
> To:	bonomi@delta.ece.nwu.edu
> Cc:	firewalls@GreatCircle.COM
> Subject:	Re: Remote management of firewalls internationally
> 
> Robert Bonomi wrote:
> 
> | Or, if you can't change configuration without taking it down to
> | 'single user'? 
> 
> | A solution:
> | 
> | This takes -two- firewall machines, and a 'secure server' behind
> each one.
> | you run a secure, encrypted, channel from the management location to
> either
> | 'secure server', as needed.  The 'secure server' connects, via
> _serial_ port,
> | to the *other* firewall box's console port.
> 
> 	And when both machines foobar due to AC failing, followed by
> power failing?  Can you accept 24 hours of downtime?  And UPSs fail as
> well.  Remember what happened to BBNPlanet's Stanford facility.
> | 
> | A less expensive solution is to have someone _local_,
> _who_speaks_the_same_
> | _language_ (*fluently*!) as support -staff-, who can be called on to
> play
> | "voice actuated terminal", for those occasions where 'secure remote
> access
> | _through_ the box' fails.   This person merely needs the ability to
> follow 
> | directions _precisely_, and observe and report *accurately*. The
> risk here
> | is mostly an added exposure to a 'social engineering' attack.
> 
> 	But you also have someone who can go by to check on the
> physical security and integrity of your location.  I would not run a
> firewall without a unix sysadmin type with a few brain cells within a
> reasonable transit distance.  If you've got office space in the area,
> you've got people.  If you don't have office space in the area, why
> are you deploying security tools there?
> 
> Adam
> 
> -- 
> "It is seldom that liberty of any kind is lost all at once."
> 					               -Hume
> 

[prev in list] [next in list] [prev in thread] [next in thread]