Q: How can I maximize security for my LISTSERV installation or for individual LISTSERV lists?
Answer by Ben Parker
Chief Corporate Consultant, L-Soft
From time to time a question arises about how to increase security for a LISTSERV installation or for individual LISTSERV lists. The basic means for improving security is to deny access to any information that might be used by unscrupulous persons to attack your server or your list.
Improving Server Security
Knowledgeable persons know that there are several basic informational commands that anyone can send to a LISTSERV server and get a response. These require no authentication. One such command is SHOW VERSION or RELEASE which returns something like this:
From: "SEARN LISTSERV Server (16.0)" <LISTSERV@SEARN.SUNET.SE>
Date: Fri, 2 Oct 2009 19:51:30 +0200
> show version
LISTSERV(R) High Performance for VM version 16.0, managed by:
POSTMAST@SEARN.BITNET
Master nodes file version: 2001-02-07 14:30:26 (VERS9922)
NJE peers file version: 2006-11-29 19:28:29
Internet peers file version: 2009-05-27 03:30:44
Service file version: 2007-05-18 20:30:31 (VERS9922)
Alias file version: 2009-09-03 18:55:21
Virus database version: 2009-10-02 17:07:06 (F-Secure Anti-Virus 8.00)
Running under: CMS release 15 (SLU 901 - ESA mode)
Build date: 15 Sep 2009
This information discloses that LISTSERV software is running on this server, gives the version number and build-date. It also identifies the underlying operating system and the F-Secure anti-virus version. Additionally, an email address known to have POSTMASTER level privileges (the highest possible level) is revealed. This address might easily be forged to issue disruptive commands to the server, such as deleting all subscribers for an unprotected list.
The first thing we can do to protect the server is modifying the revealed POSTMASTER address. Certain addresses (such as postmaster@..., administrator@..., mailer-daemon@...) are recognized by LISTSERV as special addresses, most often from automated applications and not from a real person. Commands issued coming from such addresses will be ignored by LISTSERV. Knowing this we can expose an address for POSTMASTER that is actually useless, even if forged as the From: address for some command. The line in site.cfg might look like this:
POSTMASTER=postmaster@example.com HIDE: realperson@lsoft.com
The address before the HIDE: modifier is the only one shown in response to the SHOW VERSION or RELEASE command. All addresses after the HIDE: modifier have full POSTMASTER privileges and receive various notification messages from LISTSERV when necessary, but are never revealed to the world. The only address revealed is in fact useless.
Another way to reduce revealed information is with the setting:
PLAIN_FROMLINE=1
This is a Boolean setting (0 or 1 are the only valid options). The effect of this setting is to shorten the From: address line of LISTSERV response messages. Instead of the typical:
From: "SEARN LISTSERV Server (16.0)" <LISTSERV@SEARN.SUNET.SE>
setting this value would shorten the line to simply this:
From: LISTSERV@SEARN.SUNET.SE
Another item of revealed data is at the bottom of every LISTSERV Command Response message:
Summary of resource utilization
-------------------------------
CPU time: 0.015 sec Device I/O: 11
Overhead CPU: 0.002 sec Paging I/O: 0
CPU model: 7060 DASD model: 3390
Job origin: bparker@POP.LSOFT.COM
Although this may not reveal much useful information, some people would prefer to hide it as well. This can be eliminated with the (Boolean) setting:
JOB_STAT_DEFAULT=1
Sites with many lists may occasionally suffer a hit-and-run 'spoofing' attack where some address attempts to subscribe to many lists in a short time, followed by an attempt to send some spam message to the same lists, and then unsubscribe. This can be prevented with a (Ver 14.3 and later) setting:
MAX_CONSECUTIVE_SUBS=
This sets a limit on the maximum number of subscribe commands from a single address. The default is 50, but some sites may prefer to set the value lower, such as 25 or even as low as 10. It should not be set so low that a normal subscribe request (say for 5-6 lists) would be trapped. A special aspect of this keyword is that when it is applied, LISTSERV not only prevents further subscriptions, but will in fact 'roll back' and cancel the earlier subscriptions prior to the point where the limit was activated.
Increasing List Security
List Owners can also take precautions to protect security on their lists. Site Administrators may also want to consider adding these tips to their master list creation templates or scripts so that these settings are in place as soon as a new list is created.
Perhaps one of the most useful settings has been around for several years.
.hh on/.hh off
This setting (.hh) stands for 'Header Hide'. Place the .hh on as the second line of the list header (after the List Title on the first line). Set the .hh off as the last line (or the last line after any configuration settings). Then when anyone issues the 'INFO listname' command, they will receive a response like this:
There is no information file for the TEST list. If you have any question
about the TEST list, write to the list owners at the generic address:
TEST-request@LISTSERV.EXAMPLE.COM
*
* Test list
*
* {57 lines hidden}
*
Note that all the significant lines that reveal the List Owner's personal address, any editors or moderators, any filters or other special settings are all hidden. You can allow any informational text that you want to make public outside of the .hh on/.hh off block.
Related to the above, you can also edit the INFO template in the listname.MAILTPL file and remove the line:
.dd LISTHDR
This will completely prevent the List Header from being shown at all. The Site Administrator should perform the same edit of the same template but in the SITE.MAILTPL file so it protects all lists on the site.
There are other template messages in *.MAILTPL that can reveal the List Owner's personal address. For example the DELETE1 template does this in 2 ways:
From: LISTSERV@LISTSERV.EXAMPLE.COM
Subject: Your removal from the TEST list
To: Ben Parker <bparker@EXAMPLE.NET>
cc: Ben Parker <bparker@LSOFT.COM>
Tue, 6 Oct 2009 23:41:36
You have been removed from the TEST list (Test list) by Ben Parker
<bparker@LSOFT.COM>.
The List Owner's email is shown both in the cc: and also in the message text. You can modify this template to remove both exposures:
>>> DELETE1 Your removal from the &LISTNAME list
.* next line hides true Owner= addresses
.cc off
.re owners
&WEEKDAY, &DATE &TIME
At your request, you have been removed from the &LISTNAME list (&TITLE)
by the List Owner.
Other templates that have these exposures and need similar editing include CHANGE1, SIGNOFF2, ADD1, SIGNUP1, ADDMOD2, SETINFO.
Another protection is afforded by the list configuration setting:
Validate= Yes, Confirm
With this setting, all commands must be authenticated or confirmed with the List Owner's password. All commands issued from the WWW interface are automatically authenticated this way. If any command is issued without a confirming password, then LISTSERV will send a 'Request for Confirmation' message to the List Owner. If you receive a command that you know you did not just issue (such as DEL listname *@*) then a) you will not confirm the command and your list will be protected and b) you will have evidence of attempted tampering including the IP address of the sender that you can pursue in an appropriate way.
A List Header setting of:
Confidential= Yes
will prevent your list from being listed or publicized in CataList, L-Soft's worldwide list of lists. It will also conceal it from the local list of lists on the server. This hides the existence of your list from potential prying eyes.
If you are at an educational institution or company and want to limit potential subscribers to a given domain (or even an IP address range), you can set a 'service area' this way:
Service= example.com, *.example.com
Persons with email addresses outside this range will be rejected from posting, subscribing, or examining the list message archives.
You can control who can join your list with either of these settings:
Subscription= Open, Confirm
Subscription= By_Owner, Confirm
The first allows anyone to join, but ensures they have a valid, working email address and they have confirmed their desire to join your list. Automated scripts cannot confirm and thus are prevented from joining. The second setting also requires the confirmation by the user, then the request to subscribe comes to you. You can then consult a membership list or other source to verify if the user should be allowed to subscribe. You can also modify the ADDREQ1 template to send out a questionnaire as the Confirm request with appropriate questions for the users to answer to help you validate their subscription request.
With the setting below:
Review= Owner
only the List Owner can obtain the list of subscribers to a list. Otherwise, any subscriber can request a copy of the list's subscribers from LISTSERV using the 'REVIEW listname' command. This prevents address harvesting. With this protection in place, subscribers must ask the List Owner for the list of subscribers and the Owner can assess their need to be allowed to have such information.
Of course, as people post messages to a list, their addresses (and membership in the list) is necessarily revealed. Many lists keep message archives. These can be another source of possible exposure of subscriber addresses. The first step to limit exposure is to make the archives accessible only to subscribers, by making them 'Private':
Notebook= Yes,...,Private
LISTSERV is also helpful in this regard. In Version 15.0 and later, when viewing public list message archives via the WWW interface, all subscriber email addresses in the message header and even in the message body are replaced with the phrase <log in to unmask>. This also prevents address harvesting by 'web spiders'. If the user logs in, he is authenticated and LISTSERV will display the addresses. Of course, private archives require a login anyway.
Hopefully these suggestions will help you secure your list and protect your subscribers.
| 
