"The Linux Gazette...making Linux just a little more fun!"

Setting up ISP Mail Services

From chris smith on Tue, 29 Dec 1998

James:

I have been going over all the back issues of the Linux gazette (and many books and articals) looking for info on setting up a Linux(5.1) machine as an ISP to serve e-mail to customers.

In a test sceneraio I hava created new accounts with passwords and sent them e-mail from an outside( through another ISP), but trying to find the info on how to retrive the e-mail is very difficult. My intent was to use POP3, and aparentaly I have to configure inetd.conf to run POP3 and allow others access to ther accounts.

On most distributions POP and various servers are enabled by default. Normally it's wise edit /etc/inetd.conf to disable POP and other services.

When you created these accounts --- one thing you should probably do is disable user access to shell (login) services by setting their shell to /bin/false.

Actually there is a problem with that, too. It gets a bit complicated by the fact that /bin/false on many Linux and other Unix systems is actually a shell script. You'd think that a shell script that does an immediate exit would be safe enough. However, 'telnetd' and some other services will propagate certain types of environment variables to the login shell. It's possible (using some shell quoting hackery) to trick /bin/false (the shell script) into executing arbitrary chunks of shell code if they aren't filtered by the telnet daemon.

So, you should compile your own binary equivalent of false --- actually I wrote my own I call "denysh" as shown here:

#include <unistd.h>
	/* denysh
	 *	by: James T. Dennis,  <jim@starshine.org>
	 *	    Proprietor, Starshine Technical Services
	 *
	 * 	Deny a user shell access.  Intended for use as
	 * 	the "shell" for POP mail, FTP only and other users
	 *	who are supposed to be restricted to non interactive
	 *	use of the system.
	 *
	 * 	Usage:  using vipw you can replace the "shell" field
	 *	of any user's account record in the /etc/passwd with
	 *	the full path to this binary.  You can also add this
	 *	to /etc/shells and (as root) use the chsh command to
	 *	apply this (no need to edit /etc/passwd if that bothers
	 *	you).
         *
         *  compile with:
	 *                   gcc -static -o denysh denysh.c
         *
         *  to prevent any chance for shared library (LD_PRELOAD)
	 *  exploits
	 */

int main () {
  char *message= "Access Denied:  Your account is not"
		" permitted interactive login!\n";
  write (STDERR_FILENO, message, strlen(message));
  exit(1);
}

... just compile that and read the comments.

I also recommend setting the home directories of "POP Only" users to some directory that they don't own, to which they do not have any other access, and also denying them FTP access.

Of course if your customers have special needs --- for example they intend to run 'procmail' on your server, etc --- then you'll need to review your policies and make your own decisions.

Of course, most sites don't secure their systems all that well. So many sites will continue to use the /bin/false, and they'll occasionally see their "POP Only" users (or people who've sniffed or stolen the passwords for their users) subvert the "/bin/false" into full interactive shell access.

Of course if your system is using PAM there are ways that you can limit specific users and groups to specific services (particularly using the 'listfile' module. PAM is the default authentication model for Red Hat Inc's distribution --- and it can be installed on other systems as you like. It's also possible to limit access to services based on where the request is coming from. Thus it's pretty easy to institute a policy that allows 'telnet' and other forms of access from your local LAN while denying it to anyone whose request is coming from an "outside" system.

If your going to run an ISP system you'll want to learn quite a bit more about Linux security than the average sysadmin.

(Shamless plug: I'll be giving a tutorial on the subject at the upcoming LinuxWorld Expo: http://www.linuxexpo.com).

any Help that you can give will be much apriciated.

chris

ps. I got handed this job under protest saying I am willing to learn ( I come from the land of windows and dos where everything is in one directory not scattered around {what is up with that anyway} ), and I am reading everything that I can, but there are still many many holes, the local groups are some help, but the continued refference to read the man pages helps little. I hardly under stand what they are saying 1/2 the time. just venting i guess

I've never seen an MS-DOS or Windows system where "everything is in one directory" --- even if you consider the Win '9x "Registry" --- that is more of a "virtual file system" than a "single file" (since it has many "sub trees" and "nodes").

Indeed, you'd find (if you'd studied any operating systems beyond MS-DOS, Windows, and Unix) that the similarities between MS-DOS and Unix are somewhat greater than their differences.

However, the Unix, and consequently the Linux, convention is to use relatively simple text files for configuration of almost all services. System services are almost all controlled by files under the /etc directory tree.

The use of text files allows for easy repair, auditing and relatively easy automation of changes (since awk, Perl and other text processing scripts can be written to modify many settings on systems across a network. It's also possible to distribute new configuration files (including passwd and group files to update user account information) over the net. This is facilitated by having separate files for different services.

"in the deep end and over my head comming up for air soon I hope"

Well, one approach would be to just "go with the flow" --- just enable the POP daemon support in inetd and let the users access whatever other services they like.

Professionally your best bet is to recommend that a consultant be placed on retainer to help you set up each new service as requested. That consultant should review your needs, show you how to install/configure the service and give you some pointers on maintaining it. It would be a good idea to have that consultant --- or better yet, a different one --- come in to do periodic systems administration and security audits.

In this way you get the help you need, the services installed and configured by someone whose done it before, some training, and a direction to which you can escalate emergencies.

If your boss expects you to "just do it" and expects it to all get done right and in a timely fashion, and refuses to provide you with the additional resources (consultants, training, time, leeway to mess things up, whatever) then you should definitely consider your negotiating position.

(Many employers exhibit unreasonable expectations in this field. They've fallen victim to the lies of software company marketeers that have been chanting "ease of use" for the last two decades. A lot of software is only "easy to use" if you want to do it "their way" and accept whatever limitations and flaws --- particularly security flaws --- it shipped with. However, many of these managers will listen to reason --- and the really important part of a sysadmin's job is to manage the expectations of his or her users and management).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49