6 Replies Latest reply on Jun 22, 2011 3:21 PM by sliedl

    SSH Proxy issue in v8?


      I've just come across something which has never been an issue with MFE before.


      As long as the sshd_config file is configured appropriately it has always been possible to have the ssh server and ssh proxy running in happy co-existence.


      However on a recent v8 customer installation this doesn't appear to be the case. We have another appliance (an SSL-VPN solution) sitting on the inside of the Firewall and we have an access rule in place allowing SSH proxy access on an external alias IP address. When they were running Sidewinder 6, this connection worked. They have a v7 appliance at a different location and this too allows us to establish SSH connections directly to the firewall on it's primary IP, or via an alias address which then allows us to access an internal SSH-enabled device.


      However, on the recently-installed v8 appliance (replacing the old v6 box), while we are able to SSH to the Firewall, when we try to access the SSL-VPN device we, can see an "acl allow" audit entry and a "nettraffic" entry, but sandwiched in-between is something entirely new and I suspect this is the reason why the SSH client is reporting a failure.


      2011-06-22 15:34:32 +0100 f_ssh_proxy a_proxy t_error p_major

      pid: 36682 logid: 0 cmd: 'sshp' hostname: ldnfw.x.x

      event: no transport netsessid: 7309e4e01fd78 src_geo: GB

      srcip: x.x.x.x srcport: 3365 srczone: external dst_local_port: 22

      protocol: 6 src_local_port: 0 dstip: x.x.x.x dstport: 22

      dstzone: internal attackip: x.x.x.x attackzone: external

      rule_name: CLI-Access

      reason: Transport negotiation not correctly configured.  Session terminated.

      information: key exchange


      The problem is we don't understand why it is be behaving differently with this version.

        • 1. Re: SSH Proxy issue in v8?

          Hello Phil,


          At a certain point, a decrypting SSH proxy was implemented (70100 I believe?). It appears that the error message above is related to the firewall presenting it's key to the remote device, when the remote device is expecting the client's key. I ran into this with another customer.


          Few things to try:


          1) If you don't need the decrypting SSH proxy, use a generic proxy instead.


          2) Clear the client key from the server, so that it can learn the firewall's key.


          Let me know if this makes sense or if you have questions.



          • 2. Re: SSH Proxy issue in v8?

            As it happens, Matt, we appear to have fixed the problem without implementing either of the changes you suggested.


            This Firewall's Application Defense group is "connection settings" (something we have discovered with v8, as all of it's predecessors was more proxy based and would only use the packet filter equivalent of "connection settings"  if specifically defined)  and so we've changed the App Defense group on this rule to "minimal proxy" and everything has sprung into life.

            • 3. Re: SSH Proxy issue in v8?

              That is good. Sorry, for some reason I had it in my head that you were at version 7, which is why I suggested the generic proxy.


              I am interested though, after changing to the minimal proxy group, does the audit state that you are still using the ssh proxy?



              • 4. Re: SSH Proxy issue in v8?

                What is interesting is that having just read Sam Leidl's blog about version 8 rules, the fact that we were using the SSH service in these rules should have meant that it was acting as a proxy anyway.


                We can only say, based on this experience, that it clearly wasn't - otherwise, why did the change from "connection settings" to "minimal proxy" make it work?

                • 5. Re: SSH Proxy issue in v8?

                  When you use the built-in SSH application you are always using the SSH smart-proxy, as evidenced by the audit message you pasted.  You had 'Connection Settings' set as the app. defense and this does not have the 'Use TCP proxy' box checked, but in the audit you are hitting the SSH proxy (cmd: 'sshp').


                  This probably has to do with the SSH Proxy application defense (the 'connection settings' app. def. group has <None> for SSH and the 'minimal proxy' group has <minimal proxy> selected SSH).


                  What do these commands give you back?:


                  $> cf appfilter q profile=ssh service=client_encryption


                  $> cf appfilter q profile=ssh service=server_encryption

                  • 6. Re: SSH Proxy issue in v8?

                    This looks to be a problem in the way the proxy is handling negotiation of the algorithms that will be used to secure the connection.  It's like the proxy has no settings configured in the SSH app. defense, or very strict settings (although if you configured strict settings I would have expected a better message, like 'Proxy configured for DSA keys, client sent RSA keys').


                    I've been trying to reproduce it but I cannot.  Would you like to collect data for us in a working then non-working configuration?  I would like you to if you can.  You can PM me your Grant number and I'll open a ticket and email you directions on what I'd like you to collect.  It'd be a simple setup, tcpdumps and audit with 'connection settings' as the App. Def. Group and then the same with 'minimal proxy' as the app. def. group.