Many organisations just assume that the local physical network is trusted. That their network equipment is physically secure and that it is impossible for an attacker to get on the wire and start eavesdropping on network traffic.
Many organisations do not seem too concerned about a very old vulnerability regarding Ethernet-based networks called ARP-poisoning. Basically ARP-poisoning means that an attacker-controlled system steals the identity of another legitimate server, thus drawing all network traffic away from the legitimate server to the attacker-controlled system. Then, the attacker can do with that traffic as he or she sees fit. The attacker will be performing a man-in-the-middle attack. Please note that such an attack is trivial using tools as Cain and Abel or Dsniff.
It is often the case that many different server systems are placed in a single network segment or VLAN. That implies that any of these systems poses a threat to each other. It takes just one hacked system to compromise network traffic between all the other systems. This is especially a threat to all unencrypted network traffic, but encrypted sessions may also be attacked if clients don't check the sever's identity.
Unless you've actually implemented proper network segmentation using separate (V)LANS and filter traffic between these network segments through firewalling, your environment may be at risk. In that case, please understand that it takes just one single web application containing just one vulnerability to compromise the entire environment.
Not everybody has implemented proper network segmentation and firewalling, preventing these kind of attacks. And it takes quite some labour to change all that. So what can you do, assuming that you want to do something right now?
In general, in a shared network environment, as described, the only way to make sure that data in transit is kept confidential and unmodified is to make proper use of encryption, identification and authentication.
The solution
To secure web traffic, there is already a fairly easy solution: using HTTPS or HTTP over SSL. The most difficult part is getting a valid SSL certificate and configuring the HTTP server to use it.
But if you want to transfer files between servers or between clients and servers? How about that?
Is there actually an easy way to securely transfer files between two hosts? From what I can see, the answer is "no". Security comes with some additional effort and it isn't easy.
The first problem is to understand what 'secure' actually means. To me, it means that data is not stolen or modified by an attacker during transit.
There are three requirements to make sure that confidentiality and integrity is guaranteed:
- data in transit is encrypted;
- the client authenticates the server;
- the server authenticates the client.
Encryption prevents a man-in-the-middle attacker from eavesdropping or altering data. And if the client verifies the identity of the server, the attacker cannot impose the real, genuine server. This part may be overlooked. "I'm using SSL, thus encryption, so I am safe, right?". That is a firm negative. The client is identified with a password, passphrase or client-side SSL certificate. But how does the client identify the server? If the client doesn't verify the identity of the server, you might as well turn encryption off.
For the Windows platform, there is no native solution. Most of the time, files are transfered using SMB and thus your files can be grabbed from the wire and you may be transferring your files to some impostor instead of the genuine host.
The other often-used solution is FTP. And everyone knows that the biggest problem with FTP is the lack data encryption. All communication, including credentials for authentication, are transmitted in plain-text.
Without any additional third-party software, it is impossible to securely transfer files between Windows hosts, except for one solution that I have never seen used: IPsec. IPsec is used to encrypt any network traffic between two host, thus also SMB traffic.
The Unix world has only one solution without using third-party tools and that is transferring files using SSH as a secure transport. But SSH is also used for secure shell access to hosts and it may be difficult to prevent shell access and still allow file transfers.
So now there is a new tendency to use FTP over SSL. You have the same inconvenience as with HTTPS: you need to install a valid SSL certificate on each FTPS server. And although this does improve security, encryption is still useless if the client side system does not properly validate the server's identity.
Furthermore FTP uses a control channel for commands and a separate data channel to transfer the actual data. You want both channels to be encrypted, but that may not be the default. Check your FTP server's configuration to make sure this is the case.
Implementations
To implement FTP over SSL on Windows, you might want to take a look at the Filezilla server. An FTP server that also supports FTP over SSL. It had some security vulnerabilities in the past but not too many. To me, it is a better solution than to expose TCP-port 445 to other systems. The SMB service doesn't have a good security track-record.
For Unix environments, take a look at VSFTPD. The Very Secure FTP daemon, is written by Cris Evans, who works on the security team for Google. The irony is that although VSFTPD itself doesn't seem to be affected by any security vulnerability itself, the hosting provider hosting the software was compromised by an the attacker. This attacker put a back-door in a specific VSFTPD release.
Anyway, I still recommend VSFTPD as it is very well-document and the configuration is simple.
If one of these solutions is not an option for your particular situation, you might think about using your existing insecure file transfer method on top of a VPN connection that handels authentication and encryption, such as OpenVPN. But setting up OpenVPN within such an environment may also be cumbersome.
Recent events regarding compromised certificate authorities show that the trust model SSL-authentication often leans upon may be broken. You must be sure which certificate authorities to trust. If you have your own certificate authority, make sure you take every precaution to keep it secured.
Question: should the client rely on build in CA certificates, the sames as present in your browser? Or are you going to configure the client to accept only the single certificate of the server?
If you have any other suggestions for a simple solution to securely transfer files between hosts, feel free to leave a comment.
