Solved

Firewall: Deny Access unless from another web server first

Posted on 2010-08-14
78
1,154 Views
Last Modified: 2013-11-30
I have a need to block direct access to a web server unless the request is initiated from another web server first. Once that connection is established, traffic should flow between user/server until the session is killed. At that point, the user will have to re-initiate the request through web server #1 to gain access to web server #2 again.

I use both juniper screenos based firewall's and pfsense so either would be fine.

I've been toiling on this for months, have asked everywhere, nothing ever works yet I know this isn't rocket science. Someone out there has got to know the answer so am trying again.

 Rough outline to give idea of what is needed.
0
Comment
Question by:projects
  • 43
  • 27
  • 5
  • +1
78 Comments
 
LVL 6

Expert Comment

by:nettek0300
ID: 33439284
I would be willing to bet that your firewall and/or network settings on the two web servers are misconfigured.  Can you provide further details on the firewall and webserver network configs?  Yes, this can be done, it is just a matter of getting everything configured.

Do both web servers plug directly into the firewall or is there a switch between them?  Also, what is the purpose of the connection between the two web servers?  You should be able to configure the firewall so that public traffic comes to the firewall which the directs the end user to webserver 1.  The traffic should then go back through the firewall to access Webserver 2.
0
 

Author Comment

by:projects
ID: 33439323
Hi,

The firewall in this case is a Juniper ssh-140-SH running screen os. Juniper support has not been able to find me a solution and I have revisited this prob
lem numerous times. It appears that the firewall doesn't have the capability. I also use PfSense firewall's so could use one of those if there is a solution using that.

Yes, there are switches between all servers. The firewall has multiple interfaces to which I connect switches to create multiple LANs. In this case, the servers are on the same LAN segment.

I suspect however that this may not be a firewall issue but a Linux one perhaps. Rather than blocking at the firewall, perhaps I need to tell web server #2 not to respond to anything unless it is initiated from web server #1 first.

The image is a rough one and I wasn't sure how to display what I'm after. I've updated it, maybe this will help.

Note that web server #2 has a dns entry and does allow public flow otherwise packets stop dead at web server #1 upon request since they can't make it out to the user. The interface is a wrapper on a joomla web site to the #2 web server.


Web-Direct-Access.jpg
0
 
LVL 7

Expert Comment

by:jhp333
ID: 33439449
I doubt that it can be done at firewall level, because the two web servers need to exchange session information somehow, which is usually beyond the scope of firewall functionality.

You need a shared storage/database for the two web servers to store session data. And then reconfigure/reprogram the web servers accordingly. PHP, for example, has session_set_save_handler() function for this situation. Or you can just use an NFS and set the session data directory of both web servers in it.

I think the two web servers need to be in the same domain (ex: aaa.example.com, bbb.example.com). Otherwise the cookie which has the session ID on the client side (web browser) is invalid in the other domain.
0
 

Author Comment

by:projects
ID: 33441024
In some cases yes, that could work. It's not possible in my case as the web servers are running very different applications. It would require very extensive programming to make things work as above.

When I say session, I mean that web server #2 should only respond or open a session if the traffic is first initiated from web server #1.

That would be the best way of doing this. I cannot believe that this can't be done very easily on Centos, which is what both OS's are.


0
 
LVL 7

Expert Comment

by:jhp333
ID: 33442002
I misunderstood the session you mentioned as a web session, but it seems you meant a tcp session. Now I guess you want something similar to port triggering, but triggered by IP instead of port. I never heard of such thing as "IP triggering", although it does not has a significant meaning as I am mainly a programmer, not a network administrator.

But, as a network programmer, I think it's not too difficult to make a special gateway program for your requirement, if you can afford an intermediate router running on a Linux box.
0
 

Author Comment

by:projects
ID: 33442796
Or a linux firewall that doesn't allow traffic to be initiated from anywhere other than a specific web server (IP Address or more).

I'm not sure a gateway is required but I am certainly listening.
0
 
LVL 7

Expert Comment

by:jhp333
ID: 33442960
I think what you want is not just an IP filtering on the Web server #2. Do you?
Can you elaborate what you mean by "initiated from the Web server #1"?

In your design, who is sending the HTTP Request packet directly to the Web server #2? Is it the server #1 or the client browser?
0
 

Author Comment

by:projects
ID: 33443023
>I think what you want is not just an IP filtering on the Web server #2. Do you?

I'm not really sure to be honest, depends on what the outcome ends up being.

>Can you elaborate what you mean by "initiated from the Web server #1"?

Meaning that user must log into web server #1 in order to gain access to a menu item which is a 'wrapper' connection to web server #2 on the LAN. If the user or anyone, tries to connect directly from the Internet, then connections should be denied by web server #2. Web server #2 should allow only connections which were initiated, started, through web server #1.

Basically, I want to prevent hackers from having direct access to web server #2 by making sure that requests come first from web server #1. Once a connection has been established with Internet user, then web server #2 should continue providing service until the session has ended. Session could have ended by someone logging off or disconnecting from Internet so that packets no longer flow between users pc and web server #2.

>In your design, who is sending the HTTP Request packet directly to the Web server #2?
>Is it the server #1 or the client browser?

The user who is anyone on the Internet, logs into web server #1. Having authenticated, they have a menu option which allows them to connect to web server #2. The connection is a web based connection using two different ports. Port 8443 (https) and port 8080 (http).
0
 
LVL 7

Expert Comment

by:jhp333
ID: 33443183
Sorry, it's not very clear to me yet.
Let me ask another question: when users are viewing the web pages of server 2 after being authenticated, what do you expect for them to see on the address bar of their web browser? The address of server 1 or server 2?
0
 

Author Comment

by:projects
ID: 33443211
When users connect, they are connecting through a wrapper window on web server #1.
So, to the user, the data is wrapped inside of a smaller window on web server #1.

In reality, the traffic must flow to the Internet and therefore, must have DNS entry and packets must be allowed in/out of the firewall. As such, I have a policy on the firewall which allows these packets to flow.

The address that the user sees is still web server #1.

The only time that the user would see any address of web server #2 would be for example if there was a DNS error, where the user wasn't able to reach web server #2 via Internet. We saw that when we forgot to enter in a DNS address for web server #2 when configuring this.

It works just fine as it is, but the problem is that if the user looks at the packets, then they can clearly see the requests to web server #2. That's not a big deal for our users, but it would be if a hacker found it. Then the hacker would sit there and try hacking name/passwords on web server #2.
0
 
LVL 7

Accepted Solution

by:
jhp333 earned 500 total points
ID: 33443628
Now I think I see the picture. When you said "wrapper connection" I was thinking something else.

Anyway, in your configuration, the server 1 is actually doing nothing except for giving the address of server 2 to an iframe of its web page, in regards to server 2.
Here is your problem, I think. The only machine that knows whether a user is authenticated or not, is server 1. But it's not trying anything to release that information to any other machine on the LAN. Firewall never knows it, thus it cannot provide a solution for your requirement.

I can think of 2 solutions. Both of them requires some programming on the web servers. I don't think there can be any solution not requiring programing, just my thought.

1. On web server 1, after user authentication, make the server program export the IP address of the user along with its expiration time. You can use a file on a shared file system, or a database, or direct socket connection, or SOAP/REST web service, etc. There are many technique for data exchange between server.
If the list of IP address is available on the server 2, server 2 can perform IP filtering based on the list. It can use iptables directly, or you can modify a common header file of web site 2 to accept only those IPs.
There are a few shortcoming in this solution. a. Many Internet users use NAT, which mean there can be two or more users with same IP address. b. The server 2 is still exposed to Internet - hackers' attacks.

2. Let the server 1 act as a reverse proxy for server 2. For this, you don't need to do anything on server 2 except for cutting its Internet connection. On server 1, make a new web page which gets the URL (with local ip address) for pages on server 2 as its input parameter. The server script then make the HTTP request to server 2 on behalf of the user. When it gets response from servers, it replays the contents to the user's web browser. Before it sends the page contents out, it need to rewrite some of the data in the contents, especially the link addresses to server 2 itself. Those addresses should be prefixed with the URL of the relaying page on server 1, making the actual address a parameter.
It can get a little complicated if server 2 needs to manage web sessions, but not a big deal, I think. Especially if you can adapt some libraries like cURL.
With this solution you can completely hide server 2 away from the Internet, only serving server 1. One problem with this method is that the load on server 1 will be higher than the the current load of server 1 and server 2 combined.

I hope this will help you somehow.
0
 

Author Comment

by:projects
ID: 33464966
Unfortunately, your solutions are more like a development plan than something I can do on my own so am still left with the same problem :). If I were a programmer or able to high level script, I could accomplish these things but I'm not.

I can't modify anything on the web server #2 because it's a phone system and is very finicky about changes. It is however a Centos 5.x OS so I have a little bit of leeway. There are two paths to that system which is a reason why it cannot be disconnected from the Internet.

The main path is SIP devices needing access and the second is the user control panel. I separate the two by allowing phones through SBC's while panel access is allowed through a front end web server.

So, if I needed to put something in front of web server #2, like a reverse web proxy just for the panel access, and if that's really the only way what so ever, then maybe that should be what I need to be looking at? Squid or something else but something simple, that won't become a bottleneck between the two and won't require much maintenance.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33519911
I've looked at this and want to make sure I understand.

You want the "user" to go to WEBSERV1.  

Then in certain situations they will be redirected to WEBSERV2.

You want NO direct access to WEBSERV2.

If this is what you want, you can't do this with a plan firewall.  A application level firewall may work.  The reason is that at the TCP  and IP level there is no concept of a redirect.  That is there is no way for a firewall to know that you are going to WEBSERV2 because WEBSERV1 told you too.

That type of information will be inside the HTTP packets, which most firewalls do not see.  An application level firewall can see this, but WEBSERV1 would need to be setup in a way that it inserts a cookie or some security token in the HTTP header that the application level firewall could see and that WEBSERV2 could also see and use.

Your best bet, and how it is normally done, is to have WEBSERV1 insert a security token/cookie that WEBSERV2 can check and do programming on WEBSERV2 to check for this.  Get the firewall out of the picture, unless you are going to spend the money on an application level firewall.
0
 

Author Comment

by:projects
ID: 33523016
There doesn't need to be any redirection, only that web server #2 not respond to traffic being initiated from anywhere other than a given list such as web server #1 or other workstations internally. If the initiation comes from anything in the list, then it should flow packets as usual, no redirection, nothing special.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33524062
I'm a bit confused and maybe its my terms vs. your terms.

By redirect I mean: user is entering the url http://webserv1/pagex and on pagex there is a link that says http://webserv2/pagey.  Not a HTTP redirect (http 302 code), but more of a user being forwarding to another site.

If that is what occurring, then the only way your firewall can detect this is  your firewall can examine the http headers and webserv1 places a cookie or some other http header that is also used on the request going to webserv2.



0
 

Author Comment

by:projects
ID: 33524488
I guess I'm also not quite sure how to explain it but let me try.

It's not a redirection in any way. Imagine going to a web site. You log into that web site, and you now have access to extra menu options. One of those options is a control panel for a service you subscribe to. It allows you to make custom changes to your settings etc.

That web server is on the lan side of the provider and you don't have direct access to that server, sort of. What you have is a 'window' inside of the web site you've logged into, which shows you the control panel. That control panel is in fact on that lan side web server. So, while you can interact with that web server, until you session times out at least, if you tried going to say web2.domain.com, you would reach nothing (unless your session is still open) so would have to log into web1.domain.com in order to gain access to your control panel again.

Now, part two. Because packets from web2.domain.com have to flow back out to the Internet, web2.domain.com has a DNS entry and a public IP so the user can interact with web2.domain.com.
However, if you are just a hacker and don't have an account on web1.domain.com, so have never accessed the menu option which allows you to open a session to web2.domain.com, then you cannot sit there and hack away on web2.domain.com.

Finally, this is not fool proof by any means but it would at least help in that hackers would not so easily have access to web2.domain.com. They would have to be a member of web1.domain.com in order to see the menu option which gives you the 'wrapper', 'window', to web2.domain.com.

Does this better explain it?
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33525110
Not really.  I guess the simple question is:

1) Is my browser directly interacting with WEBSERV2?

2) Or is my browser only interacting with WEBSERV1 and WEBSERV1 is acting as a proxy?

It is is #1, then everything I have said sticks.  That is WEBSERV1 must set a cookie that is passed when going to WEBSERV2. You must have an application level firewall that can "look inside" the HTTP requests.

