Monitoring hard disk health with smartd under Linux

smartd is SMART Disk Monitoring Daemon for Linux. SMART is acronym for Self-Monitoring, Analysis and Reporting Technology (SMART) system built into many ATA-3 and later ATA, IDE and SCSI-3 hard drives. The purpose of SMART is to monitor the reliability of the hard drive and predict drive failures, and to carry out different types of drive self-tests.
smartd works with following operating systems:
  1. Linux
  2. *BSD
  3. Windows
  4. Solaris etc

How do I Install smartd?

However, smartd is not installed by default. Following are distribution specific steps to install smartd:
Debian Linux:
# apt-get install smartmontools
Red hat/Fedora Linux:
# rpm –ivh kernel-utils
OR
# up2date kernel-utils
OR if you are using Fedora Linux
# yum kernel-utils
FreeBSD:
# pkg_add -r -v smartmontools
Before configuring hard disk for SMART monitoring make sure your hard disk is SMART capable:
# smartctl -i /dev/hda
Output:
smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     SAMSUNG SV2002H
Serial Number:    0395J1FR904324
Firmware Version: RA100-04
User Capacity:    20,060,651,520 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   6
ATA Standard is:  ATA/ATAPI-6 T13 1410D revision 1
Local Time is:    Tue May  2 15:44:09 2006 IST

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

You can configure the smartd daemon by editing the file /etc/smartd.conf. 
In above output the lines:
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Indicates that it is SMART capable and it is enabled.

Configure SMARTD

Debian Linux
  • Enable smart by editing /etc/default/smartmontools file.
  • Smart Configuration file: /etc/smartd.conf
  • Start/Stop smart: /etc/init.d/smartmontools start | stop
Red Hat Linux
  • Enable smart by editing /etc/smartd.conf file.
  • Smart Configuration file: /etc/smartd.conf
  • Start/Stop smart: /etc/init.d/smartd start | stop
