Where Network admins and Security clash

Here is the senerio:

You run a scan internally to find that the telnet ports to your routers are open.
You talk to the networking gurus about this and they assure you that it is only accessable internally , all router passwords have been changed and are complex and that they are all controlled by access-lists and only a couple boxes have access to the routers remotely. Are you concerned? Hell I am!!
I presented them with this senerio....I can launch a DOS attack and sniff the network to see who hits that device when the network team goes to investigate, then use that info to spoof the ip and access it through telnet using the info I pulled from the packet......Am I to paranoid? What are your thoughts?

Simply close the Telnet port. Turn off the Telnet server, use SSH (more updated, better).

There is a simple solution to this.

#1 Enable SSH to all devices and of course, disable Telnet. This takes away your ability to "sniff" the credentials during the trouble shooting process.

#2 Build encrypted access requirements into your security policy. This gives you (ideally) leverage to enforce this configuration.

#3 Test the ACLs to be sure that they are set the way they claim. If they have strong passwords and also have wrappers setup properly along with SSH access, then you can stop concerning yourself (too much).

After all, it is not efficient or reasonable to assume that your admins should be forced to have console (physical) access only. Like anything else, assess the risk and then apply the appropriate level of security.

What does it cost to get this fixed? I mean what did you have in mind to secure the routers and what's it going to cost to implement and administer? Take this figure and compare it to the costs of cleaning up a DoS.

Sometimes it costs alot more only to have a marginally better secure environment. Then the costs don't outweigh the risks.


Spyder: Not all routers/switches support ssh. Don't even get me started on keymanagement.

Here's a thought: Create a seperate management VLAN. Have the network gurus administer their boxes through this seperate VLAN. Put ACLs on the routers/switches to only accept telnet connections from this VLAN. All other (user) traffic is on other VLAN(s) (out-of-band management).

The answer to your question 'am I too paranoid' is yes, although that's not necessarily a bad thing.

This kind of a situation depends a lot on the size of the network, the resources at risk, and the capacity of the networking admin staff to ratchet down security without reducing services. The first question I would have is, what could go wrong and how long would it take them to fix it? Many of you security gurus might say that this is kind of naive, but if we're talking about a Cisco 1600 that sits in someones's office and provides connectivity to 32 workstations, then I'd say the network admin could take control back and get the network back in service pretty darn fast if something happened from the inside.

. . . but that's being a little too forgiving of lazy network administration.

Another way of looking at this is, does your organization have any network security policies in writing? It's all well and good to suggest to the admin that he/she shut off telnet, but it's even better if there is a corporate policy/procedure mandating that anyone with adminstrative rights to a router be responsible for permitting access to the device only under such and such conditions. This provides motivation to do more than just check the router for its vulnerability to the one scenario you presented.

I tend to think of network security more in terms of organizational behavior than ports and services. It's nice to know how to protect one service on one device, but it's even better to work in an organization that constantly protects all devices as a matter of course.

Quote:

---

Here's a thought: Create a seperate management VLAN. Have the network gurus administer their boxes through this seperate VLAN. Put ACLs on the routers/switches to only accept telnet connections from this VLAN. All other (user) traffic is on other VLAN(s) (out-of-band management).

---

Yep, this is a great idea, and in fact, the way I handle critical enterprise network hardware. However, this assumes that #1 He has, or the talent exists in house to manage this config and #2 He has gear that supports VLAN features. I made the assumption that he is in a smaller environment, and of course, could be completely wrong. :)

Great ideas!!! The answer is yes to the idea of a VLAN. There are multipule locations with 1600 users overall. There is one VLAN, VPN, and Citrix in this environment. The network team is top notch and very capable. When I go head to head with them I want it to be meaningful and I want to have all my ducks in a row.
I believe that telnet in general is a bad idea and that implementing a secure protocol is more a nucience to them than something that they can not do. I am resonable and I have bigger fish to fry, but wanted other opinions on where to put this on my wish list to make the enterprise more secure.

Quote:

---

I can launch a DOS attack and sniff the network to see who hits that device when the network team goes to investigate, then use that info to spoof the ip and access it through telnet using the info I pulled from the packet......

---

Ok, but in reality you have the keys. Different perspective here. If a real DOS attack was issued outside your office would you be able to detect it? Shut it down? Terminate the user based on policy violations? Assumng the routers are locked down with decent passwords and only accessible internal to the network, as you mentioned. The higher risk could be DOS initiated by bad users versus the risk of unauthorized router access. Especially if the ACL is monitored via syslog or something. You do have a policy in place to have the net ops monitor that? A reasonable one that can be adhered too? Just pointing out alternatives that could have priority in line with completely changing the base architecure of the network. Which is what you would be doing.