The v5 administrators guide says, and I hope it's ok to quote, that "The server exposes the Object Directory via fully routed TCP/IP, meaning that access to the Object Directory can be safely exposed to the Internet / Intranet, allowing clients to connect wherever they are. As all communications between the Server and client are encrypted and authenticated there is no security risk in exposing it in this way."
Are people out there doing this safely? It seems to say (quite outright) that it's safe to open up this port to the Internet and that my server is still safe and that Safeboot doesn't become more vulnerable. I'm interested in hearing what others are doing. I've heard that some customers put up a secondary server in the DMZ that talks to the primary servers database, but why have a second server up if I don't have to?
This is indeed true, and it always confused me, because then you have to route netbios through the DMZ to the internal network.
I'm not sure, but I'd rather be routing one port from the outside edge of the firewall to one port on a named address, than NetBIOS through my DMZ any day of the week..
And there's also the fact that the server>db traffic is around 20x more than the client>server traffic, so you're pulling the db server down as well.
Not something I recommend, but I suppose people try to do it because the presentation and database layers are shared in the SafeBoot architecture (for speed) - people don't consider the fact that the classic webserver/sql server architecture might not be appropriate.
This is really useful information! Along with the fact that it appears it's supported (and recommended) by McAfee to just open the port, I suppose this is the better way to go. Along with the external DNS name being "generic" (and not SafeBoot5.myCompany.com) and perhaps changing the port the clients communicate over it would seem to be a pretty safe way to go.
I received another suggestion to allow clients to synchronize with a virtural IP setup on the firewall. The firewall then uses port forwarding directed to the safeboot server. I have not implemented this yet but hope to in the future. The summary of the document is listed here:
How to Allow SafeBoot Clients to Synchronize Via the Internet
Summary All communication from SafeBoot client to SafeBoot server is done securely via TCP/IP. Using this standard makes it simple to create an infrastructure that allows encrypted SafeBoot clients to synch to the SafeBoot server via the internal network or via the internet. Here are the basic steps to setup such an environment: 1. Make a virtual IP address on your firewall and use DNS to make this IP and the SafeBoot server’s IP resolve to the same DNS name. 2. Ensure that your encrypted clients point to this DNS name. 3. Use port forwarding on the firewall to allow all traffic on the SafeBoot ports to go through the firewall and reach the SafeBoot server.
We have our SB server sitting in the DMZ (local DB, not SMB attached), but set a pseudo generic DNS name and custom port.
As far as exposing the DB, we thought that it was a small risk with large rewards. The traffic is encrypted and clients will only synch if the DB certificate is a match. The benefit we get, is that we can publish a kill policy for a machine and the machine will die if it ever connects to the internet (instead of having to be on the company network or VPN). Admit it, users are lazy... they will do stupid things, like write down their ID/password on a sticky note on the computer. If thief uses those credentials and is connected to the internet, it will kill the machine. It also helps when an employee decides to keep their laptop after being terminated, so you can lock them out if they ever connect to the internet.
We didn't want to wait for the isolation period to expire before we could consider the machine "safe". Even a few days is plenty of time to get the data out.
As far as the SB server being vulnerable on the internet... I'm not that worried about it. The only patch I've seen for the SB service was at least 18 months ago. It was a DOS attack, where you could kill the service by providing a REALLY long password.
Thanks MrGUI, it's nice to know that there's someone out there who's done what I'd like to do. Our users are forced onto VPN by the need to check email, connect to CRM applications, hit file shares, etc. so they would be only quite regularly, but a would be thief or a user who decided to keep a laptop they were supposed to return would be less likely to connect up to VPN.
I like the kill pill idea, too - I played with this for internal users during a pilot and it was pretty cool that when a system connected up we could blow away the assigned user accounts and force the machine to lock without any (easy) way to unlock it.
I'm interested in the thought process though re putting the server in the DMZ (I'm assuming JUST the server, not the DB as well?). I can't get out of my head the risk of routing netbios through to the internal DB host rather than one single port being more risky... At least with the one SafeBoot port all it can do is be naughty to SafeBoot. With NetBios there's no end to the naughtyness it can cause..