Hello all,
I am currently migrating a server to a trio of machines using OpenBSD,
and ran into a bit of a design problem. Most of this is not OpenBSD
specific; I'll happily take this question elsewhere if told so, but it
would not exactly be the first non-OpenBSD-specific question here.
To start out with: the server is a typical do-everything-on-the-LAN
linux box. It handles firewalling, web serving, and quite a few
sensitive documents. I'm trying to separate it into a firewall, a web
server, and a third server for 'anything but web' which is the only one
with any more-or-less confidential data on it.
Since I'm a bit of a security hobbyist, I prefer the system to be at
least resistant to any known attack I can reasonably protect it from.
The main problem, right now, is file transfers. The old server serves
FTP over SSL. Both the data and the control stream are encrypted for
those accounts that are likely to handle confidential data. The problem
with encrypting the control stream, of course, is that it prevents
stateful firewalls - like the OpenBSD box in front - from working as
intended.
Switching to a different system is acceptable, but not preferred, as it
has taken quite a bit of effort to get all the users who should into
using FTP. (Then again, as long as it presents a GUI resembling an FTP
interface, it might as well be FTP to pretty much all of them.)
The users are a comparatively small group, which can be told to use a
different client if really required but will bitch and moan quite a
bit. They use Windows 98, XP, or Mac OS X. Additionally, I use OpenBSD.
The Windows users have been told to use CoreFTP; I use lftp on the rare
case that I need to access anything via FTP; and I have no idea what the
Mac users use, but I've not heard any complaints from the two of them.
I'm basically asking for recommendations on file transfers. I see a
couple of options:
- FTP without SSL
This works well, and is very universally usable. The lack of any
kind of password, let alone data, protection makes it a little too
insecure for my tastes, though.
- FTP with SSL
Requires tearing a big hole in the firewall, as ftp-proxy
understandably does not grok encrypted traffic, which also causes quite
a bit of insecurity.
If allowing only passive FTP, the hole is less dangerous, but
still...
- SFTP
This works well, but requires everyone to use a different
client. Additionally, it violates the principle of least privilige in
most implementations[1]. Requires another method for distributing
publicly available files, but this is not much of a problem - push the
files from the trusted server to the web server, and let httpd do its
thing.
- Collection of (PHP?) scripts on the web server
This should work. It's not scriptable and not very usable from
anything but a browser. Additionally, webapps tend toward lots of
security holes, which is why it was decided to put the web server on a
separate box with no important data. So this breaks the security model,
either way (either there is a web server on the 'other server', or there
are important documents on the untrusted web server)
- WebDAV
I've never used this. The Apache authentication features should
be plenty; however, Apache+mod_dav isn't quite as secure and carefree as
either stock ftpd or vsftpd. There are not that many clients, and
support is not quite universal. It's not quite FTP.
The other solution I can see is hacking ftp-proxy to catch any SSL-ish
commands, and then speak plain FTP to the server and FTP+SSL to the
client. This could get complicated fast, though, as it would probably
entail changing ftp-proxy from a simple inetd process to a full-fledged
daemon (to prevent the overhead of starting OpenSSL for each
connection), as well as tacking on a system to catch SSL and
authentication commands (as, for instance, the 'ftp' user should be
given free access without SSL, but the 'veryhighlypriviliged' user
should be required to use SSL for both control and data streams).
This does have a couple of advantages - it actually works on the
firewall, it's an interesting project, and it makes use of the installed
base. OTOH, there are some disadvantages, too - mostly that it is more
than a little complicated, and requires a fair bit of custom coding.
I am leaning a bit to the latter problem, mostly out of hobbyism, but
realise it is far from perfect. Which is why I though to sollicit some
input from misc@ first.
If you've made it through all this rambling, thanks for reading, at
least! I'll happily receive any replies.
Joachim
[1] Though if I can get everyone to use public key authentication, I
could use the command= syntax in ~/.ssh/authorized_keys (where is this
documented, anyway?). If I point that to a simple binary that does a
chroot and then execs sftp-server, the problem shouldn't be too serious.