FreeBSD
  • Enable smart by editing /etc/rc.conf file (add line smartd_enable=”YES").
  • Smart Configuration file: /etc/smartd.conf
  • Start/Stop smart: /usr/local/etc/rc.d/smartd.sh start | stop

Example

You can put following directives in Smart Configuration file:
(a) Send an email to alert@nixcraft.in for /dev/sdb:
/dev/sdb -m alert@nixcraft.in
(b) Read error log:
# smartctl -l error /dev/hdb
(c) Testing hard disk (short or long test):
# smartctl -t short /dev/hdb
# smartctl -t long /dev/hdb
Caution smartd is a monitoring tool not a backup solution. Always perform data backup.

Using TCP Wrappers to secure Linux

TCP Wrappers can be used to GRANT or DENY access to various services on your machine to the outside network or other machines on the same network. It does this by using simple Access List Rules which are included in the two files /etc/hosts.allow and /etc/hosts.deny .

Let us consider this scenario: A remote machine remote_mc trying to connect to your local machine local_mc using ssh.

When the request from the remote_mc is received by the tcp wrapped service (SSH in this case), it takes the following basic steps:
  1. It checks the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule , it allows the connection. If no rule is found, it moves on to step 2.
  2. It checks the /etc/hosts.deny file and if a matching rule is found, it deny's the connection.
Points to remember
  • Rules in hosts.allow takes precedence over rules in hosts.deny . Which means if a matching rule is found in hosts.allow file, the remote_mc is allowed access to the service even if there is a matching deny rule in hosts.deny file.
  • You can have only one rule per service in hosts.allow and hosts.deny file.
  • If there are no matching rules in either of the files or if the files don't exist, then the remote_mc is allowed access to the service.
  • Any changes to hosts.allow and hosts.deny file takes immediate effect.
Rule Syntax
The syntax for both hosts.allow and hosts.deny file takes the following form:
daemon : client [:option1:option2:...]
Where daemon can be a combination of ssh daemon, ftp daemon, portmap daemon and so on. Basically any service which has support for libwrap.a library compiled into it is a good candidate for utilizing the services of TCP Wrappers.

client is a comma separated list of hostnames, host IP addresses, special patterns or special wildcards which identify the hosts effected by that rule.

options is an optional action like say sending mail to the administrator when this rule is matched, log to a particular file and so on. It can be a colon separated list of actions too.

Examples of using TCP Wrappers

I want to allow SSH access to hosts in a particular domain say xyz.com and deny access to all the others. I enter the following rule in the hosts.allow file.
sshd : .xyz.com
... and in the hosts.deny file I include the rule:

sshd : ALL
The next rule denys FTP access to all the hosts in the abc.co.in domain as well as hosts in the 192.168.1.0 network.

#FILE: /etc/hosts.deny
vsftpd : 192.168.1. , .abc.co.in : spawn /bin/echo  `/bin/date` access denied >> /var/log/vsftpd.log : deny
The backslash (\) in the above rule is used to break the line and prevents the failure of the rule due to length.

spawn and deny are options. Spawn launches a shell command as a child process. In the above rule, spawn logs a message to the vsftpd log file each time the rule matches. deny is optional if you are including this rule in the hosts.deny file.

Note: The last line in the files hosts.allow and hosts.deny must be a new line character. Or else the rule will fail.
For example, you can use spawn option to send mail to the admin when ever a deny rule is matched.

Wildcards
You can use wildcards in the client section of the rule to broadly classify a set of hosts. These are the valid wildcards that can be used.

  • ALL - Matches everything
  • LOCAL - Matches any host that does not contain a dot (.) like localhost.
  • KNOWN - Matches any host where the hostname and host addresses are known or where the user is known.
  • UNKNOWN - Matches any host where the hostname or host address are unknown or where the user is unknown.
  • PARANOID - Matches any host where the hostname does not match the host address.
Patterns
You can also use patterns in the client section of the rule . Some examples are as follows:

ALL : .xyz.com
Matches all hosts in the xyz.com domain . Note the dot (.) at the beginning.

ALL : 123.12.
Matches all the hosts in the 123.12.0.0 network. Note the dot (.) in the end of the rule.

ALL : 192.168.0.1/255.255.255.0
IP address/Netmask can be used in the rule.

ALL : *.xyz.com
Asterisk * matches entire groups of hostnames or IP addresses.

sshd : /etc/sshd.deny
If the client list begins with a slash (/), it is treated as a filename. In the above rule, TCP wrappers looks up the file sshd.deny for all SSH connections.

sshd : ALL EXCEPT 192.168.0.15
If the above rule is included in the /etc/hosts.deny file, then it will allow ssh connection for only the machine with the IP address 192.168.0.15 and block all other connections. Here EXCEPT is an operator.

Note: If you want to restrict use of NFS and NIS then you may include a rule for portmap . Because NFS and NIS depend on portmap for their successful working. In addition, changes to portmap rules may not take effect immediately.

Suppose I want to log all connections made to SSH with a priority of emergency. See my previous post to know more on logging. I could do the following:

sshd : .xyz.com : severity emerg
Note: You can use the options allow or deny to allow or restrict on a per client basis in either of the files hosts.allow and hosts.deny

in.telnetd : 192.168.5.5 : deny
in.telnetd : 192.168.5.6 : allow

Shell Commands
As mentioned above, you can couple the rules to certain shell commands by using the following two options.

spawn - This option launches a shell command as a child process. For example, look at the following rule:

sshd : 192.168.5.5 : spawn /bin/echo `/bin/date` from %h >> /var/log/ssh.log : deny

Each time the rule is satisfied, the current date and the clients hostname %h is appended to the ssh.log file.

twist - This is an option which replaces the request with the specified command. For example, if you want to send to the client trying to connect using ssh to your machine, that they are prohibited from accessing SSH, you can use this option.

sshd : client1.xyz.com : twist /bin/echo "You are prohibited from accessing this service!!" : deny

When using spawn and twist, you can use a set of expressions. They are as follows :
%a — The client's IP address.
%A — The server's IP address.
%c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.
%d — The daemon process name.
%h — The client's hostname (or IP address, if the hostname is unavailable).
%H — The server's hostname (or IP address, if the hostname is unavailable).
%n — The client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed.
%N — The server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed.
%p — The daemon process ID.
%s — Various types of server information, such as the daemon process and the host or IP address of the server.
%u — The client's username. If unavailable, unknown is printed.

Automatically rotating your Log Files

Uncontrolled growing of log files may fill up important filesystems like /var. One, not documented features under Linux is logrotate, which belongs to the standard RedHat Linux distribution.
Logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large. Normally, logrotate is run as a daily cron job. It will not modify a log multiple times in one day unless the criterium for that log is based on the log’s size and logrotate is being run multiple times each day, or unless the -f or -force option is used.
Any number of config files may be given on the command line. Later config files may override the options given in earlier files, so the order in which the logrotate config files are listed in is important. Normally, a single config file which includes any other config files which are needed should be used.
Configuration File 
The configuration file for logrotate can be found in /etc/logrotate.conf
# rotate log files daily
daily

# keep 1 day of backlogs
rotate 1

# send errors to
errors martin dot zahn at akadia dot ch

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own lastlog or wtmp -- we'll rotate them here
/var/log/wtmp {
  monthly
  create 0664 root utmp
  rotate 1
}
Included Files from /etc/logrotate.d (e.g. apache)
/var/log/httpd/akadia.log {
  missingok
  postrotate
    /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`
    2> /dev/null || true
  endscript
}

/var/log/httpd/error.log {
  missingok
  postrotate
    /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`
    2> /dev/null || true
  endscript
}
For more information type the following commands:
# man logrotate
# man logrotate | col -b > logrotate.txt
# man -t logrotate > logrotate.ps

Postfix -- the Sendmail Replacement

Architecture

Some mail systems such as Sendmail are implemented as one large monolithic program that does everything. One large program certainly makes it easy to share data between different parts of the system. Unfortunately, one large program also makes it easy to make fatal mistakes.
Postfix is based on semi-resident, mutually-cooperating, processes that perform specific tasks for each other, without any particular parent-child relationship. Postfix is implemented as a resident master server that runs Postfix daemon processes on demand: daemon processes to send or receive network mail messages, daemon processes to deliver mail locally. Postfix is intended to be a sendmail replacement. For this reason it tries to be compatible with existing infrastructure.
Mail queues
Postfix has four different queues: maildrop, incoming, active and deferred. Locally-posted mail is deposited into the maildrop, and is copied to the incoming queue after some cleaning up. The incoming queue is for mail that is still arriving or that the queue manager hasn't looked at yet. The active queue is a limited-size queue for mail that the queue manager has opened for delivery. Mail that can't be delivered goes to the deferred queue, so that it does not get in the way of other deliveries.
The queue manager qmgr keeps information in memory about the active queue only. The active queue size is limited on purpose: the queue manager should never run out of working memory because of a peak message workload. Whenever there is space in the active queue, the queue manager lets in one message from the incoming queue and one from the deferred queue. This guarantees that new mail will get through even when there is a large backlog.
Sendmail
The sendmail program implements the Postfix to Sendmail compatibility interface. For the sake of compatibility with existing applications, some Sendmail command-line options are recognized but silently ignored.
By default, sendmail reads a message from standard input until EOF or until it reads a line with only a . character, and arranges for delivery. sendmail attempts to create a queue file in the maildrop directory. The command mailq List the mail queue. Each entry shows the queue file ID, message size, arrival time, sender, and the recipients that still need to be delivered. The command newaliases initialize the alias database.
  • Sending local email with the sendmail interface.
Suppose, you have the following file to_akadia .....
From:
To:
Subject: This is a Postfix Sendmail Test

This message is sent with the sendmail front end from the postfix mail system

-- Regards Martin
.... then you can send this local email in the known sendmail syntax as follows:
# cat to_akadia | /usr/sbin/sendmail -t -bm -v
sendmail: open maildrop/746D52C01F
  • Show the mail queue
# mailq  or sendmail -bp
  • Initialize the alias database
# newaliases or sendmail -bi
Pickup
The pickup daemon waits for hints that new mail has been dropped into the world-writable maildrop directory, and feeds it into the cleanup daemon. This program expects to be run from the master process manager. The pickup daemon does not interact with the outside world. It daemon runs with superuser privileges so that it 1) can open a queue file with the rights of the submitting user and 2) can access the Postfix private IPC channels. Pickup does some sanity checks, in order to protect the rest of the Postfix system.
Smtpd
The SMTP server accepts network connection requests and performs zero or more SMTP transactions per connection. Each received message is piped through the cleanup daemon, and is placed into the incoming queue as one single queue file. For this mode of operation, the program expects to be run from the master process manager. Alternatively, the SMTP server takes an established connection on standard input and deposits messages directly into the maildrop queue. In this so-called stand-alone mode, the SMTP server can accept mail even while the mail system is not running.
Cleanup
The cleanup daemon implements the final processing stage for new mail. It adds missing From: and other message headers, arranges for address rewriting to the standard user@fully.qualified.domain form, and optionally extracts recipient addresses from message headers. The cleanup daemon inserts the result as a single queue file into the incoming queue, and notifies the queue manager of the arrival of new mail. The cleanup daemon can be configured to transform addresses on the basis of canonical and virtual table lookups.
On request by the cleanup daemon, the trivial-rewrite daemon rewrites addresses to the standard user@fully.qualified.domain form. The initial Postfix version does not implement a rewriting language. Implementing one would take a lot of effort, and most sites do not need it. Instead, Postfix makes extensive use of table lookups.
Qmgr
The queue manager is the heart of the Postfix mail system. It contacts the local, smtp, or pipe delivery agents, and sends a delivery request with queue file pathname information, the message sender address, the host to deliver to if the destination is remote, and one or more message recipient addresses.
The queue manager maintains a separate deferred queue for mail that cannot be delivered, so that a large mail backlog will not slow down normal queue accesses.
The queue manager maintains a small active queue with just the few messages that it has opened for delivery. The active queue acts as a limited window on the potentially much larger incoming or deferred queues. The small active queue prevents the queue manager from running out of memory under heavy load.
Optionally, the queue manager bounces mail for recipients that are listed in the relocated table. This table contains contact information for users or even entire domains that no longer exist.
Resolve
On request by the queue manager, the resolve daemon resolves destinations. By default, it only distinguishes between local and remote destinations. Additional routing information can be specified with the optional transport table.
Bounce and Defer
On request by the queue manager, the bounce or defer daemon generates non-delivery reports when mail cannot be delivered, either due to an unrecoverable error or because the destination is unreachable for an extended period of time.
Local
The local delivery agent understands UNIX-style mailboxes, sendmail-style system-wide alias databases, and sendmail-style per-user .forward files. Multiple local delivery agents can be run in parallel, but parallel delivery to the same user is usually limited. Together with the sendmail mail posting agent, the local delivery agent implements the familiar Sendmail user interface.
The local delivery agent has hooks for alternative forms of local delivery: you can configure it to deliver to mailbox files in user home directories, and you can even configure it to delegate mailbox delivery to an external command such as the popular procmail program.
Smtp
The SMTP client looks up a list of mail exchangers for the destination host, sorts the list by preference, and tries each address in turn until it finds a server that responds. On a busy Postfix system you will see several SMTP client processes running in parallel.
Pipe
The pipe mailer is the outbound interface to other mail transports (the sendmail program is the inbound interface) such as UUCP.

