The firewall is, in this kind of setup, most probably running NAT (and thus will probably have only one public Internet address).
Yxorp, as a reverse proxy, should be somewhere between the client browsers and the web server(s) it is proxying for; the traffic between the clients and the web server(s) should flow through Yxorp. To make this work, and especially if you want to use Yxorp as a security device, you will need to carefully plan for the network environment that you will be using Yxorp in. If you make the wrong decisions, implementing Yxorp may decrease security instead of enhancing it; but also, if the networking design is wrong, it may cause your web servers to become unreachable, or serve pages with some of the content missing etc.
The diagram below shows a typical example of the minimal Yxorp deployment. The diagram shows an Ethernet segment which connects web servers, an Yxorp server, and client systems. A firewall connects to the Internet. Clients, i.e. systems running browsers etc., reside on the Internet.
The
firewall is, in this kind of setup, most probably running NAT (and
thus will probably have only one public Internet address).
An important note to take from this picture is that this setup is not inherently secure. The firewall would need to be configured to allow traffic into the Yxorp server (i.e. port 80 and/or 443). If Yxorp is broken, this allows traffic into your network without further restrictions. If for instance Yxorp is compromised, for example by an attacker exploiting an error in Yxorp's code, or by a mistake in the configuration, the attacker might able to insert another configuration or bypass Yxorp. By changing the configuration, it might be possible to setup a tunnel that might work well enough to allow other TCP protocols to be passed into any box on your network.
A possible solution to this is to make sure all boxes on your network are secure in themselves. One way of doing that is to make sure each box runs firewalling software and is adequately patched, like you would normally do for a box that is directly connected to the Internet.
The diagram below shows a more secure setup. The Yxorp box is sitting between two firewalls; the outer firewall allows port 80 and/or 443 from the Internet into Yxorp; the inner firewall allows port 80 and/or 443 from Yxorp into the web servers.
The difference with the minimal setup is that the traffic between Yxorp and the web servers is now restricted by the second firewall; this means that even if Yxorp is compromised, it is still not possible to use that vulnerability to reach the Intranet clients or other systems on the internal network (like your server running Samba and NFS for your MP3-collection).
Another example by which almost the same security principles are reached is shown below. It uses a firewall with three interfaces; one connects to the outside world, one connects to the internal network, and one connects to Yxorp.
This
setup is almost as secure as the two-firewall setup. The differences
are mainly that the complexity of the firewall rules is increased,
and that one wrong rule in the firewall could open up the internal
network. In a corporate environment, you would want to prevent that;
if you are just running Yxorp at home and are in control of all
involved systems, the differences are not that important.
A better example of a corporate environment is in the next drawing. It shows a two-firewall setup again, but this one is even more complicated because management traffic is separated from production traffic. Reasons for doing this would be like: being able to segregate duties between several systems management teams, retaining some form of control over the infrastructure even if a denial of service attack is in progress, better insight in traffic flows so network IDS boxes would be easier to configure, etc.
Note
that the drawing is simplified; for instance, it does not shows what
happens behind the web servers. Normally, there would be another
security zone there for the application servers, and maybe even
another one for things like database servers and mainframes.
If you want to use Yxorp to enhance security, you must pay attention to the system that Yxorp will run on. Ideally, the system would be hardened (i.e. all security settings should be at the maximum level that will allow the box to do what you need it for) and also it should be minimized (i.e, there should not be any software that you do not need installed on it). The philosophy of minimizing a system is based on the idea that software that is not installed on the box cannot be vulnerable to attacks, and does not need security patches.
For Linux, most distributions come with a minimum software set; that would be a good start. Take a look at what is included in the software set anyway, some distributions for instance install inetd (which you probably wouldn't need) and telnet (which you wouldn't want). Solaris currently has the reduced networking set, which is appropriate for this kind of system.
The next step is hardening. Take a look at what listening ports there are, and determine if you really need them. Typically, a box running Yxorp only would need sshd to be active, so you can manage the box (you can of course also use a console, but that is rather awkward if you need to upgrade or patch the box). Also look at what processes are running; if there are any you don't need, prevent them from starting or uninstall the software for them.
If a user enters http://www.example.com/ in his browser, the browser connects to the IP address that his system thinks www.example.com lives on (i.e. what his DNS server tells his system). So, for Yxorp to do anything meaningful, www.example.com needs to resolve to the IP address that Yxorp runs on.
Yxorp then needs to forward the request to the real server. Yxorp uses it's own mechanism for this, which is based on IP-addresses only (it would not make sense to use DNS for this). However, the web server will need to think it is called www.example.com because otherwise it will not be able to find the right content for the request (at least not if you use HTTP/1.1 and a virtual hosting capable web server).
Exactly what and how you need to configure for this is very much dependent on the actual web servers. The most important part to remember is that the domain name needs to point to Yxorp, the Yxorp configuration needs to list the IP-addresses of the real servers, and the actual web server(s) need to be configured to serve content for the domain name.
If you want to use SSL between the clients and Yxorp, you will need to install keys and certificates on the Yxorp server. The default installation procedure described in the INSTALL file contains some steps that help in generating a test certificate authority, server certificates, and optionally client certificates.
Yxorp can deal with the TLS extension called server name indication. SNI makes it possible to use virtual hosting in combination with SSL. SNI works by allowing a client to send the desired server name before the SSL handshake has completes, and, more to the point, before the server has to present it's certificate (which must contain the server name).
Current major browsers in general seem to support SNI – if they are running on a current major operating system. To enable SSL with SNI for Yxorp, it needs to be built with OpenSSL 0.9.8g or later. The current major Linux distributions currently include a suitable version of OpenSSL; there is no need to build it specifically to enable SNI any longer. However, there are also many distributions that are not yet at a suitable level; check the output from the ./configure to be sure (especially the messages saying something like “checking if openssl version is high enough to support TLS extensions... yes” and “checking if openssl version is high enough to support TLS extensions... yes”). If necessary follow instructions on how to enable SNI on backlevel distributions in the file INSTALL.tlsext.