?-----Original Message-----
From: Mark Jones
Sent: Friday, February 04, 2011 2:54 PM
To: [email protected]
Subject: [pfSense Support] Firewall security compromised by auxillary
programs?
Well, I hear of people running pfSense in a VM, and I wonder how do you
avoid exposing the host OS to the network? How can a firewall be run in a
VM and not leave the host OS hanging out to be attacked? Or, go the
otherway and put the VM in the FreeBSD used by pfSense since there is plenty
of excess CPU and memory to do the trick. Only getting vmware to run on
pfSense FreeBSD might be difficult (I haven't actually tried it) given the
very few pieces of FreeBSD that are present in a pfSense environment.
Yes, I agree that having a jabber server on the firewall is less secure than
not having a jabber server, but I question it being less secure than having
it on my internal server. If it is on the pfSense box and becomes
compromised, the hacker will need pfSense skills to get any further, then
they will need an additional set of skills to get at my primary servers. If
I open the ports that the jabber server uses, then they have access to my
primary servers via the jabber server software because the firewall is
permitting connections into and out of the network on those ports.
Admittedly running log digesting software increases the attack surface if
those program actually use networking services, but if they are
self-contained, the attack surface doesn't change. Adding a website (like
say the pfSense PHP website interface) increases my exposure as well, but
yet we do it to facilitate easy configuration.....
If this analysis is wrong, please someone point out where it is wrong. This
assumes that the jabber server only opens the ports for XMPP and nothing
else, no management ports etc.....
--------------------------------------------------------------------------------------------------------------------
I currently run my pfSense firewall inside VMware Server on a Windows 2003
box. I set it up with 2 dedicated physical NICs for pfSense for WAN and LAN
as well as 1 virtual NIC for all other VMs.
the 2 Physical NICs have every protocol/program/connector turned OFF on them
except the VMware bridge, meaning that as far as windows sees, there's
nothing on the interface to talk to. aka, by default, the host system has
ZERO network connectivity for itself.
the Virtual interface is used for a virtual network on the server for all
other VMs that need network access as well as internet access for the server
itself.
inside PfSense I have the virtual interface set up as opt1 and put in rules
so that opt1 and LAN can communicate with each unhindered. This also means
that anything on the physical LAN network wanting to talk to the physical
server host has to pass thru the firewall first, meaning I can put rules in
place if need be to filter on internal side.
overall this gives my network a single server that handles both my Windows
file share, FreeBSD hosting servers and my firewall while keeping them all
properly set up separately on a logical network level and yet physically on
the same hardware. It is also set up in VMware that if the system crashes,
the pfSense VM will be rebooted automatically. I have even created a VM with
snort running that tapped into the same physical interfaces parallel to
pfSense and has granted me some awesome level packet capture as it will run
bus speed with only a single interface instead of 2 for physical install
(you do have to manually disable transmission on the listening interface
though inside the VM, which varies by OS)
if you have the resources, I would actually recommend use of VMware ESXi as
the host since it lets you configure virtual switches and gives much tighter
control over how the VMs and logical systems are configured.
doing it the other way and running jails/VM inside the firewall I feel is a
really bad idea as nothing should ever be run under a firewall host. you
could have a glitch and have a jail cause a kernel panic and crash the host.
-Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Commercial support available - https://portal.pfsense.org
