Want to wager a guess as to what the key issues are surrounding network and security monitoring in 2010? If you want to confirm or deny your suspicions, check out a study from Enterprise Management Associates (EMA) involving network and security operations professionals highlighting the challenges and best practices for optimizing monitoring in 2010. In case you don’t have time, here are some of the highlights:
1. 24% of participants reported they either lack the staff to keep up with monitoring tasks or the training within existing staff to keep up with administration or interpretation.
2. A trend spotted by 62% of participants was the movement of staff to more generalist roles reducing the availability of technical specialists (shrinking budgets have made this a real challenge). Does your experience support this trend?
3. 66% of participants indicated they lack enough monitoring tools or the budget to buy them.
4. 47% of respondents were not fully utilizing the monitoring tools they had in place.
It's clear that in 2010 workloads won’t be decreasing and that the trend of doing more with less will continue. Another finding is that IT staff need a tool that centralizes their monitoring into a single system that is simple to maintain and is easy to use.
If this rings true for you, I can provide some helpful guidance. My company offers dopplerVUE a powerful easy-to-use network management tool that can help you bring together security and performance management into a single system. dopplerVUE is a cost-effective ($10 per element) and proven solution (check out our tutorials). Or download the software and try if for yourself for free. We also offer great customer support to make sure you make the most out of your investment.
That’s my product pitch for the day. Enjoy the weekend!
Friday, January 29, 2010
Thursday, January 21, 2010
Routers in Space…Extending the Internet into the Universe???
Managing a network on Earth is no easy feat. How about in space? This may sound far fetched, but the concept may be becoming a reality. Internet technology is now being made available from a space-based platform.
Cisco is testing an IP router aboard a satellite in Earth orbit (22,300 miles above the Earth). The aim is to extend IP access to places that aren’t served by traditional phone and wireless networks.
As part of its Internet Routing in Space (IRIS) program, Cisco is testing the router to demonstrate to the Department of Defense (DoD) that the technology can be used to enhance military communications.
Here is a picture of the Intelsat 14 satellite with reflectors deployed for testing. Check out more pictures here.
According to Cisco, IRIS shifts much more of the intelligence to the orbiting router – with potentially dramatic benefits. The long-term goal is to route voice, data and video traffic between satellites over a single IP network in ways that are more efficient, flexible and cost effective than is possible over today's fragmented satellite communications networks.
After testing is completed in April, the IRIS project will be switched over for commercial use.
This is a very interesting development from my perspective. My company has been helping the government manage LAN, WAN, satellite and a range of networks for some time. Perhaps its time to take it to the next level….
Cisco is testing an IP router aboard a satellite in Earth orbit (22,300 miles above the Earth). The aim is to extend IP access to places that aren’t served by traditional phone and wireless networks.
As part of its Internet Routing in Space (IRIS) program, Cisco is testing the router to demonstrate to the Department of Defense (DoD) that the technology can be used to enhance military communications.
Here is a picture of the Intelsat 14 satellite with reflectors deployed for testing. Check out more pictures here.
According to Cisco, IRIS shifts much more of the intelligence to the orbiting router – with potentially dramatic benefits. The long-term goal is to route voice, data and video traffic between satellites over a single IP network in ways that are more efficient, flexible and cost effective than is possible over today's fragmented satellite communications networks.
After testing is completed in April, the IRIS project will be switched over for commercial use.
This is a very interesting development from my perspective. My company has been helping the government manage LAN, WAN, satellite and a range of networks for some time. Perhaps its time to take it to the next level….
Friday, January 15, 2010
Networks Could be 10,000 Times More Efficient…Really?????
Did you know the global network currently generates 300 million tons of carbon dioxide a year -- about as much as 15 million cars? I didn’t either until I came across an article on Market Watch. The number is increasing as Internet traffic continues to grow along with a worldwide user base. I was surprised by how much of an impact the network has on the environment. But, there is good news…
Global networks could theoretically run on 10,000 times less energy than they do today according to scientists and engineers at Bell Labs (the research arm of Alcatel-Lucent). The estimate came from the scientists when they decided to find out the minimum amount of power required to run the network. This isn’t my field of expertise, but it seems like a staggering amount of inefficiency.
Why are networks so energy inefficient? Bell Labs says that networks weren’t designed with energy efficiency in mind, but were optimized for performance and simplicity (not too surprising).
So where does this leave us? Alcatel-Lucent and Bell Labs have decided to launch a global consortium called Green Touch whose goal would be to develop the technologies needed to make networks much more efficient.
How much more? 1,000 times more efficient than it is now within five years. It's an aggressive goal, considering that a thousandfold reduction is roughly equivalent to being able to power the network for three years with as much energy as it currently takes to run it for a day.
This is great news. It’s going to be interesting to see if the consortium can deliver on their goals. I’m cautiously optimistic – how about you? If you want more details check out the Green Touch press release.
Global networks could theoretically run on 10,000 times less energy than they do today according to scientists and engineers at Bell Labs (the research arm of Alcatel-Lucent). The estimate came from the scientists when they decided to find out the minimum amount of power required to run the network. This isn’t my field of expertise, but it seems like a staggering amount of inefficiency.
Why are networks so energy inefficient? Bell Labs says that networks weren’t designed with energy efficiency in mind, but were optimized for performance and simplicity (not too surprising).
So where does this leave us? Alcatel-Lucent and Bell Labs have decided to launch a global consortium called Green Touch whose goal would be to develop the technologies needed to make networks much more efficient.
How much more? 1,000 times more efficient than it is now within five years. It's an aggressive goal, considering that a thousandfold reduction is roughly equivalent to being able to power the network for three years with as much energy as it currently takes to run it for a day.
This is great news. It’s going to be interesting to see if the consortium can deliver on their goals. I’m cautiously optimistic – how about you? If you want more details check out the Green Touch press release.
Wednesday, January 13, 2010
How Much is Downtime Costing You? Find out How to Reduce Downtime by 85%...
Any guesses on how much IT downtime is costing your organization? Maybe you already know. In case you don’t - research from analyst groups suggest the cost is anywhere from $42,000 to $90,000 for every hour of unplanned downtime. The estimates (of course) vary greatly based on industry, organization size and other variables, but even if you’re on the low end of that estimate, that’s a lot of money.
In a recent white paper “Business Operations Disruption Risk: Identify, Measure, Reduce”, IDC highlights the application of five best practices that can help reduce unplanned downtime by up to 85% (derived from interviews with multiple midsize companies).
• Consistent use of management software reduces network and system downtime by 65%
• Upgrading servers/storage/network equipment reduces downtime by 50%
• Enabling high-availability failover clustering software reduces downtime by 43%
• Adopting industry best practices standards (e.g., ITIL, Cobit) across the organization reduces downtime by 13-15%
• Using virtualization software reduces server downtime by 10%
I’m guessing you’re already using some or a combination of these tactics to mitigate the risk of downtime. Most of these best practices are well known, although I did find the percentages associated with each one interesting. Do you find them to be accurate based on your experience?
Anyway…if you’re looking for guidance in any of these areas, let me know. My company specializes in IT services and network management software (free trial for 30 days).
In a recent white paper “Business Operations Disruption Risk: Identify, Measure, Reduce”, IDC highlights the application of five best practices that can help reduce unplanned downtime by up to 85% (derived from interviews with multiple midsize companies).
• Consistent use of management software reduces network and system downtime by 65%
• Upgrading servers/storage/network equipment reduces downtime by 50%
• Enabling high-availability failover clustering software reduces downtime by 43%
• Adopting industry best practices standards (e.g., ITIL, Cobit) across the organization reduces downtime by 13-15%
• Using virtualization software reduces server downtime by 10%
I’m guessing you’re already using some or a combination of these tactics to mitigate the risk of downtime. Most of these best practices are well known, although I did find the percentages associated with each one interesting. Do you find them to be accurate based on your experience?
Anyway…if you’re looking for guidance in any of these areas, let me know. My company specializes in IT services and network management software (free trial for 30 days).
Wednesday, January 6, 2010
Network Management Security
Happy New Year! I recently read a great article on network management security by Joel Snyder, and thought it would make a nice first topic for 2010. His article offers up several very good tips that you should consider implementing if you haven't done so already. Check it out:
It doesn't happen very often, but when Cisco sends out a security advisory about one of their routing or security products, there's a big splash. Almost all of these advisories can be summarized like this: "If someone out on the Internet sends some bad packets to your Cisco device, and if your device is listening to them, then something bad will happen."
You can, and should, secure your network control plane in many ways, but they mostly come down to two techniques: access control lists and self-protection.
ACCESS CONTROL LISTS MANAGE TRAFFIC TO EDGE DEVICES
Access control list protections usually occur when you put a block of some sort in non-firewall devices at the edge and core of your network. A good example is SNMP. Let's say you have an SNMP management station at 10.20.30.161. That represents the one valid flow to and from that management station to network and security devices. Now, any other SNMP traffic floating around on your network, or coming in from the edge, should be blocked. If you have intermediate routers in your network, and certainly if you have firewalls, you should use them to block SNMP traffic -- and any other management traffic -- to your security and network devices, except from authorized sources.
permit udp any 10.20.30.161 eq snmptrap
deny udp any any eq snmp log
deny udp any any eq snmptrap log
Or you could put a block in to just protect the network and security devices. Usually, stricter is better, but if you don't know who else might be using SNMP, then you can focus on the devices that run your network.
At the edge, a much stricter approach is appropriate. In this case, you should be blocking all traffic directed at your firewalls, load balancers, and routers on their management addresses. Remember: No one on the Internet needs to send packets to your firewall, or to your external router. They legitimately send packets through those devices all the time, but the packets are never destined (at the IP layer, anyway) directly to the device. They're always for some IP address behind the device. The only time you may want to consider letting traffic come directly to the management IP of your external security and network devices is for PING traffic -- it's a very useful debugging tool and worth letting traffic come in.
deny IP any host 128.182.35.42
If you wanted to block all SNMP incoming, you could do something like this:
remark *** Deny all other SNMP incoming
deny udp any any eq snmp
deny udp any any eq snmptrap
If you're in a NAT environment and you're using the external IP address of your firewall or router both for management and NAT, here is some advice: Don't do that. You're asking for security trouble, because now you have the same IP address being used for two things. IP addresses may be in short supply, but they're not in that short supply. Here's an example in case you can't separate out NAT from other traffic, assuming you know which ports your router or firewall are listening to (not a very good assumption, as the Cisco advisories show):
remark *** Block obvious access to mgmt plane; allow others
deny tcp any host 128.182.35.42 eq 22
deny tcp any host 128.182.35.42 eq www
deny tcp any host 128.182.35.42 eq 443
permit ip any host 128.182.35.42
CONFIGURE SECURITY DEVICES TO PARTICULAR TRAFFIC
Another protective technique should be self protection. With self protection, you configure the network or security device so that it doesn't listen to traffic it shouldn't hear. On devices such as routers, you'll want to create a local access list that only allows management traffic from authorized management networks. If you can, also disable management protocols and interfaces you aren't using. On devices such as firewalls, there is often a series of check boxes that let you turn on or off management on certain interfaces. It doesn't need to be enabled on the outside, ever. That's what VPNs are for, if you really need external management.
Sometimes you want to disable protocols entirely. Most people, for example, do not manage Cisco routers using HTTP. Here's a configuration example that's double overkill: disabling the HTTP server, and then also putting an access list on it, just in case.
no ip http server
ip http access-class 21
ip http authentication local
no ip http secure-server
access-list 21 deny any
And even if you do have management enabled, you should also add lists of authorized management addresses. It shouldn't be possible for someone who happens to be inside your network to connect to the management IP of your firewalls, routers, or other security devices, unless they're on the official management network.
For example, again using Cisco syntax, here is what the SNMP part of the router configuration might look like in a self-protective mode of operation:
snmp-server community public RO 6
snmp-server community vewysekwitpassword RW 6
snmp-server location Opus One/Tucson, Arizona
access-list 6 permit 203.209.92.105
access-list 6 permit 192.245.12.0 0.0.0.255
access-list 6 deny any log
In summary…
1. Your public facing devices should not have non-essential ports open.
2. SNMP is safe when using an access list to limit who your routers will send/receive SNMP traffic to/from.
3. Use a Management or Control plane to isolate the monitoring and management tasks from the other traffic. This allows you to open ports/protocols often necessary to enable the best functionality.
Do you have any network management security tips that you frequently use or follow?
It doesn't happen very often, but when Cisco sends out a security advisory about one of their routing or security products, there's a big splash. Almost all of these advisories can be summarized like this: "If someone out on the Internet sends some bad packets to your Cisco device, and if your device is listening to them, then something bad will happen."
You can, and should, secure your network control plane in many ways, but they mostly come down to two techniques: access control lists and self-protection.
ACCESS CONTROL LISTS MANAGE TRAFFIC TO EDGE DEVICES
Access control list protections usually occur when you put a block of some sort in non-firewall devices at the edge and core of your network. A good example is SNMP. Let's say you have an SNMP management station at 10.20.30.161. That represents the one valid flow to and from that management station to network and security devices. Now, any other SNMP traffic floating around on your network, or coming in from the edge, should be blocked. If you have intermediate routers in your network, and certainly if you have firewalls, you should use them to block SNMP traffic -- and any other management traffic -- to your security and network devices, except from authorized sources.
permit udp any 10.20.30.161 eq snmptrap
deny udp any any eq snmp log
deny udp any any eq snmptrap log
Or you could put a block in to just protect the network and security devices. Usually, stricter is better, but if you don't know who else might be using SNMP, then you can focus on the devices that run your network.
At the edge, a much stricter approach is appropriate. In this case, you should be blocking all traffic directed at your firewalls, load balancers, and routers on their management addresses. Remember: No one on the Internet needs to send packets to your firewall, or to your external router. They legitimately send packets through those devices all the time, but the packets are never destined (at the IP layer, anyway) directly to the device. They're always for some IP address behind the device. The only time you may want to consider letting traffic come directly to the management IP of your external security and network devices is for PING traffic -- it's a very useful debugging tool and worth letting traffic come in.
deny IP any host 128.182.35.42
If you wanted to block all SNMP incoming, you could do something like this:
remark *** Deny all other SNMP incoming
deny udp any any eq snmp
deny udp any any eq snmptrap
If you're in a NAT environment and you're using the external IP address of your firewall or router both for management and NAT, here is some advice: Don't do that. You're asking for security trouble, because now you have the same IP address being used for two things. IP addresses may be in short supply, but they're not in that short supply. Here's an example in case you can't separate out NAT from other traffic, assuming you know which ports your router or firewall are listening to (not a very good assumption, as the Cisco advisories show):
remark *** Block obvious access to mgmt plane; allow others
deny tcp any host 128.182.35.42 eq 22
deny tcp any host 128.182.35.42 eq www
deny tcp any host 128.182.35.42 eq 443
permit ip any host 128.182.35.42
CONFIGURE SECURITY DEVICES TO PARTICULAR TRAFFIC
Another protective technique should be self protection. With self protection, you configure the network or security device so that it doesn't listen to traffic it shouldn't hear. On devices such as routers, you'll want to create a local access list that only allows management traffic from authorized management networks. If you can, also disable management protocols and interfaces you aren't using. On devices such as firewalls, there is often a series of check boxes that let you turn on or off management on certain interfaces. It doesn't need to be enabled on the outside, ever. That's what VPNs are for, if you really need external management.
Sometimes you want to disable protocols entirely. Most people, for example, do not manage Cisco routers using HTTP. Here's a configuration example that's double overkill: disabling the HTTP server, and then also putting an access list on it, just in case.
no ip http server
ip http access-class 21
ip http authentication local
no ip http secure-server
access-list 21 deny any
And even if you do have management enabled, you should also add lists of authorized management addresses. It shouldn't be possible for someone who happens to be inside your network to connect to the management IP of your firewalls, routers, or other security devices, unless they're on the official management network.
For example, again using Cisco syntax, here is what the SNMP part of the router configuration might look like in a self-protective mode of operation:
snmp-server community public RO 6
snmp-server community vewysekwitpassword RW 6
snmp-server location Opus One/Tucson, Arizona
access-list 6 permit 203.209.92.105
access-list 6 permit 192.245.12.0 0.0.0.255
access-list 6 deny any log
In summary…
1. Your public facing devices should not have non-essential ports open.
2. SNMP is safe when using an access list to limit who your routers will send/receive SNMP traffic to/from.
3. Use a Management or Control plane to isolate the monitoring and management tasks from the other traffic. This allows you to open ports/protocols often necessary to enable the best functionality.
Do you have any network management security tips that you frequently use or follow?
Subscribe to:
Posts (Atom)