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 fully manage our
router and hand them Ethernet. This seems a little odd that they want
access to our gear, and I am not too keen on giving them access unless they
are willing to accept some responsibility. They don't want to accept any
responsibility for the access they would have to this box. They say that
Verizion and AT&T don't have any problems giving them this kind of access to
their gear.
I'm not crazy about giving customers access to managed gear, particularly
if doing so would force you to treat that customer as a one-off build,
because those can easily turn into support nightmares. On the other
hand, if the equipment in question serves only that customer, then you
could do some of what they ask, possibly with minimal frustration. Under
no circumstances would I give them unfettered access to the box.
If the equipment services multiple customers, then they should get no
'live' access whatsoever. In such a case, you could provide them a copy
of the config for their interface and any ACLs that are specifically for
them, and nothing more. If the customer balks, tell them that you can't
provide more than that because the rest is considered confidential and
proprietary information.
At a minimum, the requested items would warrant either a new service
agreement, or an amendment to the existing service agreement.
1. Make sure the router is properly hardened... unnecessary services are
turned off, telnet is turned off or at the very least ACL-limited to
hosts on your network that have a legitimate need to access the router.
Same goes for SSH. Refer to Team Cymru's Secure IOS Template for some
excellent guidelines on hardening a Cisco router. [1]
2. Enable appropriate logging and log monitoring to look for evidence of
the customer trying to 'test the waters'.
3. Upgrade the code as necessary to guard against the customer trying our
some new security exploit against the router.
4. Sending them log messages and or SNMP traps is a Very Bad Idea (tm).
Don't do it :)
5. Limit the customer's SNMP read access using views.
6. Use a separate set of passwords and SNMP communities for this customer.
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...
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/
