Need advice for a corporate LAN/port/network security issue.
May 22, 2013 3:52 PM Subscribe
I have a corporate LAN/port/network security issue that I'm looking for some advice on.
Let's say you have an application server (AppServer) which has a good bit of sensitive data living directly on its harddrive.
Let's also say AppServer lives within a LAN (i.e., it is not in a DMZ).
Now let's imagine that a bunch of remote users (i.e., users who are not living within the same LAN) need to connect, using a thick application client, to AppServer.
Finally, let's say that, because of the cost of setting up a VPN server, a decision is made to just universally open up port 443 through the LAN, so that all of these remote users can talk directly to AppServer (via SSL) from their thick application client.
In this situation, what are the security risks of opening up port 443 like this? Also, is this reasonably advisable?
Let's say you have an application server (AppServer) which has a good bit of sensitive data living directly on its harddrive.
Let's also say AppServer lives within a LAN (i.e., it is not in a DMZ).
Now let's imagine that a bunch of remote users (i.e., users who are not living within the same LAN) need to connect, using a thick application client, to AppServer.
Finally, let's say that, because of the cost of setting up a VPN server, a decision is made to just universally open up port 443 through the LAN, so that all of these remote users can talk directly to AppServer (via SSL) from their thick application client.
In this situation, what are the security risks of opening up port 443 like this? Also, is this reasonably advisable?
What is the source, internet? Better make sure you have reasonable authentication set up through the application along with mitigation strategies to turn off accounts after they have failed auth.
posted by iamabot at 3:57 PM on May 22, 2013
posted by iamabot at 3:57 PM on May 22, 2013
The risk is that there are other insecure or poorly secured servers sitting on your LAN that shouldn't be available to the world. This includes emebeded devices. A lot of business printers/copiers with network cards have network management pages on 80/443. Do you really want to get 1000 printouts of goat.se from some bored pre-teen?
What you should probably do is setup a reverse proxy in your DMZ for the AppServer.
posted by sbutler at 3:58 PM on May 22, 2013
What you should probably do is setup a reverse proxy in your DMZ for the AppServer.
posted by sbutler at 3:58 PM on May 22, 2013
Response by poster: Yes, the source is the Internet. These are just users on various local, unrelated private networks.
posted by JPowers at 4:00 PM on May 22, 2013
posted by JPowers at 4:00 PM on May 22, 2013
SSL only protects the data from disclosure while in flight between the app and the client. It doesn't do a thing to protect the application against an attack. In fact, it may actually increase your risk a little. Some application-level attacks work by quickly renegotiating SSL sessions. Minimal work for the attacker, but a large workload for the app server.
You want a reverse proxy for this, plus strong authentication. Unless you've got rock-solid application code that sanitizes inputs and deals well with load, you're asking for trouble. As mentioned, the compromised app can also provide a pivot point for additional compromises within your network.
(Full disclosure: I work for a company that sells products in this space)
posted by jquinby at 4:03 PM on May 22, 2013
You want a reverse proxy for this, plus strong authentication. Unless you've got rock-solid application code that sanitizes inputs and deals well with load, you're asking for trouble. As mentioned, the compromised app can also provide a pivot point for additional compromises within your network.
(Full disclosure: I work for a company that sells products in this space)
posted by jquinby at 4:03 PM on May 22, 2013
So, the risk is two fold:
1) Authentication of users.
2) Mitigation of possible compromise of the host.
1) Is using multi factor authentication, requiring complex passwords, setting limits on failed attempts, etc.
2) Is isolating the host to a private vlan, putting it in a dmz, building defense in depth.
posted by iamabot at 4:05 PM on May 22, 2013
1) Authentication of users.
2) Mitigation of possible compromise of the host.
1) Is using multi factor authentication, requiring complex passwords, setting limits on failed attempts, etc.
2) Is isolating the host to a private vlan, putting it in a dmz, building defense in depth.
posted by iamabot at 4:05 PM on May 22, 2013
To jquimby;s point, an application firewall (f5, Imperva/etc etc) isn't a horrible idea.
Basically if you have a finite user pool, put the thing behind a VPN or define allowed incoming ip address ranges for valid users from the known private lans.
posted by iamabot at 4:07 PM on May 22, 2013
Basically if you have a finite user pool, put the thing behind a VPN or define allowed incoming ip address ranges for valid users from the known private lans.
posted by iamabot at 4:07 PM on May 22, 2013
This is just the sort of thing VPNs were made for. Ideally, you'd have a SSL VPN appliance, or a firewall with a decent SSL or IPSEC VPN server baked in - but you can definitely roll your own. With A VPN setup, your remote users can access your secure server without exposing it at all to the internet at large.
This way, no traffic from the internet reaches your LAN, only authenticated traffic over an encrypted tunnel from an end-user's PC or Mac or what have you... to your users, it's as if they're on the LAN. No hassles at all apart from launching and logging into the VPN client.
posted by Slap*Happy at 4:08 PM on May 22, 2013
This way, no traffic from the internet reaches your LAN, only authenticated traffic over an encrypted tunnel from an end-user's PC or Mac or what have you... to your users, it's as if they're on the LAN. No hassles at all apart from launching and logging into the VPN client.
posted by Slap*Happy at 4:08 PM on May 22, 2013
Yeah, a VPN wouldn't be a bad idea at all. As mentioned above, you can roll one for cheap. If you can authenticate the users against AD, LDAP, or something, so much the better.
posted by jquinby at 4:11 PM on May 22, 2013 [1 favorite]
posted by jquinby at 4:11 PM on May 22, 2013 [1 favorite]
Best answer: You are now trusting the AppServer for all authentication. If there is a way to either have privilege escalation, they can gain a foothold into the inner parts of the network. If the authentication part of the app has vulnerabilities, people can access the server.
Your security staff probably has a good bead on the security surface (patches, settings) for a VPN, they may have less knowledge of the AppServer, especially if it was custom made. I'd look for any security assessments made for the app server. People like to rely on external protection to cover up poor security. If it says something along the lines of "This server uses an out of date version of SSL, but we can mitigate that by only having people access it from inside the network" you've just stopped that protection. If you don't have a security assessment of the server, then you have no idea what the potential threat is.
Also, this wording:
a decision is made to just universally open up port 443 through the LAN,
Does this mean for the range of IPs belonging to the AppServer, or for the entire network. If it's the entire network, this is monumentally stupid. You are trusting that none of the boxes on the network are listening on that port, and that if they are, the powers that be secured them up to whatever standards you mandate. Things tend to be installed on networks and forgotten. You could have some years old xp box with god knows what http server installed on it, running god knows what scripts from some internal project that has absolute crap for authentication.
So, in general, I'd say:
1) Full blanket opening of 443 greatly increases the attack surface of the network, and as such greatly increases potential risk. If this is to be done (please don't), I'd advise a full assessment of the network, determining which boxes have that port open, followed by looking at the possible risks of opening them to the network.
2) If they are being smarter than that and just opening 443 to the range of IPs that make up the app server, I'd like an assessment of the security posture of the AppServer, looking for any vulnerabilities that might allow people to log on (logon timeouts, poor password rules), or exploit (old versions of software that could be exploited, potential avenues of what you can once authenticated). Basically, how easy is it to brute force logons to the box, and how easy, once you have, to get a root shell, or do some other damage.
3) What rules and procedures this data is restricted to should be known. There may be laws involved.
Within reason, opening up 443 to an isolated box that has a security posture is in some ways less risk than the VPN. But until you know the security posture of the box, or in the case of a blanket opening, all boxes on the network, you are going in blind.
posted by zabuni at 4:12 PM on May 22, 2013
Your security staff probably has a good bead on the security surface (patches, settings) for a VPN, they may have less knowledge of the AppServer, especially if it was custom made. I'd look for any security assessments made for the app server. People like to rely on external protection to cover up poor security. If it says something along the lines of "This server uses an out of date version of SSL, but we can mitigate that by only having people access it from inside the network" you've just stopped that protection. If you don't have a security assessment of the server, then you have no idea what the potential threat is.
Also, this wording:
a decision is made to just universally open up port 443 through the LAN,
Does this mean for the range of IPs belonging to the AppServer, or for the entire network. If it's the entire network, this is monumentally stupid. You are trusting that none of the boxes on the network are listening on that port, and that if they are, the powers that be secured them up to whatever standards you mandate. Things tend to be installed on networks and forgotten. You could have some years old xp box with god knows what http server installed on it, running god knows what scripts from some internal project that has absolute crap for authentication.
So, in general, I'd say:
1) Full blanket opening of 443 greatly increases the attack surface of the network, and as such greatly increases potential risk. If this is to be done (please don't), I'd advise a full assessment of the network, determining which boxes have that port open, followed by looking at the possible risks of opening them to the network.
2) If they are being smarter than that and just opening 443 to the range of IPs that make up the app server, I'd like an assessment of the security posture of the AppServer, looking for any vulnerabilities that might allow people to log on (logon timeouts, poor password rules), or exploit (old versions of software that could be exploited, potential avenues of what you can once authenticated). Basically, how easy is it to brute force logons to the box, and how easy, once you have, to get a root shell, or do some other damage.
3) What rules and procedures this data is restricted to should be known. There may be laws involved.
Within reason, opening up 443 to an isolated box that has a security posture is in some ways less risk than the VPN. But until you know the security posture of the box, or in the case of a blanket opening, all boxes on the network, you are going in blind.
posted by zabuni at 4:12 PM on May 22, 2013
Also, a coworker of mine made another point.
The traffic on 443 will be SSL. This is great for hiding the data from the Internet, but has the side effect of having all of this traffic be unecrypted, and thus, unscannable to any threat monitoring on your end. Any IDS's or IPS's will be rendered useless, as they won't be able to read the traffic.
posted by zabuni at 4:28 PM on May 22, 2013
The traffic on 443 will be SSL. This is great for hiding the data from the Internet, but has the side effect of having all of this traffic be unecrypted, and thus, unscannable to any threat monitoring on your end. Any IDS's or IPS's will be rendered useless, as they won't be able to read the traffic.
posted by zabuni at 4:28 PM on May 22, 2013
The cost of a full blown data leak is almost certainly far higher than the cost of a properly implemented 2 factor VPN. Therefore if management has decided to not do it the proper way, it should not be opened up at all.
That being said, SSL might be ok, so long as the software is always up to date, without a known history of secyrity issues, the logins are secure and protected against brute-force attacks, etc, etc. But if they don't want to invest in a vpn, they don't want to make sure the rest of it is up to par either.
Weigh having all your data winding up on the pirate bay versus allowing remote users.
TL; DR. If they *need* to connect, you *need* real security. Management knows better than this.
posted by TheAdamist at 5:29 PM on May 22, 2013
That being said, SSL might be ok, so long as the software is always up to date, without a known history of secyrity issues, the logins are secure and protected against brute-force attacks, etc, etc. But if they don't want to invest in a vpn, they don't want to make sure the rest of it is up to par either.
Weigh having all your data winding up on the pirate bay versus allowing remote users.
TL; DR. If they *need* to connect, you *need* real security. Management knows better than this.
posted by TheAdamist at 5:29 PM on May 22, 2013
Best answer: You should have a corporate policy that covers this situation, and that policy should be "never do this, ever". The gateway/firewall should be the only system that is accessible from the outside world. So I'm not clear on whether you have a network administration team available to you to do this work.
If you're on a shoestring and and don't have network operations staff for this kind of task and you have to hack something together on your own, then your capital expenditure for the network appliance may actually be quite tiny: a simple commodity router or single board computer with two or more ethernet interfaces running an embedded unix like (for exampie) pfSense will probably be perfectly adequate and dirt cheap: sub-$200. The staff time to configure and maintain it is actually much more expensive: assuming they're not familiar with it, figure about two days for a reasonably networking-savvy IT guy to set it up. It will have to be managed as well but mostly they just work once they're set up.
If you do have a network operations team, throw the problem to them and let them handle it. If this is a large company with lots of IT infrastructure they'll probably have specific vendor solutions they want to use.
posted by George_Spiggott at 11:57 PM on May 22, 2013 [1 favorite]
If you're on a shoestring and and don't have network operations staff for this kind of task and you have to hack something together on your own, then your capital expenditure for the network appliance may actually be quite tiny: a simple commodity router or single board computer with two or more ethernet interfaces running an embedded unix like (for exampie) pfSense will probably be perfectly adequate and dirt cheap: sub-$200. The staff time to configure and maintain it is actually much more expensive: assuming they're not familiar with it, figure about two days for a reasonably networking-savvy IT guy to set it up. It will have to be managed as well but mostly they just work once they're set up.
If you do have a network operations team, throw the problem to them and let them handle it. If this is a large company with lots of IT infrastructure they'll probably have specific vendor solutions they want to use.
posted by George_Spiggott at 11:57 PM on May 22, 2013 [1 favorite]
« Older Is it okay to plant pepper seeds from China? | Does the dot suffix of a website's name matter? Newer »
This thread is closed to new comments.
posted by jquinby at 3:57 PM on May 22, 2013