> [mailto:[EMAIL PROTECTED] On Behalf Of > Justin M. Streiner > > On Tue, 3 Jun 2008, Richey wrote: > > > I've got a customer with a T1. They have been bought out > by a large hotel > > chain. They are pretty much demanding that they have SNMP > full read access > > to our router that is at their location as well as a copy > of the config for > > the router. This is not their router, it is ours and we > > 7. Lock down the console and aux ports. It's an easy step to > overlook, > but after getting a call from my NOC at my previous job > necause a customer > with two routers managed by us decided to have a consultant > do password > recoveries on them (without my employer's knowledge or > consent) so they > could 'tune' (read: break and not know how to fix) HSRP, over > a holiday > weekend, it's something I will not overlook again...
The only way to avoid this is disabling password recovery. I'm not certain if this is what you are suggesting here, but nothing in the running configuration of the aux/con ports can prevent a recovery. Other than that, though, the reactions seem a bit on the harsh side, for someone requesting _read_ access to the system, assuming that it is strictly used for their business. I could see a charge for the time involved, and having one-off configurations is not good, but I don't think it requires a flatout refusal. There are a few things that I see that could be problems, definitely not an exhaustive list. 1) Passwords - they will be able to get your vty password, so use local user accounts and AAA. 2) Routing - they may be able to get some info about your internal network. Counter this by requiring that they switch to static routing (and lose any current redundancy) if they desire this, or possibly eBGP (not sure if this is a good idea or work, but basically don't show them your IGP). 3) Security issues - these are issues regardless, so having them exposed to the customer just means you need to be more proactive. 4) Management IP addressing could be an issue (revealing that by interface). The alternative is to manage it differently, but again that falls into the 'one off' scenario. Verizon and other providers are willing to rent/lease you hardware, and configure it, but it is always treated as a customer CPE. This means that it is not part of their network (no IGP, management addressing schemes, etc), and has no information to be revealed (as far as I know... I have only actually been in this situation a couple of times). Anyway, that's the Devil's Advocate argument. I don't think the request is worth dismissing out of hand. Thanks, Josh > 8. Back the configuration up regularly, using a backup system with > journaling/version control capabilities so you can see > changes over time. > RANCID is quite useful for this. I ended up writing > something in-house, > but the code is not packaged in a releasable format, so I > haven't turned > it out to the masses yet. > 9. Specifically note what actions are and are not allowed in > the service > agreement (see above). > 10. Affix stickers to the router explicitly stating that unauthorized > access is prohibited. > 11. Talk with your legal counsel about reasonable limitations > of liability > in circumstances like this. > > [1] - http://www.cymru.com/Documents/secure-ios-template.html > > my 2 cents :) > > jms > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
