Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Securing a Private Intranet?

Cliff posted about 11 years ago | from the safety-for-not-so-safe-web-apps dept.

Security 41

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?"

Sorry! There are no comments related to the filter you selected.

It might be too late... (4, Insightful)

twoflower (24166) | about 11 years ago | (#7069247)

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.

Re:It might be too late... (1)

sahala (105682) | about 11 years ago | (#7096192)

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.

Wonderful. I guess he should put in his resignation now because what he's doing is impossible.

I'm not trying to say you're wrong. I say the same thing about user interfaces and usability. What I've come to realize, however, is that although nothing can be bolted onto an application, sometimes that's just the way it is for business, product timelines, etc. It makes it a harder problem, but people *do* pay for hard problems to be solved.

Re:It might be too late... (1)

twoflower (24166) | about 11 years ago | (#7096245)

Wonderful. I guess he should put in his resignation now because what he's doing is impossible.

I didn't say that; you'll note I used the word might. The original poster didn't give any information about what security considerations had been part of the design, so we don't have enough information to evaluate this possibility.

If security was not part of the design, and issues I referred to were not considered, then it might very well be easier and cheaper to rebuild the system/application with security designed-in.

You should set up your VPN, (1)

Mordant (138460) | about 11 years ago | (#7069251)

and then give me access so that I can 'test' your security. ;>

How Now Brown Cow (5, Funny)

Anonymous Coward | about 11 years ago | (#7069256)

Your Security will only be as strong as the most easily tortured employee. Plan wisely.

Re:How Now Brown Cow (1)

SpaceLifeForm (228190) | about 11 years ago | (#7069766)

Why was this Funny? Seems to be quite insightful. Ultimately, there are keepers of root (or other important) passwords or PGP keys for example.

two alternatives: (3, Informative)

TheSHAD0W (258774) | about 11 years ago | (#7069295)

If it's a web app, you could make it available via https and give people usernames and passwords. ssl is a pretty secure solution, despite the recent exploits; and if you keep up with your patches, forwarding port 443 to your web server won't be an awful security problem. Your largest issues will be insecure passwords and brute-force attacks on them.

Alternatively you could add VPN access to your intranet, allowing remote users to log in via an encrypted tunnel. This would have benefits and drawbacks over the above method; it would be more secure, but less accessible. (You may not consider this a bad thing.) The key, if done correctly, would be more secure than a password a user could remember, but it might also be treated less securely and stolen from a remote machine.

Two things to remember (1)

rpresser (610529) | about 11 years ago | (#7069362)

1. To go SSL, you'll need a server certificate. Either you buy one from Verisign or Thawte, or you self-sign your own. The bad thing about the latter is that everyone who visits your page has to accept it the first time they visit; usually not a big deal.

2. Security belongs in the application as well as in the web server. For instance, if your web app takes user input and constructs SQL from it, it may be vulnerable to SQL injection [sqlsecurity.com] . There is nothing you can do to the web server to immunize your app against SQL injection; you have to fix the app.

Re:Two things to remember (1)

Directrix1 (157787) | about 11 years ago | (#7069520)

It should be noted that there has never been a flaw discovered with SSL (well besides just long running brute force computation for the host private key, and long running brute force computation for the negotiated Diffie-Hellman key using vulnerabilities in the encryption layer). Just flaws with certain implementations of SSL. The most recent one (I believe) being the timing attack against SSL implementations that short-circuitted the key checking function when the first incorrect bit was encountered, allowing a malicious host to keep firing off fake keys and measuring response time to determine which bits were off.

SQL injection is a major issue with lots of websites (although for some I've visited its been kind of a feature ;-) ). I personally would suggest just setting up proper MVC seperation. Through chrooted non-superuser jails, creation of a DMZ, only piping information back and forth from your DMZ to your intranet through a system with only port forwarders in place for the services you need and nothing else, and try using RPC or CORBA instead of SQL from your webservers. Also, a good suggestion for User/Pass verification over an insecure network is to use SRP [stanford.edu] . Just some tips. Have fun.

not applicable (2, Insightful)

TheSHAD0W (258774) | about 11 years ago | (#7069535)

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.

Re:not applicable (0)

Anonymous Coward | about 11 years ago | (#7069794)

Bad assumption. If any of the remote machines they are using is compromised, then an attacker could use SQL injection, and youre whole database is compromised. This may not have been a concern before if all of the clients with access were physically secure, and isolated from outside networks.

Use an IPsec VPN (2, Insightful)

dragonfly_blue (101697) | about 11 years ago | (#7069324)

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.

Fuck you (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#7069344)

Who gives a shit? You've done this before and it's not funny. You wanna know what a really sad passing is? I buried my newborn baby girl last week. My first and only child, my daughter. I carried her inside me for 6 months only for her to die. You know what happened then? I gave birth to her. She died before she was born. Why don't you stop this ignorant display of childishness, your desperate plea for attention. It's not funny and nobody gives a fuck.

Some potential options (5, Informative)

RedPhoenix (124662) | about 11 years ago | (#7069364)

Prefix everything I have to say with "Nothing is perfectly secure", and keep in mind that poking holes in security concepts is often a lot easier than implementing something effective, efficient, and that makes sense from a business perspective.

Some potential options are:
* Authentication / Confidentiality - Application layer
- Consider using an authentication scheme for access to portions of your web site - this can be through self-generated X.509 certificates, distributed to your users for example. Such certificates have the advantage of providing both authentication, and encryption at the application layer.

* Authentication / Confidentiality - network layer
- A VPN is a step in the right direction I suspect. Something like the openvpn suite may be appropriate. If you wish to use openvpn for authentication as well, you'll probably need to find a relatively secure mechanism to distribute key data.

You may wish to consider making up a 'autorun' CD for each user, which contains the key data, establishes the vpn link, copies the x.509 key to the appropriate location in the users browser config files, and connects to your application. If your end-users are windows machines, it should be relatively easy to automate. If you have unix boxes at the user level, then you may be able to get away with something a little less streamlined.

In this setup, your 'CD' becomes your key. When your user wants to access the 'work application', they pop the CD in their drive, and wait for a connect. You may wish to overlay password access controls on either your openvpn or http server, in order to guard against loss of a CD implying access to your network. In addition, auditing access to your network is a critical (if somewhat difficult) part of your security profile.

Alternatively, you could investigate:
* hardware tokens, or SecureID related technology. Many of these systems use usb these days, so there's less of a problem with lack of card readers like there used to be.. It really depends on how much you really want to spend.
* Dial up. This is becoming more and more difficult though - often, a user will have a modem and ADSL/Cable link active at the same time, so without additional security controls, you effectively have an uncontrolled gateway to your network.

However, in summary, I'd recommend:
* Application level identification (and possibly encryption). Potentially x.509 certificates, or strong passwords.
* Network level identification and encryption (potentially something like openvpn, but not using the zero-configuration options)
* Some form of effective auditing in lieu of an effective certificate revocation service.

Again... security is very much a marriage of risk, threat, and cost. Some of the above solutions are probabably worth considering in low threat environments, where cost is an issue, and the number of users is easilly manageable. When you have a high threat environment, or where money is not an issue, then a more 'packaged' solution would probably be appropriate.

Red.

Risk-based approaches (4, Insightful)

crmartin (98227) | about 11 years ago | (#7069371)

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).

Completly Secure is unplugged (1)

redog (574983) | about 11 years ago | (#7069398)

Just make sure you stay on top of day to day security issues. From the sound of it you have a handle on what isn't secure =/
Even UNIX VPN's can become vulnerable.

Your biggest threat.... (1)

rerunn (181278) | about 11 years ago | (#7069457)

will be from the users that have been granted bonafide access rights.

Off topic, but worth mentioning.

On the flipside -- I can still log into my old companys web portal using my old account. Its been three months now, and I still can get in with admin privs.

Silly admins.

Good luck.

ssl (1)

ljavelin (41345) | about 11 years ago | (#7069464)

HTTPS with appropriate authentication and authorization modules.

Otherwise, you have to support god knows how many idiots with the VPN client software. Forget it unless you want to support a collection of non-http services.

Common sense (1)

duffbeer703 (177751) | about 11 years ago | (#7069468)

Unix != Security.

Use VPNs to secure connectivity, and intrusion dectection like tripwire to keep your servers safe.

Outthink the intruder... (3, Informative)

SealBeater (143912) | about 11 years ago | (#7069571)

Whatever security mechanism you decide on, and I would probably recommend ssl or ipsec tunnels, remember to think in layers. Secure the host machine, and I would personally recommend the Bait and Switch Honeypot system. From the freshmeat entry, "The Bait and Switch Honeypot System combines the snort Intrusion Detection System (IDS) with honeypot technology to create a system that reacts to hostile intrusion attempts by marking and then redirecting all "bad" traffic to a honeypot that partially mirrors your production system. Once switched, the would-be hacker is unknowingly attacking your honeypot instead of the real data, while your clients and/or users are still safely accessing the real system." Monitor the IDS in real time, keep up on patches, you should be good to go. You can get it here [sourceforge.net] .

SealBeater

Don't do it. (2, Insightful)

Kris_J (10111) | about 11 years ago | (#7069705)

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 (2, Insightful)

perljon (530156) | about 11 years ago | (#7069891)

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.

Re:Hire Someone (1)

Thu Anon Coward (162544) | about 11 years ago | (#7070045)

Like the parent-poster above said, if you have to ask how, then you need to hire somebody who DOES know how. you're a programmer,not a security geek

Re:Hire Someone (1, Informative)

lanswitch (705539) | about 11 years ago | (#7070495)

And if you are interested in becoming a professional, or you don't have the funding, look at www.cert.org . They have a lot of information about security, ranging from a vulnerability-database to complete worked-out methods for data-protection.

SSL w/Certificate Validation (1)

sidespace (652582) | about 11 years ago | (#7069900)

A reasonable solution without incurring the need for costly software would be requiring self-signed SSL certificates to view the Intranet site.

You would create these certificates, and then physically distribute them to your remote users.

Using this method with a login/password provides you with end-to-end security from a known set of clients.

Sound good? Pick up the O'Reilly OpenSSL book for more info.

Read the OWASP guide (4, Informative)

Rich Dougherty (593438) | about 11 years ago | (#7070052)

The Open Web Application Security Project [owasp.org] have a guide [owasp.org] to help those who want to improve the security of their web applications. I've had a skim and it looks pretty good. They claim two million downloads, so other people must think so too. :-)

If you're feeling lazy, you could do worse than reading their list of the top ten web application vulnerabilities [owasp.org] .

VPN options (1)

bedessen (411686) | about 11 years ago | (#7070365)

Well, for starters, don't use CIPE, vtun, or tinc [slashdot.org] . If all you're doing is http, you might consider just using ssh to forward the web server ports... but that has the undesireable issue of making all URLs start with "http://localhost/...". Otherwise, it looks like the consensus is FreeSWAN or IPSEC if you are looking for true security with a VPN.

Some people have said "just use https", I don't think that's a very good suggestion at all. The only thing that SSL really provides in this context is end-to-end encryption, and assurance that the other end is who it says it is. It does not provide any sort of access control or authentication, so you'd have to bolt that on if you don't have it already. From the sounds of it, this application was NOT designed with security as a high priority, and so I would be very leery of exposing it to the world without some layer of encapsulation (as with a VPN) that would enforce access control. For example, https wouldn't protect you at all from things like cross-site scripting errors, or SQL injection, or poor parameter checking/validation, or any of the other common errors that web applications tend to be littered with. Plus, when the attacker breaks through the web application logic they have control of a server on the inside of your network, which is presumably a "Game over man, game over!" type of situation. With a ssh tunnel or VPN, the attacker must overcome password or public-key (or both) authentication first, which is specifically hardened against these sort of attacks.

Re:VPN options (1)

TheLink (130905) | about 11 years ago | (#7070413)

You can use client certificates for https authentication.

I made a webapp which does that, you click on a "login using cert". I still prefer logging in to be explicit, but you can have your server reject https connections from clients without a valid or recognised certificate.

Re: "How secure is secure?" (2, Informative)

bobv-pillars-net (97943) | about 11 years ago | (#7070422)

The Australian lesson:
If it's cheaper and easier to walk away with the hardware than to crack in over the wire, then the NETWORK security manager has done an adequate job...

Honestly and no joke, that's how I curb my paranoia. I take a look at the physical security and say, "Well, at least I'm doing better than THAT," and stop worrying so much.

Don't let remote VPN users have direct access. (1)

TheLink (130905) | about 11 years ago | (#7070458)

Don't let remote VPN users have direct access to your network. So what if they are employees - they are unlikely to manage their personal systems as well as you do. It is harder to ensure an employees mobile PC is clean compared to a normal desktop.

What you do is let them VPN in to a different "quarantine" network and firewall off that network from the actual servers. The rules will allow a bit more access but limited to only what is deemed necessary for _remote_employees_.

Also employee notebook PCs and their other mobile computers should also have restricted access to the network. They should not be allowed to directly connect to the main employee network (which is of course firewalled from the main server network).

With this sort of thing, even if an employee at home is infected with a worm, the damage is limited to those in the quarantine network.

And people bringing in mobile computers also can't as easily infect others in the main network.

If you're paranoid, you could use VLANs and if employees connect their mobile computers to a network they're automatically placed in a special two member VLAN and you run something like nessus on them, sniff for suspicious traffic etc, if they pass, you switch them to a VLAN with more services.

There's no such thing as perfect security, but you can control certain risks and their impact.

Risk assessment NOT technology is the key (2, Insightful)

martin (1336) | about 11 years ago | (#7070483)

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 (2, Insightful)

jgardn (539054) | about 11 years ago | (#7070580)

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 (2, Insightful)

dmayle (200765) | about 11 years ago | (#7070745)

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...

Dear /. readers.... (0)

Anonymous Coward | about 11 years ago | (#7070848)

Can you please help me do my job... and finish the project i cant finish...you are all idiots with some spare time up your ass.

VPN and the mythical 'Trusted Client' (2, Insightful)

slittle (4150) | about 11 years ago | (#7071126)

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. (2, Insightful)

WoTG (610710) | about 11 years ago | (#7073888)

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.

One-Time Password generators (1)

pyite (140350) | about 11 years ago | (#7075503)

You want these [securecomputing.com] . Basically, you give one to each user who needs access to the site. They enter their username, and then to get their password, they enter their PIN into this credit card sized device, and it gives them a one time password. To further enhance security, you can make the password they have to enter a concatenation of a "permanent" password and the one time generated one. This pretty much ensures you are allowing the right person in. You can also implement paranoia features in the generators (we call them Enigmas where I work, as that used to be the name of the company). Such things include lockout from the physical password generator itself when the wrong PIN is entered N times or lockout from the authentication system after a number of incorrect tries.

NAT + SSL + authentication (1)

pointbeing (701902) | about 11 years ago | (#7084009)

My vote? Glad you asked :)

Use a hardware router and network address translation to stick the web stuff on a nonroutable network like 10.x.x.x or 192.168.x.x and only have a single port on the router show up on the public Internet.

Then, with a combination of SSL and password authentication you ought to be about as secure as you can make things.

Layer it on! (1)

scorp1us (235526) | about 11 years ago | (#7084899)

Use private subnets, with IP Masq. Have them VPN in to your network, but go through a router and make sure that router only explicitly allows traffic from a selected set of MAC addresses to specific IP addresses (or MAC). Yeah, the maintaince will suckm but it'll only let people on through the boxes you know you have out there.

Then it's a matter of authentication security. Make sure the VPN passwords are unique and not the same as the application passowrds, so you can revoke a compromised (stolen) laptop without revoking the user's application privilages. True you'll have to add the new system where they originate from.

If you're using a database, don't have a generic web-account. Make the user app tie into the database's GRANT security.

Don't keep your database on the web host.

By then, you can reasonably assert that only a few authorised machines can get on the network; authorised users can run the app, and those users are contstrained to theit tables.

Proxies and Trused OS (0)

Anonymous Coward | about 11 years ago | (#7088101)


In addition to the other recommendations here, you might want to consider a proxy server and firewalls between the edge of the network and the server providing access to your application.

It might also be useful to host the application on a trusted operating system, like Trusted Solaris [sun.com] , which can help limit the damage from the system being cracked.

You will also want to use various web and system auditing tools to check it before you deploy it.

securing intranet (1)

Nykon (304003) | about 11 years ago | (#7096892)

Instead of going thru the trouble of VPN, or on top of why not just certificate enable (PKI) the website?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?