General: May 2004 Archives
Network World has put two leading Voice over IP solutions to the test in what they claim is the world's first public VoIP security challenge. In this challenge they invited multiple vendors to come in and set up a complete and secure network. Network World then had a red team try to disrupt services.
The full article is here.
What they concluded is that it is possible to secure a VoIP network, but it is not cheap. Also it requires planning and expert help which is basically what I was trying to point out in my earlier post.
Voice over IP is an alluring goal for I.T. departments. They promise the ability to rid the department of expensive duplicate networks for data, ease the administrative burden for when users change, and lets not forget provide flashy new features like a color touch lcd display.
In that eagerness to grab the promised cost savings of VoIP it is important not to run past security considerations. NIST recently released a recommendations guide for VOIP.
Their starting guidelines are:
1. Separate voice and data on logically different networks. Different subnets with separate RFC 1918 address blocks should be used for voice and data traffic, with separate DHCP servers for each.
2. At the voice gateway, which interfaces with the PSTN, disallow H.323, SIP, or MGCP or Megaco/H.248 connections from the data network. Use strong authentication and access control on the voice gateway system, as with any other critical network management component. Strong authentication of clients towards a gateway is often very difficult. Here, access control mechanisms and policy enforcement may help.
3. Use firewalls designed for VOIP traffic, through either ALGs or Firewall Control Proxies. Stateful packet filters can track the state of connections, denying packets that not part of a properly originated call. (This may not be possible/feasible, when multimedia protocol inherent security or lower layer security is applied, e.g., H.235 Annex D for integrity provision or TLS to protect SIP signaling.)
4. Use IPsec or Secure Shell (SSH) for all remote management and auditing access. If practical, avoid using remote management at all and do IP PBX access from a physically secure system.
5. If performance is a problem, use encryption at the router or other gateway, not the individual endpoints, to provide for IPsec tunneling.
The full article is definately worth a read. Those are general recommendations having to do with VoIP. There are also problems with SIP the communications protocol used by VOIP phones as well as problems with specific implementations.
After reading that article, I did some googling and found some interesting articles.
The first link is from Sys-Security. They are a cool group that I respect.
http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf
They talk about configuration vulnerabilities due to the use of TFTP amongst other things.
Cisco’s rebuttal is at http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a00800e251b.shtml
The second link is from British tech website, the register.
http://www.theregister.co.uk/2004/02/20/cisco_voip_kit_open/
Cisco hadn’t responded in time for the register article above. They respond in http://www.theregister.co.uk/2004/03/05/cisco_dismisses_voip_snooping_concerns/ where some security steps are detailed.
http://www.cisco.com/en/US/products/products_security_advisory09186a0080094ac6.shtml
http://www.securiteam.com/exploits/5HP0O0U75Q.html
I think that it is possible to deploy VoIP on an internal network in a secure fashion. However, security concerns must be addressed. Vendors should assist companies in implmenting a secure solution. After all we are all plenty busy trying to keep our computers secure. We dont need to add phone patch management to the problem list.
I went over to Cisco in Herndon this morning to see a presentation on Cisco's self-defending network. The goal of this product seems to differ from what I had been thinking of. My goal had been endpoint compliancy, and their product doesn't do that today at all. It may do it tomorrow or in a few months. I translate that into the 12th of never, or whenever we feel like it. I know they have the Cisco Trust agent coming out in July-August timeframe, so at least they are working on it.
Infoexpress has a product called Cybergatekeeper Lan and Cybergatekeeper remote. It allows the administrator to require that everyone on the network have passed an audit. It can check for the presense of antivirus software (by looking at processes, file versions and config files), that the AV software is up-to-date and configured correctly. If they dont have a template for the AV software you use, you can create one for yourself. The same is true for requiring patches or any other software. You can also prohibit machines with specific executables. You might do this to keep a specific virus off the network.
The problem with the infoexpess approach at present is that it is extremely manual. When sasser came out on a Saturday, I needed to write a rule to look for systems with that EXE.
Cisco does not currently match up at all with the infoexpress product. They are working on a product called the Cisco Trust Agent. They are partnering with the four leading antivirus companies to create a agent built into the AV product that will report to the cisco management device the status of the antivirus so the machine can be isolated if it is not up to snuff. Very little is available on this product as it is not released yet. However, I have been told that it does not do enforcement of other things like personal firewalls or patches. In fact we do not yet know what level of enforcement will be possible for the antivirus product. I like to require that all files be scanned for example.
Where Cisco gets interesting is in the IDS product. Generally IDSes have been something that you hang outside your firewall or just before your DMZ. This IDS goes on the core routers of the company. This way it can do enforcement on all internal traffic. So you may get infected because I cant force you to patch, but I can shut you down once you do get infected. Perhaps a reasonable accomodation to people who dont want me to have anycontrol over their system.
Another part of this IDS is the Cisco Security Agent. This is a host based intersion prevention system. It is behavior based in that it looks for activity it wouldn't expect for the role that you have assigned to the computer. If I say that a server is running IIS, the agent recognizes the correct behavior of IIS and will take action if IIS starts spinning out of control or contacting a bunch of other servers on port 80.
Another interesting security feature is 802.1x. If a user is authenticated, they are placed on the corporate lan. If they are not, then they drop into a restricted vlan that may have access to the internet only (still restricted by websense and behind the corporate firewall).
A lot of products in a short period of time, but it is exciting to see what can be done to keep the network safe. Speaking of safe, time to see if we can crack open the safe to get some money to pay for this.
An article over at ArsTechnica reports that 800 MB of Cisco source code related to the 12.3 IOS has been stolen. One of the sessions I was at at a BlackHat conference was on Cisco insecurity. It was really amazing to see the vulnerabilities they have had in their software over time.
Its too soon to speculate about what sorts of vulnerabilities will be discovered through this. I'm not familiar enough with Cisco to even know if that is a recent IOS version. It is safe to predict that the doomsayers will be out in full force predicting a full internet meltdown.
One thing I do know. In this instance, Cisco's network wasn't as self-defending as they would have prefered.
