rexm@lookout.uswest.com (Rex Mammel) (06/06/91)
Has anyone looked at logging the configuration mode entries. We have several people in our network operations group, and it would be a good change control feature to have an automatic record of changes to the AGS configuration. Also, is there a good reason to prevent someone from looking at the config listing from initial password level. As far as we we can tell only changes, debugging and other sensitive operations need to be restricted. Is there a way to configure this? Thanks.
MAP@lcs.mit.edu (Michael A. Patton) (06/06/91)
Date: Wed, 5 Jun 91 09:34:38 MDT
From: Rex Mammel <rexm@lookout.uswest.com>
Has anyone looked at logging the configuration mode entries. We
have several people in our network operations group, and it would
be a good change control feature to have an automatic record of
changes to the AGS configuration.
I have been running a script that gets printouts of various info on my
ASM by telnetting in with a fixed set of commands. It runs once an
hour and produces a script file (I have available dumps for nearly 3
years [starting June 27, 1988 @10PM], once an hour). I mostly keep
these long term for the connectivity info of the terminal users (for
usage trend analysis), but the same technique would work for what you
want. I have occasionally used these to determine when a particular
configuration change was done. The one possible problem you might
have is that you get no record of WHO did it.
I have two Cisco routers in addition to the ASM. I don't keep any
data like thi on them. That's because, in my setup, the official
config is the one on a master server, it's controlled with RCS. The
Makefile copies it to the individual boot servers from whence it is
TFTP loaded into the Cisco boxes.
Also, is there a good reason to prevent someone from looking at
the config listing from initial password level.
Yes! One of the things in the config is the privileged password!!!
Most of the information they might want can be obtained by other
non-privileged commands. In that form, it's also more human oriented.
__
/| /| /| \ Michael A. Patton, Network Manager
/ | / | /_|__/ Laboratory for Computer Science
/ |/ |/ |atton Massachusetts Institute of Technology
Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)sherk@nmc.cit.cornell.edu (Erik Sherk) (06/07/91)
> > > Has anyone looked at logging the configuration > mode entries. We have several people in our network > operations group, and it would be a good change control feature to > have an automatic record of changes to the AGS configuration. This would be nice. I recently implemented some procedures that use Emacs's ChangeLog function. I know of some people who use SCCS or RCS. > Also, is there a good reason to prevent someone from looking at > the config listing from initial password level. As far as we we > can tell only changes, debugging and other sensitive > operations need to be restricted. Is there a way to configure this? > > Thanks. Well, you can see the enable password! Other than that, I don't see a reason either. Erik Sherk sherk@nmc.cit.cornell.edu
Watt-Alan@mickey.ycc.yale.edu (06/07/91)
Rex Mammel (rexm@lookout.uswest.com) writes: >Has anyone looked at logging the configuration >mode entries. We have several people in our network >operations group, and it would be a good change control feature to >have an automatic record of changes to the AGS configuration. Keep your configurations in a text file which is under RCS or SCCS or similar configuration control. I keep mine as a set of configuration templates, and generate the specific configuration for each gateway with m4. The welcome text includes the RCS revision number of the last loaded configuration. You do have the problem on gateways with configuration memory that the operating configuration can diverge from the stored one; this requires more in the way of discipline than tools to overcome. I have found it somewhat irksome in the past that I cannot load a configuration from a server on a running gateway and have it take proper effect. It is not possible to "clear" some configuration parameters without knowing what they currently are (administrative distance and static routes are common examples). Thus loading a stored configuration on a running gateway can have an additive rather than absolute effect. The only sure fix is a gateway reload, which is probably what you should do anyway. >Also, is there a good reason to prevent someone from looking at >the config listing from initial password level. As far as we we >can tell only changes, debugging and other sensitive >operations need to be restricted. Is there a way to configure this? There is the small matter of the privileged password. I don't think I'd want random people looking at my routing filter lists. For the same reason, I really don't want people looking at my access list definitions, but that isn't privileged in the current scheme. They can't find out what a specific access list is applied to without priviliges, but simply looking at the definitions can be fairly suggestive. - Alan S. Watt High Speed Networking, Yale University Computing and Information Systems Box 2112 Yale Station New Haven, CT 06520-2112 (203) 432-6600 X394 Watt-Alan@Yale.Edu Disclaimer: "Make Love, Not War -- Be Prepared For Both" - Edelman's Sporting Goods [and Marital Aids?]
dana@thinman.cray.com (Dana Dawson) (06/07/91)
> Also, is there a good reason to prevent someone from looking at > the config listing from initial password level. As far as we we > can tell only changes, debugging and other sensitive > operations need to be restricted. Is there a way to configure this? If you have access-lists configured, you may not want the specifics of those lists publicly available as a security precaution. Dana J. Dawson Manager, Internetworking Group Cray Research, Inc. (612) 683-3056 dana@cray.com
aggarwal@nisc.jvnc.net (Vikas Aggarwal) (06/07/91)
We use RCS to maintain all the jvncnet config files for the routers. Has served us well so far,,, we also put the revision number in the banners so that we can compare the loaded config file with the present RCS version (telnet ford.jvnc.net for an example). -vikas vikas@jvnc.net (609) 258-2403 Network Engineering -2400 JvNCnet, Princeton, NJ -----------------------------------------------------------------------------