Now your better choice may be to have WEBSERV1 act as a proxy to WEBSERV2.  That way the users are only directly interacting with WEBSERV1 period.  They don't know anything about WEBSERV2 at all.

0
 

Author Comment

by:projects
ID: 33525522
Your latter suggestion would be perfect. As you say, it would hide web2 completely.
The web1 server is a standard centos/apache setup so guess I would need more details on how to set this up then. I cannot modify web2 in any way what so ever. The server is very finicky.
0
 

Author Comment

by:projects
ID: 33526970
Another nice thing about doing it this way would be that I would no longer need to have web2 connecting to the Internet, and only to web1.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33527454
Apache doc on mod_proxy:

     http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

A article on running Apache as a proxy:

     http://www.apachetutor.org/admin/reverseproxies

You should not need to do the assembly  of Apache, all you need is the modules.

0
 

Author Comment

by:projects
ID: 33527714
But can apache run as both a server for local content including ssl AND as a proxy to talk with the remote?
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33527717
Yep. I would say it is a fairly common setup.  A single Apache server serving up static content front ending other servers that are running applications serving up dynamic content.
0
 

Author Comment

by:projects
ID: 33528247
Well, it would be static and dynamic on both but what I'm asking is can I configure Apache to run both being a server, static or otherwise, AND as a proxy server for another web server? Can't say I've ever seen that type of setup.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33529726
Yes, you can configure Apache to be both a server and a proxy at the same time.
0
 

Author Comment

by:projects
ID: 33531032
Any chance you might have some leads on this? I know about the individual aspects but not in terms of both working together so looking on apache.org for example won't give me a full solution.

Might you know of a URL, web document that shows how to set this up for Centos?

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33531712
The two links I provided earlier both have information on how to setup reverse proxies, which is what you want.

Since this is Apache specific, the OS or the Distribution of Linux really does not matter, so you can use the above links for CentOS.

For the stuff that WEBSERV1 will serve up, you need to make no changes.

So say currently your host is http://webserv1, you leave this alone. What you want is to reverse proxy requests to WEBSERV2.  Below are a couple of samples that may get you started (I got these from the above links and slightly modified):


ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /webserv2 http://webserv2.example.com/bar
ProxyPassReverse /webserv2 http://webserv2 .example.com/bar

What this should do is if the user enters http://webserv1/index.html then WEBSERV1 will serve this up itself.  However if they enter say http://webserv1/webserv2/index.html, then WEBSERV1 will actually convert this and pass through as HTTP://webserv2.example.com/bar/index.html, WEBSERV2 will respond back to WEBSERV1 and WEBSERV1 will send back to the user as if it came from WEBSERV1.


0
 

Author Comment

by:projects
ID: 33532963
Working on it, not having much luck so far.
The front end, web1.domain.com is centos LAMP running joomla CMS as it's application.
In joomla, we have a wrapper window which connects users to the lan site web2.domain.com.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33533022
You may want to read:

http://www.linuxquestions.org/questions/linux-server-73/some-findings-for-reverse-proxy-apache2-and-cmss-like-joomla-drupal-grails-etc-803910/

This gives links to various things the author found while trying to use Apache as a reverse proxy server while running Joomla as a CMS.
0
 

Author Comment

by:projects
ID: 33534135
So, with the modules loaded in apache, to reach only https via port 8443 on web2, do I only add the following into my web1 httpd.conf?

ProxyRequests On
ProxyPreserveHost On
ProxyPass / https://web2.domain.com:8443/sipxconfig/app
ProxyPassReverse / https://web2.domain.com:8443/

This seems to work but the URL being shown is the web2 server and I'm only testing internally so of course everything has access.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33534979
You want ProxyRequests Off, not ON.

ProxyRequests On tell Apache to act as a "normal" (or forwarding) proxy server.  A normal/forward proxy is what you would configure a browser to use.  You don't want this.

What URL are you entering?  You should be entering something like http://web1.domain.com.
0
 

Author Comment

by:projects
ID: 33535173
The URL is in fact https on port 8443, there is no option for http only as we don't make it available.

The url to the internal server would be like I posted above.

https://web2.domain.com:8443/

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33535548
No, I understand that webserv2 only listens on 8443 and only supports https.

What I am talking about is what URL are you using to get to web1?

With the proxypass and proxypassreverse you have coded you are redirecting the URI "/" to web2, which I don't think you really want.  I think you want something like:


ProxyPass /web2 https://web2.domain.com:8443/sipxconfig/app
ProxyPassReverse /web2 https://web2.domain.com:8443/sipxconig/app

To get to the stuff that is on web2, your users would enter:

     http://web1.domain.com/web2/aaaa

where aaaa is the file (or dirctory) you want them to get to that is in or under the sipxconig/app directory on web2.

To get to stuff on web1 you they would enter:

     http://web1.domain.com/bbbb

where bbbb is the file or directory on web1 that you want the users to get to.



     



0
 

Author Comment

by:projects
ID: 33535753
I see.
Right now, the test environment is a server which is handling multiple domains (virtualhosts) so let me set it up on one of the actual servers, test, and update.

And by the way, I very much appreciate your input on this and you will be awarded the solution. I just want to get it running so that it's complete as I've been trying to solve this for some time now.
0
 

Author Comment

by:projects
ID: 33535885
Wait now, how does this end up being a menu item that only a logged in user has access to?

ProxyRequests Off
ProxyPreserveHost On
ProxyPass /usettings https://web2.domain.com:8443/
ProxyPassReverse /usettings https://web2.domain.com:8443/

So, using this, anyone on the Internet can reach the internal web server right?
0
 

Author Comment

by:projects
ID: 33536148
I've put this into one of the real servers and am having problems.

From a remote client, I'm seeing;

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, support@domain.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

I have in the ssl.conf;

ProxyRequests Off
ProxyPreserveHost On
ProxyPass /usettings https://web2.domain.com:8443/
ProxyPassReverse /usettings https://web2.domain.com:8443/

ssl_access_log;

70.85.xx.xx - - [26/Aug/2010:15:06:18 -0500] "GET /usettings HTTP/1.1" 500 542

And in ssl_error_log, this sort of gives it away;

[Thu Aug 26 15:10:13 2010] [error] [client 192.168.1.232] SSL Proxy requested for www.web2-server-domain2.com:443 but not enabled [Hint: SSLProxyEngine]
[Thu Aug 26 15:10:13 2010] [error] proxy: HTTPS: failed to enable ssl support for 192.168.1.232:8443 (web2.domain.com)

So what seems to be happening is that I've got port 8443 in the proxy settings while web2 seems to see the incoming connection as being to port 443.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33538438
What server does the message:

[Thu Aug 26 15:10:13 2010] [error] [client 192.168.1.232] SSL Proxy requested for www.web2-server-domain2.com:443 but not enabled [Hint: SSLProxyEngine]

Appear on?  web1 or web2?
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33538448
Since you want to do SSL between web1 and web2 you will need to code some of the SSLProxy* statements:

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
0
 

Author Comment

by:projects
ID: 33539002
The msg shows up on web1 server ssl logs.

As for coding, I'm not sure what you're saying at this point. I do want to remind that I cannot mess with web2 in any way.
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 

Author Comment

by:projects
ID: 33539020
I'm not clear on 'coding' because at the moment, this works perfectly using nothing more than something called rinetd without any additional coding of any sort.

Of course, the current method doesn't stop Internet users from connecting directly to web2 however which is ultimately what I'm trying to achieve here.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33540865
"code" is meant to add Apache SSLProxy* directives as needed.    To the Apache config on web1 you need to add:

     SSLProxyEngine On
     SSLProxyCACertificateFile /usr/local/apache/conf/cacerts.crt


Where /usr/local/apache/conf/cacerts.crt is the file that contains the PEM encoded certificate used to sign the
certificate on web2.  This does not need to be the exact file name and location.  If you are already doing SSL on web1, you can add web2's PEM cert to your current crt file.
0
 

Author Comment

by:projects
ID: 33542019
Yes, both servers have their own godaddy certs. Mainly, I did this so that users would not keep getting the self signed cert popup.

So, the cert for web2 needs to be on web1 because for all intents, the data is coming from web1 so web1 needs to know where to get the cert info from?

