Blending Intranet content into public websites

@SpecOpsXMar 05.2007

Is it possible to have a publically accessable website show intranet content to viewers who belong to the intranet network, but the intranet navigation/content be hidden from any public (non-networked) viewers?

The intranet content would be on a seperate drive that is non-accesible by the general public.

For example… have a main navigation… then, if the user is an intranet user, they also see an extra navigation for private links.

to post a comment

Full-stack Developer

15 Comments(s) _↴

@ray326Mar 05.2007 — #That would be a portal.

@svidgenMar 05.2007 — #Sure. If you're thinking of creating two totally different websites for intranet and internet viewers, you can set up two virtual hosts in apache and block non-network traffic to the intranet only site. If you're thinking of having everybody see the same site, but with slightly varied content, you can base the page output on the client's IP address (environment variable: REMOTE_ADDR).

In PHP you need to check $_SERVER["REMOTE_ADDR"].

In Perl you need to check $ENV{'REMOTE_ADDR'}.

Then, you can do whatever operations you feel you need to test the IP.

I hope that helps.

@SpecOpsXauthorMar 05.2007 — #If you're thinking of having everybody see the same site, but with slightly varied content, you can base the page output on the client's IP address (environment variable: REMOTE_ADDR).

In PHP you need to check $_SERVER["REMOTE_ADDR"].

In Perl you need to check $ENV{'REMOTE_ADDR'}.

Then, you can do whatever operations you feel you need to test the IP.[/quote]

Thanks! That sounds exactly like what I need to do. Now I need to get the server admin to enable PHP on both internet ane intranet servers... I'm only vaguely experienced in PHP as well... guess I could look up some sample code.

