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
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