Mailing List Archive

On Fri, Jan 02, 2004 at 01:34:56PM -0500, Joshua Wright wrote:
[...]
> Why wouldn't you just grant a similar AAA configuration entry for
> "show running-config" for privilege 2 (or whatever privilege level you
> assign this user)?
Did you tried that, ever? Because even if I grant access to "show
running-config" you will get an answer with some comments and nothing
else. Not a single configuration line. I tested that without enabling
"aaa new-model". So there is no alternative in using "show
startup-config"

> 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.

> Also, consider the case when someone makes a change to the router and
> doesn't save the configuration changes. Next time the router reboots,
> something breaks because the configuration change was lost. With
> RANCID monitoring the running configuration file, it would alert you
> when the router came back online since the new running configuration
> reflects the previously saved startup config file.
So you blame "someone" for not saving the configuration. In that case,
you see the big backdraw on not saving the running-config. You can't do
a simple reboot. That "is bad style (TM)", generally. That's an argument
pro saving "startup-config".

--
erik at code.de

"I am not a Geek! I shower."

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

Tue, Jan 06, 2004 at 04:22:18PM +1100, Andrew Fort:
> 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.

just want to add two bits to this.
1) "router has the canonical config", ie: what's in nvram is authoritative,
is a practice that most folks grow out of. you will eventually begin to
generate your configs and load those into nvram.

2) what i'd like to add for rancid 3.0 (or whatever) are boiler-plate device
types. for example, type "cisco" runs commands x, y, & z. but, a user
can define their own type, cisco-startup which might run x, y, z, & show
startup-config. not quite sure how to do that yet.

On 7/01/2004 3:03 PM, john heasley wrote:

>2) what i'd like to add for rancid 3.0 (or whatever) are boiler-plate device
> types. for example, type "cisco" runs commands x, y, & z. but, a user
> can define their own type, cisco-startup which might run x, y, z, & show
> startup-config. not quite sure how to do that yet.
>
>

Thinking out loud here, but...
How about merging the concept covered in 'rancid-fe' with this, so you
have a device type which nominates a given *rancid script to execute and
also a file which has the commands for that script to run, along with
the function names to parse them. The parsers commands are split out
into a perl module or similar, with examples on how to write your own
and what inputs to expect and outputs to provide.

-afort

Wed, Jan 07, 2004 at 04:28:48PM +1100, Andrew Fort:
> On 7/01/2004 3:03 PM, john heasley wrote:
>
> >2) what i'd like to add for rancid 3.0 (or whatever) are boiler-plate
> >device
> > types. for example, type "cisco" runs commands x, y, & z. but, a user
> > can define their own type, cisco-startup which might run x, y, z, & show
> > startup-config. not quite sure how to do that yet.
> >
> >
>
> Thinking out loud here, but...
> How about merging the concept covered in 'rancid-fe' with this, so you
> have a device type which nominates a given *rancid script to execute and
> also a file which has the commands for that script to run, along with
> the function names to parse them. The parsers commands are split out
> into a perl module or similar, with examples on how to write your own
> and what inputs to expect and outputs to provide.

that is what i had in mind. plus some default device "types".

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

On Fri, 9 Jan 2004, Henry Kilmer wrote:

>
> 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

I would like to start with the broader view. I think CVS of rancid should
reflect the stable and working configuration. I am usually not interested
in the transient state of the router. In my opinion the running config is
only interesting if:

- You are actually configuring something
- You are running a certain test, - the result are not sure.

If you look at another type of router. For example Juniper router. You can
always see the the "startup config". You can see the transient config
only if you are in the config mode....

So my vote would be default to startup config, and possible option for
running config.

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

>
> 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
>

On Fri, 9 Jan 2004, Mohacsi Janos wrote:

> I would like to start with the broader view. I think CVS of rancid should
> reflect the stable and working configuration. I am usually not interested
> in the transient state of the router. In my opinion the running config is
> only interesting if:
>
> - You are actually configuring something
> - You are running a certain test, - the result are not sure.

Or someone makes changes and neglects to write mem. There are other odd
(beneficial) side effects of having rancid get the running config.

Cisco as5200's, when low on memory, show a partial running config. The
rancid email serves as an early warning system, telling us it's time to
reboot an as5200.

> So my vote would be default to startup config, and possible option for
> running config.

I'd vote the other way :)
Keep it as is, and maybe make it an easily configured option to look at
startup configs.

----------------------------------------------------------------------
Jon Lewis *jlewis at lewis.org*| I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

I implemeted an option, configured in rancid.conf, which satisfies my
security needs. This option is disabled by default.

--
erik at code.de

"I am not a Geek! I shower."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cisco-lower-privilege.patch.gz
Type: application/octet-stream
Size: 1515 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/rancid-discuss/attachments/20040119/62be8eb7/attachment.obj