Security and the SME Server V5 - Version 5.0

A technical white paper

Dan York

Mitel Networks Corporation

Table of Contents

1. Introduction
2. The Role of the SME Server
3. Elimination of Non-essential Services
4. Replacement of Services With More Secure Alternatives
5. Open Source Code Review
6. Network Security
6.1. Packet filtering
6.2. Disabled Services Do Not Run
6.3. Selective Address or Port Binding
6.4. Application-level Access Control Lists
6.5. Authentication and Authorization Mechanisms
7. User Accounts, Groups and Passwords
8. Remote Access
8.1. Secure Shell (ssh)
8.2. Telnet
8.3. Point-to-Point Tunnelling Protocol (PPTP)
9. File Transfer
9.1. File Transfer Protocol (FTP)
9.2. Windows Networking (SMB)
9.3. Macintosh Networking
10. E-mail
11. DNS
12. Web Services
12.1. SSL Support
12.2. CGI Scripts
12.3. PHP
12.4. Webmail
12.5. Web Proxy Server
13. Server Console
14. Information Bays
15. Ongoing Security Updates
16. Conclusion
Appendix A. List of Processes
Appendix B. List of Loaded Kernel Modules
Appendix C. Packet Filtering Rules
Appendix D. List of Open Network Ports
Appendix E. List of Open UNIX Domain Sockets
Appendix F. Configuration of tcp_wrappers
Appendix F.1. /etc/hosts.deny
Appendix F.2. /etc/hosts.allow
Appendix G. SMB Security
Appendix H. Apache Security
Appendix I. Rules For Mail Relaying
Appendix J. List of setuid Files and Directories
Appendix K. List of setgid Files
Appendix L. Sample ssh Server Configuration File
Appendix M. Listing of Software Packages

1. Introduction

This white paper discusses security as it relates to version 5.0 of the SME Server V5. It is aimed at system administrators and those with an interest in the technical aspects of system and network security.

While no product can be 100% secure, we have configured the SME Server to provide the highest possible level of security "out of the box". We recognize that security is important in businesses of all sizes and we want to ensure that your system and network are protected. In order to do so we take actions such as disabling non-essential services, configuring services to operate in their most secure mode, automatically providing packet filtering, providing encrypted means of remote access and taking other steps that are part of an effective firewall solution.

Beyond these steps, we strive to automate "best practices" in Linux system administration so that tasks that an expert system administrator would normally do are done automatically for you. Regardless of your experience level, this automation relieves a great deal of pain that is normally associated with security and system administration and also reduces the possibility of accidental mis-configuration.

In this document, we will discuss the major components of the SME Server as they relate to security and the technical steps that we have taken to ensure the integrity and security of the system.

2. The Role of the SME Server

The SME Server builds on the widely acknowledged reliability of the Linux platform, and addresses the complexity problem through a very simple installation process. Once installed, the SME Server provides security and a rich set of Internet services including e-mail, web hosting, webmail, secure remote access, ftp hosting, file and print-sharing and many other features. The SME Server V5 software runs on any commodity PC, works with virtually any Internet provider, and allows customers to use their choice of desktop platform.

The SME Server can be configured in either of two modes of operation. In server-only mode, the SME Server operates as a standalone server on a local network and provides file and network services to all systems on that network. In server and gateway mode, the SME Server is configured with one network connection to the local network and a second connection to the Internet. In addition to providing file and network services to the local network, it also acts as a gateway allowing the entire local network to access the Internet.

3. Elimination of Non-essential Services

The developers of a generic Linux distribution such as Red Hat do not know exactly how that computer system will be used. For that reason, they usually configure the operating system to be able to support many different types of server and workstation uses. Many services are included on the system that may not ever be used. When someone installs such a generic distribution, those services may open up security holes into that computer system.

A cardinal rule of system security is "only run the absolute minimum number of services necessary for your operations". With the SME Server, we know precisely how the vast majority of users are going to use our server and therefore can simply remove all other services. Unnecessary services such as NFS, NIS, the Berkeley "r" suite of programs (such as rsh and rwhod) and many others have not been included.

Beyond services, we do not include many of the packages that are included with a standard Red Hat installation. As an example, the SME Server does not include any of the standard compilers or development libraries, as these development tools have been used in the past to install compromised programs during network attacks. Additionally, we eliminate most of the user tools that would be used in a Linux workstation configuration. For instance, the X Window System and associated programs are not included.

Essentially, if we could not identify a need to include a package or service in the product that would benefit small to medium enterprises with their daily operations, we eliminated it. Through this simplicity, we are able to minimize the security risks to the system.

If you are interested in specifically what services are enabled, the following list indicates the services started in a default configuration. They are listed in the order in which they are started. A definitive listing of running processes can be found in Appendix A.

syslogd, klogd, crond, xinetd, ntpd, lpd, dhcpd, ldap, qmail, smtpfwdd, httpd, 
sshd, mysqld, squid, atalkd, papd, afpd, smbd, nmbd, named, mingetty

While this list may seem lengthy, experienced Linux/UNIX system administrators will recognize the list as being short compared to a typical Linux/UNIX system.

4. Replacement of Services With More Secure Alternatives

As part of our security review of the base Linux operating system, we also evaluate services that are included in the standard Red Hat release to determine if there are more secure alternatives. For instance, we have replaced the following services from Red Hat 7.1:

  • sendmail - Given the number of security vulnerabilities reported in sendmail over the years, we have instead opted to use qmail and obtuse-smtpd, both of which have been designed from the beginning with security in mind.

  • wu-ftpd - Like sendmail, wu-ftpd has suffered from security flaws over the past years. We chose proftpd as a replacement because of its focus on security as well as our ability to more easily configure it to limit access.

These services will be discussed in more detail in other sections of this document.

5. Open Source Code Review

One of the greatest strengths of the SME Server is that our base SME Server product source code is completely open and available to anyone to examine and review. At first glance, this statement might seem counter-intuitive. If you let people see all of your code, how is it secure? The traditional view in software development has been to closely guard your product source code so that no one can examine it and find potential security holes. Why do we say that our open source process is in fact more secure than traditional "closed source" or "proprietary" development models?

The answer lies in the fact that our code undergoes a strenuous peer review by people working with our product. Given that anyone can look at our code, we benefit from a large and constantly growing developer community. For instance, on our developers' mailing list, we have over 400 developers who are working with our product on an ongoing basis. Many more participate in our web forums and still others simply download and use our product. When someone suspects a problem, they (or someone else with the technical knowledge) can look directly at our source code and find out how we are implementing a particular item. If they see that there is an issue, they even have the option of implementing their own fix.

The value of open source peer review was dramatically illustrated in the year 2000 with the discovery that for eight years the Interbase database had contained a hard-coded username and password that would allow anyone knowing that user/password combination the ability to access any Interbase database. The developers had put this back door in the product to solve a particular authentication problem. For eight years this security vulnerability had been there. It is impossible to know how many databases might have been compromised. How was the hole found? In mid-2000, Interbase opened their source code and made it available on the Internet. A developer in Germany was looking through the source code and found this back door. He immediately alerted the product developers who quickly put out a fix and disabled this back door in new versions of the product. Had the code not been available, who knows how long this might have continued and who might have had access to the back door?

We believe, too, that the fact that our code is open encourages a much stronger internal code review process as well. All our staff developers know that others will see the code, and for that reason we need to be sure that the code is as secure and tight as possible. Our developer community is extremely active, strong, diverse and not at all hesitant to test our code and push the edges of what we say it can and should do. We welcome that scrutiny as we firmly believe that through that process our product becomes that much more secure!

6. Network Security

For a server functioning as a network gateway, the security related to the underlying basic network connection is of critical concern. We take this extremely seriously and use multiple tools and layers to restrict access. It starts with the fundamental distinction that in server and gateway mode, we have an internal network interface card connected to the local network and an external connection to the outside Internet, through either another network interface card or a dial-up modem. The internal card will allow most connections from the local network, but connections coming into the external interface are subject to very tight controls.

In this arrangement we use network address translation (NAT) to masquerade the entire internal network behind a single external IP address. In our recommended (and default) configuration, all internal systems have non-routable private IP addresses (per RFC1918) and there is therefore no possible way for a connection to be made from the external Internet to any internal machine. This allows us to concentrate all network security resources on protecting the server and external interface.

When we speak of network security, we wish to secure the server so all actions taken by the server in response to external network packets are defined, and all responses to external network packets are authorized and conform to a defined policy.

We achieve this restriction of server response to external network packets by multiple restrictive layers described below.

6.1. Packet filtering

A Linux kernel packet filter is configured, using the ipchains command, which implements the general policy on the external interface that "all incoming packets are denied except those which are explicitly allowed". Packets which are denied may be logged (there is a configuration parameter which defines whether all, none or some of any denied packets are logged), but otherwise elicit no response from the server - they are simply discarded.

The set of explicitly allowed incoming packets is configurable. Each of the set of services offered by the server can be enabled or disabled in a configuration database. A subset of the services may be available as a public service (for example, a web server is a public service) - each of these services is optional, and can be restricted to private access (i.e. only on the local network). Whenever this configuration database is changed, the packet filter is reconfigured to enforce the changed access policy. An annotated listing of the default ipchains rules is provided in Appendix C.

6.2. Disabled Services Do Not Run

The SME Server is configured to run only those services which are enabled in its configuration database.

6.3. Selective Address or Port Binding

Some applications offer the option to selectively bind to network interfaces. For services which are configured to offer access only to the internal network, this feature can be used to prevent any possibility of external connection to the network service program independent of the packet filter configuration. This feature is used, for example, in the SMB (Samba) daemon configuration. Listings of exactly what programs are bound to which ports in a default installation are provided in Appendices D and E.

6.4. Application-level Access Control Lists

Each network service program is configured to provide selective service based on the IP address of the originating request. Selective service configuration is mediated by three different mechanisms:

  1. by use of the TCP wrappers daemon tcpd, which acts as a gatekeeper application, dropping the network connection without any data transfer if the request is not from a permitted address. Accesses from permitted addresses result in the TCP wrappers daemon executing the network service program (for example, the IMAP daemon). The access restrictions are specified in the files /etc/hosts.allow and /etc/hosts.deny, and these files in turn are configured to comply with the policy recorded in the server configuration database. Examples of these files from a default installation are provided in Appendix F.

  2. by the application itself, through use of the TCP wrappers library, which naturally is also used by the TCP wrappers daemon. The application uses the TCP wrappers library to evaluate access rules specified in /etc/hosts.allow and /etc/hosts.deny, and then drops the network connection without any data transfer, or provides the network service, as appropriate. An example of this class of application is sshd, the OpenSSH daemon, which implements the SSH protocol for secure remote access.

  3. by the application itself, using application specific access control mechanisms. A further class of applications has its own set of mechanisms to restrict service availability according to originating network address of the request. These applications have their own mechanism for specifying and enforcing access restrictions. Examples of this class of application are mysql and squid.

6.5. Authentication and Authorization Mechanisms

Once the connection has passed through all these layers, it must finally be authenticated by the appropriate mechanism. In most cases this involves checking that the user does in fact have a valid user account and password. In some cases, such as pptpd and sshd, encryption initialization will also occur.

7. User Accounts, Groups and Passwords

In order for a user to access most services on the server, a user account is required. As a server administrator, you create the user accounts through the web-based server manager. Each user account name can be up to twelve characters in length and each must be unique on the server. With an account, a user can login to receive e-mail and may also access private portions of the SME Server by various file transfer methods.

Before a user can use his or her account, the administrator must first assign the user a password. User accounts are locked out and cannot be used until you set this initial password. Accounts without set passwords appear in red italics in the server manager. Passwords are allowed to contain upper and lowercase letters, numbers and punctuation. They are not restricted in length.

Once the initial password has been provided to the user, the user has total control over changing that password. At any time, a user can use a web browser to go to http://servername/user-password, enter the old password, and then enter a new password. The administrator does not have the ability to view the user's password in any form. If the user forgets the password, the administrator cannot retrieve that password. Instead, the administrator can reset the password and communicate that new password to the user, but the administrator can never see the actual password used by the user.

Once user accounts have been created, they can be put into group accounts to ease administration issues. The group can in turn be assigned specific permissions. For instance, the ability to load files into an information bay can be restricted to members of a certain group. Users can be members of multiple groups.

Note that as described in the next section, only one user, root, is configured by default to be able to login to the SME Server and access the Linux shell prompt.

8. Remote Access

In any network configuration, users typically want access to the network from remote locations. Examples may include employees who also want to work from home or who are traveling and want to connect from hotel rooms. The local system integrator or Authorized Partner who installed your system may also wish to connect to your network. The challenge, of course, is to allow this access while ensuring that your system is secure.

To meet this need, the SME Server allows several forms of remote access. Services such as e-mail access, the web server, ftp, etc. can be configured individually to allow private (local network only) or public (entire Internet) access. In the case of some of those services, you may even allow public access but require a password. These services will be discussed in more detail below.

However, there are three services specifically targeted at allowing remote login to the server (ssh and telnet) and to the network (PPTP). These will be covered in this section. It should be noted that all of these services are disabled by default and a server administrator must specifically enable them for such access to occur.

If either of the services that allow remote login to the server are enabled (ssh or telnet), by default only one account is able to login to the server. Logging in as the admin user will bring you to the SME Server server console.

For ssh, the server manager also has the option to allow administrative access. While this feature is disabled by default, enabling it will allow the root user to login via ssh and access the standard Linux command prompt.

By default, no other user accounts are configured to allow a login to the server. If you wish for a user account to be able to login to the server remotely, you must first login as the root user and then change the user account shell to be /bin/bash using the chsh command. Without this change, the user account will not be able to login to the server using either ssh or telnet.

8.1. Secure Shell (ssh)

The secure shell (ssh) command provides a secure, encrypted method of communication between a client and server. Unlike telnet, passwords are encrypted in transit and a secure session key is used to encrypt all packets sent between the client and the server. ssh and its companion program scp (secure copy) are available for Linux/UNIX, Windows, Macintosh and other client operating systems. In its simplest form, use of ssh merely involves initiating the command and entering the user account password. The user will then see a Linux command prompt and can begin entering Linux commands.

The implementation of ssh used by the SME Server is OpenSSH available from http://www.openssh.com/. It supports both the SSH1 and SSH2 protocols as well as both DSA and RSA authentication.

When ssh access is enabled, a user may connect and enter his or her user account password to gain access to the system. The only issue in this default configuration is that if a correct password is not supplied, the user is offered another chance to enter the password. The user may continue to do so, which does allow for someone trying to crack into the system to sit there and simply keep trying to guess passwords. Note that there is a time delay between login prompts that makes brute force attacks on good passwords impractical.

To get around this issue, for systems where security is very high yet secure remote access is desired, the SME Server also supports ssh using RSA authentication. In this mode, an ssh key is generated on the client computer system and then added to the list of allowed keys on the server. Only users connecting from a system with an authorized key will be allowed to login to the system.

Note that all ssh access is disabled by default.

8.2. Telnet

Because telnet has traditionally been used for remote access to Linux systems, we have included telnet access. However, it is disabled by default. The primary security problem with telnet is that it transmits all user names and passwords over the network without any form of encryption. Someone operating "packet sniffing" software and connected to any network between your SME Server and the remote machine may be able to intercept and read any user names and passwords and thus could gain access to your system. For that reason we strongly discourage the use of telnet and encourage users to use ssh instead.

Within the server manager, telnet access can be restricted to only the local network or allowed from the entire network. Administrative access for the 'admin' user is allowed to allow the use of the server console. Again, because of the security implications, this is strongly discouraged.

Note

Access for 'root' to use the Linux command line is not allowed through telnet.

8.3. Point-to-Point Tunnelling Protocol (PPTP)

While ssh meets many remote access needs, many users simply want to connect to their remote network and then access e-mail or use their file manager (such as the Windows Explorer or Network Neigborhood) to view and access files across the network.

To do this, the SME Server provides network access using the Point-to-Point Tunnelling Protocol (PPTP). PPTP allows you to provide a virtual private network between your remote client computer and your SME Server and internal network. It creates a secure encrypted channel between your client and the server. As far as the server is concerned, the client computer appears to be on the local internal network and can access all resources that the user would normally see if connected to the internal LAN.

When PPTP was first introduced by Microsoft, many implementations suffered from poor security and the protocol gained a reputation of being insecure. Since that time, the quality of the protocol definition and its implementations has improved dramatically and it now does offer a reliable and highly secure connection.

PPTP clients are available for Microsoft Windows and may already be installed in recent versions of Windows. Users typically launch a PPTP connection by double-clicking an icon on their desktop and then entering a password.

Because PPTP allows a remote client to appear as if they are a local user and can therefore access anything on the local network, the security of the passwords in transit is paramount. For that reason, we require client systems to use 128-bit encryption. The SME Server will not accept connections from PPTP clients that use 40-bit encryption. This may require an upgrade to the PPTP component of some of your client systems.

Like ssh and telnet, PPTP access is specifically disabled and must be enabled through the server manager. At the time you enable access, you may configure how many PPTP clients you will allow to access the system at any given time.

9. File Transfer

One of the main reasons users want remote access is to be able to retrieve or use files located on the server. The SME Server allows users to access files via the FTP protocol or through standard Windows and Macintosh networking.

9.1. File Transfer Protocol (FTP)

To allow users to upload or download files to and from the SME Server, we provide FTP access. The specific FTP server we use is proftpd ( http://www.proftpd.net/), configured with the latest security updates and patches.

In the default configuration, ftp access for users is allowed on the local (internal) network, but not from the external network. A user must login with a valid user name and password combination in order to access files.

Through the server manager, it is possible to configure the server to allow public (external) FTP access for users. We strongly discourage this action, though, because ftp, like telnet, transmits passwords from the client to the server as clear, unencrypted text. Instead we suggest users use the scp (secure copy) program provided with the ssh family of tools.

Anonymous ftp access is allowed on the local network for read access only. Information bays also may have a username and password associated with them and this information can be used for read access only. In no event can anonymous or i-bay users upload information. The ability to write to the server is restricted to users with a valid user account on the server manager.

FTP access for i-bays is a setting that can be configured for each individual i-bay and can be configured to be allowed for either private or public access. However in the server manager Remote Access panel you have the ability to set a FTP access policy that will override all other FTP settings. You have the option of disabling public (external) FTP access and in fact completely disabling all FTP access from both the internal and external networks.

9.2. Windows Networking (SMB)

Users may access files on the SME Server using standard Windows networking through such tools as the Windows Explorer, Network Neighborhood or My Network. They may connect either to their home directory on the server or to one of the information bay directories. Connections occur through the standard Server Message Block (SMB) protocol used within Microsoft networking.

Each user's home directory is protected so that only the user may read and write to that "share". In the process of doing so, the user must enter the password for that particular user account on the server.

Shares for information bays are also visible in the browse list. Access to those shares is controlled by the configuration for that specific i-bay. An i-bay is assigned a group ownership and the default configuration limits read and write access only to group members. A user would therefore need to be a member of the appropriate group in order to access the i-bay.

The specific tool we use on the SME Server to allow Windows users to access server directories via the SMB protocol is samba (http://www.samba.org/). The security-related portions of the default Samba configuration file are provided in Appendix G.

9.3. Macintosh Networking

For file transfer to and from Macintosh systems we use an implementation of the AppleTalk file sharing protocols called netatalk ( http://sourceforge.net/projects/netatalk/). As with Windows networking, users must supply a valid username and password to access private directories on the server. Macintosh users connect to the folders using the regular Chooser within the Macintosh operating system.

10. E-mail

Because e-mail is mission-critical for almost all organizations, we view it as extremely important that the mail server component of the SME Server be extremely secure. For this reason, we replaced the standard Linux sendmail program with the highly secure qmail server. qmail was designed from the very beginning with security in mind. The entire architecture of qmail is designed to minimize any possibilities for security exploits.

While qmail alone is extremely secure, we went one step further and chose a more flexible yet secure program called obtuse-smtpd for the mail server to which all SMTP mail connections (both outbound and inbound) are made. obtuse-smtpd allows us to further restrict exactly who can send in e-mail (for use in, for instance, blocking spam) and also provides hooks that we can use for filters such as content-filtering and virus scanning.

While qmail and obtuse-smtpd provide the mail server functionality, most users will be using the POP3 or IMAP protocols to read their e-mail. The SME Server supports both protocols. By default, POP3/IMAP access is only available to users on the local network. If you wish to allow users to access their e-mail via POP3 or IMAP from remote systems outside your network, the server administrator must specifically enable such "Public" access through the server manager.

Note that under no circumstances are any users outside of your local network allowed to send mail to other external users through your mail server. The mail server (obtuse-smtpd) will only accept mail messages from external sources that are for local users. Allowing such access would open your server to abuse by spammers as a mail relay. External users who want to send mail to other external users will either need to connect to their ISP's mail server or use PPTP to make a VPN connection to the internal side of the SME Server (at which point the SME Server will accept mail for other external users because as far as it is concerned, the PPTP-connected user is on the local network).

11. DNS

As with most Linux systems, we use the industry standard BIND server to provide Domain Name Service (DNS) access to the local network. Because of recent security exploits related to BIND, we are constantly monitoring BIND security mailing lists and regularly update our system to have the most current and secure version of the BIND program.

We take additional steps, too, to ensure that the system is safe. For instance, the BIND daemon (called named) is set to run as the local user dns instead of the normal configuration of having named run as the root user. In addition to running named as an unprivileged user, named is further restricted by being forced to run in a "chrooted jail". Essentially, this means that the program has an extremely restricted view of the system, which it thinks is in fact the entire system. In the event that somehow the named daemon was compromised, the attacker would not be able to see anything outside of the limited area in which the named daemon is confined.

Further, DNS access is only allowed from the internal local network. Users on the external Internet are not able to connect to the DNS server because it is configured to listen only on the internal network.

12. Web Services

Web services on the SME Server are provided through the open source Apache web server ( http://www.apache.org/). As the most highly-used web server on the Internet, Apache is constantly undergoing extensive source code peer review and has a solid record of being secure. The SME Server supports both standard HTTP connections as well as secure HTTPS connections that use the Secure Socket Layer (SSL) protocol.

There are actually two Apache server daemons running on the SME Server. One runs on ports 80 (HTTP) and 443 (HTTPS) and provides standard user access to the primary web site, i-bays or webmail. The second operates on port 980 and provides access to the server manager. A user can only connect to it on the local network and only if the user knows the password to the admin user account.

To further secure the server, the main Apache web server runs on the SME Server as the user www in a severely restricted environment. The administrative Apache server runs as the user admin which also has a restricted shell (the server console). For more information, you can view the security-related sections of the configuration file for the main Apache web server in Appendix H.

12.1. SSL Support

As mentioned above, the primary Apache server supports SSL authentication and listens on the standard port 443 for HTTPS connections. During the installation of the software, a set of 128-bit RSA keys is generated by the openssl command. The public RSA key is then placed in a self-signed X.509 certificate. This certificate is presented to all browsers attempting to connect via HTTPS.

The OpenSSL Project ( http://www.openssl.org/) has developed an open source, commercial-grade implementation of the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols. OpenSSL is widely used throughout the Linux and BSD UNIX world and is also used on other versions of UNIX. As we have done on the SME Server, OpenSSL is very often used in conjunction with the Apache web server.

12.2. CGI Scripts

When speaking of web server security, one of the primary concerns is often with the execution of CGI scripts on the server. On the SME Server, CGI scripts are disabled by default and must be specifically enabled by the server administrator for the i-bay in which the scripts are to be executed. Once enabled, CGI scripts can be executed if they are placed in the cgi-bin directory found in each information bay or as part of the primary directory used for the main web site. As this separate directory is not viewable by regular HTTP requests, users cannot see the contents of the actual CGI scripts.

12.3. PHP

In order to allow the webmail component of our server to function, we needed to enable the PHP scripting module for the Apache web server. PHP is a robust language that allows people to very quickly and easily create dynamically-generated content for their web site. For example, they could create a discussion forum or a catalog that linked to a database to provide the actual data. PHP is similar conceptually to Microsoft's Active Server Pages (ASP) and provides similar functionality.

Users may choose to enable the use of PHP in each i-bay through the "Enable dynamic content" checkbox in the i-bay configuration screen of the server manager. PHP is disabled by default and must be specifically enabled by the server administrator.

While this allows users to easily add dynamic content to their web sites and may be a great benefit to your users, you should be aware of an inherent weakness within server-based active content such as that of PHP. With PHP enabled, a knowledgeable user could upload a PHP script to the i-bay and then call that script to read any file that the Apache userid has access to. For instance, if a user did not have access to an i-bay called sales, but did have write access to an i-bay called research where PHP was enabled, the user could upload a PHP script into the research i-bay that, when called through a web browser, would open up and display files found in the sales i-bay.

As this is part of PHP's basic functionality, and is also possible through the use of the CGI scripts mentioned earlier, we recommend that you only enable dynamic content for those i-bays where either write access is restricted to the administrator or to a group of users that you trust will not upload scripts that could potentially compromise your security.

12.4. Webmail

The webmail functionality of your SME Server is provided through the Internet Messaging Program (IMP) open source software package created by the Horde Project (http://www.horde.org/imp/). It is disabled by default and must be specifically enabled by the server administrator before users can access the server. Once enabled, the IMP software uses PHP scripts to connect to a MySQL database which starts running on the server.

When the server administrator enables webmail, it can be set to use secure connections via Secure Socket Layer (SSL) connections (commmonly called "HTTPS" access) or to allow both standard HTTP and HTTPS connections. Because user account names and passwords will be transmitted across the network or Internet, we strongly recommend enabling webmail in only the secure HTTPS mode. This will ensure that all communication between the client web browser and the SME Server will be encrypted during transit.

12.5. Web Proxy Server

In addition to the standard Apache web server, the SME Server comes automatically configured with a fully functional proxy and caching web server. The specific program we use is called squid ( http://www.squid-cache.org/). It runs on the standard port 3128 and can be utilized by any web browsers on the internal network.

13. Server Console

The server console program is one of the means by which someone can administer the SME Server. In the default configuration, the server console appears on the monitor of the server after the initial reboot during the installation process. It can also be activated by logging into the SME Server locally or remotely as the user admin. From the server console, a user can also use a text-based browser to access the server manager. Between the console and web manager, you have full access to the entire SME Server configuration. Note that you need to know the admin password to access the server manager via a browser.

There is a physical security issue with regards to the console. If the console is set to automatically display on the system, anyone with physical access to the server will be able to use the console and web manager. If you are unable to guarantee the physical security of the monitor and keyboard of your SME Server, we recommend you configure your system to require a login before the console can be viewed.

14. Information Bays

Information bays, or i-bays, are areas on the server in which data can be stored and made accessible through a variety of methods. Files in an i-bay can be access through the web server, Windows and Macintosh file sharing and public or private FTP access. While settings for i-bays have been discussed in previous sections, they can be summarized as follows:

  • Group ownership - each i-bay is owned by a specific group account

  • User access via file sharing and ftp - the default configuration of an i-bay is to restrict read and write access to only members of the assigned group. Access can also be restricted so that only the "admin" group can write to the i-bay, or opened up so that everyone can read or write to the i-bay.

  • Public access via web or anonymous ftp - by default this is configured for No access. However, the server administrator can allow such access to either the local network or the larger Internet, and can allow open access or require a password.

  • Dynamic content - by default, this is disabled, but if enabled will allow users with write access to the i-bay to upload CGI or PHP scripts that can create web pages dynamically. While a powerful tool, be aware of the security implications mentioned earlier.

You should note that if a password is required for public access via web or anonymous ftp, the password is the one assigned to the i-bay and not to a user's regular user account. As with user accounts, the i-bay password is not set by default and users will not be able to access the i-bay until the administrator sets the password for the i-bay. Until that time all attempts to access the i-bay where the password is required will be refused.

15. Ongoing Security Updates

The Mitel Networks Corporation technical staff constantly monitors industry sources of security information to be sure that no emerging issues will impact our product. Because our product is based on the Red Hat Linux distribution, we pay careful attention to notices originating from Red Hat's offices or mailing lists. Each notice is carefully evaluated to determine if there is a security impact on the SME Server. Because we ship without many of the standard Linux services installed, many security alerts that apply to a generic Red Hat Linux installation do not apply to the SME Server. Regardless, each alert is examined in detail.

We also continually monitor our support forums both on our web bulletin boards and our devinfo mailing list. Many of the developers and administrators using those forums are among the first to identify any potential security issues. They also are often connected to additional security mailing lists and forward announcements and warnings from those sources.

Finally, each and every release of our product undergoes constant intensive scrutiny by our development team. As part of the release cycle, we extensively test all services and packages.

In the event that security holes are identified by our own staff or by other parties, we rapidly make fixes available through our public FTP site and http://www.e-smith.org/ web site and through automatic updates to registered customers.

16. Conclusion

While no system can be 100% secure, we have created a product that provides an extremely secure computing environment. Through the elimination of non-essential services, the replacement of other services with secure alternatives, and the general tightening of all possible security parameters, the SME Server comes "out of the box" ready to protect your network and server. While sophisticated administrators can adjust the configuration to meet particular needs, both they and others will benefit from the SME Server V5 approach.

Appendix A. List of Processes

The following processes are running on an SME Server V5 after a default installation. The list was generated by the command ps fauxw. Note that the f option, also available as --forest, shows the child processes underneath their parent, providing a clearer view of which processes are launched from the parent processes.


USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.1  1.1  1388  560 ?        S    02:35   0:06 init [7]
root         2  0.0  0.0     0    0 ?        SW   02:35   0:00 [kflushd]
root         3  0.0  0.0     0    0 ?        SW   02:35   0:01 [kupdate]
root         4  0.0  0.0     0    0 ?        SW   02:35   0:00 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   02:35   0:00 [keventd]
root         6  0.0  0.0     0    0 ?        SW<  02:35   0:00 [mdrecoveryd]
root       205  0.0  0.8  1380  392 ?        S    02:36   0:00 /usr/local/bin/svscan /service
root       220  0.0  0.7  1344  344 ?        S    02:36   0:00  \_ supervise qmail
qmails    1334  0.0  0.8  1400  424 ?        S    02:43   0:00  |   \_ qmail-send
root      1336  0.0  0.7  1352  360 ?        S    02:43   0:00  |       \_ qmail-lspawn ./Maildir/
qmailr    1337  0.0  0.7  1352  360 ?        S    02:43   0:00  |       \_ qmail-rspawn
qmailq    1338  0.0  0.7  1348  380 ?        S    02:43   0:00  |       \_ qmail-clean
root       221  0.0  0.7  1344  344 ?        S    02:36   0:00  \_ supervise log
qmaill     224  0.0  0.7  1356  352 ?        S    02:36   0:00  |   \_ /usr/local/bin/multilog t s5000000 /var/log/qmail
root       222  0.0  0.7  1344  344 ?        S    02:36   0:00  \_ supervise qmailscan.log
qmailq     225  0.0  0.8  1360  404 ?        S    02:36   0:00  |   \_ /usr/bin/tail -f --retry --follow=name /var/run/qmailscan.log
root       223  0.0  0.7  1344  344 ?        S    02:36   0:00  \_ supervise log
qmailq     226  0.0  0.7  1356  348 ?        S    02:36   0:00      \_ /usr/local/bin/multilog t s5000000 -*: file truncated <== /va
ldap       678  0.0  6.4  5368 3128 ?        S    02:42   0:00 /usr/sbin/slapd -u ldap
root      1147  0.0  1.3  1452  660 ?        S    02:42   0:01 syslogd -m 0 -a /home/dns/dev/log
root      1157  0.0  1.7  1728  872 ?        S    02:42   0:00 klogd -c 1
root      1182  0.0  1.3  1428  652 ?        S    02:42   0:00 crond
root      1215  0.0  1.8  2192  920 ?        S    02:42   0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
lp        1269  0.0  1.9  2372  932 ?        S    02:43   0:00 lpd Waiting 
root      1559  0.0  5.3  5728 2600 ?        S    02:43   0:00 /usr/sbin/httpd-admin -f /etc/httpd/admin-conf/httpd.conf -D HAVE_PER
admin     2431  0.0  5.3  5728 2600 ?        S    04:10   0:00  \_ /usr/sbin/httpd-admin -f /etc/httpd/admin-conf/httpd.conf -D HAVE
root      1590  0.0  1.9  1952  932 ?        S    02:43   0:00 sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf
mysql     1634  0.0  8.8 26924 4324 ?        S    02:43   0:00  \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --
mysql     1637  0.0  8.8 26924 4324 ?        S    02:43   0:00      \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/us
mysql     1638  0.0  8.8 26924 4324 ?        S    02:43   0:00          \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir
mysql     1639  0.0  8.8 26924 4324 ?        S    02:43   0:00          \_ /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir
root      1658  0.0  2.0  3712 1012 ?        S    02:43   0:00 squid -D
squid     1659  0.0  8.8  6164 4316 ?        S    02:43   0:01  \_ (squid) -D
squid     1667  0.0  0.6  1336  340 ?        S    02:43   0:00      \_ (unlinkd)
root      1720  0.0  2.7  3092 1324 ?        S    02:44   0:00 smbd -D
root      1730  0.0  2.7  2468 1352 ?        S    02:44   0:00 nmbd -D
root      1733  0.0  2.1  2380 1048 ?        S    02:44   0:00  \_ nmbd -D
root      1771  0.0  8.8  5488 4308 tty1     S    02:44   0:00 perl -wT /sbin/e-smith/console tty1
root      1776  0.0  0.8  1344  436 tty1     S    02:44   0:00  \_ /usr/bin/logger -p local1.info -t console
root      2563  0.4  1.5  1988  736 tty1     S    04:10   0:00  \_ /usr/bin/whiptail --clear --backtitle   March Networks SME Server
root      1772  0.0  2.1  2252 1044 tty2     S    02:44   0:00 login -- root    
root      1788  0.0  2.5  2208 1260 tty2     S    03:13   0:00  \_ -bash
root      2655  0.0  1.5  2624  760 tty2     R    04:11   0:00      \_ ps fauxw
root      1773  0.0  0.9  1348  452 tty3     S    02:44   0:00 /sbin/mingetty tty3
dns       1774  0.0  3.5  2856 1740 ?        S    02:44   0:00 /usr/sbin/named -f -u dns -g dns -t /home/dns
mail      2499  0.0  1.2  1480  588 ?        S    04:10   0:00 /usr/sbin/smtpfwdd -d /var/spool/smtpd/spool
root      2511  0.0  1.4  1580  708 ?        S    04:10   0:00 /usr/sbin/dhcpd eth0
root      2554  0.3  2.1  2056 1036 ?        S    04:10   0:00 sh /etc/rc.d/init.d/atalk restart
root      2555  0.0  1.0  1356  520 ?        S    04:10   0:00  \_ /usr/bin/logger -p local1.info -t e-smith-bg
root      2632  0.1  2.2  2092 1076 ?        S    04:10   0:00  \_ sh /etc/rc.d/init.d/atalk start
root      2651  0.1  1.0  1376  512 ?        S    04:10   0:00      \_ initlog -q -c /usr/sbin/atalkd
root      2652  0.1  1.6  3084  824 ?        S    04:10   0:00          \_ /usr/sbin/atalkd
root      2653  0.0  1.9  3152  972 ?        S    04:10   0:00              \_ /usr/sbin/atalkd
root      2570  0.6  8.7 10264 4244 ?        S    04:10   0:00 httpd
www       2575  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2576  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2577  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2578  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2579  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2580  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2581  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2582  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2583  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd
www       2584  0.0  8.6 10264 4240 ?        S    04:10   0:00  \_ httpd

Appendix B. List of Loaded Kernel Modules

The is the minimal list of kernel modules loaded after a default installation (created by the lsmod command). The pcnet32 module is for the network interface card used in the sample machine. As the sample machines was installed in server and gateway mode the ip_masq_* modules are loaded. In server-only mode, these modules are not loaded. Note that our default policy is to provide as much power and flexibility for users as possible, while maintaining high security. As a consequence, our default gateway configuration includes a large set of masquerading modules, including popular games. Naturally, this can be customized for sites who want restricted functionality.

Note that this list is highly dependent upon the exact hardware configuration of your system. Additional modules may be loaded to support USB controllers, tape drives and certain types of disk drives and video boards.


Module                  Size  Used by
appletalk              18208  12 
pcnet32                10752   2  (autoclean)
ip_masq_vdolive         1536   0  (unused)
ip_masq_raudio          3136   0  (unused)
ip_masq_pptp            4400   0  (unused)
ip_masq_irc             2112   0  (unused)
ip_masq_icq            13920   0  (unused)
ip_masq_h323            3696   0  (unused)
ip_masq_ftp             3776   0  (unused)
ip_masq_cuseeme         1248   0  (unused) 

Appendix C. Packet Filtering Rules

The following packet filtering rules are established by the ipchains command for the default installation in server and gateway mode. In this example, the IP address for the internal network interface card is 192.168.1.1 and the IP address for the external network interface card is 192.168.65.17. This listing was generated by ipchains -L -n.

Annotations are provided below to explain specific blocks of rules.

The first chain, input, specifies what packets will be accepted into the server. At the very beginning, all inbound ICMP packets are immediately routed to a separate chain, icmpIn for processing. Note that the second line, starting with "ACCEPT", applies to the loopback interface, lo, and accepts all incoming packets (which can only originate on the local machine).


Chain input (policy DENY):
target     prot opt     source                destination           ports
icmpIn     icmp ------  0.0.0.0/0            0.0.0.0/0             * ->   *
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a
denylog    tcp  ------  0.0.0.0/0            0.0.0.0/0             0:19 ->   *
denylog    udp  ------  0.0.0.0/0            0.0.0.0/0             0:19 ->   *
denylog    tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   0:19
denylog    udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   0:19
DENY       all  ------  224.0.0.0/4          0.0.0.0/0             n/a
DENY       all  ------  0.0.0.0/0            224.0.0.0/4           n/a
ACCEPT     all  ------  192.168.1.0/24       0.0.0.0/0             n/a
ACCEPT     tcp  !y----  0.0.0.0/0            0.0.0.0/0             * ->   *
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   113
ACCEPT     udp  ------  0.0.0.0/0            192.168.65.17         * ->   113
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   20
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   21
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   80
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   443
ACCEPT     ipv6-crypt------  0.0.0.0/0            192.168.65.17         n/a
ACCEPT     udp  ------  0.0.0.0/0            192.168.65.17         500 ->   500
ACCEPT     gre  ------  0.0.0.0/0            192.168.65.17         n/a
ACCEPT     tcp  ------  0.0.0.0/0            192.168.65.17         * ->   25
denylog    tcp  -y----  0.0.0.0/0            192.168.65.17         * ->   3306
DENY       udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   520
DENY       tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   137:139
DENY       udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   137:139
denylog    tcp  -y----  0.0.0.0/0            192.168.65.17         * ->   3128
ACCEPT     tcp  -y----  0.0.0.0/0            192.168.65.17         20 ->   1024:65535
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   1024:65535
ACCEPT     udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   1024:65535
denylog    all  ------  0.0.0.0/0            0.0.0.0/0             n/a

The forward chain specifies that any packets from the internal network will be masqueraded and passed on to the output chain for processing before being sent out to the external Internet.


Chain forward (policy DENY):
target     prot opt     source                destination           ports
ACCEPT     all  ------  192.168.1.0/24       192.168.1.0/24        n/a
MASQ       all  ------  192.168.1.0/24       0.0.0.0/0             n/a
DENY       all  ------  0.0.0.0/0            0.0.0.0/0             n/a

The output chain specifies which packets will be allowed to leave the server. Note again that outbound ICMP packets are sent to the separate icmpOut chain for processing.


Chain output (policy ACCEPT):
target     prot opt     source                destination           ports
icmpOut    icmp ------  0.0.0.0/0            0.0.0.0/0             * ->   *
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   80
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   22
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   23
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   21
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   110
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   25
-          tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   20
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a
DENY       all  ------  224.0.0.0/4          0.0.0.0/0             n/a
DENY       all  ------  0.0.0.0/0            224.0.0.0/4           n/a
ACCEPT     icmp ------  192.168.1.0/24       0.0.0.0/0             * ->   *
ACCEPT     all  ------  0.0.0.0/0            192.168.1.0/24        n/a
ACCEPT     tcp  !y----  192.168.65.17        0.0.0.0/0             20 ->   *
ACCEPT     tcp  !y----  192.168.65.17        0.0.0.0/0             21 ->   *
ACCEPT     tcp  !y----  192.168.65.17        0.0.0.0/0             80 ->   *
ACCEPT     tcp  !y----  192.168.65.17        0.0.0.0/0             443 ->   *
ACCEPT     tcp  !y----  192.168.65.17        0.0.0.0/0             25 ->   *
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a

The denylog chain is referenced by several of the other chains and just denies a packet while logging the packet denial. This chain is used simply to avoid cluttering up individual rules with logging options.

Chain denylog (9 references): target prot opt source destination ports DENY all ------ 0.0.0.0/0 0.0.0.0/0 n/a

This icmpIn chain specifies which types of ICMP packets we will allow into the system.


Chain icmpIn (1 references):
target     prot opt     source                destination           ports
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             0 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             3 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             4 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             11 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             12 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             8 ->   *
denylog    all  ------  0.0.0.0/0            0.0.0.0/0             n/a

The icmpOut chain specifies which types of ICMP packets we will allow to leave the system.


Chain icmpOut (1 references):
target     prot opt     source                destination           ports
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             8 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             0 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             3 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             4 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             11 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             12 ->   *
denylog    all  ------  0.0.0.0/0            0.0.0.0/0             n/a

Appendix D. List of Open Network Ports

Programs are bound to and listening on these TCP or UDP ports. This output was generated by netstat -anp | egrep "LISTEN|udp" | grep -v "^unix" and then sorted by port number and divided into sections. The last column lists the process that is bound to the specific port number.

The following processes are bound to the internal network interface card and/or the localhost. They are for DNS (named), NetBIOS naming a.k.a. WINS (nmbd), the Apache public web server (httpd) and administrative web server (httpd-admin).


tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      1774/named          
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1774/named          
udp        0      0 192.168.1.1:53          0.0.0.0:*                           1774/named          
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1774/named          
tcp        0      0 127.0.0.1:80            0.0.0.0:*               LISTEN      2570/httpd          
tcp        0      0 192.168.1.1:80          0.0.0.0:*               LISTEN      2570/httpd          
tcp        0      0 192.168.65.17:80        0.0.0.0:*               LISTEN      2570/httpd          
udp        0      0 192.168.1.1:137         0.0.0.0:*                           1730/nmbd       
udp        0      0 192.168.1.1:138         0.0.0.0:*                           1730/nmbd           
tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN      2570/httpd          
tcp        0      0 192.168.1.1:443         0.0.0.0:*               LISTEN      2570/httpd          
tcp        0      0 127.0.0.1:980           0.0.0.0:*               LISTEN      1559/httpd-admin    
tcp        0      0 192.168.1.1:980         0.0.0.0:*               LISTEN      1559/httpd-admin    
tcp        0      0 127.0.0.1:981           0.0.0.0:*               LISTEN      1559/httpd-admin    
tcp        0      0 192.168.1.1:981         0.0.0.0:*               LISTEN      1559/httpd-admin    

The following processes are bound to the external interface. Most of these processes should be familiar to Linux/UNIX administrators, but two may not be. afpd is the AppleTalk file sharing component of netatalk. slapd is the LDAP directory server that we are using. Note that external connections to almost all of these processes asterisk in the first column are blocked by the packet filtering rules mentioned previously in Appendix C.


udp        0      0 0.0.0.0:67              0.0.0.0:*                           2511/dhcpd          
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1730/nmbd           
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1730/nmbd           
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1720/smbd           
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      678/slapd           
tcp        0      0 192.168.65.17:443       0.0.0.0:*               LISTEN      2570/httpd          
tcp        0      0 0.0.0.0:515             0.0.0.0:*               LISTEN      1269/lpd Waiting    
tcp        0      0 0.0.0.0:548             0.0.0.0:*               LISTEN      2678/afpd           
udp        0     80 0.0.0.0:1024            0.0.0.0:*                           1774/named          
tcp        0      0 0.0.0.0:3128            0.0.0.0:*               LISTEN      1659/(squid)        
udp        0      0 0.0.0.0:3130            0.0.0.0:*                           1659/(squid)  
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      1634/mysqld         
udp        0      0 0.0.0.0:3401            0.0.0.0:*                           1659/(squid)         

In addition, a number of processes do not run as separate daemons but instead are launched by the inetd daemon. Red Hat 7.1 uses xinetd, a newer and more flexible implementation of the traditional inetd daemon. As shown below, xinetd is listening on ports 21 (FTP), 25 (SMTP), 110 (POP3), 113 (identd) and 143 (IMAP).


tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1215/xinetd
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1215/xinetd         
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      1215/xinetd         
tcp        0      0 0.0.0.0:113             0.0.0.0:*               LISTEN      1215/xinetd
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      1215/xinetd

Appendix E. List of Open UNIX Domain Sockets

These ports are UNIX sockets open for access by programs on the SME Server only. This output was generated by netstat -anp | grep unix. The final column shows the socket file name to which the process is bound.


unix  1      [ ]         DGRAM                    1611   1147/syslogd        /home/dns/dev/log
unix  0      [ ACC ]     STREAM     LISTENING     6497   1774/named          /var/run/ndc
unix  11     [ ]         DGRAM                    1609   1147/syslogd        /dev/log
unix  0      [ ACC ]     STREAM     LISTENING     2137   1634/mysqld         /var/lib/mysql/mysql.sock
unix  0      [ ]         DGRAM                    8124   2678/afpd           
unix  0      [ ]         DGRAM                    8119   2668/papd           
unix  0      [ ]         DGRAM                    8075   2653/atalkd         
unix  0      [ ]         DGRAM                    7927   2511/dhcpd          
unix  0      [ ]         DGRAM                    7907   2499/smtpfwdd       
unix  0      [ ]         DGRAM                    6745   678/slapd           
unix  0      [ ]         DGRAM                    6551   1772/login -- root  
unix  0      [ ]         DGRAM                    6495   1774/named          
unix  0      [ ]         DGRAM                    6276   1658/squid          
unix  0      [ ]         DGRAM                    1707   1215/xinetd         
unix  0      [ ]         DGRAM                    1662   1182/crond          
unix  0      [ ]         DGRAM                    1629   1157/klogd          

Appendix F. Configuration of tcp_wrappers

The primary application level access control lists are implemented via a mechanism called tcp_wrappers. This involves both an explicit daemon tcpd as well as a set of libraries called by some applications (such as sshd). Both the daemon and the libraries first check /etc/hosts.deny to see if a connection is denied and then check /etc/hosts.allow to see if the connection is explicitly allowed.

As you can see from the listings below, our default policy is to deny all connections to the server except for those explicitly allowed to specific ports.

Appendix F.1. /etc/hosts.deny


ALL: ALL

Appendix F.2. /etc/hosts.allow

Note that /etc/hosts.allow is dynamically changed whenever a subnet is added or the IP address of the server or its netmask is changed.


# appletalk services
afpd : 127.0.0.1, 192.168.1.0/255.255.255.0
papd : 127.0.0.1, 192.168.1.0/255.255.255.0

in.identd: 127.0.0.1 ALL

# IMAP server
imapd : 127.0.0.1, 192.168.1.0/255.255.255.0

# LDAP servers
slapd : 127.0.0.1, 192.168.1.0/255.255.255.0
# obtuse-smtpd - also see smtpd_check_rules
smtpd: 127.0.0.1 ALL
# ftp daemon
in.proftpd : ALL

# pop3 server
qmail-popup : 127.0.0.1, 192.168.1.0/255.255.255.0

# sshd access is currently disabled
# telnet access is currently disabled 

Appendix G. SMB Security

The following information is from the /etc/smb.conf configuration file that controls Samba's operations. Note that only the relevant security-related sections of the file have been included here.


# This option is important for security. It allows you to restrict
# connections to machines which are on your local network. The
# following example restricts access to two C class networks and
# the "loopback" interface. For more examples of the syntax see
# the smb.conf man page
   hosts allow = 127.0.0.1 192.168.1.0/255.255.255.0

# Configure Samba to use multiple interfaces
# If you have multiple network interfaces then you must list them
# here. See the man page for details.
   interfaces = 127.0.0.1 192.168.1.1/255.255.255.0

# Security mode. Most people will want user level security. See
# security_level.txt for details.
   security = user
# Use password server option only with security = server
;   password server = <NT-Server-Name>

# Password Level allows matching of _n_ characters of the password for
# all combinations of upper and lower case.
;  password level = 8
;  username level = 8

# If this parameter is 'yes' for a service, then no password is
# required to connect to the service.
   guest ok = yes

# This is a username which will be used for access to services which
# are specified as 'guest ok'.
   guest account = public

# If unknown user logs in, treat as guest. (In older versions of
# Samba this was a compile-time option.)
   map to guest = bad user

# You may wish to use password encryption. Please read
# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
  encrypt passwords = yes
  smb passwd file = /etc/smbpasswd

# The following are needed to allow password changing from Windows to
# update the Linux sytsem password also.
# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.
# NOTE2: You do NOT need these to allow workstations to change only
#        the encrypted SMB passwords. They allow the Unix password
#        to be kept in sync with the SMB password.
;  unix password sync = Yes
;  passwd program = /usr/bin/passwd %u
;  passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*

# Unix users can map to different SMB User names
;  username map = /etc/smbusers

# This global parameter allows the Samba admin to limit what
# interfaces on a machine will serve smb requests.
    bind interfaces only = no

# Configure remote browse list synchronisation here
#  request announcement to, or browse list sync from:
#	a specific host or from / to a whole subnet (see below)
;   remote browse sync = 192.168.3.25 192.168.5.255
# Cause this host to announce itself to local subnets here
;   remote announce = 192.168.1.255 192.168.2.44

# Browser Control Options:
# set local master to no if you don't want Samba to become a master
# browser on your network. Otherwise the normal election rules apply
   local master = yes

# OS Level determines the precedence of this server in master browser
# elections. The default value should be reasonable
#   os level = 33
    os level = 65

# Domain Master specifies Samba to be the Domain Master Browser. This
# allows Samba to collate browse lists between subnets. Don't use this
# if you already have a Windows NT domain controller doing this job
   domain master = yes

# Preferred Master causes Samba to force a local browser election on startup
# and gives it a slightly higher chance of winning the election
   preferred master = yes

# Use only if you have an NT server on your network that has been
# configured at install time to be a primary domain controller.
;   domain controller = <NT-Domain-Controller-SMBName>

[homes]
   comment = Home directory
   browseable = no
   guest ok = no
   read only = no
   writable = yes
   printable = no
   create mode = 0660
   force create mode = 0660
   directory mode = 0770
   force directory mode = 0770
   path = /home/e-smith/files/users/%S/home


[Primary]
   comment = Primary site
   path = /home/e-smith/files/primary
   read only = no
   writable = yes
   printable = no
   create mode = 0640
   directory mode = 02750
   force create mode = 0640
   force directory mode = 02750

[netlogon]
   comment = Network Logon Service
   path = /home/netlogon
   guest ok = yes
   writable = yes
   browseable = no
   share modes = no
 

Appendix H. Apache Security

The following lines are the security-related sections of the Apache configuration file found at /etc/httpd/conf/httpd.conf. The first block of code determines what port the server will run on, where the root of the files are and what user and group the server will run as.

Note

The example below assumes that the system is configured with a domainname of tofu-dog.com.


Port 80
ServerAdmin admin@tofu-dog.com
ServerType standalone
ServerRoot /etc/httpd
User www
Group www

The next relevant block lists all the modules that are loaded into the Apache web server. Apache provides a modular structure that allows additional functionality to be be loaded into the program through compiled modules. In keeping with UNIX/Linux conventions, the # character indicates that a given line is "commented out" and that module is therefore not loaded.


# Dynamic Shared Object (DSO) Support
#
#LoadModule mmap_static_module modules/mod_mmap_static.so
LoadModule env_module         modules/mod_env.so
LoadModule config_log_module  modules/mod_log_config.so
LoadModule agent_log_module   modules/mod_log_agent.so
LoadModule referer_log_module modules/mod_log_referer.so
#LoadModule mime_magic_module  modules/mod_mime_magic.so
LoadModule mime_module        modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule status_module      modules/mod_status.so
LoadModule info_module        modules/mod_info.so
LoadModule includes_module    modules/mod_include.so
LoadModule autoindex_module   modules/mod_autoindex.so
LoadModule dir_module         modules/mod_dir.so
LoadModule cgi_module         modules/mod_cgi.so
LoadModule asis_module        modules/mod_asis.so
LoadModule imap_module        modules/mod_imap.so
LoadModule action_module      modules/mod_actions.so
#LoadModule speling_module     modules/mod_speling.so
LoadModule userdir_module     modules/mod_userdir.so
LoadModule proxy_module       modules/libproxy.so
LoadModule alias_module       modules/mod_alias.so
LoadModule rewrite_module     modules/mod_rewrite.so
LoadModule access_module      modules/mod_access.so
LoadModule auth_module        modules/mod_auth.so
LoadModule anon_auth_module   modules/mod_auth_anon.so
#LoadModule dbm_auth_module    modules/mod_auth_dbm.so
LoadModule db_auth_module     modules/mod_auth_db.so
LoadModule digest_module      modules/mod_digest.so
#LoadModule cern_meta_module   modules/mod_cern_meta.so
LoadModule expires_module     modules/mod_expires.so
LoadModule headers_module     modules/mod_headers.so
LoadModule usertrack_module   modules/mod_usertrack.so
#LoadModule example_module     modules/mod_example.so
#LoadModule unique_id_module   modules/mod_unique_id.so
LoadModule setenvif_module    modules/mod_setenvif.so

# Extra Modules
#LoadModule php_module         modules/mod_php.so
#LoadModule php3_module        modules/libphp3.so
#LoadModule perl_module        modules/libperl.so
LoadModule external_auth_module modules/mod_auth_external.so

LoadModule php4_module /usr/lib/apache/libphp4.so

LoadModule ssl_module        /usr/lib/apache/libssl.so


The next block of code configures Secure Socket Layer support within Apache.


##########################################################
##  SSL Global Context Configuration
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts
##	(unless overridden by virtual hosts)
##
<IfModule mod_ssl.c>
##  SSL Support
##  When we also provide SSL we have to listen to the 
##  standard HTTPS port - 443
##
Listen 127.0.0.1:443
Listen 192.168.1.1:443
Listen 192.168.65.17:443

SSLEngine off

SSLPassPhraseDialog  builtin

SSLSessionCache         dbm:logs/ssl_scache

SSLSessionCacheTimeout  300

SSLMutex  file:logs/ssl_mutex

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin

SSLLog      logs/ssl_engine_log


SSLLogLevel info

SSLProtocol all
</IfModule>

Next, the configuration file specifies how many clients can connect at any one time, where the documents are stored and other content-related configuration parameters.

MaxClients 150
MaxRequestsPerChild 100
#ProxyRequests On
ServerName www.tofu-dog.com
MinSpareServers 8
MaxSpareServers 20
Timeout 300
DirectoryIndex index.htm index.html index.shtml index.cgi index.php index.php3
DocumentRoot /home/e-smith/files/primary/html
FancyIndexing on
# UserDir public_html
AccessFileName .htaccess
DefaultType text/plain
TypesConfig /etc/mime.types

# To use CGI scripts:
AddHandler cgi-script .cgi

AddHandler server-parsed .shtml

Next are listed the aliases for the primary web site and any virtual domains. These allow the settings above to be overriden for each of the individual virtual domains. Note that this information is generated automatically by the SME Server management software.


NameVirtualHost 127.0.0.1:80

<VirtualHost 127.0.0.1:80>

    ServerName www.tofu-dog.com
    ServerAlias tofu-dog.com

    # primary content

    DocumentRoot         /home/e-smith/files/primary/html
    ScriptAlias /cgi-bin /home/e-smith/files/primary/cgi-bin
    Alias       /files   /home/e-smith/files/primary/files

    # alias for Apache icons

    Alias /icons/ /var/www/icons/

</VirtualHost>

NameVirtualHost 192.168.1.1:80

<VirtualHost 192.168.1.1:80>

    ServerName www.tofu-dog.com
    ServerAlias tofu-dog.com

    # primary content

    DocumentRoot         /home/e-smith/files/primary/html
    ScriptAlias /cgi-bin /home/e-smith/files/primary/cgi-bin
    Alias       /files   /home/e-smith/files/primary/files

    # alias for Apache icons

    Alias /icons/ /var/www/icons/

</VirtualHost>

NameVirtualHost 192.168.65.17:80

<VirtualHost 192.168.65.17:80>

    ServerName www.tofu-dog.com
    ServerAlias tofu-dog.com

    # primary content

    DocumentRoot         /home/e-smith/files/primary/html
    ScriptAlias /cgi-bin /home/e-smith/files/primary/cgi-bin
    Alias       /files   /home/e-smith/files/primary/files

    # alias for Apache icons

    Alias /icons/ /var/www/icons/

</VirtualHost>


Now the aliases are again defined, but this time for SSL (port 443) connections with additional SSL-related information.

Note

For the purpose of conserving space, only one instance of <VirtualHost> is shown. However, the information shown below is identical (except for the IP address) for the 192.168.1.1 and 192.168.65.17 interfaces.


NameVirtualHost 127.0.0.1:443

&lt;VirtualHost 127.0.0.1:443&gt;

    ServerName secure.tofu-dog.com
    ServerAlias tofu-dog.com www.tofu-dog.com

    # primary content

    DocumentRoot         /home/e-smith/files/primary/html
    ScriptAlias /cgi-bin /home/e-smith/files/primary/cgi-bin
    Alias       /files   /home/e-smith/files/primary/files

    # alias for Apache icons

    Alias /icons/ /var/www/icons/

    # SSL Directives

    SSLEngine on
    SSLCertificateFile /home/e-smith/ssl.crt/secure.tofu-dog.com.crt
    SSLCertificateKeyFile /home/e-smith/ssl.key/secure.tofu-dog.com.key
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive  ssl-unclean-shutdown  downgrade-1.0 force-response-1.0

    # ProxyPass executes a module which relays requests to another server
    # We use it to allow transparent access to the admin instance of the
    # web server.

    ProxyPass /server-brand http://127.0.0.1:980/server-brand/
    <Location /server-brand>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /e-smith-brand http://127.0.0.1:980/e-smith-brand/
    <Location /e-smith-brand>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /e-smith-common http://127.0.0.1:980/server-common/
    <Location /e-smith-common>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /server-common http://127.0.0.1:980/server-common/
    <Location /server-common>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /common http://127.0.0.1:980/common/
    <Location /common>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /e-smith-manager http://127.0.0.1:980/e-smith-manager/
    <Location /e-smith-manager>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /server-manager http://127.0.0.1:980/server-manager/
    <Location /server-manager>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /e-smith-password http://127.0.0.1:980/user-password/
    <Location /e-smith-password>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

    ProxyPass /user-password http://127.0.0.1:980/user-password/
    <Location /user-password>
	order deny,allow
	deny from all
	allow from 127.0.0.1 192.168.1.0/255.255.255.0 
    </Location>

&lt;/VirtualHost&gt;


The final security-related section of the Apache configuration deals with configuring the security of the various directories whose content will be served by the Apache web server. Once information bays are added to the system, they will each have entries listed here.


# First, we configure the "default" to be a very restrictive set of 
# permissions.  

<Directory />
    Options None
    AllowOverride None
    order deny,allow
    deny from all
    allow from none
</Directory>

# horde not configured as it is disabled in the config db

# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.

#------------------------------------------------------------
# primary directories
#------------------------------------------------------------

<Directory /etc/e-smith/web/common>
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /home/e-smith/files/primary/html>
    Options Indexes Includes 
    Options +Includes
    AddType application/x-httpd-php .php .php3 .phtml
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /home/e-smith/files/manager/html>
    Options Indexes Includes ExecCGI
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /var/www/icons>
    Options Indexes Includes
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /home/e-smith/files/primary/cgi-bin>
    Options ExecCGI
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /home/e-smith/files/manager/cgi-bin>
    Options ExecCGI
    AllowOverride None
    order deny,allow
    deny from all
    allow from all
</Directory>

<Directory /home/e-smith/files/primary/files>
    AllowOverride None
    ForceType application/octet-stream
    order deny,allow
    deny from all
    allow from all
</Directory>

Appendix I. Rules For Mail Relaying

The rules listed below are from /var/spool/smtpd/etc/smtpd_check_rules. They are used by the smtpfwd program to determine whether mail should be accepted for delivery based on the sender's IP address as well as the envelope recipient address. This example uses our sample domain tofu-dog.com and blocks all relaying of e-mail except from users on the internal network. Note that it also blocks anyone from the Internet from being able to send to everyone@tofu-dog.com or shared@tofu-dog.com.


# Don't allow bang paths via us
noto:ALL:ALL:*!*@*:551 Sorry %H (%I), I don't allow unauthorized relaying. You can't use me to send mail from %F to %T.

# Don't allow two @s (equivalent to %hack) via us
noto:ALL:ALL:*@*@*:551 Sorry %H (%I), I don't allow unauthorized relaying. You can't use me to send mail from %F to %T.

# Don't allow %hack relay via us
noto:ALL:ALL:*%*@*:551 Sorry %H (%I), I don't allow unauthorized relaying. You can't use me to send mail from %F to %T.


# Allow relaying from the local network
allow:127.0.0.1:ALL:ALL
allow:192.168.1.0/24:ALL:ALL

# Prohibit access to these addresses from the outside world
noto:ALL:ALL:everyone@*.tofu-dog.com everyone@tofu-dog.com:551 Sorry %H (%I), you cannot send mail to %T from outside our local network.
noto:ALL:ALL:shared@*.tofu-dog.com shared@tofu-dog.com:551 Sorry %H (%I), you cannot send mail to %T from outside our local network.


# Allow any of our domains
allow:ALL:ALL:*.tofu-dog.com *@tofu-dog.com

# Just say no to anything else, we won't relay for people we don't know.
noto:ALL:ALL:ALL:551 Sorry %H(%I), I don't allow unauthorized relaying. Please use another SMTP host to mail from %F to %T  

Appendix J. List of setuid Files and Directories

The following files have the setuid bit set which, in all but one case, means that these commands are executed as if by the root user. Note that the SME Server setuid programs can only be executed by the root user or members of the admin group. This list was generated by the command find / -path /proc -prune -o -perm +4000 -exec ls -ld {} \; which lists all setuid files except for those found in the virtual /proc filesystem.


-rws--x--x    1 qmailq   qmail       12680 Feb  8  2001 /var/qmail/bin/qmail-queue
-rwsr-sr-x    1 qmailq   qmail       33824 Aug 17 20:27 /var/qmail/bin/scanner
-rwsr-x---    1 root     admin       32116 Aug 19 21:38 /etc/e-smith/web/functions/backup
-rwsr-x---    1 root     admin       21696 Aug  8 17:53 /etc/e-smith/web/functions/groups
-rwsr-x---    1 root     admin       32782 Aug  8 17:53 /etc/e-smith/web/functions/ibays
-rwsr-x---    1 root     admin       13999 Aug  8 17:53 /etc/e-smith/web/functions/localnetworks
-rwsr-x---    1 root     admin        2701 Aug 22 20:56 /etc/e-smith/web/functions/online-manual
-rwsr-x---    1 root     admin        6377 Aug  8 17:53 /etc/e-smith/web/functions/password
-rwsr-x---    1 root     admin         937 Aug  8 17:53 /etc/e-smith/web/functions/pleasewait
-rwsr-x---    1 root     admin        4665 Aug  8 17:53 /etc/e-smith/web/functions/reboot
-rwsr-x---    1 root     admin       12874 Aug 22 20:56 /etc/e-smith/web/functions/remoteaccess
-rwsr-x---    1 root     admin        9168 Aug 22 20:56 /etc/e-smith/web/functions/review
-rwsr-x---    1 root     admin        9662 Aug 22 20:56 /etc/e-smith/web/functions/starterwebsite
-rwsr-x---    1 root     admin       47148 Aug  8 17:53 /etc/e-smith/web/functions/useraccounts
-rwsr-x---    1 root     admin       17726 Aug 22 20:56 /etc/e-smith/web/functions/virtualdomains
-rwsr-x---    1 root     admin        7031 Aug  8 17:53 /etc/e-smith/web/functions/workgroup
-rwsr-x---    1 root     admin       17769 Aug 22 01:39 /etc/e-smith/web/functions/blades
-rwsr-x---    1 root     admin       12633 Aug 21 03:57 /etc/e-smith/web/functions/emailretrieval
-rwsr-x---    1 root     admin       10740 Aug  8 18:04 /etc/e-smith/web/functions/otheremail
-rwsr-x---    1 root     admin       17788 Aug  8 18:04 /etc/e-smith/web/functions/pseudonyms
-rwsr-x---    1 root     admin       61401 Aug  8 18:09 /etc/e-smith/web/functions/hostentries
-rwsr-x---    1 root     admin       10164 Aug 17 11:55 /etc/e-smith/web/functions/directory
-rwsr-x---    1 root     admin       12435 Aug  8 17:39 /etc/e-smith/web/functions/printers
-rwsr-x---    1 root     admin        8037 Aug  8 18:27 /etc/e-smith/web/functions/navigation
-rwsr-x---    1 root     admin        7531 Aug  8 18:27 /etc/e-smith/web/functions/noframes
-rwsr-x---    1 root     admin       17460 Aug  8 20:12 /etc/e-smith/web/functions/datetime
-rwsr-x---    1 root     admin        6193 Aug 17 08:39 /etc/e-smith/web/functions/qmailanalog
-rwsr-x---    1 root     admin        4901 Aug  8 20:28 /etc/e-smith/web/functions/reinstall
-rwsr-x---    1 root     admin        8397 Aug 21 18:01 /etc/e-smith/web/functions/viewlogfiles
-rwsr-x---    1 root     admin        7148 Aug 21 04:37 /etc/e-smith/web/functions/virus
-rwsr-x---    1 root     admin       12425 Aug 21 04:33 /etc/e-smith/web/functions/dns
-rwsr-x---    1 root     admin        6341 Aug 29 19:23 /etc/e-smith/web/functions/vpn
-rwsr-x---    1 root     admin       19434 Aug 24 16:44 /etc/e-smith/web/functions/service_status
-rwsr-x---    1 root     admin        5186 Aug 16 02:39 /etc/e-smith/web/functions/support
-r-sr-s---    1 root     admin        5914 Jan 15  2001 /etc/e-smith/web/panels/password/cgi-bin/userpassword
-rwsr-xr-x    1 root     root        34588 Mar  9  2001 /usr/bin/chage
-rwsr-xr-x    1 root     root        36228 Mar  9  2001 /usr/bin/gpasswd
-rwsr-xr-x    1 root     root        37764 Apr  4  2001 /usr/bin/at
-rws--x--x    2 root     root       795092 Mar 23  2001 /usr/bin/suidperl
-rws--x--x    2 root     root       795092 Mar 23  2001 /usr/bin/sperl5.6.0
-r-sr-sr-x    1 root     mail        22808 Aug  7 12:56 /usr/bin/dotlock
-r-sr-sr-x    1 root     mail       146008 Aug  7 12:56 /usr/bin/maildrop
-rwsr-xr-x    1 root     root       214220 Aug  1 14:37 /usr/bin/ssh
-r-s--x--x    1 root     root        13536 Jul 12  2000 /usr/bin/passwd
---s--x--x    1 root     root        81020 Feb 23  2001 /usr/bin/sudo
-rws--x--x    1 root     root        13048 Jul 12 18:22 /usr/bin/chfn
-rws--x--x    1 root     root        12600 Jul 12 18:22 /usr/bin/chsh
-rws--x--x    1 root     root         5464 Jul 12 18:22 /usr/bin/newgrp
-rwsr-xr-x    1 root     root        21312 Mar  8  2001 /usr/bin/crontab
-r-sr-x---    1 root     www          4656 Feb  8  2001 /usr/lib/apache/pwauth
-r-s--x---    1 root     apache      10976 Mar 29  2001 /usr/sbin/suexec
-rwsr-xr-x    1 root     root         6316 Jul 31 19:08 /usr/sbin/usernetctl
-rwsr-xr-x    1 root     root        18256 Dec  1  2000 /usr/sbin/traceroute
-rwsr-xr-x    1 root     root        14112 Jan 16  2001 /bin/su
-rwsr-xr-x    1 root     root        22620 Jan 16  2001 /bin/ping
-rwsr-xr-x    1 root     root        56508 Apr 30 15:02 /bin/mount
-rwsr-xr-x    1 root     root        25148 Apr 30 15:02 /bin/umount
-r-sr-xr-x    1 root     root        14960 Apr  7  2001 /sbin/pwdb_chkpwd
-r-sr-xr-x    1 root     root        15448 Apr  7  2001 /sbin/unix_chkpwd
-r-sr-sr--    1 root     root        83262 Aug 22 20:56 /sbin/e-smith/console

Appendix K. List of setgid Files

The following files have the setgid bit set which means that these commands are executed by a user with the specific group permissions rather than the user's normal group settings. Note that some of these files will also be found earlier in Appendix J. This list was generated by the command find / -path /proc -prune -o -perm +2000 -exec ls -ld {} \; which lists all setgid files except for those found in the virtual /proc filesystem. The listing was further piped through grep -v "^d" to remove extraneous directory entries.


-r-sr-s---    1 root     admin        5914 Jan 15  2001 /etc/e-smith/web/panels/password/cgi-bin/userpassword
-rwxr-sr-x    1 root     root         4144 Jul 31 19:08 /sbin/netreport
-r-sr-sr--    1 root     root        83262 Aug 22 20:56 /sbin/e-smith/console
-r-sr-sr-x    1 root     mail        22808 Aug  7 12:56 /usr/bin/dotlock
-r-sr-sr-x    1 root     mail       146008 Aug  7 12:56 /usr/bin/maildrop
-rwxr-sr-x    1 root     uucp       167324 Feb 23  2001 /usr/bin/minicom
-rwxr-sr-x    1 root     mail        12440 Jul  3 18:55 /usr/bin/lockfile
-r-xr-sr-x    1 root     tty          6492 Apr  4  2001 /usr/bin/wall
-rwxr-sr-x    1 root     tty          8692 Jul 12 18:22 /usr/bin/write
-rwxr-sr-x    1 root     utmp         6584 Jul 13  2000 /usr/sbin/utempter
-rwsr-sr-x    1 qmailq   qmail       33824 Aug 17 20:27 /var/qmail/bin/scanner

Appendix L. Sample ssh Server Configuration File

Although not enabled by default, many users enable the sshd daemon to provide login capabilities through ssh programs. The example below shows /etc/ssh/sshd_config in the default configuration of no access allowed. The system is configured with the default IP address of 192.168.1.1.


Port 22
ListenAddress 192.168.1.1

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa_key
KeyRegenerationInterval 3600
LoginGraceTime 600

ServerKeyBits 768
ChallengeResponseAuthentication no

IgnoreRhosts yes

KbdInteractiveAuthentication no



MaxStartups 10:30:60

PasswordAuthentication yes
PermitEmptyPasswords no
PermitRootLogin no
RSAAuthentication yes
RhostsAuthentication no

RhostsRSAAuthentication no

StrictModes yes
Subsystem      sftp    /usr/libexec/openssh/sftp-server
X11DisplayOffset 10
X11Forwarding no
CheckMail no
KeepAlive yes
PrintMotd yes


SyslogFacility AUTH
LogLevel INFO 

Appendix M. Listing of Software Packages

The following listing is a sorted list of all RPM software packages installed in the SME Server V5. This list was generated by the command rpm -qa | sort -f.


anacron-2.3-16                         ftp-0.17-7                             perl-HTML-Parser-3.20-1
apache-1.3.19-5                        gawk-3.0.6-1                           perl-libwww-perl-5.48-10
apmd-3.0final-29                       gd-1.8.3-7                             perl-MIME-Base64-2.11-2
ash-0.3.7-1                            gdbm-1.8.0-5                           perl-perl-ldap-0.22-10
at-3.1.8-16                            glib-1.2.9-1                           perl-Text-Template-1.20-2
authconfig-4.1.6-1                     glibc-2.2.2-10                         perl-Time-HiRes-01.20-9
autopassword-2.0-3                     glibc-common-2.2.2-10                  perl-URI-1.11-2
basesystem-7.0-2                       gmp-3.1.1-3                            php-4.0.4pl1-9
bash-2.04-21                           gnupg-1.0.6-1                          php-imap-4.0.4pl1-9
bc-1.06-2                              gpm-1.19.3-16                          php-ldap-4.0.4pl1-9
bdflush-1.5-16                         grep-2.4.2-5                           php-mysql-4.0.4pl1-9
bind-8.2.4-1es                         groff-1.16.1-7                         pidentd-2.8.5-3+masq
bind-utils-8.2.4-1es                   gzip-1.3-12                            pine-4.33-8
binutils-2.10.91.0.2-3                 hdparm-3.9-6                           popt-1.6.2-8
buffer-1.19-5                          horde-1.2.6-2es                        ppp-2.4.0-12
bzip2-1.0.1-3                          horde-mysql-1.2.6-2es                  pptpd-1.1.2-2
checkpassword-0.90-02                  imap-4.7-1mdir6es                      procmail-3.21-0.71
chkconfig-1.2.22-1                     imp-2.2.6-2es                          procps-2.0.7-8
compat-libstdc++-6.2-2.9.0.14          indexhtml-7.1-2                        proftpd-1.2.0rc3-2es
console-tools-19990829-34              info-4.0-20                            psmisc-19-4
cpio-2.4.2-20                          initscripts-5.49-11es                  pwdb-0.61.1-1
cracklib-2.7-8                         ipchains-1.3.10-7                      python-1.5.2-30
cracklib-dicts-2.7-8                   ipmasqadm-0.4.2-4es                    qmail-1.03-06
crontabs-1.9-2                         ip_masq_h323-1.0beta-8                 qmailanalog-0.70-03
cyrus-sasl-1.5.24-17                   ip_masq_icq-0.56-9                     quota-3.00-4
daemontools-0.70-05                    iproute-2.2.4-10                       raidtools-0.90-20
db1-1.85-5                             iptables-1.2.1a-1                      readline-4.1-9
db2-2.4.14-5                           iputils-20001110-1                     rmt-0.4b21-3
db3-3.1.17-7                           isapnptools-1.22-2                     rootfiles-7.0-4
dev-3.1.0-14                           ispell-3.1.20-26es                     rpm-4.0.2-8
dhcp-2.0pl5-4                          kbdconfig-1.9.12-1                     rpm-build-4.0.2-8
dhcpcd-1.3.18pl8-10                    kernel-2.2.19-7.0.8                    rp-pppoe-2.6-5es
diald-0.99.4-2                         kernel-pcmcia-cs-2.2.19-7.0.8          rsync-2.4.6-2
diffutils-2.7-21                       kernel-utils-2.2.19-7.0.8              samba-2.0.10-2
dosfstools-2.2-8                       krb5-libs-1.2.2-12                     samba-client-2.0.10-2
dot-forward-0.71-02                    kudzu-0.72-4es                         samba-common-2.0.10-2
dump-0.4b19-5es                        less-358-16                            sash-3.4-8
e2fsprogs-1.19-4                       libjpeg-6b-15                          sed-3.02-9
ed-0.2-19                              libpng-1.0.9-1                         ServiceLink-activation-1.2.0-02
eject-2.0.2-7                          libsmbpw-1.1-3                         ServiceLink-antivirus-trend-1.2.0-05
e-smith-4.2.0-06                       libstdc++-2.96-85                      ServiceLink-branding-1.4.0-02
e-smith-backup-1.4.0-03                libtermcap-2.0.8-26                    ServiceLink-dns-1.2.0-04
e-smith-base-4.6.1-05                  lilo-21.4.4-13                         ServiceLink-email-1.0.0-07
e-smith-blades-1.0.0-13                logrotate-3.5.4-1                      ServiceLink-freeswan-1.2.0-05
e-smith-boot-image-1.4.0-02            losetup-2.11b-3                        ServiceLink-keys-1.2.0-04
e-smith-daemontools-1.2.0-02           LPRng-3.7.4-23                         ServiceLink-registration-1.2.0-06
e-smith-devtools-1.4.0-01              lynx-2.8.4-5es                         ServiceLink-scanner-1.0.0-07
e-smith-dynamicdns-dyndns-1.2.0-04     mailcap-2.1.4-2                        ServiceLink-support-1.2.0-06
e-smith-dynamicdns-dyndns.org-1.2.0-04 maildrop-1.3.0-1.7.0                   setserial-2.17-2
e-smith-dynamicdns-tzo-1.2.0-04        mailx-8.1.1-20                         setup-2.4.7-06es
e-smith-dynamicdns-yi-1.2.0-04         MAKEDEV-3.1.0-14                       shadow-utils-20000826-4
e-smith-email-4.6.1-02                 mc-4.5.51-32                           shapecfg-2.2.12-5
e-smith-flexbackup-1.2.0-07            mingetty-0.9.4-16                      sharutils-4.2.1-7
e-smith-horde-1.4.0-02                 minicom-1.83.1-5                       sh-utils-2.0-13
e-smith-hosts-1.4.0-04                 mkbootdisk-1.2.8-2                     slang-1.4.2-2
e-smith-imp-1.4.1-03                   mkinitrd-3.0.10-1                      squid-2.3.STABLE4-10
e-smith-ipmasq-1.4.0-02                mktemp-1.5-8                           sshell-2.0-3
e-smith-ldap-4.4.0-03                  mod_auth_external-2.1.2-6              stat-2.2-2
e-smith-lib-1.6.0-09                   mod_perl-1.24_01-2                     stunnel-3.13-3
e-smith-lilo-1.4.0-02                  mod_ssl-2.8.1-5                        sudo-1.6.3p6-1
e-smith-LPRng-1.4.0-03                 modutils-2.4.2-5                       sysklogd-1.3.33-8es3
e-smith-manager-1.2.0-02               mount-2.11b-3                          syslinux-1.52-1
e-smith-mod_ssl-1.8.0-03               mtools-3.9.7-4                         SysVinit-2.78-15
e-smith-mysql-1.4.0-02                 mt-st-0.5b-10                          tai64nunix-0.70-03
e-smith-named-1.6.1-01                 mutt-1.2.5i-9                          taper-6.9b-3
e-smith-netatalk-1.4.0-02              mysql-3.23.36-1                        tar-1.13.19-4
e-smith-netlogon-1.2.0-06              mysqlclient9-3.23.22-4                 tcp_wrappers-7.6-18
e-smith-ntp-1.4.0-02                   mysql-server-3.23.36-1                 tcsh-6.10-5
e-smith-obtuse-smtpd-1.4.1-03          ncompress-4.2.4-21                     telnet-0.17-18
e-smith-openssh-1.4.0-04               ncurses-5.2-8                          telnet-server-0.17-18
e-smith-packetfilter-1.4.0-01          netatalk-1.5pre6-1rh7                  termcap-11.0.1-8
e-smith-php-1.4.0-02                   net-tools-1.57-6                       textutils-2.0.11-7
e-smith-pptpd-1.2.0-08                 newt-0.50.17-3es                       time-1.7-13
e-smith-proftpd-1.4.0-04               ntp-4.0.99k-15                         tmpwatch-2.7.1-1
e-smith-proxy-4.4.0-05                 ntsysv-1.2.22-1                        tnef-0.16-1mdk
e-smith-qmail-1.2.0-02                 obtuse-smtpd-2.0-27                    traceroute-1.4a5-25
e-smith-qmailanalog-1.4.0-06           openldap-2.0.11-8                      trendVirusWall-3.01-4
e-smith-reinstall-floppy-1.4.0-02      openldap-clients-2.0.11-8              unzip-5.41-3
e-smith-release-5.0-01                 openldap-servers-2.0.11-8              urlview-0.9-2
e-smith-rp-pppoe-1.4.0-03              openssh-2.9p2-1                        utempter-0.5.2-4
e-smith-telnet-1.2.0-04                openssh-clients-2.9p2-1                util-linux-2.10s-13.7
e-smith-viewlogfiles-1.0.0-02          openssh-server-2.9p2-1                 vim-common-6.0-0.27
e-smith-wu-imap-1.2.0-04               openssl-0.9.6-9                        vim-minimal-6.0-0.27
fastforward-0.51-03                    pam-0.74-22                            vixie-cron-3.0.1-62
fetchmail-5.7.4-4                      passwd-0.64.1-4                        wget-1.6-2
file-3.33-1                            patch-2.5.4-9                          which-2.12-1
filesystem-2.0.7-1                     pciutils-2.1.8-19                      whois-1.0.6-1
fileutils-4.0.36-4                     perl-5.6.0-12                          words-2-16
findutils-4.1.6-2                      perl-Convert-ASN1-0.07-10              xinetd-2.3.0-1.71
flexbackup-0.9.8-06es                  perl-Crypt-SSLeay-0.25-1               zlib-1.1.3-22
freeswan-1.8-06                        perl-Error-0.14-01                     
freetype-2.0.1-4                       perl-FreezeThaw-0.41-2 

 

 

Revision 1.0, published October 29, 2001. Copyright 2001 Mitel Knowledge Corporation.

The Mitel logo and the term and "i-bay" are trademarks or registered trademarks of Mitel Networks Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds. The terms "ssh" and "Secure Shell" are trademarks of SSH Communications Security Corp. All other trademarks are the property of their respective holders.