Moving JSS into the DMZ

[tuinte]

Hey there, best community in the world:

We have Casper set up on our internal network, everything working pretty much as we like it. The request now is to make Self Service available to our users outside our network.

I've read the article at https://jamfnation.jamfsoftware.com/article.html?id=174, which discusses setting up a second JSS, in the DMZ, and pointing it to the internal one. I may be missing a whole lot, but would it not be possible to just move our current Casper server (JSS and Distribution Point on the same box) into the DMZ and be done with it?

Thoughts?

[hkim · Accepted solution]

Serious security concerns. Because now you have the only JSS exposed to the internet, including your MySQL database, you just opened yourself up to one password hack away from hosing your entire JSS infrastructure.

By putting a limited JSS in the DMZ, you limit exposure because the JSS web interface is disabled, the server can only accept connections from enrolled clients.

Consider your bandwidth concerns as well before putting Self Service out on the DMZ. Depending on your situation, do you really want to host large packages and allow users off your network to take up your internet upload bandwidth with downloading packages? Although additional cost, would it be better to host a 2nd JSS / Distribution point in "the cloud"?

[JPDyson · Accepted solution]

The bandwidth one can be cleverly handled with network segments (limit "sensitive" policies to internal segments).

[JPDyson]

If your org allows it, it's possible. They might have security concerns (justifiable ones).

[hkim · Accepted solution]

Serious security concerns. Because now you have the only JSS exposed to the internet, including your MySQL database, you just opened yourself up to one password hack away from hosing your entire JSS infrastructure.

By putting a limited JSS in the DMZ, you limit exposure because the JSS web interface is disabled, the server can only accept connections from enrolled clients.

Consider your bandwidth concerns as well before putting Self Service out on the DMZ. Depending on your situation, do you really want to host large packages and allow users off your network to take up your internet upload bandwidth with downloading packages? Although additional cost, would it be better to host a 2nd JSS / Distribution point in "the cloud"?

[mm2270]

Agreed with hkim, for all the reasons he stated.

That said, I do know there are some environments that have chosen to just open up their JSS to the outside and weren't concerned about it. Whether that was just blissful ignorance or that they weren't high profile targets, etc, I don't know. But before JAMF had a supported and documented method of setting up a clustered JSS setup like that, some organizations did exactly what you're stating. I'm not sure how well that worked for them in the long run though. Given there is a way to do this now that many are doing, I would recommend following that process.

[JPDyson · Accepted solution]

The bandwidth one can be cleverly handled with network segments (limit "sensitive" policies to internal segments).

[tuinte]

Thanks everyone for your contributions.

I had considered bandwidth issues and, in a manner like JPDyson suggests, I think I can control that satisfactorily.

Definitely appreciate the security concerns, though. I'll be having a meeting with the powers that be for a nice discussion on this. The pain for me isn't setting it up, it's getting them to authorize the purchase of a new box to host it.

[benjamin_michae]

One more thing to consider then tuinte as you could use a VM as your JSS in the DMZ. For that matter, you could use an Ubuntu VM if you are comfortable with it. That would likely reduce your cost significantly and still allow you to get the full breadth of functionality from the JSS in the DMZ. Something to consider!

[franton]

As everyone else has mentioned, moving the entire box into the DMZ is a security nightmare. If you're reliant on AD logons then that also means tunnelling a hole through your firewall to let AD info in and out. That's the kind of thing that gives security pros heart palpitations!

A far better solutions (which is what i'm currently implementing where I am), is to use a clustered JSS set up with one JSS inside your network and another restricted JSS in the DMZ.

For further security, both of these JSS should have your database stored on a separate cluster MySQL server setup. This is done for security, reliability and scalability as your organisation requires.

Lastly we're doing all of this with RHEL 6 based VM's. You'll have the advantage of Red Hat's support without having to buy lots of commodity hardware.

[franton]

I almost forgot. You'll need some sort of externally available distribution point. Without this, your external clients will be able to connect but any policy you have that involves scripts or packages will fail without this.

A slow but reliable method would be to set up "yet another RHEL 6 VM" (tm) with the Apache webserver and have an HTTPS only D.P.

[nessts · Accepted solution]

you can reverse proxy from the external to an internal http server works for me in my lab so far.

[RobertHammen]

Depends on the size of the organization... if you move the whole box into a DMZ, at a minimum you'll need to open TCP ports 8443 and 80 (assuming you're using http distribution points) to the outside world. You'd need to have these ports, plus AFP or SMB (assuming you're using Casper Admin), and possibly ports for AD/LDAP to the device.

I am a big fan of the limited-access machine in the DMZ approach - still need 80 and 8443 exposed to the outside world, but your admin/web console isn't exposed.

For most of the clients I've implemented this for, they've used a physical machine in the DMZ, with the server(s) internally running on VM's... all Win2K8R2.

[tuinte]

Thanks everyone for their input.

I got an OK for a Mac mini to set up as limited external JSS. Will reverse proxy to an internal HTTP DP as per nests suggestion.

Very helpful.

Michael

[ImAMacGuy]

i'm trying to fill out our change form to get the ports opened up for the limited access jss...

can someone tell me if these are correct or what's missing/can be removed?

dmz.jss.com 3306 --> internal.jss 3306 - MySQL
dmz.jss.com 25 --> internal.smtp 25 - SMTP
dmz.jss.com 389 --> LDAP server 389 - LDap
dmz.jss.com 8443 --> dmz.jss.com - not sure on this? Would it be the internal server or the dmz's?

[tlarkin]

Hi Everyone,

I am chiming in late here, on an old thread but I think some information may give more insight to people who want external access to their JSS from off premise clients. Typically, this is how I design the network infrastructure for these scenarios that allows for both secure practices and scalability. The most typical setup with out going into too much of org specific needs, is as follows (in no specific order):

1 - HTTP proxies in the DMZ redirecting traffic to an internal load balancer, SSL terminates at the load balancer
2 - Set up multiple web apps in the data center, 2+ which are client facing and limited access which the load balancer points to, one clustered web app that is set to the side as the master web app and admin console
3 - Scale web apps and database to handle all connections | bandwidth | and usage of the Casper Suite

This way you aren't putting a web app in the DMZ with access to the database, and any web app the client hits from the URL, is all limited access. The only way to get into the JSS is to actually hit the hostname of the master web app directly, which can be behind a secured VPN connection, or it can only be accessed via secure org network. The proxies can also be behind an external load balancer for scaling and redundancy. That way if a proxy goes down or gets overwhelmed it will load balance to the next available proxy server. Proxy servers also add more layers of security since you can control and throttle traffic. You can also set up filters to view and log all incoming connections, as well as limit and control a plethora of other things.

Now when your needs and infrastructure grow, you simply just need to add proxies in the DMZ and web apps internally. All credentials are on data center servers in your company's secure data center, and all connections are routed specifically to that load balancer, and all web apps the load balancer points to are limited access. So there is no way for anyone to login to a web app at all, nor can they access the file system of the web apps host. You can also leverage all your reporting tools you use on your server side infrastructure to monitor things like disk I/O, network connections, bandwidth, RAM and CPU usage, and so forth. This way you can proactively scale your infrastructure out and spin up more web apps and simply add them to your cluster and modify your database accordingly to match what you have added.

Of course putting a web app in the DMZ is also always an option. I think it highly depends on many factors. This also is not the gospel of JSS infrastructure design. You could use other design methods. I am just sharing this as an idea that is some-what typical with some of the customers I have worked with or currently work with.

I hope this helps out on this topic.

Thanks,
Tom