Best Practices

We have 80 laptops that mainly stay off-campus or use the public wireless when on campus.  We had to open only the two ports in the firewall and so far only problem was some strange machines started showing up from a company back east and contacted them and it was from some misconfiguration they did and it pointed their clients to our IP. When their machines did check in they were at our mercy, not the other way around.

We feel it is worth it to open it up now we see the laptops check in and they also get critical patches this way, this is handy only half of the laptop users are admins on their systems

For the best possible security you will want to enable SSL and get yourself a publicly signed certificate. I had my K1000 outward facing for a few years without incident.

Remote management is always a bit difficult, especially when a Replication Share is not an option. The vpn script idea isn't bad for inventory purposes, just realize that you could potentially be pushing software and patching across the WAN.

As the KBOX can be put in the DMZ or behind the firewall, we recommend behind and just install agents with a public dns or ip address so that it connections thorugh your firewall. This reduces your exposure as mpace indicates you want to enable SSL and then only have to open port 443 in your firewall for connections. 

That has been the best option for post people, as if they get past your firewall, you probably have bigger issues to deal with other then them getting to your kbox.

Now if you already deployed agents to these machines that are outside the network, it may require removing and reinstalling them so they have the FQDN as their host name. 

Smal is right any computer that does stray in would be at your mercy not the other way around. 

BY using ssl you are no moe exposed than running a public webserver on unix and php

Thank you all very much for the replies.

Assuming we opened 443 through the firewall, would we still be able to push updates/packages to the machines? I understood that the AMP service port would also need to be opened (tcp/52230). It seems that 139/445 is only needed for provisioning, there is no way we'll be opening these - Smal, do I understand correctly that with tcp 80/443 and 52230 open you are able to push updates and get inventories from the clients? I'd imagine it needs the cifs ports open to be able to push managed installations, or are you able to do this with just AMP/HTTP(S)?

Once open, I would imagine this would give access to the /admin section as well, which does not seem to have any rate limiting or brute force protection. Has anyone run this through a reverse proxy? This might be a way to only allow access to the "user" parts of the web ui.

We're still looking at the vpn route, but this is more of a culture problem, I'll post back if we find a good way to force regular "roadwarrior" vpn connections - since these would connect over the same medium as https clients, we dont really have a bandwidth benefit either way.

Thanks again - your experiences have been very helpful!