Intro to securing Free BSD Part 4




Securing FTP -


This is only going to be a very minimal section for FTP because I've written a tutorial on FTP security already with SUSE Linux and if you use PureFTPd on Free BSD, I think you can use my configuration file from that tutorial so that this tutorial doesn't become big.



FTP is at a risk being a clear text service that has been around for a long time. FTP was not intended really for security, but for transferring files from one host to another, or from a server to a host. It's a fairly simple idea in theory that works quite well. FTP has some limitations that HTTP does not have, but HTTP was made different than FTP.

FTP transfers in clear text meaning it has potential for someone to sniff the traffic. This means your username and password are at risk. Now you could of course just make FTP annonymous but then you have even more to do. I'm going to try and keep this one simple because, as I said, I've covered the topic before. I'm only adding it in really to make it relevent to Free BSD.

FTP is used for things like downloading files, such as Free BSD ISOs or Linux and of course uploading web pages and other files to a server somewhere.

It's not as predictable like POP3 and IMAP are with the regular username and password being sent every few minutes... Don't give yourself a false sense of security though. A false sense of security is worse than none at all. If you know there isn't much security you're less likely to wrote down a password or do things that you would do if you thought good security meassures are in place.






If you have SSH enabled -



Encrypted FTP is possible over the SSH channel, with the SSH program establishing a connection starting the /usr/libexec/sftp-server program on the server end, and opening the needed connections back to the client over encrypted channels. The secure FTP client then operates transparently to the user, just like a regular FTP program.

With Free BSD, the built in sftp that's part of the Open SSH serves the purpose of handling the client end of a secure FTP session. On Windows the SSH communications security package provides a secure FTP client that works with Free BSD. If you're a Mac OS user, MacSSH does have FTP capabilities and of course, Mac OS X, which is based on Free BSD at it's very core, has a command line tool called sftp.

An alternative way to perform file transfer over a secure connection is to use scp. This allows you to copy files to and from a remote server sing login authentication much like RCP. The difference is that scp operates with SSH and an encrypted tunnelto the remote machine.


A few SSH clients such as NiftyTelnet/SSH for the Mac support file transfers in this way.

For more info man scp.







Securing Apache -

This is not going to be a complete guide. Entire books have been written on this, but you can get a good idea of how to do things here.

HTTP, the protocol over which the Web travels, is probably the most visible service on the internet today. A lot of information some would consider sensitive is being passed over HTTP. Secure HTTP is vital to web commerce and any online business. HTTP itself send in clear text, some peopel don't always understand the importance of encryption for web traffic, so grab a port sniffer and let them log into their email account and show them how their username and password are right there. Then just to make a point, send their wife a message saying they are cheating.

In any event the important thing is telling users why exactly they should not use plain HTTP. Free BSD comes with Apache. Apache is the most populkar web server ever and was considered a "killer app" for Linux as well, though I think I would argue somewhat against it, but it was very important.

Apache gets it's name not just from helicopters, but "a patchy" web server. It was patched a lot and turned into something new.

Apache comes on just about every version of Linux there is and comes with BSD and Unix as well. Windows has a port for it as well. Web servers are very large applications and any app this big is going to have bugs. You can patch Apache but you'll need to secure it so your users are not so much in the high risk area.

I can't stress the importance with secure web servers enough. If you have to prove to someone why they should lock down Apache, show them a mirror of web defacements. People do this for fun and it's showing your system as insecure. How many of your customers are OK knowing you've been hacked before?

One of the earliest uses for SSL was securing Apache. A few years ago, getting apache and SSL to play was really something you would buy software for from a commercial vendor who specialized in it, but there were free versions of Apache with SSL enabled. When 2.0 of Apache was released this was a bit easier as SSL was tightly integrated into Apache in the default install so setting it up was much easier.

If you are using Apache 1.3 as of et, I will try and get as much of that as I feel needed. Secure HTTPS and the Clear Text HTTP are made to work nicely. You shouldn't use SSL enabled HTTP all the time with every HTTP request, this is not done often. HTTPS should be used for sensitive information as encrypting every page takes a lot of processing.

If you run an online business your customers should use it when they are entering information like credit card numbers, usernames, and passwords.






Apache-SSL -

Apache-SSL is the "Official" secure implementation of Apache prior to 2.0. Apache-SSL has a more limited feature set than mod_ssl, being primarily concerned with stability and performance than prettyness. Development of Apache-SSL is fairly slow at times which is mainly there with the tightly controlled features and the low number of known bugs.

The Apache-SSL binary is httpsd, not httpd. The idea here is that you use HTTPd for regular web pages and HTTPs with encrypted requests on port 443 so 80 is open with HTTP.

This would mean that you need a version of Apache without SSL as well. You can get apache-SSL from /usr/ports/www/apache13-ssl.






Apache with mod_ssl -




mod_ssl is a more complete and active implementation of SSL on HTTP than Apache-SSL. mod_ssl is a standard Apache module that links OpenSSL into Apache, taking advantage of the modern modular architecture of the software. It's more streamlined than Apache-SSL, and it incorporatesmany more features and a more versatile configuration model.


The apache13-modssl port installs a single httpd executable, for example, just like the regular apache13 port, except the configuration files have special tuning to enable SSL requests when needed.

<ifDefine SSL>
Listen 80
Listen 443
</IfDefine>



You can add more modules to Apache with mod_ssl; these include mod_php, mod_perl, and all the rest in /usr/ports/www.

The focus of mod_ssl is a complete set of features and configurability.

In Apache 2.0 mod_ssl is compiled into the httpd binary by default. The configuration options are given in the basic conf file /usr/local/etc/apache2/ssl.conf which you can add into your httpd.conf file.







Running a secure web server -




Installing either Apache-SSL or Apache with mod_ssl makes updating and keeping your web server going a bit more complex. As I said, Apache-SSL operates thinking that you're going to have a regular HTTP server running to hanbdle non SSL requests and this means a seperate httpsdctl program controls Apache-SSL, operating the same way as apachectl with regular Apache.

You should also note that an httpsd.conf program is added to /usr/local/etc/apache parallel with http.conf.

These seperate programs aren't present if you install Apache with mod_ssl and the functionality is rolled into a single set.

The ports, both of them, install a complete Apache directory trees, including icons, samples, dynamic modules, and conf files.This is the reason you should take your time when updating the parallel installations of Apache-SSL and regular Apache. The mod_ssl version only has a single installation, replacing the standard Apache installation, so the upkeep is potentially much simpler.