Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We already have a couple of people working from home, accessing some internal servers via VPN. They're all using company provided laptops or PCs which we have complete control over. Now we're faced with more people wanting to do home office but using their own machines. They need access to at least our internal IM and fileserver.

Giving them VPN access to our internal network from their own machines seems to pose a potential security risk. I'm mostly concerned about giving them access to our samba fileserver. What has been suggested is to simply rely on an on-access virus scanner protecting the fileserver, but I'm not completely convinced this is sufficient.

Is there some kind of access-proxy or something like that which we could put into an DMZ and only allow outside access to that server, do some kind of scanning/filtering and have them access our internal servers from there? Preferably opensource/linux based as we're mostly using CentOS/RHEL for our servers and would like to keep it that way (opensource shouldn't imply we're not willing to pay for it, just need some ideas or products which we could look at).

share|improve this question
up vote 3 down vote accepted

I'd be loathe to give VPN clients in such a scenario unfettered layer 3 (and up) access to my network. Aside from whatever application-layer tools you're going to use I'd be very draconian, at layer 3, about what the remote VPN clients can "talk to".

If you're worried about protocol-level attacks against your file server you might think about exposing the file server via a WebDAV over SSL gateway. WebDAV is arguable a more "auditable" protocol than SMB and most versions of Windows and many Linux distros handle accessing files via WebDAV very well.

In terms of the classic "confidentiality, availability, integrity" attacks against your file server by these VPN clients I think you're going to have trouble finding a "magic bullet" solution. Assuming these machines are "owned" by third parties (malware, etc), you have to assume that keyloggers could be present (thus implying the need for one-time-password functionality in a trusted device). Anything the user will have rights to access (modify, etc) will be available to the malware on these machines as well.

Given how little I'd trust personally-owned computers I'd lobby hard for giving the VPN users access to compute resources hosted on trusted computers via a "thin client" protocol-- X Windows, RDP, PCoIP, etc, and require them to use a hardware token for one-time-password sign-on. It's still not perfect (since data could be injected into or pulled out of the thin client protocol stream by a malicious third party) but it keeps direct access to the data away from the remote client computers.

share|improve this answer
+1 for the thin client suggestion – Javier Dec 2 '10 at 19:07
The thin client/terminal server idea absolutely hasn't been considered so far, but I like really really like it, as I'm with you not trusting personally-owned machines at all. – toString Dec 2 '10 at 22:16

Something like a Juniper SSL VPN comes with a Windows component called Windows Secure Access Manager that isn't quite a proxy or firewall, but it lets you specify applications (and MD5 hashes to ensure it really is the app) and source destinations and ports.

That may be an option for the IM stuff.

File shares is a tricky one as even using that sort of component you still have drive or UNC access in Windows, least I don't know of a way to restrict it to read-only at the VPN level.

Depending how much access they need, one option would be to use the web file access component of the VPN, that way they have access to the files but using a web interface, no SMB access.

Also with a commercial VPN you get host checkers so you can mandate that machines must have AV and it must be up to date, and if it isn't, come back and try again when you meet the rules.

share|improve this answer
"Network Access Protection" and the like (mentioned in your last paragraph) is all a big farce unless it's running on cryptographically trusted hardware (think machine w/ TPM and trusted boot environment). You can ask my computer "Are you good?" all you want and, unless there's a root of trust in my computer that you trust, my computer can just lie and say "Oh, yeah-- we're all good here." All types of NAP / NAC schemes suffer from this fault-- the machines being tested must be "trusted" to begin with or it's all a meaningless farce. – Evan Anderson Dec 2 '10 at 18:37
Of course, but how far do you take it in a typical business environment before you let a machine get to the logon screen? You're right it's not perfect, but I suspect few SMB's can afford to truly enforce "trust". – Hutch Dec 2 '10 at 18:49
That's why I'd suggest treating the clients as untrusted and using a "thin client" method of access rather than using something that lulls you into a false sense of security re: the state of the clients. – Evan Anderson Dec 2 '10 at 18:52

We have numerous folks connecting remotely from their own PCs. We use Winfrasoft enterprise edition ( which checks the client for requisite security patches, anti-virus software current, connection sharing disabled, etc.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.