Using Postfix for Secure SMTP Gateways
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.
Having said that, for most sites this is an acceptable risk (avoidable, too, through end-user education), and we recommend that at a minimum, you set the following in main.cf:
smtpd_recipient_limit. This setting indicates how many recipients may be addressed in the header of a single message. Normally, such a number should not exceed something like 500. It would be extreme to receive an e-mail that has 500 recipients and was not being sent to a mailing list.
smtpd_recipient_restricitons. Not every e-mail that arrives at your server should be accepted. This parameter instructs postfix to check each message's recipient-address base on one or more criteria. One of the easiest to maintain is the access database. This file lists domains, hosts, networks and users who are allowed to receive mail from your server. To enable it: (1) set check_recipient_access = hash:access; (2) create /etc/postfix/access (do a man 5 access for format/syntax); and (3) run postmap hash:/etc/postfix/access to convert the file into a database. Repeat step (3) each time you edit /etc/postfix/access.
smtpd_sender_restrictions. By default postfix will accept SMTP connections from everybody, potentially exposing your server to SMTP relaying, a method often used for UCE perpetrators who wish to hide their identities by “bouncing” their messages off unsuspecting SMTP relayers. If this occurs, it's possible and even likely that other servers will reject e-mail from your domain(s). Other protection mechanisms lie in the fact that it is always wise to check the sender against DNS. Although this costs some performance, it makes it harder to send the information from a faulty sender e-mail address. See the file /etc/postfix/sample-smtpd.cf for a list of possible list options for this parameter. Note that hash:access is one of them; the access database can be used not only to allow/disallow particular recipients, but senders as well. For a complete list of anti-UCE parameters and their exact syntax see /etc/postfix/sample-smtpd.cf.
In order to prevent giving out information that serves no purpose to legitimate external parties, it is wise to set in the main.cf file the parameter masquerade_domains = $mydomain (remember, “$mydomain” refers to a variable). If you wish to make an exception for mail sent by “root” (probably a good idea), you can set the parameter masquerade_exceptions = root. This will cause internal host names to be stripped from FQDSes in “From” addresses of outbound messages.
Now we come to one of the groovier things we can do to secure postfix: running it in a “chroot jail”. chroot is a UNIX command that confines the “chrooted” process to a specified directory; that directory becomes “/” for that process. This usually requires you to first create copies of things needed by the process but normally kept elsewhere. For example, if the process looks for “/etc/mydaemon.conf” upon startup but is being chrooted to “/var/mydaemon”, the process will actually look for “/var/mydaemon/etc/mydaemon.conf”.
The advantage to chrooting should be obvious: should a chrooted-postfix process become hijacked somehow, the attacker will find himself in a “padded cell” from which (hopefully) no sensitive or important system files or data can be accessed. This isn't a panacea, but it significantly. increases the difficulty of exploiting postfix.
Happily, the preparations required to chroot postfix are provided in a subdirectory of the postfix documentation called “examples”. These files aren't really shell scripts: they're suggested sequences of commands.
Better still, some binary distributions of postfix have installation scripts that automatically make these preparations for you after installing postfix. In SuSE, for example, the postfix RPM package runs a script that creates a complete directory tree for postfix to use when chrooted (etc, usr, lib, and so forth) in /var/spool/postfix, with the appropriate ownerships and permissions.
In addition to “provisioning” postfix's chroot jail, you need to edit /etc/postfix/master.cf to toggle the postfix dæmons you wish to run chrooted (i.e., put a “y” in the “chroot” column of each dæmon to be chrooted). Do not, however, do this for dæmons whose “command” column indicates that they are of type “pipe” or “local”. Some binary-package distributions toggle the appropriate dæmons to chroot automatically during postfix installation (again, SuSE does).
After configuring the chroot jail and editing master.cf, all you need to do is start postfix the way you normally would: postfix start. Postfix's master process handles the actual chroot-ing.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Petros Koutoupis' RapidDisk
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- ServersCheck's Thermal Imaging Camera Sensor
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Varnish Software's Varnish Massive Storage Engine
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide