 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
4 messages in net.nether.puck.cisco-nsp[c-nsp] BCP for an ISPs large number ...| From | Sent On | Attachments |
|---|---|---|
| Kim Onnel | Jan 9, 2005 6:59 am | |
| Colin Whittaker | Jan 9, 2005 8:45 am | |
| Kim Onnel | Jan 9, 2005 9:23 am | |
| Jason Ackley | Jan 9, 2005 10:40 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [c-nsp] BCP for an ISPs large number of network devices authentication | Actions... |
|---|---|---|
| From: | Jason Ackley (jas...@ackley.net) | |
| Date: | Jan 9, 2005 10:40:21 am | |
| List: | net.nether.puck.cisco-nsp | |
On Sun, 9 Jan 2005, Kim Onnel wrote:
so you're saying option B is better because its easier, i just wanna strike balance between security and usability,
You have more flexibility on a full unix box. You can set up all sorts of elaborate controls (and key loggers/session loggers if your audit policy requires it).
probably each NOC user has his own settings like batch files, SecureCRT scripts which auto authenticates, these all would still be valid with the IPSec, but not with the Linux ssh solution,
This is a policy concern for some people. E.g. do you really want all of your NOC credentials (for multiple NOC staff members no doubt) sitting on a windows machine and set up for auto-login?
Making them 'bounce' via a bastion host is one way to enforce that they do things that is the approved and proper method to access the remote devices.
Another point would be that IOS is a little more secure than linux, since its less complex, but that comes with other point, less interactivity and monitoring,
Determine what your needs are first, then select the solution that meets your particular needs. Balance this with ability to audit and enforce policy and usability for your NOC staff.
I just wonder whats the common practice for ISPs with similar resources like mine, whats the trend ?
Always deploy multiple bastion hosts or you can easily find yourself locked out of your network elements until you get something back up on that IP.
I have tossed around VPNs to/from Network Elements. My thoughts are that they always tend to break when you dont want them to break. E.g. when your remote POP appears to be down for some reason, having IPsec/ISAKMP running may be enough to really push it over the edge..
Common practice:
Place all NOC machines on a specific set of subnets. Restrict SSH to your bastion hosts from these subnets only (and maybe a remote VPN IP pool for remote work).
SSH into bastion host using a one-time password or other strong method.
Bastion host has session/audit logging. From there, SSH/telnet into remote router devices to manage them.
Network elements use TACACS/RADIUS back to a TACACS/RADIUS server. NOTE: Password for NEs should be different from what they use on the bastion host (Just reject password logins on bastion host really). NEs require VTY connections from the bastion host network(s).
Deploy multiple setups like this. One for your primary NOC, one for your secondary.
Audit/Session logs are sent to another host that only your Security team has access to.
Continue to run RANCID or other homegrown scripts for configuration versioning and tracking.
cheers,
-- jason