Securing a Private Intranet?

crustythecrab asks: "My company wants to take a web-based data management system I wrote which runs on a closed network not connected to the internet and put it out on the net so everyone can access it remotely. The number one issue of course is security, and I've been asked to write a paper on how to make the system 'secure' in order to convince management that it will be safe to proceed. But the question runs through my mind: How secure is 'secure'? I'm running all UNIX, no Windows of anything on the server side, and I'll certainly recommend a VPN, but since nothing is 100% secure, I was wondering what the current state of the art in 'Intranet' security is. Are there any novel new concepts out there. Or do you just put up a VPN and hope for the best?"

It might be too late...

[twoflower]

Unfortunately, security isn't something you can bolt on to an application after it's developed; it has to be part of the design process. For a great example of some of the things that you should already have done, read the file SECURITY included in the qmail distribution.

Use an IPsec VPN

[dragonfly_blue]

Honestly, IPsec is secure enough. Make sure you have it set up by someone who has considerable field experience, and make sure your end-point devices are reasonably secure (i.e. patches are applied to the VPN gateway in a regular and consistent manner, remote clients running Windows presumably have patches, antivirus, and software installation policies installed).

I don't really understand why you're nervous about going with a VPN. There are really no other "cutting-edge" solutions available that have been reliably tested, at this point.

VPN's may not be cutting-edge, but at least they have some kind of track record and have the advantage of being stable enough that you can deploy an application without taking unnecessary risks.

I would follow this up with some relevant URLs but my girlfriend is freaking out because there's a spider on the ceiling and she's too chicken to swat at it with a broom. Meh.

Risk-based approaches

[crmartin]

Here's what you do:

(1) figure out how valuable the data really is: what would it cost you if it were disclosed.

(2) figure out who you really want to have access to the data, and under what rules. (This is called a "security policy").

(3) Figure out a way to enforce (2) without exceeding (1).

not applicable

[TheSHAD0W]

SQL injection would be a potential problem, but in this case the application isn't designed for public use. In order for someone to access the web pages he would need a valid user name and password. It's assumed that people with that information would be valid users and wouldn't abuse the system.

Don't do it.

[Kris_J]

I vetoed a plan to make publicly available a database of questionable security that I developed for internal consumption only. I could demonstrate at least a dozen ways that security could be compromised, most of which I've addressed in my more recent development project (killing the session if any variables are passed on the address line, turning less than and greater than signs in user-submitted text blocks into their ampersand enties, that sort of thing).

Hire Someone

[perljon]

If it's really that important for it to be secure, hire someone that knows what they are doing. Nothing you read in slashdot will give you enough knowledge to make risk calculations for your data. You need a professional.

Risk assessment NOT technology is the key

[martin]

Doing a risk assessment is the first step.

Then and only then can you properly secure the data with appropriate policies, and implement the policies with procedures and technology.

Then repeat every so often.

Remember security is a process!

Treat the intranet as you treat the internet

[jgardn]

In other words, while you do have a bit more security because you are able to control what it going on, don't count on it.

I always SSH between boxes, avoid FTP unless it is publically available files (like ISO images of Red Hat) and deploy services that should be secure over SSL (IMAPS, HTTPS, SMTPS, and other encrypted channels)

Otherwise, you run the risk of having your entire intranet compromised if one machine is compromised or the firewall is broken. But if you play it safe, the worst case scenario is a single machine is infected or the firewall goes down, but not much more.

Application Security

[dmayle]

Arguably the most important form of security for something like this is application security. When you receive variables in a form, do you check them in the form page before submitting AND in the receiving page to make sure you don't have any rogue POST'ers?

In fact, have you disabled passing variables by GET? This doesn't protect variables absolutely, but it will stop the casual snoopers.

Also, if you have any includes that are just utility pages, are they built/secured so that someone couldn't wright a webpage on another computer, include it, and get access to information allowing them to break the code? (Server-side includes should be in a non-publicly accessible directory, or failing that, should be coded such that they produce a blank page. This can be accomplished by recquiring a server side variable be set a certain way before the include to enable the page.)

Also, after you've authenticated a user, how do you keep the session open? Do you just pass a user variable around, or do you verify at each page? If you just pass the variable around, it could be susceptible to altering, especially if it's a numeric id that is auto-incremented, or an obvious string like an email address.

Instead of paassing the variable around, if you can't depend on server-side sessions, it's a good idea to generate one-off unique session id's that are good for a limited amount of time, and aren't auto-incremented (maybe an MD5 hash, or a GUID), which makes it much more difficult to hijack.

If you use access to an out-of-process resource (like a database), do you implement user security there, too? If you have read only, or no access to important tables, than even if you application code is compromised, that still prevents an attacker from wreaking havoc elsewhere...

VPN and the mythical 'Trusted Client'

[slittle]

VPNs are fucking dangerous.

Private LANs usually have poor security since they're allegedly cut off from public access. That means older version of daemons, unfiltered access from anywhere to anywhere, low/no security logging, and whole forgotten servers. Once you're on the LAN, you usually have free access to everything for as long as you need to guess the password/crack a daemon.

One just has to crack the remote workstation (which are typically much less secure than an onsite station), and then go back out via the VPN to the private LAN. Same way a lot of these email worms get in: the company mail server/firewall filters out all the trojans/attacks, but there's always that one clueless dialin user with direct LAN access to start the domino effect.

Either firewall the VPN down to accessing only specific IPs AND ports, or put your service on the public Internet and use appropriate authentication.

I suggest the latter, security on a VPN will only get worse as users want to do more with it, and IT staff get the shits with constant requests to update access controls.

Don't forget to keep things in perspective.

[WoTG]

It's great to come up with super complex systems for security. You could layer a VPN on top of one time passwords on top of application level security on top of who knows what else. However, at some point, you've done enough, and the risk of intrusion is higher from other sources.

How secure is your LAN? How secure are your laptops? How about your suppliers/contractors/customers systems? How much do you trust employees?

... just a reminder to not lose perspective of the broader issues of IT security.