1. General questions

1.1 Why Zorp is better?

Am I right in thinking that plain old HttpProxy still leverages significant intelligence against my connections? What sort of attacks does it defend against? (Cross-site scripting? Really-long URL (GET) requests?)

Zorp forces strictly the correct usage of the given protocol, which means RFC compliant usage of commands (reqests and responses), correct orders and attributes (lengths, character sets etc).

So if an exploit, a worm or a valid utility;-) keeps the RFC it will get through the proxy. Fortunately majority of the worms, attacks and other bad things do not comply with the protocol (like code red or nimda). If something complies with the protocol it is an nIDS, content vectoring or virus detection issue, not a protocol proxy's task.

Zorp's architecture has many layers, but two main layer is the proxy itself, which is writen in C (it is a "stupid" protocol parser) and the python layer, which gives a very powerful tool to implement your policy and an administrator can create the narrowest channel between the zones with it.

As you can see the zorp modules (binaries) are in /usr/lib/zorp/ and python codes are in /usr/share/zorp/pylib/Zorp/*.py. All .py files begin with a long documentation, which describes how the given proxy works and what kind of attriutes it has. These attributes' defaults has been set to the possible strictest state. It is strong enough to block many attacks. In addition all the proxies can parse the protocol and it is transmitted to the python layer. From the policy you can accept, reject or even change the the given request or response. For example in a Http proxy you can change the user agent to hide your internal architecture (MUAs, browsers, etc):

class MyHttpProxy(HttpProxy):
        def config(self):
                HttpProxy.config(self)
                self.request_headers["User-Agent"] = [HTTP_CHANGE_VALUE, "Lynx 2.4.1"]

There are alvays an AbstractProxy, which contains the basic settings of the proxy (many of the protocol commands are handled here) and there are many predefined proxy sets derived from Abstractproxy, which are the most common used proxy sets. Ftp is a good example. There are the following proxies defined in Ftp.py:

class FtpProxy(AbstractFtpProxy):
class FtpProxyAnonRO(AbstractFtpProxy):
class FtpProxyRO(AbstractFtpProxy):
class FtpProxyAnonRW(AbstractFtpProxy):
class FtpProxyRW(AbstractFtpProxy):
class FtpProxyMinimal(FtpProxyRO):

1.2 Isn't the Official Unofficial Zorp project a fork? Forks are frowned upon for good reasons.

It isn't a fork, this is why the unofficial zorp is official.

The fixes will be get back to zorp-gpl. It is simply that zorp-gpl have been neglected a bit, and I could not see this.

The other side is that there are things which do not or only to a little extent related to the core, and I want to play with anyway. Bazsi do not want to see these features in their version until they aren't rock solid, and the users get the feeling of the ideas behind (zorp builds on a lot of concepts even right now which not understandable for a simple firewall administrator used to fw-1). You cannot yet see too much of these yet, because it is very disgusting to look through the code line-by-line to spot that few points which should not made public. But for example the filltable utility goes to this direction (well, it is not core to the extent that it isn't even zorp).

1.3 What is the version policy?

For BalaBit's version policy, see their policy. The zorp-unoff versions simply append the debian revision number, that is a hyphen and a number.