I'm still not clear about how this ends up hiding web2 behind web1, allowing only users who are logged into web1 to see web2. Seems to me that so long as someone has the url, that's all they need. My hope was to hide the actual url in a menu item which can't be guessed. I think your proxy suggestion was because web1 would act as a proxy for web2 which would obfuscate any url information but that's what I'm wanting to confirm.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33543309
Who is doing the authentication web1 or web2?

Are all resources on web1 protected or just some?

How are you doing authentication on web1 right now?
0
 

Author Comment

by:projects
ID: 33545901
Both servers use their own SSL certs. Https is used for user login and other functions which should not be in the clear. All other functions are http.

When the user logs into web1, it has it's own cert, when they log into web2, it has it's own also.
0
 

Author Comment

by:projects
ID: 33546493
Sorry, it dawns on me that you're asking which server users authenticate on, not where there are certs.

So, web1 has it's own cert, where users would log into an account. It is by this process that I want them to be able to be allowed to access web2. Otherwise, users should not be able to access web2.

When user connects to web2, there also, the user is required to log in so there is an authentication process there also which is independent of web1.

I am looking into if there might be a way of pushing an env variable or something to auto log the user into web2.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33547861
--> I am looking into if there might be a way of pushing an env variable or something to auto log the user into web2.

You have to know if the application on web2 supports having something passed to it that has the user-id and says that it is already authenitcated.

In fact this is one of the options I mentioned earlier and you said you could not do this because you could not modify the application on web2.  So you need to find out what the applications supports.
0
 

Author Comment

by:projects
ID: 33547929
I looked into that and was told that the webserver is tomcat running on top a apache. Its
really a tomcat question is what I was told. So, if there is a way of passing the user name/password from web1, that would be wonderful but not a requirement.

Right now, just keeping this web site private, to users who are logged into web1 only, that's what I am hoping to achieve.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33547976
And that brings us back to the start and the problem.  You need to know if the application can accept some type of cookie from another site that basically says:

   "Hey this is web1 and I have already authenticated this user, their id is "bob""

Now, Tomcat can, but you may need to have tomcat running on Web1 and write a simple program there:

     http://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Single_Sign_On
0
 

Author Comment

by:projects
ID: 33548156
That's ok, single sign on isn't the important part of this. The main problem is having users who are authenticated on web1, being the only users who can see/use web2.

Your proxy idea sounds fine to me if I can implement it. I like that I could pretty much hide the server from public view but what I'm still not clear on is how it would be accessible. Authenticated users would have a menu option to go to the server but it can't simply be a url or anyone can bypass this.
0
 

Author Comment

by:projects
ID: 33548168
BTW, interesting lead on tomcat, thanks.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33548198
From my first post:

"Your best bet, and how it is normally done, is to have WEBSERV1 insert a security token/cookie that WEBSERV2 can check and do programming on WEBSERV2 to check for this."

So again, once again, the only way for web2 to know that the user has been authenticated on web1 is for web1 to pass something that web2 can check.  

However, you stated you can't modify the application running on web2.  Therefore, if you can't modify the application on web2 to check for something passed to it by web1, then you need to setup Tomcat to use single sign-on.
0
 

Author Comment

by:projects
ID: 33548212
Hehe, yes, we are going in circles now :).
Yes, it cannot be modified. Yes, it does run tomcat so there might be a possibility with that.

What I was really hoping for was something along the lines of what you got me excited about however. A reverse proxy, running on web1, which allows users to gain access to web2 via a menu option on web1. No public web URL means no Internet side hacking so that would be perfect.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33549117
When I mentioned the reverse proxy, I did not realize/understand that you had to be authorized on web2.  The I was interpreting it originally is that you just wanted them to get to "site1" on web1 before they could through to "site2" on web2.

Now with single sign-on setup properly and if the application on web2 supports it, it should work.  But the application has to also support.  Well its not as much as it has to support it, its more that it can't have its own built in security/authorization.  It would need to depend on Apache/Tomcat security/authorization.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33549133
Oh, you can still do the reverse proxy so that web2 has no direct access to it from the outside.
0
 

Author Comment

by:projects
ID: 33549433
As to tomcat, I would need to dig up more information to better know how this could be accomplished. However, if it's really just for a single sign on function, then while I'd love to have it, it seems to go well beyond the question I've posted :). Happy to work on it if you're willing to hang in there of course as I certainly appreciate the help.

As for reverse proxy, you mention above that web2 has no direct access so I'm assuming you meant that users would have no direct access to web2. That would work fine, so long as it could be done in a way that allows it to work as follows.

1: User connects to web1 from Internet
2: User logs in or authenticates themselves
3: User is now given a menu option which doesn't show up unless logged in.
4: Menu option is a link or wrapper to web2.
5: User logs into web2 inside of that wrapper or possible to send variables to tomcat for auto login. Not required but would certainly make things smoother.
0
 

Author Comment

by:projects
ID: 33555246
Have to leave until end of following week at which time I will continue on this. Thanks for your help to date.
0
 

Author Comment

by:projects
ID: 33623188
Am back and badly need to find a solution on this.
Need a way to keep the internal web servers available to logged in users on web#1 only and not allow open access from internet.

Reverse proxy might not be a solution if it doesn't know that a user is logged in or not.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33625789
Using SSO (single signon) it will.  However it all hinges on how the application on web2 does security.
0
 

Author Comment

by:projects
ID: 33628147
What I need to prevent is Internet users hacking away at web#2.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33628256
The most secure way to do that (IMHO) is to setup SSO between web1 and web2, configure web1 to be a reverse proxy for web2.  Do NOT setup web2 so that it can be directly accessed from the Internet.

If you setup web2 so that it can be directly accessed from the Internet, then no matter what you do somebody is going to try and break it.  Even if every page requires an authorized user.

However, even with SSO and reverse proxy, web1 could still be compromised.
0
 

Author Comment

by:projects
ID: 33628412
Web2 is a phone server so needs Internet access on SIP/RTP ports. The other part is the control panel which I don't want to make public, and available only via web1 through a wrapper available only to logged in/authenticated users.

We've talked about using a reverse proxy but this doesn't solve the problem after all unless there is a simple, non programming way, to let it know when a user is authenticated and so is allowed to connect to web2.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33628584
Even though it may need access to/from the Internet, you can filter what ports so you could allow SIP/RTP in/out,  but block whatever port the control panel is on.

There is NO way to require a user to go through some other box unless the application on web2 allows you to do this.

If the application does not allow for SSO or some other way to confirm that the user has been authenticated already there is nothing you can do.  You can't add functionality that is not there.

0
 

Author Comment

by:projects
ID: 33628639
SSO however will not solve the issue but would be a nice feature.

Currently, SIP/RTP are on one firewall which allows only these ports. The phone systems gateway is that firewall. The control panel to control settings are accessed through our main firewall which works perfectly both internally to from the Internet.

However, I'm trying to find a way of not allowing direct access from the Internet to that control panel. So, back to wanting only users who are authenticated on web1 to be able to access the control panel on web2.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33629136
I'm not sure how much clearer I can be:

--> I'm trying to find a way of not allowing direct access from the Internet to that control panel ....

Something must sit in front of web2 that can relay requests to/from the user from/to web2. That is exactly what  reverse proxy is.  

Therefore, The only way to do this is via a reverse proxy.  PERIOD.  

--> So, back to wanting only users who are authenticated on web1 to be able to access the control panel on web2.

The only way to do this is if the application supports some type of "pre-authentication" method or the passing of security credentials, such as SSO.  PERIOD.

--> ... nothing ever works yet I know this isn't rocket science

Sometimes it is.

0
 

Author Comment

by:projects
ID: 33630901
Wasn't implying that you're being unclear, I said that it still doesn't solve the problem.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33632769
Based on what you have said you don't know if it solves the problem.  

Have you checked with the vendor to see if they support some sort of "pre-authentication?"  Either based on SSO, pass tickets, kerberos certs, or something else.
0
 

Author Comment

by:projects
ID: 33638081
It's just gotten a little confusing that's all.

This could still work IF data from web2 flows only to web1, meaning that a user would have to be on web1 in order to access web2 data over the lan.

I think the confusion is coming from talking about users being authenticated on web2. This isn't important. So long as users can only access web2 via a menu option on web1, that alone implies that the user is authenticated at least on web1. If they have to double log in, so be it, that's something I can deal with down the road.

So long as web2 cannot be seen from the Internet directly, then this is what I need. It's just a matter of nailing down how to put it together.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33638432
I think we are back to where we were once before.

With the reverse proxy setup on web1 the users would be forced to go through web1 to get to web2.  That is true, but I don't know if you can force them to be authenticated on web1.

What you would need to try and do is access the "web2" URL directly from the browser.   That is using your information from above you would enter:

     http://web1/usettings

WITHOUT going to any other page on web1 first.  If web1 forces you to logon before it passes you to web2, then you are set.  If it does NOT force you to logon, then we have a problem.

I'm not sure if there is a way to protect a URI that is part of a  reverse proxy.


0
 

Author Comment

by:projects
ID: 33642401
The user on web1 cannot see the menu option unless logged in so yes, the user does have to connect to web1 and log in first. This is how it works now.

The problem is that anyone on the Internet can also try connecting to web2 if they know the URL, having acquired it from somewhere. The reason is that when a user connects to web2, web2 must have access to the Internet in order for it's packets to flow back out to the user. It also needs to have a DNS entry which is of course public.

The proxy idea would at least prevent Internet users from connecting directly to web2 since web2 would no longer have to be on the Internet as it is now.

I'm not worried about users having to authenticate into web2 as well once connected to it, that's not the main problem and something I can tackle down the road using LDAP or SSO as you mentioned.

So right now, a reverse proxy on web1 is the closest I've come to finding a solution. I just need to figure out how to run both a web server and a reverse proxy on the same server. Or, perhaps using a virtual server as the reverse proxy might make sense. I don't know, this is something I've never done.

I have set up reverse proxy using squid before but it wasn't in this type of application, it was only to cache and speed up traffic.

0
 
LVL 57

Expert Comment

by:giltjr
ID: 33643029
--> The proxy idea would at least prevent Internet users from connecting directly to web2 since web2 would no longer have to be on the Internet as it is now.


Wrong.  They will still know the URL, it will just be a different URL.  Today the URL is http://web2/something, tomorrow it will be http://web1/web2.
0
 

Author Comment

by:projects
ID: 33706752
I'm at a loss on this.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 33709790
If you can not modify the application running on web2, there is no way to prevent somebody from attempting to get to web2 as long as you can get to it from the Internet.  Either directly or through a reverse proxy.  You can do all you want to try and hide it, but you can't.
0
 

Author Comment

by:projects
ID: 33710008
If web1 can serve up data from web2 using a reverse proxy on the network, then that would work without having to give web2 access to the Internet, thereby, preventing users from directly connecting. Users would have to log into web1 in order to get a menu option that would allow them to access web2.

Gotta be a way of doing that :)
0
 

Author Comment

by:projects
ID: 33710080
I seem to recall that using squid as a reverse proxy, I can specify on squid which IP's are allowed to connect to a certain resource.
Would I not be able to specify that connections would not be allowed unless they are from web1 only? Then users would have to be authenticated on web1 in order to get the menu item which allows them to connect to web2.
0
 

Author Comment

by:projects
ID: 33716138
I've been reading for some time about this and it looks like I could set up a reverse proxy for web1 where the only client allowed is web1. That should do the trick and sounds pretty simple.

Problem I'm having is not knowing which way to go with it.
I could build a squid reverse proxy or I could use the proxy directive in the httpd.conf on the web1 server.

I may need to post another question if this is beyond something you can help me with however.
0
 

Author Closing Comment

by:projects
ID: 33716187
I'm awarding this because the answer ultimately ends up being a proxy solution which is what was suggested. There is some confusion in how to go about it but to be fair, this lead me to a decision and an answer which I appreciate.
0
 

Author Comment

by:projects
ID: 33716201
The end result will be as follows.

-No need to cut Internet access to web2, I will simply not open any firewall ports for web access to web2.

-Either install a squid server acting as reverse proxy, which would be best as it could also handle other such requirements, which I have.

-Alternatively, use the Proxy directive in httpd.conf on web1 which handles requests to web2.

0

Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Join & Write a Comment

Envision that you are chipping away at another e-business site with a team of pundit developers and designers. Everything seems, by all accounts, to be going easily.
ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

26 Experts available now in Live!

Get 1:1 Help Now