[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
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 file. * 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 www.usa.siemens.com/it-solutions