Basic Postfix Configuration

All of the many configuration parameters can be found in the main.cf file, located in the ./conf directory in the postfix source. You need not change every parameter, as they are set to sensible defaults. Here are the details on some of the more important parameters, which will affect the performance of Postfix the most. Please note that if you change the main.cf file after installation, you must issue the postfix reload command.
# postconf -d  (Show default values)
# postconf -n  (Show non default values)
Basic Parameters
  • queue_directory - the location of the Postfix queue as well as the root dir of the postfix daemons that run chrooted. This field should be left with the default /var/spool/postfix.
# Mail Queue
queue_directory = /usr/local/postfix/spool
  • daemon_directory - the location of the daemon programs such as smptd, pickup, cleanup, etc.
# Daemon Directory
daemon_directory = /usr/local/postfix/bin
  • mail_owner - the owner of Postfix's queue and most of the daemon processes. For this you must add a user to your machine, this has to be a user that owns no other files or processes (so using nobody here is a very bad idea for security reasons).
# Mail Owner
mail_owner = postfix
  • myorigin - the origin is set to $myhostname by default, which defaults to the local hostname of the machine. This should not be used unless you are running a very small site. Most people want to change myorigin to $mydomain which will default to the parent domain of the machine name (i.e. if the hostname is rabbit.akadia.com and you are using $myhostname, the origin will be rabbit.akadia.com. On the other hand if you were using $mydomain, the origin will be akadia.com.)
