projects
asked on
Firewall: Deny Access unless from another web server first
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.
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.
ASKER
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
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
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()
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.
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()
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.
ASKER
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.
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.
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.
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.
ASKER
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.
I'm not sure a gateway is required but I am certainly listening.
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?
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?
ASKER
>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).
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).
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?
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?
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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.
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.
ASKER
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.
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.
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.
ASKER
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?
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?
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.
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.
ASKER
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.
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.
ASKER
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.
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.
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.
ASKER
But can apache run as both a server for local content including ssl AND as a proxy to talk with the remote?
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.
ASKER
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.
Yes, you can configure Apache to be both a server and a proxy at the same time.
ASKER
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?
Might you know of a URL, web document that shows how to set this up for Centos?
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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/
The url to the internal server would be like I posted above.
https://web2.domain.com:8443/
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.
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.
ASKER
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.
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.
ASKER
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?
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?
ASKER
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.
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.
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?
[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?
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
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
ASKER
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.
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.
ASKER
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.
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.
"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/cac
Where /usr/local/apache/conf/cac
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.
SSLProxyEngine On
SSLProxyCACertificateFile /usr/local/apache/conf/cac
Where /usr/local/apache/conf/cac
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.
ASKER
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.
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.
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?
Are all resources on web1 protected or just some?
How are you doing authentication on web1 right now?
ASKER
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.
When the user logs into web1, it has it's own cert, when they log into web2, it has it's own also.
ASKER
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.
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.
--> 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.
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.
ASKER
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.
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.
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
"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
ASKER
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.
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.
ASKER
BTW, interesting lead on tomcat, thanks.
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.
"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.
ASKER
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.
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.
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.
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.
Oh, you can still do the reverse proxy so that web2 has no direct access to it from the outside.
ASKER
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.
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.
ASKER
Have to leave until end of following week at which time I will continue on this. Thanks for your help to date.
ASKER
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.
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.
Using SSO (single signon) it will. However it all hinges on how the application on web2 does security.
ASKER
What I need to prevent is Internet users hacking away at web#2.
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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.
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.
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.
--> 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.
ASKER
Wasn't implying that you're being unclear, I said that it still doesn't solve the problem.
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.
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.
ASKER
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.
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.
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.
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.
ASKER
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.
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.
--> 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.
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.
ASKER
I'm at a loss on this.
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.
ASKER
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 :)
Gotta be a way of doing that :)
ASKER
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.
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.
ASKER
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.
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.
ASKER
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.
ASKER
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.
-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.
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.