[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

RE: Proposal: Inhibit "console down"

Harris, David (IT Solutions US) david.k.harris@siemens.com
Fri, 7 Sep 2007 09:51:20 -0700 (PDT)

  First, my hat is off to Greg, for many years of support, discussion,
and code contributions to Conserver. 

  I understand Greg's security perspective, but I feel moved to discuss
cases where turning off logging, or being able to 'down' a console have
been useful and necessary. My intent is only to present the cases,
without trying to lobby for the preservation of the features, and then
see what discussion may evolve from the group. :-)

  STOP LOGGING: I will suggest that, as an net admin, that it is far
easier to disable logging temporarily is easier, and faster, than doing
a task that exposes passwords in the clear into the log file, and then
trying to go back after the fact and clear the entries from the log

  * In this case, I think the integrity of the log file is preserved, in
that it was not, itself, physically modified, and notation was made
where an operator invoked a "gap in the tape"...;

  * I also suggest that it is a LOT more manual effort (and therefore
introduces more risks of unintended consequences) if someone must modify
the CF file, HUP the server, make their changes, then re-modify the
config, and HUP Conserver again. 

  DOWN A CONSOLE: In a recent case, a console started spewing ~120
Mbytes of data per 24-hr period. (It was a debug port on a "standby
firewall" that went 'active'. It was logging to the partition that
contained the other system logging for the OS, and it was rapidly
filling the disk. We couldn't disconnect the port, as we needed to use
it to command the firewall...but we couldn't let the disk fill (as that
would halt the Conserver machine). Our tasks included sequences of
up'ing the port, typing commands at the firewall, and down'ing the port,
and testing the results.

  * We later moved the logs to a larger partition, and lowered the log
rotation size from 20 MB to 10 MB. 

  * From time to time, "Down Happens". I'm pretty sure that the
discussion hasn't approached whether or not client users should be able
to "up" a port. But what if the port is something that spews, such as
the firewall debug port? If a client 'up's the port, sees that it's
spewing, but cannot 'down' the port again...what then? You don't know
what is on the 'other side of the door' until you open it. (In real
life, you feel the door before you open it to see if there is fire on
the other side, but you can't tell if the other side 'only' has a toxic
smoke... ;-)

  In summary, I like KISS, but I also like flexibility. I see that
Conserver can evolve into a very secure tool, or it can become a bit
more complex in order to allow the administrator to configure
very-secure, or looser levels of control.
David 'Zonker' Harris
Silicon Valley Service Delivery Center, Network Operations
Siemens IT Solutions and Services, Inc. 
Infrastructure Management Services
39600 Eureka Drive
Newark, CA  94560
Tel:    510 624-5524
Mob:    510 648-0701
Fax:    510 624-5508
mailto: david.k.harris@siemens.com