ssh-proxy, a new approach to firewall software

[mag () BUNUEL TII MATAV HU (Magosanyi Arpad)]

Hi!

After 3 days of furious programming, here is the half-finished code of
the ssh gateway: http://www.linux.hu/~mag/openssh.prepared.tar.gz
[No, it isn't even quarter finished, but I am forking to background again,
and have no time/whatever to end it in the foreseeable future (except
if one says "gee, it _is_ nice, here is the cash for finishing it")].

There are logically two parts of the work. Let's start with the more
boring one: I have modified a big part of the openssh code making
functions to include and use an int session parameter.
Now this parameter can be 0 or 1, but writing the necessary initialization
functions for the packet and the channel handling it is relatively 
straightforward to raise the limit to <undefined>.
Rationale: The ssh proxy needs at least two of the encrypted connections,
        because it has to talk with a client and a server in the same time.
Status: I _believe_ that this wasn't introduce a security hole, and
        possibly only minor bugs. I was modified every other line of the
        code in some sources, but the modifications were straightforward.
        I have tested it, and seems to work.
        Of course I cannot be sure that is the case.

The really interesting one is the ssh proxy (ssh-proxy.c). 
The idea is the following:
To the client it looks like an ssh daemon, but forwards anything politically
accepted to some other host, for which it looks like an ssh client.
Because the encryption, it does a "man-in-the-middle attack":
substitues every key with a fake one, etc,etc. So far it is the normal
behaviour an ssh proxy is expected to work. The design of the beast is
the interesting part:
        There is expected to be a higher level where the policy decisions
        are made: where to connect, when does the connection gets
        accepted, what are the substitue keys, etc. I think of the
        upper layer as a scheme script, part of which constitue
        the configuraion files, the other parts are the configuration
        library, which can be replaced by the admin if she knows a better.
        A bit like the state machine code of fw-1.
        Whenever the proxy gets to a state it generates an event and the
        upper layer decides on logging it, possibly aborting, and the
        parameters of the following control flow.
        The proxy knows the details of the protocol, the upper layer
        knows about the states of the protocol, and the configuration
        parts of it possibly knows only some configuration parameters.
        The communication of the proxy and the upper layer is done
        via events (the fw_event() function). Before the event the
        proxy sets variables which are the parameters of it ( with
        fw_set_option_* ). The upper layer makes decisions based
        those parameters, and other parameters set in previous events.
        The decisions are communicated either through setting variables
        or directly modifying the control flow (tipically aborting).
        The proxy reads the variables set by the upper layer (with
        fw_get_option_*), and acts accordingly.
Rationale: By my experience all firewall software have the problem
        of not giving enough chance of decision to the firewall
        administrator, and not going up enough on the OSI layer.
        The (even stateful) packet filters are by design cannot easily have
        the information needed to do real firewalling work. The proxy
        firewalls would have the chance, but (at least I) haven't seen
        one which would really pull everything which is in the
        technology. Typically they stop at IP based access control,
        user based access control where inbound authentication is
        easy enough, and some simple filtering capability. And you end
        up using just plugs for everything, which is nearly as bad as
        just having a packet filter. Maybe your vendor calls
        one particular setup of his plug as samba gateway, and if
        you not look into the insides of your firewall, you will
        think that it really parses the protocol. (Practice #1
        for script kiddies: fire a VPN through telnet port using ssh 
        and have your firewall administrator not notice it. 
        Practice #1 for firewall administrators: Make it at least
        a bit harder to do for a script kiddie with your current
        firewall software.)
        So we need something which can keep up with the kiddies at least.
        Here is it. If you like buzzwords, call it stateful proxy
        technology. Have a proxy, and if you like it, alter
        every nuance of the way it speaks the protocol.
        And (it doesn't appear in the code, because it isn't
        ready), if you need to stack in something to keep care
        of the healthy state of your data and systems (covert
        channel minimising comes to mind), just stack it in, and
        have phun.
Status:
        A serious programmer does not give out such a code. I wouldn't
        either, but I have to abort this project of mine here and
        I hope someone will find it interesting enough to keep on.
        What is written is only ssh-proxy.c and fw/fw.h . 
        It compiles cleanly to object, but you would not find
        a lib to link with, and there is no main() anywhere.
        (Yes, there is a proxy_main()).
        What is missing:
                The helper functions on the bottom, and the upper layer
                on the top:)
                Everything after we got into the server. There is no channel
                code, or main loop.
        What we have:
                Lots of memory leaks. If you give me a buck for every memory
                leak you find in the code, I will be _rich_!
                Surely other bugs. 1400 lines of C code untested
                should be a very healthy location for millions of bugs.
                If you ever have problems about your house having to many
                bugs, just untar the archive to the carpet, wait until
                the bugs run in, and put out the thing to the dust bin.

Credits:
        To the openssh team.
        To the ALF team.

-- 
GNU GPL: csak tiszta forrásból