I wonder if theirs a javascript way to check the IP addresses in a similar fashion (JS is already enabled on the server.

P.S. - There's no security risk in doing this is there? lol

@svidgenMar 05.2007 — #I've never used server-side javascript. But, if you know what you're doing there, the idea is the same. As far as risk, there is always the risk of a hacker spoofing an internal IP address or hacking themselves a tunnel through an internal computer. If this worries you, password all private content. This is an especially good idea since a great deal of "hacking" can be mere social engineering anyway. You don't want anyone that's capable of getting into your building to immediately have access to sensitive information.

Use passwords and, if possible, SSL.

@SpecOpsXauthorMar 05.2007 — #Well, the real question is, would having the "if, then" statement to display the intranet nav place a security risk in itself...

All of the private content will be located on a private server, in the "if IP address = Intranet User, Then show nav from Intranet Drive" none of the files will be put on public server.

The Intranet drive is already protected from outside entrance through network/usergroup permissions.

But, I'm not the server admin... I'm just the webby. I don't know many details on what their doing to secure their network, but I think they'd have it sealed tight.

Oh, and... our buildings are most definately NOT accessible to the public... lol.

@svidgenMar 05.2007 — #Unless I'm uninformed, the if-then in itself will not pose a security risk. You just have to be careful about what exactly your if-then is testing and how you go about including the private content. Remember, the web server (I'm assuming) is probably part of the network and therefore probably has permissions to access the private data (maybe it shouldn't). So, you don't want to have your web server accidentally be acting as a proxy for the whole world. For this reason alone, you should probably check with the admins and make sure your web server is explicitly disallowed normal network member permissions.

@SpecOpsXauthorMar 05.2007 — #Ah, you hit it on the nail and made it clear as to what I need to look out for. Thanks a lot for your help!

@ray326Mar 06.2007 — #What you're looking at is a reverse proxy to a server running a PHP app. A reverse proxy is a rather dangerous mechanism if your IT department isn't very good at networking. In fact if they are very security conscious they won't allow it at all. The rule of thumb for extranet security is no unauthenticated request should be allowed through the inner firewall.

@svidgenMar 06.2007 — #I'm not entirely familiar with the security risks of a reverse proxy, but I'm also not suggesting one. I'm actually advising against proxying of any kind. Could you be more specific as to where your concern lies?

@SpecOpsXauthorMar 06.2007 — #The public server has no access at all to the private server, and their on seperate drives/machines.

What I'd want is for everyone to go to the public page... but those that are within the private network will also see a private nav.. the files to display this private navigation are on the private, innacessable server. (Only accessible to authorized network users) ... so it shouldn't even show up for public users.

And eve if they did try to find "http://intranet/" ... it would be denied access or "no such URL" for them.

Am I right? But yea, I'll still have to figure out the PHP function that says to show the nav if its private user, and block showing it for public users (b/c I assume that if it tried showing it for public users it would be a bunch of broken links/images/content)

@ray326Mar 06.2007 — #It's hard (for me) to talk network stuff without pictures but maybe the following will do. This is how the network is generally done.

WB--OFW--{-EWS-}--IFW--IWS

Web Browser, Outer Firewall, External Web Server, Inner Firewall, Internal Web Server, { DMZ }

The OFW allows the Internet in; the IFW blocks the Internet but allows the internal network out. In an alternate design the EWS could be a proxy server instead or in addition to serving HTTP.

If you put the public parts of the site on the EWS you might be able to use URL rewriting rules base on the referrer to control the menu inclusion on the pages. That would lock things down better and cost less to maintain than trying to code the security into the web app.

@SpecOpsXauthorMar 06.2007 — #you might be able to use URL rewriting rules base on the referrer to control the menu inclusion on the pages[/quote]
Could you explain that?

-

Also, from your word mapping, it sounds like your thinking that the internal server and external server are on the same machine, just seperate sectiosn have seperate permissions... but, they are two completely seperated servers, their own machine/OS, ect.

If I just wrote it show the content from the intranet (for example... lets I try to show an intranet image to private users... just by typing "[img src="I:/folder/folder/name.jpg"] I'm thinking the image should show for private users whom are networked to the intranet server, but public users would see a broken image.

Now... what the PHP is for would be to say "parse this code if they're a private user... and don't if its a public user" which would prevent the broken image from appearing to the public.

@svidgenMar 06.2007 — #Right. In your setup, as far as I can tell, the only risk of a quick PHP driven IP-conditional content solution is that, if you make a mistake, some of your extneral users might see links to things they can't access and therefore might know some trivial information about your internal network, such as what drive letter you've associated with a certain machine or what a certain private filename is or something. If you want to try URL rewriting, you're welcome too. However, if you're not familiar with it, it'll take some research (dig through apache's online documentation), and it might be more complicated than just using a PHP solution for your purpose.

There might be some useful built-in PHP functions for comparing IP's and such, but if you're lazy enough not to dig around for them and think it's easier to use another solution, here's what I've used:

[code=php]$digit_set = split(".", $ip_string);
 $int_ip = (pow(256, 3) * $digit_set[0]) + (pow(256, 2) * $digit_set[1]) + (256 * $digit_set[2]) + $digit_set[3];[/code]

$ip_string is the IP addy, and after the script runs, $int_ip is an integer representation. You can use this conversion to easily see if an IP address lies in a given range. Keep in mind, this method doesn't include any IP adress format validity checks or anything. If you pass in 123.123.123.123.123.123.123, it'll just take the first four blocks and use that. You might want to pass $ip_string through a regex or something and raise hell if the string isn't a valid IP address. But, if you get your IP address from $_SERVER['REMOTE_ADDR'] you should be fine.

I hope that helps.

@SpecOpsXauthorMar 06.2007 — #Roger that, thanks.

Now if I could just get my system admins to enable PHP... I've asked them to, but man are they slow at it! lol...

Javascript is already enabled... I'll see if I can find a function that would do the same thing as that bit of PHP.

@ray326Mar 07.2007 — #Also, from your word mapping, it sounds like your thinking that the internal server and external server are on the same machine[/QUOTE]Actually there are four or five hosts there depending how you want to look at the firewall. The dashes are network connections. (Graphics do make a difference.) ?
src="I:/folder/folder/name.jpg"[/QUOTE]Of course the source would be a real URL, not something with a drive mapping. If you run your site with PHP then I assume PHP has a "create session" event like ASP does where you could look at the referer's address and set a session variable accordingly that would be used to remap desired URLs on the fly including those for menu includes. Yes, URL rewriting can be very finicky.