Bugtraq mailing list archives

By Date

By Thread

Re: TCP Timestamping and Remotely gathering uptime information

On Sat, 17 Mar 2001, Darren Reed wrote:

In some mail from Bill_Royds () pch gc ca, sie said:

Actually, the logic is "This has been up for 300 days. It probably is not
being maintained so it likely has that unpatched exploit avaialable".

I thought about this before I posted that email but decided against any
inclusion of it.  Why ?

There are systems running around the world, today, that *need* to run
24x7 and security patches are no reason for a reboot.  That aside, that
a system has been up, since its release, longer than it takes the time
information to wrap, do you *really* know how long it has been up ?

So if a system can't be brought down for a reboot what do you do in case
of a system failure. Be it hardware or software you have a problem way
beyond a reboot.

If anything is that mission critical you should make it redundant.

In the past our company used to accept a no-reboot-now policy by the
customer. However we stopped to do this because any mission critical
system must be made redundant. So we can reboot a firewall at 17:00 if we
need to install security fixes.

we usually don't need to play it hard. But if a 5 minute interruption is
unacceptable you should make things redundant because hardware will
breakdown when it is extremely inconvinient.

Hugo.

--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ  Maasland
hugo () vanderkooij org         http://hvdkooij.xs4all.nl/
--------------------------------------------------------------

By Date

By Thread

Current thread:

• Re: TCP Timestamping and Remotely gathering uptime information, (continued)
• • • • Re: TCP Timestamping and Remotely gathering uptime information arivanov (Mar 19)
    • Re: TCP Timestamping and Remotely gathering uptime information Stephen White (Mar 19)
      • Re: TCP Timestamping and Remotely gathering uptime information bert hubert (Mar 20)
      • Remote fingerprinting/uptime (was Re: TCP Timestamping ...) Darren Reed (Mar 20)
      • Re: Remote fingerprinting/uptime (was Re: TCP Timestamping ...) Jason R Thorpe (Mar 22)
  • Re: TCP Timestamping and Remotely gathering uptime information Chris Tobkin (Mar 19)
  • Re: TCP Timestamping and Remotely gathering uptime information Ted U (Mar 19)
  • Re: TCP Timestamping and Remotely gathering uptime information Matt Lewis (Mar 19)
    • Re: TCP Timestamping and Remotely gathering uptime information Theo de Raadt (Mar 20)
  • Re: TCP Timestamping and Remotely gathering uptime information Darren Reed (Mar 19)
    • Re: TCP Timestamping and Remotely gathering uptime information van der Kooij, Hugo (Mar 20)