From: john s w. <joh...@wo...> - 2012-07-20 19:40:50
|
That comment give a pretty clear starting point for IPCop virtualization. I can imagine building off of that description into various applications of virtual IPCop setups. On Fri, Jul 20, 2012 at 3:04 PM, Chad Neeper <cn...@le...>wrote: > 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* > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > IPCop-user mailing list > IPC...@li... > https://lists.sourceforge.net/lists/listinfo/ipcop-user > -- Cheers John S Wolter ------------------------ LinkedIn: johnswolter <http://www.linkedin.com/in/johnswolter> - Mailto:joh...@wo... - Desk: 734-408-1263 - USA, Eastern Standard Time, -5 GMT, -4 GMT DST |