On Tue, 3 Jun 2008, Higham, Josh wrote:
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.
You can also change the port speed, flowcontrol, etc, if you want to be
particularly devilish.
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.
I didn't refuse it flat-out. If the box serves a single customer,
some level of access is OK but from my experience, the vast majority of
the customers I've dealt with over the years don't care about the CPE
router, as long as it works, so providing this level of joint access was
a one-off for a long time. I no longer work in the ISP field, but I'd
imagine that regulatory controls like HIPAA, GLB, SOX, etc, or their
equivalents in countries other than the USA would cause that number to
climb somewhat and providers' business processes would need to evolve to
handle cases like this.
If the box serves multiple customers they can have a sanitized copy of
elements that are specifically for them (interface config, any ACLs that
are specifically for them, etc).
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.
True. Newer spins of IOS also allow for the encryption of things like VTY
passwords with the same one-way MD5 hash that's used for the enable
secrets. It's not bulletproof, but it's much better than the Vigenere
cipher that was used for ages on type 7 passwords (easily reversed and
tools are widely available online to do it). That same protection might
not extend to other sensitive bits (RADIUS/TACACS keys, SNMP communities,
other passwords and keys).
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).
Agreed. If the customer is single-homed, then static routing is fine.
BGP is OK as long as you take proper precautions on the aggregation side
(prefix lists, flap damping, distribute-lists (if necessary), max-prefix
limits, etc). Filtering link-state protocols like OSPF can be more
problematic.
3) Security issues - these are issues regardless, so having them exposed
to the customer just means you need to be more proactive.
Some organizations' change management policies may run counter to the need
to be 0-day proactive. I don't have an issue with the customer knowing
that their router is running IOS x.y(z), which is potentially vulnerable
to bug 12345. Acknowledge that could be an issue and that a maintenance
window will be forthcoming to upgrade the router and address the
vulnerability, if necessary. Many ISPs that offer SLAs to their
customers have a clause that allows them to perform routine maintenance
without counting against the SLA. A customer deciding to try out the
latest version of "pwn-my-r0ut3r.exe" usually doesn't count as routine
maintenance and you'd possibly end up having to eat the SLA credit for
that one :)
jms
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
