Re: [IPCop-user] want to setup a virtual IP cop system and simulate connection

[Chad N. <cn...@le...>]

On Tue, Jul 17, 2012 at 8:08 PM, john s wolter
<joh...@wo...>wrote:

> Jim
>
> It would work, yes.  There is a need to build virtual infrastructure for
> production not just testing.  That is the future.  Every distro needs to
> anticipate going virtual including IPCop.  That is step one.
>


> On Tue, Jul 17, 2012 at 7:58 PM, Jim Stephens <jw...@jw...> wrote:
>
> > On 7/17/2012 11:14 AM, G.W. Haywood wrote:
> > > I recommend that you do not attempt to do this using virtual machines.
> > > IPCop is a very undemanding package,
> > I think in reading the request, he wants to do tests where he can do
> > live scenario.  I didn't get that he wanted to do it live for the
> network.
> >
> > I may have confused things with my post about it being feasible to do so
> > with vmware esxi 5 and I agree that it probably isn't a recommended
> > solution.  However it would work.
> >
> > Jim
>
Just to chime in with my own experience:

Recommended or not, I've been running IPCop in numerous small PRODUCTION
networks as virtual machines for over nine (I think) years now. With very
careful consideration to how the host is configured, I don't believe any of
my hosts have ever become compromised nor has the networks in general
become compromised as a result of running IPCop as a VM.

Specifically, with regards to the IPCop virtual machines...I've found it to
work quite nicely and reliably as a VM. In fact, I find using VMs to be
considerably easier than physical computers. For instance, it is a simple
matter to shut down a VM, make a copy of the files on the host that
comprise the VM, and then turn the VM back on again. Then you can play
around with your config, install your add-ons, etc. and have complete
confidence that it really doesn't matter if you hose up your VM. If you do
irreparable damage, simply shut down the VM and copy your backups back into
place. No re-installation and recovery from IPCop backups required. It's
literally as if you shut down IPCop ...and then powered back up again later.

So anyway, we know that IPCop as a firewall is rather secure.  :-)  So the
trick is to ensure that the VM host itself is secure. When I started out, I
was using a Windows XP Pro host, VMware Workstation as the hypervisor, and
IPCop (among others) as a virtual machine. Typically, I'd have three
physical NICs in the host server, one each representing RED, GREEN, and
BLUE. I always also configure an ORANGE, but it's always purely a virtual
NIC connected to another VM running an HTTP server and also connected to
the same ORANGE dmz. To secure the Windows host, I simply did not bind
TCP/IP to the physical NIC on the host. With TCP/IP not being bound to the
Windows host, the attack surface is pretty much limited to a MAC
spoof...which would have needed to occur between the router and the host.
Since the router and the host are directly connect to each other, anyone
attempting that type of attack would have had local physical access to the
host anyway.

With VMware Workstation, the virtual IPCop only needed the physical NIC for
RED to be configured and available. It doesn't care if the host itself has
an IP address or can communicate via that same physical NIC. So, while the
host DOESN'T have the ability to use the physical NIC connected to the
Internet, the VM DOES. So what I ended up with was a Windows XP host
computer running a bunch of virtual machines (servers). The host computer
could only be managed locally with direct physical access to the computer.
The VMs, however, had full network access and didn't care one way or
another what the host could or could not do.

In other iterations, I had the same WinXP host/VMware config, but DID bind
TCP/IP to the physical NIC attached directly to the Internet. In a case
like this I would always configure the host's personal firewall to ONLY
permit access via SSH from select IP addresses for remote control
purposes...BEFORE physically plugging the "RED" NIC into the router.

In other iterations, again with the same WinXP host/VMware config...did NOT
bind TCP/IP to the physical NIC, but DID bind TCP/IP on the physical NIC
also connected to the IPCop VM's GREEN interface. The host's personal
firewall was configured of course. Then, using a site-to-site VPN
established by the IPCop VM, was able to connect to the host computer for
remote control.

These days I'm essentially still doing the same thing, only using VMware
ESXi version 3.x, then 4.x, now 5.x hypervisor. The host, even though it
has a NIC that is physically and directly connected to the Internet router,
remains secure from remote attacks because the host isn't listening on that
physical NIC. The only device listening on that physical NIC is the IPCop
VM's RED interface. All of the other VMs are behind and protected by IPCop.

Many years and counting. To the best of my knowledge, I've yet to
experience a problem with the configuration.

Be aware, though. This is not likely to be a recommended configuration and
no doubt carries a certain level of risk. There is always someone smarter
than we are who will (or more likely already has) devised a way to get
around every road block we put up.

But the moral of the story is that you very certainly CAN run IPcop in a
VM...and quite well. It's a great environment for production and better yet
for testing. I've found that once I started using VMs, they are so
beneficial I have no intentions of ever going back to running any one
single server on any one physical computer (Unless, of course, a single VM
requires so much capacity that it's the only VM running on a host...and
even in that scenario, a VM has benefits).

My 2 cents,

-- 
______________________________
*Chad Neeper*
Senior Systems Engineer

*Level 9 Networks*
740-548-8070 (voice)
866-214-6607 (fax)

*Full LAN/WAN consulting services -- Specialized in libraries and schools*