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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:57 PDT