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; there are also clients 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 and the attacker is able to insert another configuration, it would 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, i.e. at least they run firewalling software and are adequately patched.
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 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, having 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).
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 and telnet. 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. Normally, 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 we 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, and the Yxorp configuration needs to list the IP-addresses of the real servers.
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 “make install” will generate a test certificate for you automatically.
Normally, using SSL will block virtual hosting. Since the certificate must be sent before the Host: header can be read, it is not possible to send the correct certificate for the domain name in the Host: header. There is a way around this; it is possible to generate certificates containing more than one domain name, but as far as I'm up to date on this, only IE correctly checks for this variant; Mozilla-derivatives, Safari & Konqueror reject the certificate.
For personal use, this is not a bad thing; it only means you will get a popup window asking if you want to accept the certificate. For public use, this means that the users have no way of being sure that the site they are connecting to is the right one.