# My own domain name
mydomain = akadia.com
# What domain to use in outbound mail
myorigin = $mydomain
  • inet_interfaces - the inet_interfaces parameter defines which network interface addresses that the stmp daemon will listen on. By default this is set to all, which will listen on any active interface on the machine. This will control the delivery to users@.
# Listen to
inet_interfaces = all
  • mydestination - this parameter specifies the list of domains that the machine considers itself. The default of $myhostname and localhost.$mydomain should do here. Don't specify the virtual domains that are hosted on the machine here!
# What domains to receive mail for
mydestination = $myhostname, localhost.$mydomain
  • mailbox_command - this parameter defines the external command to use instead of local mailbox delivery. It is a completely optional parameter. If you're interested in having procmail to do your mail, this is where you set it.
  • mynetworks - mynetworks specifies a certain list of network addresses that are local to this machine. The list is used to distinguish lusers from strangers. The addresses go in the format of X.X.X.0/X and can be separated by a comma. By default the list of all of the networks attached to the machine is a complete class A network (X.0.0.0/8), a complete class B network (X.X.0.0/16), a complete class C network (X.X.X.0/24), and so on. You can also specify a path of a pattern file instead of listing the patterns here.
# Accept Mail only from
mynetworks = 192.168.32.32/32, 195.65.134.0/26, 127.0.0.0/8
  • notify_classes - You should set up a postmaster alias that points to a human person. This alias is required to exist, so that people can report mail delivery problems. The Postfix system itself also reports problems to the postmaster alias. You may not be interested in all types of trouble reports, so this reporting mechanism is configurable. The default is to report only serious problems (resource, software) to postmaster:
    # Notify Errors to
    notify_classes = bounce,delay,policy,protocol,
                     resource,software

Address Manipulation with Postfix

Although the initial Postfix release has no address rewriting language, it can do quite a bit of address manipulation via table lookup. While a message flows through the Postfix system, its addresses are mangled in the order described in this document. Unless indicated otherwise, all parameters described here are in the main.cf file. If you change parameters of a running Postfix system, don't forget to issue a postfix reload command.
  • Canonical address mapping
  • Address masquerading
  • Virtual address mapping
  • Relocated users table
  • Mail transport switch
Canonical address mapping
Before the cleanup daemon stores inbound mail into the incoming queue, it uses the canonical table to rewrite all addresses in message envelopes and in message headers, local or remote. The mapping is useful to replace login names by Firstname.Lastname style addresses, or to clean up invalid domains in mail addresses produced by legacy mail systems. In addition to the canonical maps which are applied to both sender and recipient addresses, you can specify canonical maps that are applied only to sender addresses or to recipient addresses. For example:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
The sender and recipient canonical maps are applied before the common canonical maps.
Sender-specific rewriting is useful when you want to rewrite ugly sender addresses to pretty ones, and still want to be able to send mail to the those ugly address without creating a mailer loop.
Example
You are a dial-up with the local name "zahn@saphir" and you want to convert this address to "martin dot zahn at akadia dot ch", so the ISP will accept the name. Enter the following line in /usr/local/postfix/etc/canonical:
zahn@saphir     martin dot zahn at akadia dot ch
Canonical mapping is disabled by default. To enable, edit the canonical_maps parameter in the main.cf file and specify one or more lookup tables, separated by whitespace or commas. For example:
canonical_maps = hash:/usr/local/postfix/etc/canonical
Be sure to run
# postmap /usr/local/postfix/etc/canonical
# postfix reload
Important Note
For canonical address mapping the address must not be a local user as it is in Alias mapping
Address masquerading
Address masquerading is a method to hide all hosts below a domain behind their mail gateway, and to make it appear as if the mail comes from the gateway itself, instead of from individual machines.
Address masquerading is disabled by default. To enable, edit the masquerade_domains parameter in the main.cf file and specify one or more domain names separated by whitespace or commas. For example:
masquerade_domains = $mydomain, akadia.ch
In this example, addresses of the form martin.zahn@rabbit.akadia.com would be rewritten to martin dot zahn at akadia dot ch.
The masquerade_exceptions configuration parameter specifies what user names should not be subjected to address masquerading. Specify one or more user names separated by whitespace or commas. For example, masquerade_exceptions = root. By default, Postfix makes no exceptions. 
Important Note
Address masquerading is applied only to message headers and envelope sender addresses, not to envelope recipients, envelope addresses can be manipulated with virtual address mapping ... see next section.
Virtual address mapping
After applying the canonical and masquerade mappings, the cleanup daemon uses the virtual table to redirect mail for all recipients, local or remote. Virtual lookups are useful to redirect mail for virtual domains to real user mailboxes, and to redirect mail for domains that no longer exist. Virtual lookups can also be used to transform Firstname.Lastname back into UNIX login names, although it seems that local aliases are a more appropriate vehicle.
virtual_alias_maps = hash:$config_directory/virtual
virtual_alias_domains = $virtual_alias_maps
Important Note
Virtual address mapping is applied only to envelope recipients; it has no effect on message headers or envelope senders, message headers and envelope sender addresses can be manipulated with address masquerading ... see previous section.
Virtual Table
The first line in the virtual table describes the virtual domain. This line is necessary to avoid
  • Postfix does not refuse mail for unknown virtual users.
  • Mail for unknown virtual users fails with "mail loops back to myself".
  • Postfix refuses mail for virtual domains with "user unknown".
  • Postfix refuses mail for virtual domains with "relay access denied".
The left part of the next lines defines the E-Mail address which should be forwarded, the right part are local users or external E-Mail addresses.
Example of /etc/postfix/virtual for individual addresses
arkum.ch              My Virtual Domain
info@arkum.ch         info@akadia.ch, martin dot zahn at akadia dot ch
zahn@arkum.ch         zahn_martin@hotmail.com
Example of /etc/postfix/virtual if all addresses should be transparently forwared
arkum.ch              My Virtual Domain
@arkum.ch             @akadia.com
The second line defines, that all E-Mail for ARKUM.CH should be forwarded to AKADIA.COM
Relocated users table
Next, the queue manager runs each recipient name through the relocated database. This table provides information on how to reach users that no longer have an account, or what to do with mail for entire domains that no longer exist. When mail is sent to an address that is listed in this table, the message is bounced with an informative message.
Lookups of relocated users are disabled by default. To enable, edit the relocated_maps parameter in the main.cf file and specify one or more lookup tables, separated by whitespace or commas.
relocated_maps = hash:/etc/postfix/relocated
Example of /etc/postfix/relocated
hans.mueller@infoline.ch    Hans Mueller has left
Alias database
When mail is to be delivered locally, the local delivery agent runs each local recipient name through the aliases database. The mapping does not affect addresses in message headers. Local aliases are typically used to implement distribution lists, or to direct mail for standard aliases such as postmaster to real people. The table can also be used to map Firstname.Lastname addresses to login names. Alias lookups are enabled by default. The default configuration depends on the system environment, but it is typically one of the following:
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
The path to the alias database file is controlled via the alias_database configuration parameter. The value is system dependent. Usually it is one of the following:
Example of /etc/aliases
# Postfix User
postfix:   root
# Person who should get root's mail
root:      martin dot zahn at akadia dot ch
Mail transport switch (Mail Proxy, Mail Gateway)
Once the queue manager has established the destination of a message, the optional transport table controls how the message will be delivered (this table is used by the address rewriting and resolving daemon). By default, everything is sent via the smtp transport. The transport table can be used to send mail to a mail server in the HSZ, in this case we implement a mail gateway (proxy) in the DMZ.
Transport table lookups are disabled by default. To enable, edit the transport_maps parameter in the main.cf file and specify one or more lookup tables, separated by whitespace or commas.
transport_maps = hash:/etc/postfix/transport
Example of /etc/postfix/transport
arkum.ch             smtp:[192.168.32.32]
.arkum.ch            smtp:[192.168.32.32]
paragon.akadia.com   local:
localhost.akadia.com local:
The first line (arkum.ch) forwards all E-Mails user@arkum.ch the internal E-Mail server on 192.168.32.32. The second line is used to forward E-Mails for user@firewall to 192.168.32.32. Do not omit the entries that deliver mail locally, or else mail will bounce with a "mail loops to myself" condition.

Keeping out Unsolicited Commercial E-mail

Junk mail is one of the most common and annoying types of e-mail abuse. Postfix offers protection against UCE (Unsolicited Commercial E-mail) via a couple of settings in main.cf. Some caution is in order, however: there's a fine line between spam and legitimate dissemination, and it's entirely possible that even modest UCE controls will cause some legitimate (i.e., desired) mail to be dropped.
See more information here

Postfix Installation

Download
Download Source for http://www.postfix.org
# gunzip postfix-2.2.0.tar.gz
# tar xvf postfix-2.2.0.tar
# cd postfix-2.2.0
# make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/usr/local/postfix/etc\"'
# For Postfix 1.1.x
# make makefiles CCARGS=-DDEF_CONFIG_DIR=
  \\\\\\\"/usr/local/postfix/etc\\\\\\\"
# make
This will install Postfix in /usr/local/postfix, and therefore no conflicts with an existing sendmail configuration will happen.
Configuration
If you are replacing an existing sendmail installation with Postfix, you may need to keep the old sendmail program running for some time in order to flush the mail queue. As superuser,
execute the following commands (your sendmail, newaliases and mailq programs may be in a different place).
# mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
# mv /usr/bin/newaliases /usr/bin/newaliases.OFF
# mv /usr/bin/mailq /usr/bin/mailq.OFF
# chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF
  /usr/bin/mailq.OFF
In order to install or upgrade Postfix
Create a user "postfix" with a unique user id and group id. Preferably, this is an account that no-one can log into. The account does not need an executable login shell, and needs no existing home directory.
postfix:*:12345:12345:postfix:/no/where:/no/shell
Make sure there is a corresponding alias in /etc/aliases
postfix: root
Create a group "postdrop" with a group id that is not used by any other user account. Not even by the postfix user account.
postdrop:*:54321:
Run the "make install" script as the super-user
# make install
install_root: [/] /
tempdir: /tmp
config_directory: /usr/local/postfix/etc
daemon_directory: /usr/local/postfix/bin
command_directory: /usr/local/postfix/sbin
queue_directory: /usr/local/postfix/spool
sendmail_path: /usr/local/postfix/sendmail/sendmail
newaliases_path: /usr/local/postfix/sendmail/newaliases
mailq_path: /usr/local/postfix/sendmail/mailq
mail_owner: postfix
setgid_group: postdrop
manpages: /usr/local/postfix/man
sample_directory: /usr/local/postfix/sample
readme_directory: /usr/local/postfix/readme
Copy /etc/aliases to /usr/local/postfix/etc
# cd /usr/local/postfix/sendmail
# ./newaliases

Important Commands

postconf mail_version
Find out what Postfix Version is installed
mailq
Show Mail Queue
postsuper -d ALL
Remove bounced mail from the queue.
postfix flush
Flush the Mail Queue
postfix check
Check Installation
telnet mail-abuse.org
Test your own Mailserver against attacks.

 

How to check your mailserver against attacks

The delivery of unsolicited commercial email (UCE) must be avoided on a secure mailserver. But how to check the mailserver against relaying and attacks? Abuse.org offers a public mailserver, which can be used to check the own mailserver.
  1. Login to your mailserver
  2. Execute: telnet mail-abuse.org
Now you can see, how your system will be attacked and how secure it is.
Escape character is '^]'.
<<< 220 SMTP service ready
>>> HELO dante.mail-abuse.org
<<< 250 Requested mail action okay, completed
:Relay test: #Test 1
>>> mail from:
<<< 250 Requested mail action okay, completed
>>> rcpt to:
<<< 554 Transaction failed
>>> rset
<<< 250 Requested mail action okay, completed
:Relay test: #Test 2
.....
.....
<<< 250 Requested mail action okay, completed
>>> QUIT
<<< 221 SMTP server closing transmission channel
Tested host banner: 220 SMTP service ready

System appeared to reject relay attempts

Typical Configurations

Postfix Mailbox Host in the DMZ
Email is saved on the Postfix Mailbox Host, located in the DMZ. All clients get their E-Mail using POP or IMAP. All clients uses the Mailbox Host as their Relay-Host. The Mailbox Host delivers E-Mail directly to the recipient using DNS and SMTP. The disadvantage of this solution is, that the Mailboxes are located in the DMZ.
Main.cf
postfix_root = /usr/local/postfix
config_directory = $postfix_root/etc
queue_directory = $postfix_root/spool
program_directory = $postfix_root/sbin
command_directory = $program_directory
daemon_directory = $postfix_root/bin
mail_owner = postfix
mydomain = akadia.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain,
                $mydomain, akadia.ch, arkum.ch

relayhost =
masquerade_domains = $mydomain
alias_maps = hash:$config_directory/aliases
alias_database = hash:$config_directory/aliases
notify_classes = bounce,delay,policy,protocol,resource,software
mynetworks = 193.247.121.192/28, 192.168.138.0/24, 127.0.0.0/8
maps_rbl_domains = rbl.maps.vix.com
smtpd_client_restrictions =
        permit_mynetworks,
        check_client_access hash:$config_directory/access,
        reject_maps_rbl
Postfix Host inside the Intranet (on HSZ)
Email is saved on the Postfix Mailbox Host, located in the DMZ. All clients get their E-Mail using POP or IMAP. This example shows how to configure a Postfix Client in the HSZ, which delivers all Mail to the Relayhost 193.247.121.196.
Main.cf
postfix_root = /usr/local/postfix
config_directory = $postfix_root/etc
queue_directory = $postfix_root/spool
program_directory = $postfix_root/sbin
command_directory = $program_directory
daemon_directory = $postfix_root/bin
mail_owner = postfix
mydomain = akadia.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain,
                $mydomain, akadia.ch, arkum.ch
relayhost = $mydomain
masquerade_domains = $mydomain
transport_maps = hash:$config_directory/transport
alias_maps = hash:$config_directory/aliases
alias_database = hash:$config_directory/aliases
notify_classes = bounce,delay,policy,protocol,resource,software
mynetworks = 192.168.138.0/24, 127.0.0.0/8
smtpd_client_restrictions = permit_mynetworks
Transport Table
akadia.com             smtp:[193.247.121.196]
.akadia.com            smtp:[193.247.121.196]
akadia.ch              smtp:[193.247.121.196]
.akadia.ch             smtp:[193.247.121.196]
arkum.ch               smtp:[193.247.121.196]
.arkum.ch              smtp:[193.247.121.196]
paragon                local:
paragon.akadia.com     local:
localhost.akadia.com   local:
Postfix as a Proxy Mailhost in the DMZ
Email is saved on the Postfix Mailbox Host (192.168.138.10), located in the HSZ. The Postfix Mail-Proxy (193.247.121.196) forwards all E-Mail to the Mailbox Host in the HSZ. All clients get their E-Mail using POP or IMAP from the Mailbox Host in the HSZ. All clients use the Mail-Proxy as their Relay-Host. The Mail-Proxy delivers E-Mail directly to the recipient using DNS and SMTP. The advantage of this solution is, that the Mailboxes are located in the HSZ, therefore we suggest to use this architecture.
Main.cf
postfix_root = /usr/local/postfix
config_directory = $postfix_root/etc
queue_directory = $postfix_root/spool
program_directory = $postfix_root/sbin
command_directory = $program_directory
daemon_directory = $postfix_root/bin
mail_owner = postfix
mydomain = akadia.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain,
                $mydomain, akadia.ch, arkum.ch
relayhost = 
masquerade_domains = $mydomain
transport_maps = hash:$config_directory/transport
alias_maps = hash:$config_directory/aliases
alias_database = hash:$config_directory/aliases
notify_classes = bounce,delay,policy,protocol,resource,software
mynetworks = 193.247.121.192/28, 192.168.138.0/24, 127.0.0.0/8
smtpd_client_restrictions = permit_mynetworks
Transport Table
akadia.com             smtp:[192.168.138.10]
.akadia.com            smtp:[192.168.138.10]
akadia.ch              smtp:[192.168.138.10]
.akadia.ch             smtp:[192.168.138.10]
arkum.ch               smtp:[192.168.138.10]
.arkum.ch              smtp:[192.168.138.10]
Postfix as a Multi Domain Mail-Host (for ISPs)
If you want to server multiple domains, then Postfix is the right tool. Use the virtual table to configure the domains.
The optional virtual table specifies redirections for local and non-local recipients or domains. The redirections are used by the cleanup daemon. The redirections are recursive. The virtual redirection is applied only to the recipient envelope address, and does not affect message headers. Think Sendmail rule set S0, if you like. Use canonical mapping to rewrite header and envelope addresses in general.
Main.cf
postfix_root = /usr/local/postfix
config_directory = $postfix_root/etc
queue_directory = $postfix_root/spool
program_directory = $postfix_root/sbin
command_directory = $program_directory
daemon_directory = $postfix_root/bin
mail_owner = postfix
mydomain = akadia.com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain,
                $config_directory/localdomains
relayhost = 
masquerade_domains = $mydomain
virtual_maps = hash:$config_directory/virtual
alias_maps = hash:$config_directory/aliases
alias_database = hash:$config_directory/aliases
notify_classes = bounce,delay,policy,protocol,resource,software
mynetworks = 193.247.121.192/28, 192.168.138.0/24, 127.0.0.0/8
smtpd_client_restrictions = permit_mynetworks
Localdomains File (Important !)
The "localdomains" file is not mapped or hashed. It uses plain text, one listing per line. It's equivalent to class w with sendmail.
akadia.com
akadia.ch
arkum.com
arkum.ch
bohl.ch
bohl.com
Virtual Table
Typical support for a virtual domain looks like the following:
virtual.domain                  Description for the Domain
postmaster@virtual.domain       postmaster
user1@virtual.domain            address1
user2@virtual.domain            address2, address3
#
# Domain AKADIA.CH
#
akadia.ch                  Virtual Domain for Akadia
martin.zahn@akadia.ch      zahn@akadia.com,zahn@hotmail.com
info@akadia.ch             zahn@akadia.com
marianne.zahn@akadia.ch    pmz@akadia.com
#
# Forward transparently all address for ARKUM.CH to AKADIA.COM
#
arkum.ch                   Virtual Domain for Akadia
@arkum.ch                  @akadia.com
#
# Domain BOHL.CH
#
bohl.ch                    Virtual Domain for employee
info@bohl.ch               bohl@akadia.com

20 Linux Server Hardening Security Tips

This summary is not available. Please click here to view the post.