Security for "Free Home Page" Linux Web Service 12
Anonymous Coward writes "I have a couple of Web servers (running RedHat 5.0) which I'm using to offer free Web hosting on, and I've been giving the users standard accounts, the only exception being that their HOME directory is also set to their HTML directory. This means that telnet is active, as well as ftp, which I didn't consider a problem (that's how I learned, after all), but I was wrong.
One of these boxes was hacked, by someone telnetting in and installing a sniffer. We've had to take the box down and scrub it clean, and before I bring it back online, I'd like to know the best way to give users relatively unfettered access to their own files via ftp, while disabling their ability to do anything else, on a box running any brand of Linux." I know we've touched on this aspect of security before in several Slashdot forums, but this question has been asked (and will be asked again) many times. I figure it may as well have its own forum for discussion.
Security.. (Score:2)
Then go and reinstall a recent Linux distro. I recommend Slackware [slackware.com]. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD [openbsd.org] is another possible solution
Now, if you want to just give them FTP access (and nothing else), ProFTPD [proftpd.org] provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH [openssh.org] and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq [securityfocus.com] for possible advisories. I also recommend (very much so) that you read LASG [securityportal.com] -- the Linux Administrator's Security Guide. It's very good
---
Lynx (Score:3)
There are a lot of features of Lynx that makes this a great idea. Users can upload/manage/edit files, and it can be set up to only run programs that are specifically set in Lynx. You can also disable the access to a shell in it (the keystroke is '!', I think).
Check out the well documented system-wide lynx.cfg file. You can use TRUSTED_EXEC to limit what local commands may be run and TRUSTED_LYNXCGI to limit what local CGIs the users can run. Set SYSTEM_EDITOR to force the user to only use the editor that specifies. Uploader definitions allow uploading using rzsz or kermit though ftp appears to be safe enough (as long as you make sure the version of the daemon you're running has no known holes). KEYMAP allows you to disable certain commands (shell, and possibly goto). The DIRED_MENU definitions allow you to set what users can do in their directories (copy, move, edit, compress, etc). Yes, you can tag multiple items for file operations.
I've seen systems with this setup and they work really well. Newbie users who are scared of CLIs will find it nice as well.
For extra-extra security, try removing the all-execute bit for all of your regular shells and set it so that only a trusted group may execute them, just to make it *that* much harder to screw with the system.
Get Help!!! (Score:3)
This is a job for a professional, and since you are asking for help in this forum, you would be wise to pay for some professional assistance. If you do not wish to do this, at least follow these steps:
First of all read the linux security HOWTO [linuxdoc.org].
Start with a minimal install of a Linux you are comfortable with. RedHat is probably ok if you use the latest version and keep up with patches. I'd consider using OpenBSD for this kind of server since it's more secure by default, but it's not better if you don't know how to administer it properly. The only visible services you should need are ftp, apache, and sshd. That means no sendmail, nfs, linuxconf, talk etc. Edit
find . -type f -perm ++s -print
In fact, you can gain a little peace of mind by running the command
chmod -R o-rwx *
Which will remove normal user read, write, and execute permissions from every file and directory.
Then reinstall the ftp daemon because otherwise people won't be able to list their files etc. Other things may break. Add things back as needed. For instance if you allow CGI scripting, you would need to give execute permissions on
If you use wu-ftpd (default with RedHat) then add '/./' (that's slash dot slash) to the end of their home directory path in
Secure apache with appropriate configuration. I don't recommend allowing CGI scripts, but if you do, at least use cgiwrap [freshmeat.net]
Now that you have everything setup, freeze everything except
Log the heck out of user activity, preferably onto a box that is not connected to the internet. Read Bugtraq religiously and follow your distributions security lists.
And finally, get help, really. Paying somebody upfront, even if it is only to review your actions and policies is a very good idea.
--
Re:Security.. (Score:1)
How to limit shell access to a box (Score:2)
there are many ways to limit shell access while still allowing ftp access. the main things to keep in mind are:
these things (especially number 1) let you do some neat things--you can create a user called ''nslookup'' with /usr/bin/nslookup as their shell and no password; when someone connects to your box as nslookup, they can execute the command, and then they get disconncted when they are done. the university of washington has a test account [washington.edu] for people to try out pine that does this. any other interactive program can be used in the same way: provide a telnet gateway via /usr/bin/telnet, a news reader via /usr/bin/tin, and so on.
hope this was helpful
darren
A well-rounded solution. (Score:1)
Second consider using OpenBSD [openbsd.org] as the OS on the web server. Use the included IP Filter software that ships with OpenBSD, in addition to the packet filter in step 1.
If you are using Apache for your HTTPd, compile it with as few modules as possible, and no dynamic module support.
To really go whole-hog on security, you could block ALL protocols except HTTP and HTTPS, and have all user uploads and other account management go through cgiwrap on a HTTPSD instance.
Personally what I do for friends who want FTP access is use a One Time Password (S/Key or the like), but the average user probably won't be willing to deal with OTP.
Re:Security.. (Score:2)
1) To sniff, you'd have to be in a direct route between the user and the server. The likely hood of this over the internet is rare, at best. Unless, of course, you compromise one of the ISPs.. Which leads to
2) The user is chrooted into their own home directory by the ProFTPD configuration. The only thing they can change, would be the files in that dir. Even if they magically broke out of the chroot jail (impossible, AFAIK), they would still have normal Unix file premissions stopping them from changing random files.
In this case, encrypted FTP does not show a significant benefit for a great deal of effort. I still suggest my original premise of seal-box with normal FTP access for all, and SSH for one.
---
Re:Security.. (Score:1)