Re: Another Secure FTP thread -- Protection Levels

In article <Alm9g.58227$x97.54158@xxxxxxxxxxxxxxxxxxxxxxxxxx>, jaltman2
@nyc.rr.com says...
John Santos wrote:

I think to do this, the OP's company's security people need to set up a
gateway or proxy system (not the firewall) to act as an FTP relay
^^^^^^^^^^^^^^^^

between his system and the remote system. There would then be two FTP
connections, his system to the gateway, and gateway (through the
firewall) to the remote system. He would need to establish his FTP
session to the gateway, telling it via some magic (encoded in the
username or file specification or stored in a config file on the gateway
or ...) that he really wanted to send the file to the remote system (or
that he wanted to pull it back). The gateway would then set up a
second (encrypted) FTP session to the remote end. It would receive
packets from the first system, decrypt them, do what ever validation
and logging is needed, re-encrypt them and send them over the 2nd FTP
connection to the remote end. The same in reverse for the reply
packets. The encryption between your system and the gateway and the
encryption between the gateway and the remote system need not have any
connection: separate keys, certificates, algorithms, etc. (He may not
even need any encryption between his system and the gateway; that
depends on how much the security people trust their corporate network.
Most likely it will be required, though.)

This would require that the private keys that are supposed to be
controlled by the user must be in the possession of the firewall.


No, the gateway system is not the firewall. It would probably be run
by the network security people, but could be a different set of people
than do the firewalls. (The firewall people would have to trust the
gateway people to properly monitor and record the sessions, and permit
connections from the gateway to the remote system while blocking FTP
connections to or from anywhere else.)

As far as I am concerned firewalls, should not be involved in
decrypting my traffic. You want firewalls to authenticate outgoing
connections in order to ensure that only those services running
on approved machines are allowed to make connections to the
destination address.

In my scenario, the firewall does *NOT* decrypt the traffic.

We had a solution for this years ago, its called SOCKS v5. The
client machine opens a socket level connection to the firewall
which instructs the client whether the desired connection
should be established:

* direct to the destination

* through the firewall without authentication

* through the firewall with authentication

* or is not permitted.

The application running on the client is unaware of this negotiation.
When the application connects to the destination it may or may not be
using a redirected socket. It is completely unaware.

The firewall would be coded to allow encrypted traffic from the gateway
server (but not his own system) to the specified remote system, and
rely on the gateway to do the necessary validation and logging. Both
the gateway and the firewall would be under control of the security
people, not the end users.

You (the OP) could use Kermit to do the FTP client functions on your
system, just as you do (or are trying to do) now. For that matter, you
could probably implement the gateway system as a giant Kermit macro, too
:-)

I think secure FTP gateways (not sure what they are called) are
available commercially. At least one company I know of uses one to
send credit card information to the company that actually manufactures
and mails the credit cards to their customers, so it must be fairly
secure. I don't know if the gateway they are using is home-brew or
COTS. Maybe the firewall people at the OP's company already have
one - he should ask.

The problem with this is that I don't trust the security people and
neither should you. In fact, the security people shouldn't trust the
security people because you never know when someone is going to become
compromised.


If you don't trust the security people, fire them, immediately :-)

Clients are issued certificates, tickets, or other credentials to
authenticate the client. They are not meant to be used to authenticate
the firewall. If you give all of your credentials to the firewall then
not only do the administrators of the firewall have the ability to
impersonate you but so does anyone that is able to compromise the
firewall. There have been plenty of security holes in the operating
systems that firewalls and routers run on that would allow for the box
to be compromised by an attacker. By intentionally installing a man
in the middle, you are opening the door to significant risk.

1) The gateway is neither a router nor a firewall.

2) You can encrypt the data separately, end-to-end. The gateway can't
tell if it is legitimate or not anyway. (I'm sure there is an
information theory proof of this - if the gateway could validate the
data, it could probably produce it in the first place, obviating the
need for the client system to exist.)

What the gateway is trying to validate is the direction of data flow,
the file names being sent or received, and possibly the timing and
amount of data and any other information it can pick out of the FTP
protocol. In addition, the firewall still validates the source and
destination systems, even it can't filter on the content.


3) Rhetorical question: Who is the client? Is it some system on
corporate network, or is it the corporation itself? The end system
users, the firewall administrators, etc. are all employees or agents
of the corporation, so in that sense, they are all the client.


Jeffrey Altman


--
John
.

Relevant Pages

  • Re: [Full-Disclosure] MS should point windowsupdate.com to 127.0.0.1
    ... Stick the kit behind a NAT gateway, ... For incoming connections, once can just forward incoming port 80 connections ... So far, so good, other than we are now running IIS exposed to the world. ... process for sorting out the problems with a certain very buggy piece of FTP ...
    (Full-Disclosure)
  • Re: Another Secure FTP thread -- Protection Levels
    ... through your firewall that is not authorized. ... FTP either restrict what commands can be sent or logging each command ... gateway or proxy system to act as an FTP relay ... between his system and the remote system. ...
    (comp.protocols.kermit.misc)
  • Re: Another Secure FTP thread -- Protection Levels
    ... gateway or proxy system to act as an FTP relay ... between his system and the remote system. ... There would then be two FTP ... firewall) to the remote system. ...
    (comp.protocols.kermit.misc)
  • Re: Intermittent intra-LAN connectivity
    ... > other desktops and their server produces strange ... > except the gateway. ... Plugged into different interface on the firewall. ... > connections for all interfaces and was rebooted. ...
    (microsoft.public.win2000.networking)
  • Re: Routing problems
    ... >definition of a default gateway, ... local, or reachable through QWorst, and QWorst knows how to distribute ... >central routing point for all clients on the .1 subnet to access any of the ... I mentioned that the firewall has very tight security, ...
    (comp.os.linux.networking)