ssh-proxy, a new approach to firewall software

[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