integration of security enhancement patch

[Henry Kilmer]

Rancid's original goal was to track the changes in the running
network.  That meant grabbing the running configs since they might
have changed from the startup config (people forget/don't want to save
configs all the time).  It is useful to track on-going changes too if
you work in a NOC.  If changes are made and a save isn't done, the
configs rancid stores (if using the startup configs) would not restore
the router as well.

It was always my opinion when this topic got brought up that it was
trivial for a site to make the change to grab the startup config if
they really wanted but that rancid's default should be the running
config.

-Hank

Andrew Fort writes:
>On 5/01/2004 9:20 PM, Erik Wenzel wrote:
>
>>On Fri, Jan 02, 2004 at 01:34:56PM -0500, Joshua Wright wrote:
>>[...] 
>>  
>>
>>>Changing RANCID to perform "show startup-config" instead of a running
>>>configuration is "a bad idea" (tm).  If an attacker were able to
>>>compromise your router and make changes to the configuration, RANCID
>>>in its current state will identify the changes and let you know about
>>>it.  If RANCID used "show startup-config" instead, you would be
>>>unaware of the changes until they were saved.  The running
>>>configuration is a better reflection of the state of the router.
>>>    
>>>
>>Using Rancid to check if an attacker is compromising your routers is
>>only possible if only one person is having write access. If you have
>>a colleague you are not able to distinguish configuration changes coming
>>from your colleague or an attacker. So, using RANCID for that purpose is
>>one thing. On the other Hand is the purpose of having backups for desaster
>>recovery and for that I can't see a reason to prefer one of the other.
>>In a production environment I concider it "a bad idea (TM)" to have a
>>difference between both configurations.
>>
>>  
>>
>
>I think you both have a point worthy of argument, but noone wins 
>arguments.  There's no reason why the site administrator can't do this 
>locally, nor why it could not be a configuration (bin/env) variable.   
>The quick hack I just did to do this is kinda ugly (rewrite both the 
>%commands and @commands variables _entirely_, based on whether a ENV 
>variable is set one way or another), so I wont submit it if there's a 
>cleaner way to just re-write that last line.  Can someone submit a 
>cleaner method?  (Default behaviour remains the same, i.e., if there's 
>no variable in the bin/env file).
>
>What do other people think?  I've often had people ask me "oh, why 
>doesn't RANCID look at the startup config", and I've explained it as 
>Joshua has, above, but Erik makes a good point, and this seems like 
>something that should be decided by the administrator.
>
>-afort