A technical white paper
Dan York
Copyright © 2001 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
- 7. User Accounts, Groups and Passwords
- 8. Remote Access
- 9. File Transfer
- 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
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.
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.
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.
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.
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!
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.
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.
The SME Server is configured to run only those services which are enabled in its configuration database.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
NameVirtualHost 127.0.0.1:443
<VirtualHost 127.0.0.1:443>
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>
</VirtualHost>
|
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.