Re: Acqusition of time

[Brian Ford <brford () cisco com>]

Paul,

You make a couple of good points.

If a security device uses network time and can't set the clock there needs 
to be a capability to drop the Firewall into a blocking mode.  It's the 
same as the capability that if the device can't write to the log it should 
go into blocking mode.   If you must have an accurate audit capability you 
have to be able to put coherent time stamps on packets and be sure that 
they are acknowledged by the log server device.

Liberty for All,

Brian

At 06:04 PM 1/29/2003 -0500, firewall-wizards-request () honor icsalabs com wrote:
> Date: Wed, 29 Jan 2003 12:29:56 -0500 (EST)
> From: "Paul D. Robertson" <proberts () patriot net>
> To: Brian Monkman <bmonkman () comcast net>
> Cc: <firewall-wizards () honor icsalabs com>
> Subject: Re: RE: [fw-wiz] Acqusition of time
>
> On Wed, 29 Jan 2003, Brian Monkman wrote:
>
> > Ok - so something more specific this time.
> >
> > We are talking about a firewall farm. We want the time to be sync'ed
> > between all of the firewalls. Logs go to a central logging server.
> > Reason for the sync'ing, to ensure that time is accurate across all of
> > the firewalls in order to facilitate forensics and event correlation.
> >
> > In your opinion - should we have a battery backed-up clock on these
> > firewalls or is the network time source sufficient?
>
> If the criterion is that the firewalls be synchronized to some standard,
> then I suppose the real issue is what happens if a single firewall is
> rebooted and unable to reach either the time server or the logging server
> (if it's syslog, you don't even know you didn't get there?)
>
> (UDP-based syslogs were heavily affected by SQL-Slammer for instance.)
>
> Battery back-up helps for the reboot instance, and (potentially, though
> not normally) for the timeserver goes down instance.  If there's defined
> behaviour for "system rebooted and couldn't reach the timeserver" and it's
> materially seperable from "just after midnight," then I don't suppose
> there's much of an issue, you can put things back together by deltaing
> once you do get reliable time information.
>
> Paul
> -----------------------------------------------------------------------------
> Paul D. Robertson      "My statements in this message are personal opinions
> proberts () patriot net      which may have no basis whatsoever in fact."
> probertson () trusecure com Director of Risk Assessment TruSecure Corporation


Brian Ford
Consulting Engineer
Corporate Consulting Engineering, Office of the Chief Technology Officer
Cisco Systems, Inc.
http://www.cisco.com
e-mail: brford () cisco com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards