Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Software Windows Technology

Choosing the Right Security Tools To Protect VMs 44

Nerval's Lobster writes "Tech writer David Strom starts a discussion about how you should go about securing virtual machines for your organization. 'The need to protect physical infrastructure is well known at this point: most enterprises would balk at a network without any firewalls, intrusion prevention devices or anti-virus scanners. Yet these devices aren’t as well deployed in the virtual context. ... Take firewalls, for example. The traditional firewalls from Checkpoint or Juniper aren’t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers. Because VMs can start, stop, and move from hypervisor to hypervisor at the click of a button, protective features have to be able to handle these movements and activities with ease and not set off all sorts of alarms within an IT department.' He goes through the main functional areas that need protection, and points out that many vendors make it difficult to price out a given security plan."
This discussion has been archived. No new comments can be posted.

Choosing the Right Security Tools To Protect VMs

Comments Filter:
  • by Anonymous Coward on Tuesday July 03, 2012 @01:37PM (#40531703)

    They DO exist : Juniper proposes Virtual Gatezay, Trend Micro has Deep Security, etc.

    Do a google search sometimes ?

  • Uh what? (Score:4, Funny)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday July 03, 2012 @01:50PM (#40531853) Homepage Journal

    The traditional firewalls from Checkpoint or Juniper arenâ(TM)t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers

    So uh, how do those firewalls normally handle the "vast amount of traffic" originating from that many REAL systems, which can actually send MORE data than a bunch of virtualized ones?

    • by khasim ( 1285 )

      I think you're on the right track there. It isn't about how many machines ... or whether they're virtual or physical ... it's about the cat5 connections. (or cat6 or whatever)

      If you cannot manage the firewall so that the traffic over the data cables that are connected to it is handled correctly then find someone who can.

      It's all about correctly designing the network and segmenting the systems. Do NOT put your external servers on the same VM host as your DMZ servers and/or your internal servers. (Yes, I have

      • by kcbnac ( 854015 )

        Why not?

        With proper VLAN segmentation, it's fine. Heck, we have VLANs on top of VLANs. The blade chassis does VLANs for its internal capabilities, then via ESXi we have actual VLANs for the different networks.

        • Re:Uh what? (Score:4, Informative)

          by khasim ( 1285 ) <brandioch.conner@gmail.com> on Tuesday July 03, 2012 @02:51PM (#40532645)

          Because it puts you in danger from "VLAN hopping" attacks.

          http://en.wikipedia.org/wiki/VLAN_hopping [wikipedia.org]

          And if one of your external servers is cracked then you SHOULD distrust all the systems on that system. If they're all on the same VM host then you have a big problem.

          If they were segmented then the problem domain is reduced.

          Just because it can be done does not mean it is good practice to do it.

          • depends on your size as a company. The VLAN setup is likely the best you can do if you are a very small startup. It certainly is better then stuff we've all seen where the domain server is also the web server is also the DB server, etc.

            At some point you need to do better, but starting out I would say it's viable.

            On the flip side, if you already have enough demand to need the capacity for two blade systems full of blades, then you really should be physically segmenting stuff at that point.
            -nB

          • by drsmithy ( 35869 )

            Because it puts you in danger from "VLAN hopping" attacks.

            It's trivial to mitigate vlan-hopping attacks in several ways (the wiki pages covers two, a third is to simply use a physically different set of adapters for DMZ vlans).

            And if one of your external servers is cracked then you SHOULD distrust all the systems on that system. If they're all on the same VM host then you have a big problem.

            Uh, no. VMs can't just up and communicate with each other through the host at a whim.

            Just because it can be done does

          • by Vanders ( 110092 )
            That's why you have firewalls and network ACLs between VLANs.
          • by Anonymous Coward

            sure, at the fortune 500 scale you can probably justify this. anyone else who does not have multiple clusters of hosts cannot.

            as previous posters commented, vlan tagging and the fear of hopping is pretty easily mitigated, there are also fun things one can do such as disallow spoofed packets from vm guests.

            the odds of a meaningful exploit traversing the guest VM stack and into a hypervisor are pretty slim in my view, i see xen has one alert for something like this, but again...pretty slim.

          • How can you attack another VM on the same host? Seriously, I'd like to know if there's weaknesses in the hypervisor that could allow this?

    • Yes, of course the article's mostly confused. But there are a few issues that aren't fictitious, to go along with the ones that are.

      Inter-VM traffic is a problem, because it stays inside the server instead of getting out to where a firewall or intrusion detection system might see it, so there are cases where you might want either a virtual machine firewall or IDS, or need to move some of that traffic out of the server's virtual networks onto a physical Ethernet. I've been starting to work with Sourcefire

      • by swb ( 14022 )

        IMHO the real security issue isn't network traffic -- a bad virtual network design isn't worse than a bad physical design, the real security issue is in the hypervisor and hypervisor management. In large clusters, what vulnerabilities are there at the hypervisor level? Is it possible to inject a VM? Mask a VM from management software (ie, vCenter)? Change VM attributes (execution, memory, I/O priorities, virtual disk configurations, network access)? Initiate management controls (ie, self-vMotion)?

        Right

    • by zlives ( 2009072 )

      you fail to see the marketing potential of this article.... buy buy buy

  • The traditional firewalls from Checkpoint or Juniper aren’t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers.

    LOL very funny. If it were true, which it is not, but for the sake of argument were it true, then you'd just use the magic of VLANs to put a tenth on each of ten VLANs, and have 10 firewalls run in parallel.

    Traffic is parallelizable. This is not the famous "nine chicks give birth to a baby in one month by cooperation" situation. This is more like you got 9 inches of old fashioned printed paperwork, and 9 interns who can only handle one inch of paperwork each, hmm I wonder how that works.

    • by sconeu ( 64226 )

      So it's like Snow White complaining, "Yeah, you promised me 7 inches... but not one inch AT A TIME!!!"

  • by the_humeister ( 922869 ) on Tuesday July 03, 2012 @01:59PM (#40531983)

    Itanium emulation! You can't exploit hardware that no one runs!

    • by CAIMLAS ( 41445 )

      That will only go so far. Architecture-agnostic code is fairly common these days; an exploit for, eg. SSH is likely to work on many platforms.

      Running NetBSD on MIPS or something like that does have a somewhat inherent advantage in that regard, though. Ecological diversity leads to robustness.

      • by DarkOx ( 621550 )

        I doubt it. I would say an exploitable bug in SSH is like to effect multiple platforms. Its highly unlikely and shell code will be cross platform. Which might save you from the script kiddies running metasploit, but not from anyone who knows a little C.

  • This is just and ad for trend micro.

    • by jerpyro ( 926071 )

      And an effort to get the writer some "I've been published" resume building cred.

      Either way the article isn't helpful, nor does it provide any insight. Save yourselves the 20 minutes.

      • 20? Man, you must read slow.

        I just wasted 2 minutes, dismissed the article as shallow and ill thought out pap, and thought I'd see how many others thought the same.

    • Well it it's not an ad for Trend Micro's Deep Security it is definitely a setup for one since there the only company that uses the VMWare's vmsafe and epsec api to achieve agentless antivirus, firewall, application control, deep packet inspection, virtual patching, and file integrity checking meeting 6 out of 12 PCI requirements all from a single console.
    • +1 We're a Trend shop, and we investigated Deep Security (antivirus and soft firewall that runs at the hypervisor level, so no client on your VMs) but it was ridiculously expensive compared to running Officescan with Intrusion Defence Firewall on each VM. It is more efficient in terms of host resources, but we've got IO and CPU to burn, so there was no return for the huge cost.
      I hear they may be moving away from a per VM licence, so it may become financially realistic for us. But for now we're sticking wit

  • I may be a little dense here, but I can't figure out why you would be exposing your VM host in such a fashion that you would need some special security measures. I'm just running KVM, and my hosts sit on the internal network. When I need direct access to virsh it's via SSH and if I need direct access to a guest's console it's via VNC over SSH. Moving guests around isn't really different than any other sort of network traffic, and is done via encrypted connections. Individual guests (like a mail server or we

    • Once you understand what a Slashvertisement is, you will understand the point of this article.
    • The main problem is that VM-to-VM traffic doesn't always head out over a physical network. It's easy to put a firewall between different sections of a physical LAN; it's a good deal harder to put it between different sections of a single physical computer.

      • Iptables doesn't really care whether the network interfaces it's working on are real or virtual. If you have a problem with configuring iptables to deal with virtual networks on a host, then I'd say you've got bigger problems than just securing communications between guests.

        I've had no problem setting up firewalls between guests on the same machine. I have two hosts that serve two different networks each, and the rules controlling the guests on both networks are not any worse than any other firewall rules.

      • by drsmithy ( 35869 )

        The main problem is that VM-to-VM traffic doesn't always head out over a physical network. It's easy to put a firewall between different sections of a physical LAN; it's a good deal harder to put it between different sections of a single physical computer.

        How are you firewalling traffic between two physical machines plugged into the same switch and on the same vlan ?

    • by fak3r ( 917687 )
      I'm with you, I've built a few networks of VMs, and my latest has an OpenBSD KVM host as the gateway - what is the fear this article is trying to perpetuate? Maybe it's BE AFRAID, BUY MORE NETWORK APPLIANCES!
  • linux iptables or windows firewall can be used to filter traffic between VMs. Network firewalls can be used for the traffic that actually leaves the physical host. It is safer to make assumption that all VMs on the host share the local network and therefore if they need to protected from each other that is responsibility of the guest system.
  • by mseeger ( 40923 ) on Tuesday July 03, 2012 @02:58PM (#40532773)

    When did he do his last google search?

    Must be some time, otherwise he might have found Firewalls from "traditional vendors" integrated into the Hypervisor like https://www.checkpoint.com/products/security-gateway-virtual-edition/index.html [checkpoint.com]

    The product is on the market for some years now....

  • Terry Tate is the man.

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Working...