On Wed, Feb 07, 2007 at 06:11:56PM -0600, Ron Johnson wrote: > On 02/07/07 17:04, Andrew Sackville-West wrote: > > On Wed, Feb 07, 2007 at 04:56:31PM -0600, Ron Johnson wrote: > > > >> Have the firewall *redirect* incoming imaps requests to your server. > >> > > > > and that is what I currently do. And its a great use for this old 486 > > that currently runs the firewall. I'm just looking at other > > possibilities to cut down on power usage and the all important > > available horizontal surface space. I discussed this issue a while ago > > with no real resolution, hence my question. > > > > So running the service (IMAPS) in this case on the same box as the > > firewall exposes that firewall machine to direct attack if there is a > > compromise in the IMAPS server. This makes sense. But how exactly is > > that different from my current setup where the IMAPS server is run on > > a machine within the greenzone of my LAN.... hmmm... not really > > different at all in that a compromise on that server is still inside > > the lan. So in my now obviously bad setup it doesn't matter either > > way: a compromised IMAPS server is a compromise on my lan. ugh. gotta > > rethink all that. > > Yes, a compromised IMAPS daemon will leave your main server > vulnerable to attack from packets redirected from the router. > > > What about running servers in sandboxes (virtual machines or > > chroots). I could move the only externally visible service (IMAPS) to > > a virtual machine or a chroot on my server and tie it to one of the > > two nics. THis would put that service in a sort of orange-zone. And > > with the right configs, so that it only accepts requests from the > > fire-wall and not anywhere else on the lan, isolate it even more. > > AKA a DMZ. That's a interesting thought: putting a DMZ inside a vm > on your main server. I wouldn't trust a chroot, though. thank you, DMZ. stuck on that smoothwall terminology. red/orange/green interfaces. the trick with the DMZ in a vm is tying the right nic to the vm and *only* the vm. I suppose its another vulnerability point, that connection, in that if you could break out of that connection you could be connected to the main server. I'll have to look into this a bit. I just hate to put another machine on-line (I've got 5 running now with the firewall, server and 3 desktops in the house).... a little googling turns up several options using xen or uml to run virtual firewalls and virtual public servers. sweet. I thought about it for a minute too -- which makes more sense: a real firewall or a virtual firewall and i guess a virtual one makes more sense. A virtual firewall cracked leaves one with root on a virtual machine... a real firewall leaves one with root on a real machine. Likewise for virtual public servers. Granted there are probably ways out of a vm, but its gotta be harder than getting out of a real machine. I'll report back. A
Attachment:
signature.asc
Description: Digital signature