Security for "Free Home Page" Linux Web Service

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..

[Inoshiro]

First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).

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

[jfunk]

You can set up Lynx as the user shell.

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!!!

[copito]

Making a secure multi-user Unix box is difficult with any Unix. It requires a good clean start, perferably professionally audited, with as few services running as possible, as few setuid programs as possible, and as draconian as possible restrictions on the access and activities of users as possible. Then add robust monitoring of critical system files and users activities and be constantly vigilent to spot any abnomalities and apply security patches when vulnerabilites are discovered.

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 /etc/inetd.conf and comment out every line except the in.ftpd line. Edit your rc scripts and disable all nonessential services. Check yourself with nmap. Don't install X or gnome/kde since they tend to have security problems. If you must have X (or even if you don't), make sure that you don't have any setuid programs on the system. You can find them with
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 /usr/bin/perl.

If you use wu-ftpd (default with RedHat) then add '/./' (that's slash dot slash) to the end of their home directory path in /etc/passwd. This will lock their ftp sessions in a chrooted jail.

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 /var. This could mean, minimally, using tripwire or something of that nature to monitor file changes, but it is a very good idea to use a read only (hardware read only is the best) file system.

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..

[FigWig]

What do you think of allowing normal FTP logins? Doesn't it just beg for password sniffing? Although not as convenient would it be better to make users tunnel through SSH for FTP?

How to limit shell access to a box

[dlc]

there are many ways to limit shell access while still allowing ftp access. the main things to keep in mind are:

1. a user needs an interactive shell (in the traditional sense), like bash or csh to actually do things on your box. once that program ends, the user is logged out. you can assign, for example, /bin/passwd as a user's shell; when they sucessfully log in via telnet or ssh, they will be prompted to change their password, and then logged out. colleagues and i have been jokingly coming up with ideas about good non-shells-- /bin/passwd is a good one; if you want to be obnoxious, you can use /bin/login. :)
2. in order for a user to ftp into your box, their shell needs to be listed in /etc/shells. simple: add /bin/passwd to /etc/shells, and set their home directory to be the document root for their web site. this way, they have (up|down)load privileges for their files, but not shell access.

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.

[Nonesuch]

First, put the box behind a packet-filter, either a standalone router or behind another box running IP-Filter [anu.edu.au]. The filter should block ALL outboung connections initiated by the web server- your users will have to use passive FTP or HTTP for file uploads. There should be no other hosts on the same ethernet segment as the web server.

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..

[Inoshiro]

"What do you think of allowing normal FTP logins? Doesn't it just beg for password sniffing? Although not as convenient would it be better to make users tunnel through SSH for FTP?"

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..

[FigWig]

I missed the SSH for one bit...I was thinking someone on the same network could sniff the password over FTP and login using SSH to do their evil, but if only one person can SSH in then no problem...