Linux Server Security: Hack and Defend by Chris Binnie Make Your Servers Invisible!

I'm delighted to be able to offer the first chapter of my new security book, Linux Server Security: Hack and Defend, for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak, walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren't discoverable on the network.


Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.



Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform


Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.


The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you're less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie's bookshelf.


Download: Linux Server Security: Hack and Defend by Chris Binnie - Chapter One - Invisibility Cloak


©2016 Chris Binnie - please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click for DevSecOps articles and free Linux tutorials on DevSecOps.cc


Troubleshooting Postfix

©2016 Chris Binnie

There are a number of Mail Servers available on the market today. Some are more confounding than others to configure but super-reliable, others are a little old-school and rely on no small degree of background knowledge prior to getting them up and running.

According to the website Mail Radar (http://www.mailradar.com) one randomised survey of 59,209 servers, which helpfully responded with a banner stating their make and model, some 24% were running the parent of all popular MTAs (Mail Transfer Agents) “Sendmail” followed by “Postfix” at 20% and “qmail” at 17%. Surprisingly almost half (48%) of the IP Addresses hosting these Mail Servers were registered to ranges in the United States.

Having used the mighty qmail, which is so efficient that it thwarted non-trivial Mail Bomb attacks in the late 1990s without breaking a sweat at an ISP that I worked for, I became a Postfix convert around the time that the most popular Linux distributions took a shine to its reliability and began including it as their default MTA.

To say that Postfix is brimming with features is an gross understatement. There’s simply too many features to cover. This powerful Mail Server can seemingly process prodigious amounts of e-mails in a highly efficient manner and still pay close attention to somewhat obscure, but very useful for some users, config options.

The main Postfix manual spanned some 8,800 words (and there are several other manuals in addition) so it’s not surprising that one of the topics that Postfix pays attention to is getting the best possible performance out of your Mail Server.

Let’s look at a few of the tips that the Postfix documentation recommends in order to get the most out of your MTA build and process e-mails more efficiently. Not all scenarios will apply to your build of course but as with all things which relate to computing the understanding of and exposure to various scenarios should help improve your ability to troubleshoot in the future. For clarity, when “clients” are mentioned they are almost always other Mail Servers and not what some might consider as Mail Clients (the ones you pick up e-mail with such as Thunderbird or Evolution etc).

Debaser

There’s a welcome file bundled with Postfix called “DEBUG_README” which cites the best routes to follow when solving an issue; it can be seen in Listing One.

* Look for obvious signs of trouble

* Debugging Postfix from inside

* Try turning off chroot operation in master.cf

* Verbose logging for specific SMTP connections

* Record the SMTP session with a network sniffer

* Making Postfix daemon programs more verbose

* Manually tracing a Postfix daemon process

* Automatically tracing a Postfix daemon process

* Running daemon programs with the interactive ddd debugger

* Running daemon programs with the interactive gdb debugger

* Running daemon programs under a non-interactive debugger

* Unreasonable behavior

* Reporting problems to postfix-users@postfix.org

Listing One: Starting from the top here is how Postfix recommends you approach troubleshooting any issues which you encounter

As we can see there’s several methods to first explore before enabling “ddd” (https://www.gnu.org/software/ddd/) and “gdb” (https://www.gnu.org/software/gdb/) debuggers.

Qshape

If you’re ever hit by a mountain-sized amount of e-mail from a particular Domain Name which has opened its Spam floodgates and haven’t set up your anti-spam filters correctly beforehand then you can use a clever tool called “qshape”. Although this tool is apparently bundled in certain older versions I couldn’t find it on my Postfix 2.6 installation so apparently this is the way forwards if you need to install it on Red Hat derivatives and Debian derivatives respectively:

# yum install postfix-perl-scripts

# apt-get install postfix-perl-scripts

Any issues with running qshape once the package is installed might be be relating to the fact that Perl isn’t installed so look into the relevant packages for your distribution if you encounter headaches. On Red Hat and its children you can reportedly achieve that very task by running this command:

# yum groupinstall perl development

Now we’ve got a working installation of qshape let us see how it works. The ever-helpful Postfix docs discuss the fact that Qshape offers a formatted table of your mail queue usage as we can see in Listing Two, having run this command (for the “hold” queue which we’ll look at closer in a moment):

# qshape -s hold | head


                         T           5 10 20 40 80 160 320 640 1280 1280+
                 TOTAL   486  0  0  1  0  0   2   4  20  40  419
           yahoo.com    14  0  0  1  0  0   0   0   1    0    12

extremepricecuts.net  13  0  0  0  0  0   0   0   2    0    11
        ms35.hinet.net   12  0  0  0  0  0   0   0   0    1    11
     winnersdaily.net   12  0  0  0  0  0   0   0   2    0    10
          hotmail.com    11  0  0  0  0  0   0   0   0    1    10
          worldnet.fr        6  0  0  0  0  0   0   0   0    0     6
       ms41.hinet.net     6  0  0  0  0  0   0   0   0    0     6
               osn.de         5  0  0  0  0  0   1   0   0    0     4

Listing Two: Results from the “hold” queue on Postfix using the helpful “qshape” tool

In Listing Two the top line showing "T" stands for the total “sender” count for each Domain Name. The manual explains that the “columns with numbers above them, show counts for messages aged fewer than that many minutes, but not younger than the age limit for the previous column.” Then if you notice the “TOTAL” count tallies up all Domain Names.

If you read Listing Two there are 14 messages which may or may not have legitimately come from “yahoo.com”. One of those messages is between 10 and 20 minutes old, one is between 320 and 640 minutes old and twelve e-mails are older than 1,280 minutes which is rapidly approaching a full day.

Hopefully the insightful qshape tool will assist with your discerning of which offenders are clogging up your Mail Server’s pipes. Having gleaned that information you can then create filters or rules to help reduce the volume of e-mails from problematic senders.

Queue Types

In Listing Two we used the “hold” queue. Postfix uses a number of different queues which offers exceptional flexibility and keeps it running efficiently. Table One shows us what each is used for.

Queue Name

Usage

incoming

This queue receives incoming e-mail either via network interfaces or by the local mail “pickup” daemon via the “maildrop” directory.

active

When Postfix’s queue manager opens an e-mail with a view to delivering it such an e-mail sits in the active queue. This queue is limited in size for performance.

deferred

If an initial effort to deliver e-mail fails to succeed then this queue picks up that e-mail. The delays between attempted retries are cleverly increased over time.

corrupt

Any e-mails which Postfix can’t read and thinks that they may be damaged or corrupt in some way are moved into this queue for inspection.

hold

If you need to manually delay either individual or volume transmissions of certain e-mails for any reason then you can set them to sit in the hold queue, essentially in jail, until you deem them publically acceptable.

Table One: The different queues which Postfix uses to assist with achieving the best efficiency

If you have a look in the “/var/spool/postfix” directory then you should see something similar to that displayed in Figure One (potentially depending on your version and distribution).

Linux Server Security

Figure One: We can see familiar directory names from the different queues Postfix uses (which would contain e-mail data if there was anything queued)

An example of an unhealthy queue is also available in the Postfix docs. The docs discuss a dictionary-based attack where multitudinous e-mail addresses are e-mailed in the hope that they are valid. We check the “deferred” queue with this command as so:

# qshape -s deferred | head

 
                                    T  5 10 20 40 80 160 320 640 1280 1280+
                    TOTAL 2193  4  4  5  8 33  56 104 205  465  1309
 
  MAILER-DAEMON 1709  4  4  5  8 33  55 101 198  452   849
     example.com          263  0  0  0  0  0   0   0   0    2   261
     example.org            209  0  0  0  0  0   1   3   6   11   188
     example.net               6  0  0  0  0  0   0   0   0    0     6
     example.edu              3  0  0  0  0  0   0   0   0    0     3
     example.gov              2  0  0  0  0  0   0   0   1    0     1
     example.mil               1  0  0  0  0  0   0   0   0    0     1

Listing Three: A mail queue after an attack which hunted for valid addresses to send Spam to

It’s important to note that a busy “deferred” mail queue is not always cause for alarm. This is especially the case if your “active” and “incoming” queues are relatively quiet so that mail deliveries can continue efficiently. In Listing Three however “MAILER-DAEMON” entries display a large number of bounces and some 849 e-mails have been sitting undelivered for some time.

As you can imagine digging out such information from the logs is a far harder challenge. The qshape tool is a welcome addition to any admin’s Postfix toolkit and comes highly recommended for a quick glance at what your MTA is up to. The installation, if it’s not bundled with your version, is worth the effort.

Having Trouble Shooting

Let’s spend a moment considering a smattering of other issues that might need looked at on an MTA.

One of the few times that you tinker with a file called “master.cf”, which is a relatively dangerous undertaking relative to other config files, is when you introduce the running of Postfix inside a chrooted environment. In other words it's when you run Postfix inside a limited environment in order that it has little chance of contaminating other parts of your system should it suffer a security compromise. The docs suggest that not managing to set up a chroot correctly is fairly common so if you have problems, it should be one of the first things that you disable if you suffer issues. Apparently the master Postfix process won’t run chrooted thanks to the fact that it is needed to spawn the other processes so don’t let that confuse you if you can’t get a chroot working. I’m guessing but this “root” privilege might be required in the same way that Apache needs the “root” user to open a privileged TCP port (where the initial process runs as “root”) and from there many child processes run as the less-privileged users “httpd” or “apache” for example.

On a separate topic in the past I’ve seen an issue where the mail logs contain lots of entries mentioning “Unknown”. If you find yourself flummoxed by such errors then rest assured that they tend to relate to a DNS lookup problems. Check that the server’s local “resolv.conf” file holds valid Name Server information or if those servers are down or misbehaving. Essentially this error means simply that no hostname resolved correctly so the machine name remains “unknown” to Postfix.

Before we take a look at how to pacify an unhappily busy Postfix instance, one which is so stressed with load that it’s creaking at the seams, we will first consider that (until recently at least) each and every SMTP connection to your MTA spawned an individual process. If your server is having a tantrum because it’s too busy then is is perfectly possible that you’re not getting the best out of your SMTP processes and there’s also a chance that the limit of the number of processes allocated is too low and needs adjusted within the “master.cf” file. Let’s look further into this issue, albeit briefly.

Although this next recommendation only applies to deprecated versions in my experience you can never predict when you might have an ancient version of a piece of software foisted upon you to fix. A somewhat older approach to machines that abused the services provided by a server was referred to as “tar-pitting”. This is where a delay was purposely introduced at the initial greeting stage. The idea was that as a result of this irritating delay the attraction of sending lots of Spam is lessened (and less profitable) as it takes much longer to send a large volume of e-mails successfully and therefore requires more resources. This was phased out in Postfix 2.0 but there is a useful setting to disable this “sleep” time. Again this is not needed from Postfix 2.1 onwards but resides in “/etc/postfix/main.cf”:

smtpd_error_sleep_time = 0

It was phased out because other anti-spam measures were successfully employed and introducing lengthier sessions to every single e-mail exchange which your server makes, on reflection, isn’t always entirely helpful.

I mention this however because a couple of clever options were spun off the basic premise of “sleeping”. I’ve used it (along with many other carefully considered options) so successfully in the past that all but every piece of Spam was caught before hitting my Inbox. Let’s look at the newer, more evolved options now.

Firstly the “smtpd_soft_error_limit” option allows us to set a limit of errors which an individual connection generates. This defaults at ten errors. If that count is reached then Postfix will delay any valid and invalid responses it sends by the value configured by the option “smtpd_error_sleep_time” in seconds (which is one second by default).

Having seen the name of the first option you might have guessed that the second option refers to “hard” limits: “smtpd_hard_error_limit”. If the default limit of twenty is hit then Postfix dutifully stops speaking to the remote server completely, throws its toys out of any nearby prams and storms off in a huff.

You’re advised to tweak and tune these error limits to suit your preferences. Of course it’s sensible to start off being less restrictive and slowly adjusting them (followed by reloading Postfix’s config each time). I have to admit that I opted for the other route (mainly because the Mail Server which I tested the config changes on only received a small amount of e-mail traffic).

Knowing that I had half an hour spare to tune the aforementioned settings to my heart’s content I introduced relatively Draconian limits (in amongst several other settings) and immediately locked out all the pesky Spam. Gingerly I opened up some of the limits and began to see Ham (legitimate e-mails) slowly return from their MTAs to retry their deliveries having been told to delay their initial attempt. After some trial and error (and only a few e-mails were ultimately delayed by five or ten minutes) I was merrily only munching on Ham and there was no Spam anywhere to be seen.

Cortisol Not Welcome

Clearly it’s really important to be able to tell when your trusty MTA is crying out for help and struggling to perform its duties. Let’s now look in a bit more detail at some warning signs and consider potential ways to mitigate issues when you spot that your server is stressed.

When there’s no stress encouraging your Mail Server to creak at the seams a standard response time is, to all intents and purposes, immediate. It’s a very snappy retort with no latency at all visible to the human eye in most cases. If there are unwieldy, sizeable attachments you may see a slight performance hit because network IO (Input/Output) and disk IO obviously need to stretch their legs, limber up and get involved to a greater extent.

For Postfix the point of no return however is when the number of SMTP clients exceeds the number of SMTP server processes. There’s a whole host of reasons why a higher volume of usual of legitimate e-mails may arrive within a short period of time. For example a Mail Server which has been unavailable for some time (due to maintenance, network outages, DNS problems or one of many other issues) might suddenly become available again and empty its previously undelivered queue. Equally of course it could be due to an attack of varying flavours and the deluge of e-mail may not be legitimate or welcome at all.

On a basic level you can probably spot a busy Postfix machine relatively easily. You can fire up a Telnet session to your Mail Server (running the command “telnet <mail.chrisbinnie.tld> 25”) and look for a slow initial response. This is where the following line is presented, replacing “mail.chrisbinnie.tld” with your MTA’s name obviously, acting as the opening gambit of the transaction:

220 mail.chrisbinnie.tld ESMTP Postfix

As we’ve said these delays might be because of DNS issues somewhere in the transaction chain and can obviously exist even when the server is running without excessive load so don’t immediately jump to conclusions.

Consider another error now. It’s possible that your logs contain multiple “lost connection after CONNECT” errors. Here a Mail Client is connecting but not completing the transaction and, frankly, just irritating your poor, old Mail Server. Note, from a security perspective, that it’s possible to attempt to tie your server in knots with many of these connections each second; you can generate this error by running a port scan for example. The clever Postfix (from version 2.3 onwards) adds a helpful reminder to your logs however to help you figure out if you’re suffering from process depletion more promptly as follows:

warning: service "smtp" (25) has reached its process limit "30": new clients may experience noticeable delays

In reality there are all sorts of reasons which could cause this issue, from saturated bandwidth, incorrect MTU, slow DNS lookups, reverse/forward DNS lookup mismatches to misconfigurations at the other end of the connection.

There’s a few things to bear at mind at your side however. These errors could potentially be a symptom of Postfix tripping over itself with any rules which process inbound e-mails before they hit its queue. If you’re stumped with what the root cause of such problems might be then look for errors and typos in your config (or switch off pre-processing to see if it fixes it). In most cases legitimate clients aren’t that likely to generate these errors so something else is to blame.

Hopefully this highly logical, supplementary comment which is apparently from the writer of Postfix, Wietse Venema, might help if you get stuck tirelessly head-scratching thanks to the appearance of such an issue:

“The client disconnected before Postfix could ask the KERNEL for the client IP address. Either your server is too slow or the client is too impatient.“

There’s additional wisdom to that comment held in greater detail here: http://postfix.1071664.n5.nabble.com/Question-about-postfix-smtpd-connect-from-unknown-unknown-td2020.html#a2021

One final thing to assert is the fact that if you server’s capacity issues are only temporary then clearly there’s much less chance of e-mails actually being lost. Retries should mean that deliveries will be successful when the condition subsides.

Destressing Yourself

From Postfix version 2.5 onwards a clever addition was added to assist with automatically mitigating stressful operating conditions. Postfix calls it “stress-adaptive behaviour” and sadly the solution only applies to your MTA and not real life, which would be welcome for many Sysadmins I’m sure.

According to the docs if your Postfix server encounters an "all server ports are busy" error then, as well as logging a warning, somewhat remarkably your trusty MTA will also actually restart itself (and without interrupting existing network sessions). When Postfix comes fully back up the eagle-eyed amongst you will spot that it has added this option to its command line options: "-o stress=yes". It would look something like this if you ran the “ps -ef” command:

1010  ??  S      11:11.11 smtpd -n smtp -t inet -u -c -o stress=yes

Should it be the cause of consternation apparently the “yes” is usually missing but otherwise “-o stress=” is present and this option only applies to public-facing services and not local ones.

This super-clever option means that a number of additional options kick in. I was genuinely intrigued when I discovered that Postfix had this undeniably sophisticated capability. Let’s look at the options it controls in more detail.

The first change it makes is that the “smtpd_timeout” option is altered when Postfix feels stressed out. Normally it would default to 300 seconds but under heavy load this will drop to just 10 seconds. This will not meet RFC rules so should only be temporarily used. Even lowered to 5 seconds means that most clients will still manage to deliver e-mail successfully and those which are too slow will retry so in theory if this is used briefly then no valuable e-mail will be lost.

Next we get seriously medieval with a command that we’ve already looked at, namely “smtpd_hard_error_limit”. The usual default value of 20 drops to just one. Very sensibly Postfix is far less sympathetic to Mail Client problems when it’s busy as you can see.

Our battle-hardened MTA also massively reduces the value for “smtpd_junk_command_limit” all the down to one instead of the default 100. Essentially this should penalise any client which tries to keep connections open. It stops them from continually bombarding your server with HELO, EHLO, NOOP, RSET, VRFY or ETRN commands.

The last three adjustments, which are deployed like chaff is used as a countermeasure, only apply to Postfix versions 2.6 upwards by all accounts. In this case Postfix alters the way that it handles the “smtpd_timeout” and “smtpd_starttls_timeout” options. Rather than focussing on a time limit for reads or writes what now becomes important is the time taken, for both sending and receiving, a complete e-mail transaction (this involves an SMTP command line, an SMTP response line and SMTP message content line or a TLS protocol message).

The second countermeasure, from version 2.6 upwards, used as a stress relief mechanism comes in the form of “smtpd_timeout” now also applying to TLS handshakes too. Here we drop to floor and offer ten push-ups instead of 300. Clearly any transaction involving encryption encourages greater server load and again there should be retries so that no e-mail is lost should an e-mail take more than ten seconds.

The third option enforces a strict option where Postfix won’t wait for six seconds for an address verification probe. An explanation of how it works from the unerring docs: “Address verification is a feature that allows the Postfix SMTP server to block a sender (MAIL FROM) or recipient (RCPT TO) address until the address has been verified to be deliverable.” Again the functionality is very clever; (much) more information is available here: http://www.postfix.org/ADDRESS_VERIFICATION_README.html

The long and short of using this setting under heavy load is that if the result is not already in the address verification cache, reply immediately with “unverified_recipient_tempfail_action” or “unverified_sender_tempfail_action”. If this option is a used as a temporary countermeasure e-mail should arrive after retries kick in. I would encourage a quick read of that URL above for more detail.

Permanence

What about if you encounter ongoing load issues and you can’t bump up your server specification or bandwidth? Let’s consider a few options to assist in making useful changes permanent.

Think back to the "all server processes busy" error again for a moment. To mitigate the effects of that particular issue we need to increase the number of SMTP processes. I’m sure that you won’t be surprised to read that Postfix appears to prefer, by default, not to aim for world domination and utilise every possible last modicum of system resource but instead it prefers to take a considerate approach. Let’s look at hogging more of your server's overall resources in order to meet the demands of more simultaneous client connections.

We’ll avoid tinkering with the “master.cf” file and ignore the optional way to achieving this outcome via that route (it’s considerably easier to break Postfix). Instead we edit or add the “default_process_limit” option in “main.cf” adding a higher value as we do so. A reminder to execute a reload following this change:

# postfix reload

The docs warn that you need Postfix version 2.4 or higher to configure over 1,000 processes (and an Operating System which supports BSD kqueue(2), Linux epoll(4), or Solaris “/dev/poll”) and that adding more processes soaks up more of your precious RAM so tread carefully.

You can apparently reduce the RAM hit by opting for “cdb” lookup tables instead of other alternatives such as Berkeley DB's hash table format. One quick caveat, in case you’re using a relatively old version, is that the “SMTPD_POLICY_README” might contain misleading information relating to fixed daemon processes so even if you can’t install the latest version, view it’s README file.

If you’re in an unhappy job and want to spend less time with the clients which pester you  then you can of course limit your server’s attention span instead of bumping your RAM usage up.

A popular addition to “greylisting” (an invaluable anti-spam measure) is to use Realtime Black Lists (RBLs), also called Realtime Blackhole Lists, which need to perform a remote, third-party lookup before an incoming e-mail is deemed acceptable.

It’s common to add several RBLs to your configuration but over time some of these blacklists are closed down or no longer useful due to containing obsolete, dated information. Additionally it’s quite possible that you are duplicating your RBLs lookups because a provider, such as the excellent SpamHaus (https://www.spamhaus.org), offers several blacklists in a combined format. The Postfix docs recommend disabling both obsolete RBL and duplicated RBLs in order to remove their lookup times and therefore the time you spend on each transaction.

An (incomplete) example of how efficient Postfix is with RBL follows. Here we are actually only querying the same RBL once with one lookup despite the repetition (added to your “main.cf” file again):

smtpd_client_restrictions =
       permit_mynetworks
       reject_rbl_client zen.spamhaus.org=127.0.0.10
       reject_rbl_client zen.spamhaus.org=127.0.0.11
       reject_rbl_client zen.spamhaus.org

Additionally if you add rules for checking e-mail headers to a greater degree than is usual then it’s more efficient to combine them as opposed to have them spread out in your config file as individual rules. The docs suggest this approach in the “/etc/postfix/header_checks” file:


if /^Subject:/
  /^Subject: virus found in mail from you/ reject
  /^Subject: ..other../ reject

endif

As you can see more than one rule is held within one “if” statement to expedite its processing time.

Innately Suspicious

When your MTA is stressed out you might adopt a much stricter stance so that any machine connecting to you, which sniffs only a little of potentially being suspicious, is presented with a cold shoulder.

We can use the SMTP 521 error code which returns a response saying that a certain Domain Name does not accept e-mail as per RFC 1846 (https://www.ietf.org/rfc/rfc1846.txt). This applies to newer versions of Postfix (2.6 onwards) and other codes are used in earlier versions. The sophisticated Postfix dutifully rejects the e-mail and then stubbornly disconnects. This is Postfix acting as intransigent as it gets; there’s no patience and the connection is dropped even without receiving a remote QUIT command.

Testing

Earlier I mentioned that it is very easy to cause your Postfix build headaches if you break the “master.cf” file. We need to edit it for these next two tweaks (carefully).

You can force Postfix into, what I refer to as, overload-mode (where it deploys its countermeasures to combat stress) by diligently adding a line to the “master.cf” file. Introducing “-o stress=yes” as an option will enable that mode as is shown in Listing Four:

# ==========================================================================

# service type  private unpriv  chroot  wakeup  maxproc command + args

#               (yes)   (yes)   (yes)   (never) (100)

# ==========================================================================

smtp      inet  n       -       n       -       -       smtpd

      -o stress=yes
     -o . . .

Listing Four: Enabling countermeasures manually which usually Postfix will do automagically when it is under heavy load

After making the changes in Listing Four then please remember to run this command:

# postfix reload

Conversely if you would prefer to never allow automatic stress-adaptive behaviour then you simply alter “master.cf” as seen in Listing Five.

# =============================================================
# service type  private unpriv  chroot  wakeup  maxproc command
# =============================================================
#
 submission inet n       -       n       -       -       smtpd
        -o stress=
        -o . . .

Listing Five: Never permit Postfix’s anti-stress mode to automatically kick in

Essentially we’re adding the option but leaving it empty. A reminder again to run a config reload after deploying the changes which we can see in Listing Five.

Flesh Eating

Sadly botnets continue to remain popular and spambots also continue to relentlessly hammer poor, unsuspecting Mail Servers. As they search tirelessly looking for the latest place to deposit their unwelcome payloads clearly it’s important that MTAs evolve to keep up. As of Postfix 2.8 the “postscreen” command was introduced to help mitigate spambots. It cleverly achieves its welcome effects by handling several SMTP connections within just one system process apparently.

The efficacious “postscreen” keeps track of connections by using its own whitelist for clients which  have been proven valid previously by passing a series of connection-related checks. It then remembers IP Addresses within its whitelist and if it deems one such machine is friend and not foe then it will push through the e-mail delivery onto an SMTP process. This cache of friendly IP Addresses cuts down on how much effort that Postfix applies to each valid e-mail as a result, thus reducing load and delivery times. If you would like to read more about this clever addition to Postfix then the manual can be found here: http://www.postfix.org/postscreen.8.html

EOF

Tempting as it is to continue exploring the many other options which Postfix includes unfortunately there are simply too many to cover.

What with debugging, automatic stress-adaptive functionality and briefly touching upon “postscreen” we haven’t really done the powerhouse that is Postfix any justice at all. The quality of the features included with Postfix, its reliability and the sheer volume of choices available in how you deploy the superior MTA make the subject sizeable to say the least.

The next time that you encounter a config mistake, an unwelcome zombie attack or if you indeed simply need to check how your mail queue is performing then, having read this overview, hopefully you’re now armed with the information required to make headway.

Linux Servers and Security Howtos - Chris Binnie - Linux Server Tutorial

Linux Server Security: Hack and Defend by Chris Binnie Make Your Servers Invisible!

I'm delighted to be able to offer the first chapter of my new security book, Linux Server Security: Hack and Defend, for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak, walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren't discoverable on the network.


Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.



Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform


Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.


The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you're less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie's bookshelf.


Download: Linux Server Security: Hack and Defend by Chris Binnie - Chapter One - Invisibility Cloak


©2016 Chris Binnie - please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click for DevSecOps articles and free Linux tutorials on DevSecOps.cc