mt.cfg dark matter: TransparentProxyIPs

The TransparentProxyIPs directive for mt.cfg does manage to qualify as documented, barely: mtchanges.html lists it as:

TransparentProxyIPs configuration setting allows IP addresses to be seen through a local proxy.

Not quite enough? With the default, TransparentProxyIPs 0, MT determines the remote_ip (in lib/MT/App.pm) as $app->{apache}->connection->remote_ip if you are running mod_perl, or $ENV{REMOTE_ADDR} if you aren’t. With TransparentProxyIPs 1, remote_ip (which is what MT uses for IP blocking and throttling, and saves in the activity log and along with comments) comes from $app->get_header('X-Forwarded-For').

I think what they actually mean is a reverse (caching) proxy. The way the term seems to be generally used, a transparent proxy is something that the BOFH sets up at your office, to intercept all outgoing intarweb traffic and prevent you from doing useful things like surfing weblogs. The transparency comes in because you don’t have to (or get to) make any changes in your browser configuration: it just grabs your packets and does what it wants with them.

A reverse caching proxy is when you set up something like Squid aimed backwards, looking at incoming traffic instead of outgoing, in front of your web server. Anything that Squid has a good cached copy of, it just sends back to the requesting browser, anything it doesn’t have (including dynamic things, like MT pages and comment forms) it passes on to the actual web server. Because it wants the server to send it back to it, not to the requesting browser, it sends the request from it, with an X-Forwarded-For: header containing the original IP address (or a whole string of them, if the request has passed through multiple proxies). The web server can concentrate on doing the dynamic stuff, while squid handles the boring static things, but if something like MT doesn’t know to look at X-Forwarded-For: (and whoever compiled Apache didn’t bother to include Ask’s mod_proxy_add_forward), you wind up getting all your comments from something unhandy like 192.168.1.2.

But wait, there’s more! While your BOFH is competant, and set up his proxy server to only accept connections from the proper IP addresses, lots of other people have incompetant BOFHs, who set up open proxies that the whole world, including comment spammers, can connect through. You can even enjoy the fun yourself: in Firefox, Tools → Options → Connection settings will let you route everything through any open proxy server. I personally favor things like 61.121.224.11:80, which is a Japanese proxy server with a vicious content filter. Use that, then try to go to www.google.com, and you’ll find yourself at www.google.co.jp. Search for anything, er, interesting, and you’ll find yourself up against a 403 Forbidden, or an explanation of what evils the SmartFilter saved you from, Chat, Personal, Politics, Mature, you name it. I’m afraid I introduced it to the fact that I’m a Chatty Cathy, since the first few times it didn’t mind my blog, but now it’s firmly in the Evil Chat category.

Oh, my point. While a comment spammer would certainly prefer an anonymous proxy server which doesn’t pass on any information about him at all, possibly not even the fact that the connection passed through a proxy, they tend to have pretty bad latency and uptime, what with the thousands of sleazeballs all trying to use them. And since we haven’t bothered to try logging X-Forwarded-For: or Client-IP, we aren’t even denying them the use of the least anonymous of open proxies. Yet.

4 Comments

Comment by Matt #
2004-09-12 21:11:12

These are great. You seem to have a knack for writing documentation.

 
Comment by Scott #
2004-09-12 21:53:35

Evil BOFH? That’s the second crack in a week. You got something against sysadmins, or what? :-)

Transparent proxies _are_ evil, though, because they mess with your browser’s brain, they don’t work 100% of the time, don’t save any time for the admins (see WPAD or autoconfig scripts for proxy settings), and are unnecessary if all you want to do is log or block IPs.

Reverse proxies, on the other hand, are extremely useful for reducing the load on an Apache server, since the proxy does a better job at caching (like you say) and performing SSL handshakes. And anything worth protecting with a password is worth encrypting with SSL. Especially now that you can get free certificates at CAcert.

Comment by Phil Ringnalda #
2004-09-12 22:04:09