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


Fast Forward E-mail

©2016 Chris Binnie

These days more people than ever feel compelled to get their e-mail fixed super-swiftly if it ever fails. When used several times a day, every day of the year, some of us feel truly bereft when e-mail isn’t available to us. There’s even recognised medical conditions relating to those who obsessively check their e-mails, forcing cognitive failures (whatever they may be) as they do so.

Clearly it’s important to set up your Mail Servers robustly in order to avoid a barrage of complaints from your users; even if an issue is caused by something out of your remit, upstream, as opposed to locally.

One of the original Internet services was SMTP (the Simple Mail Transfer Protocol). Within its original RFC (Request For Comments 821: https://www.ietf.org/rfc/rfc821.txt) which was published in August 1982 there was lots of forward planning and most likely as a result it remains one of the fundamental cornerstones of the Internet that we know and love today. A reminder of how a typical SMTP transaction looks is visible within the RFC itself:

Example of the SMTP Procedure

This SMTP example shows mail sent by Smith at host Alpha.ARPA,
to Jones, Green, and Brown at host Beta.ARPA.  Here we assume
that host Alpha contacts host Beta directly.

           S: MAIL FROM:<Smith@Alpha.ARPA>
           R: 250 OK

           S: RCPT TO:<Jones@Beta.ARPA>
           R: 250 OK

           S: RCPT TO:<Green@Beta.ARPA>
           R: 550 No such user here

           S: RCPT TO:<Brown@Beta.ARPA>
           R: 250 OK

           S: DATA
           R: 354 Start mail input; end with <CRLF>.<CRLF>
           S: Blah blah blah...
           S: ...etc. etc. etc.
           S: <CRLF>.<CRLF>
           R: 250 OK

        The mail has now been accepted for Jones and Brown.  Green did
        not have a mailbox at host Beta.

Figure One: Example SMTP transaction as found at: https://www.ietf.org/rfc/rfc821.txt

As intimated in Figure One there are actually only a handful of commands used in sending an e-mail. Let’s not forget everyone’s favourite “hello” command of course, namely the “HELO” command which initiates a connection, whereas “QUIT” closes it. The “HELO” command is as straightforward as this:

HELO chrisbinnie.tld

With the above line we are simply saying “Hi, I’m a Mail Server called chrisbinnie.tld” as the opening gambit in an e-mail exchange.

As simple, as the “simple” in SMTP is however, sometimes the server and client software involved in forwarding and receiving e-mails isn’t quite as straightforward as you might think.

Let’s have a quick look at getting the sending of outbound e-mails working from the command line and then we’ll explore an overview of a very popular Mail Server.


Command Line SMTP

Sometimes, when testing a Mail Server’s installation, you need to send e-mails directly from the command line. When you’re not testing you might also need the same functionality from within system scripts. Let us briefly look at a miniscule package that is useful to have sitting alongside a Mail Server which fulfils that very requirement.

If you’re using any derivatives of Debbie and Ian’s favourite Linux distribution then you can install an outbound e-mail tool, run from the command line, to assist you in your testing endeavours as so:

# apt-get install heirloom-mailx

There’s a lot of history behind the “mail” and “mailx” packages, which is so far-reaching and detailed that we’ll save it for another day, but trust me when I say that you are likely to have success on some, if not all, Red Hat derivatives by using the following command to install the package rather than using the Debian package name as so:

# yum install mailx

Now that’s installed, here is a simple example of how we can send e-mail directly from the command line. The functionality which we have at our fingertips is not just that of the old style “mail” command (as truly clever as it was upon release) but instead we can also manipulate a number of other e-mail related tweaks too.

# mailx -r 'script@binnie.tld' -s 'Subject Line' -a '/fullpath/.bashrc' -S 'smtp=localhost' 'chris@binnie.tld'

Having looked at our example you can clearly see that we can alter the “-r” option to change which “from line” is presented to the mail client when the e-mail is picked up at the other end. This is sometimes surprisingly difficult to get working with other command line Mail Clients so cherish the moment as a test e-mail arrives in your inbox and it doesn’t say that it’s been sent by “root@localhost” or something equally disappointing.

Hopefully the other options are equally easy to follow. The “-s” option lets you edit your e-mail’s subject whereas “-a” is the filename of your attachment. You might need to compress the file if the plain text file arrives with extra carriage returns. Also ensure that you’re definitely using the full path to the file if you have other issues with attachments. The above “mailx” command example can either be completed with “< /dev/null” appended to the end or by manually typing a dot and then hitting the Enter key. This dot acts as an End Of File (EOF) marker and is used to populate the body of the e-mail with some content, even if the content is non-existent. Here’s an example of that full command, without an attachment, for ease of reading:

# mailx -r 'script@binnie.tld' -s 'Subject Line' -S 'smtp=localhost' 'chris@binnie.tld' < /dev/null

You can see that we’re using “/dev/null” to populate an empty e-mail body to save you interacting further with the software once you’ve hit the Enter key. Don’t be concerned if you see a warning of little consequence such as “Null body. Hope that’s okay.” which is helpfully telling you that there’s no content to the e-mail, just headers and a subject line.

Undisputed Heavyweight Champion

On now to the star of the show, our Mail Server. The rocket-fueled MTA (Mail Transfer Agent) that is Postfix (http://www.postfix.org) has such a wide array of features that quite honestly it’s a struggle to know where to begin. However starting with an overview of a handful of its features might help introduce them to any newcomers and additionally act as a refresher to anyone that’s used them before.

Rather than relying on an ISP’s SMTP Servers let’s have a quick look at running your own. Postfix was written by the award-winning programmer and physicist Wietse Venema, who brought us other excellent software packages such as TCP Wrappers and security tool SATAN (Security Administrator Tool for Analyzing Networks - http://www.porcupine.org/satan). The highly performant Postfix rapidly became my MTA of choice when I discovered it, having used “qmail” (http://www.qmail.org) for years. Indeed it became the default MTA on a number of the larger Linux distributions shortly afterwards too. This is of benefit to anyone looking for a well-supported piece of software, with ever-increasing levels of unofficial online documentation, to help you solve a tricky problem.

I’m certain that one of the reasons that Postfix gained popularity was that even straight out of the box it’s relatively secure and should meet most people’s needs. As with many powerful software packages there’s a multitudinous array of features which range from the abstract, and therefore rarely needed, to those which many people will want to use.

I find that even when delving much deeper into the more complex facets of Postfix it’s remarkably difficult to get lost inside its config thanks to its undeniable simplicity. The installation of this powerhouse won’t keep you up at night either I’m sure that you’ll be glad to hear. Simply use the correct commands for either Debian or Red Hat derivatives respectively as shown below:

# apt-get install postfix

# yum install postfix

From the console itself you’ll see a handful of colourful ANSI menu screens. Amongst other easy questions you need to answer when you’re asked you should choose “Internet Site” and then enter your Mail Server’s fully qualified hostname, including your Domain Name such as this example shows:

mail.chrisbinnie.tld

To all intents and purposes you’re up and running having followed those remarkably simple installation steps. Let’s however look at the main config file “/etc/postfix/main.cf” to get our bearings.

Upon opening that file you’re dutifully reminded that only a tiny percentage of the mammoth number of features available to Postfix are mentioned within it by default. You can query its many “postconf” options inside the manual as so:

# man 5 postconf

If you’re sitting down and not prone to any sudden heart issues then I’ll surprise you with the fact that there’s around 8,800 lines of content in that single manual alone and Postfix uses several additional manuals too. The extensive, (almost entirely) crystal clear documentation (which is also found online at http://www.postfix.org/documentation.html) is exceptionally readable and the simplicity of the config very rarely trips you up with its dependencies. This is a far cry from other MTAs I’ve battled with in the past and there’s no doubt Postfix should be heralded as a shining beacon of usability and functionality. Needless to say that it’s popularity speaks volumes.

Incidentally if you’re using Debian, or of course one of its derivatives like Ubuntu Linux, then if you mess up the installation steps you can always re-run the initialisation of Postfix like so:

# dpkg-reconfigure postfix

On Red Hat derivatives apparently there isn’t a generic reconfiguration utility however some packages do offer similar support to help effectively reconfigure a piece of software’s basic configuration options from scratch; a little like a factory-reset I suppose, despite maintaining other config options afterwards.

Lay Of The Land

Now that we’ve got a working Mail Server we can forge ahead and examine some of its config. However before we do that consider another scenario briefly, partly to introduce Postfix’s preferred config syntax and also to see how to refresh Postfix after you’ve made any changes.

If you ever felt the need to only set up a Mail Server to send outbound e-mails from your localhost address (to avoid exposing an MTA on an external IP Address for example and/or running a fully configured MTA) then read on. You might want to do this in order to only allow software installed on your server to send outbound e-mails for example too. Think of it as a mini installation of sorts.

With Postfix this is quite possible to achieve with a simple change to your config file. Begin by making sure that his line appears as so:

inet_interfaces = localhost

As you can see there’s simply a “key: value” style of config formatting. It’s usual to separate multiple entries with commas. Add a space after the commas and it makes more sense when reading it back later on.

For comparison, by default, that setting would usually look like this:

inet_interfaces = all

Populating that key with multiple values (according to the online docs here: http://www.postfix.org/postconf.5.html#inet_interfaces) might look like this for example:

inet_interfaces = 10.10.10.1, 127.0.0.1, [::1]

As you can see the entries sit nicely separated by commas and spaces. The final entry is the IPv4 “localhost” equivalent on IPv6 (and only applies to Postfix 2.2 onwards apparently).

There’s a good chance that you can simply reload Postfix after making changes, to only introduce a tiny pause in service, as opposed to a full restart. If I’m not sure I tend to try a reload first, especially on busy production servers. Typically config changes that need a restart (if my memory serves, they’re not needed that often) might be bigger alterations such as renewing expired TLS (Transport Layer Support) certificates and the likes.

If you’re on a “systemd” Operating System then you can reload and restart Postfix respectively as so (or use “service postfix restart” or ““service postfix reload” or their equivalents):

# systemctl reload postfix

# systemctl restart postfix

Since we now have a functioning Mail Server by using the magical “mailx” you can now send a test e-mail, using a command along these lines:

# mail -s “Local Outbound SMTP Test” chris@chrisbinnie.tld < /dev/null

The body of the e-mail will be empty (thanks to the null content from “/dev/null”). Otherwise hopefully your Inbox is now in receipt of a test e-mail.

E-mail Aliases

My first professional introduction to serving HTTP was via the clever Roxen Web Server (http://www.roxen.com) when I worked for an ISP during early 1997 and one of the first elements of an MTA that I maintained (using the mighty “qmail”) was its E-mail Aliases. The premise of E-mail Forwarding (or Aliasing) is super simple but I remember that some customers couldn’t immediately get their heads around it, possibly because public e-mail was relatively new. For the sake of those new to the idea, here’s the basics. Apologies to those who aren’t.

Imagine you own a Domain Name, we’ll use “chrisbinnie.tld”, and you want to send and receive e-mail from your Gmail account using that Domain Name.

You’ll firstly want to change your “From” line or sender address inside Gmail’s settings to make sure that your e-mails look as if they come the e-mail address held under your Domain Name, such as “chris@chrisbinnie.tld”.

The other element of getting this to work is obviously dealing with inbound e-mails when they are are sent to “chris@chrisbinnie.tld”. The Web Hosting company (or ISP) which looks after your Domain Name needs to forward your e-mails sent to “chris@chrisbinnie.tld” onto your Gmail address. I told you it was simple.

Without running an unwieldy mailing list you can also add lots of people to an E-mail Alias. Imagine you’ve got ten Sysadmins in a department and everyone wants a copy of the daily sarcasm-fueled humour sent to “admins-are-better-than-devs@company.tld”.

Postfix uses old-school Sendmail formatting to add a few simple aliases. This isn’t very effective for many aliases but in this case we need to add a line or two to the file “/etc/aliases”. Note that whenever we make a change to this file we need to run this command:

# newaliases

Alternatively, run this command, Postfix-style to achieve exactly the same thing:

# postalias /etc/aliases

Let’s make sure that all of the “root” user e-mail (the key system e-mails in other words) are forwarded to the user “chrisbinnie”. Simply edit the “/etc/aliases” file and alter the pertinent line so that it looks like this:

root:          chrisbinnie

That line is commented out at the foot of the file in my version and thankfully it’s intuitively formatted so it shouldn’t present any issues. Remember to run “newaliases” or its equivalent afterwards.

The mighty “sendmail” uses “.forward” files to create e-mail aliasing possible and the venerable qmail uses this format: “.qmail-ALIASNAME”. If you have the basic premise of e-mail forwarding and aliasing covered then they’re easy to use.

With qmail for example if e-mail is routed to your home directory for the an e-mail address beginning “support@” then inside our “.qmail-support” file we could add a few e-mail addresses, something like this:

phillipe@chrisbinnie.tld

daniel@chrisbinnie.tld

christian@chrisbinnie.tld

roberto@chrisbinnie.tld

Postfix Aliases

Onto a more industrial approach to aliases now. As you would expect Postfix’s aliases are typically easy to get your head around. Let’s have a look at them now. Sometimes the extensive online Postfix documentation refers to the same aliasing or forwarding functionality with different names such as “address rewriting” in case it trips you up. Additionally “database” and “lookup table” are frequently interchangeable it seems.

You begin by declaring which Domain Name you want to add a list of “virtual users” to (e-mail aliases in other words), inside the main configuration file. If you’ve forgotten the file lives at “/etc/postfix/main.cf” and the line you need to append would look like this, where “chrisbinnie.tld” is your Domain Name obviously:

virtual_alias_domains = chrisbinnie.tld

Simply separate multiple Domain Names with a comma and a space for better readability. Incidentally Postfix makes a big deal about the “mydestination” variable (which Domain Names that it will accept e-mail for) and it’s important to never add a “virtual_alias_domain” as a entry to “mydestination” or (very) bad things, think along the lines of Ghostbusters crossing the streams, will happen.

Next we need to create our virtual users file which we’ll “hash” in order to make it much more efficient as it grows lengthy. Imagine that for some insane reason an ISP doesn’t use an external database server like MySQL to house all of its aliases for a shared Domain Name. That flat aliases file could grow to tens of thousands of lines so it has to be efficient. More on this subject in a moment.

Even though we haven’t got thousands of entries we can create the file “/etc/postfix/virtual” and merrily populate it with our e-mail forwarding information.

We’ll mention this again in a moment  

######## chrisbinnie.tld aliases ########


postmaster@chrisbinnie.tld      postmaster
info@chrisbinnie.tld                 luis
sales@chrisbinnie.tld              lionel
support@chrisbinnie.tld           neymar, xavi@barca.tld, victor, cesc, carlos, gerard, jordi

### Catch-all address - use with caution ###

# @chrisbinnie.tld                           andres

Listing One: Our e-mail aliases file contents

As we can see in Listing One we can forward one address to another with ease. Again with the comma separation we can add multiple entries to one alias. Let’s consider an external address to our Domain Name too. We can force address redirection, sorry “forward”, e-mail like so:

support@chrisbinnie.tld           chrisbinnie@linux.tld

We now need to nip back to our main config file (“/etc/main.cf”) and add this line next to the Domain Name line we just added for clarity:

virtual_alias_maps = hash:/etc/postfix/virtual

We need to create an efficient “hash” file of our Postfix config. We’ve chosen “hash” because it’s used at length in the comprehensive Postfix documentation. I can tell that my current system will allow me to hash a file (which means that it supports Berkeley DB databases) and create a hashed version of my config file adding a “.db” extension to it but retaining the same name thanks to the results of this command:

# postconf -m

btree

cidr

environ

hash

ldap

mysql

nis

pcre

proxy

regexp

static

unix

I mentioned that we’d look at remote Virtual User lookups using a non-local Database Server. The machine which I’m working on can support lots of different database types so you can alter that easily if you have a preference, including network databases. You’re encouraged to get local config working before diving into serving network information back to Postfix. You can test if your remote, network config achieves the same results as your local files as so with this LDAP (Lightweight Directory Access Protocol) example:

# postmap -q support@chrisbinnie.tld ldap:/etc/postfix/virtual.cf

Incidentally when we’re updating our config files the clever Postfix used to make sure that conflicts are avoided by using file locking. Apparently however Berkeley DB has evolved into a more aggressive beast which utilises caching to a greater extent. To help get around this (infrequent issue) you are encouraged by the online documentation to follow a step similar to the one which follows:

# postmap access.in && mv access.in.db access.db

Before you do however the sophisticated Postfix realises that the typing of this command could lead to an unwelcome degree of tedium and to counter this issue introduced a “Makefile” to circumvent the pain. After editing your aliases config you now simply type “make” to skip, fast-footed past any conflicts.

# make
postmap access.in
mv access.in.db access.db

The addition of the “make” command means Postfix is also wise enough only to update files which have changed and it additionally includes some welcome error checking too.

Clarity

We mentioned the old-school “/etc/aliases” file earlier before looking at Postfix’s virtual users. In case you become rattled and perplexed by the differences between the two let’s have a quick look now.

Postfix makes a somewhat conciliatory attempt to include the otherwise directly accessible “/etc/aliases” file available within its configs like so in the “/etc/postfix/main.cf”:

alias_maps = hash:/etc/aliases

The main differences are that the “alias_maps” option only applies to local deliveries therefore as a result the Domain Name element of an email address is discarded and only the prepended part before the “@” sign, such as “chris@” is checked against. You might forward an e-mail received using this method or do some other filesystem-based work like filter it before a local mailbox delivery.

In contrast the “virtual_alias_maps” option does pay heed to Domain Names. This option is all about the processing of Internet-friendly addresses and not local ones. Valid recipients Domain Names will match “username@local_machine_name” when “local_machine_name” is equal to $myorigin in your config. Or if “local_machine_name” is present in $mydestination or when it is listed in $inet_interfaces or $proxy_interfaces. Think of it effectively overlapping with the “/etc/aliases” file functionality and being useful for more than a few local alias changes.

Error Checking

The final steps to set your altered virtual user files live are simply these, starting with:

# postmap /etc/postfix/virtual

This creates a “.db” hashed version of what is essentially a “.cf” config file (even if you haven’t explicitly named it as much). The clever Postfix just needs to know the root of the name and by prepending “hash:” to the “hash:/etc/postfix/virtual“ entry in your main config file it knows not to look for the “.cf” version but rather the “.db” equivalent for translation.

It’s useful to also know that when you update your file the “postmap” command will look for a “key: value” style of format, in two columns and complain if you’ve missed an entry. For example if a row contains an alias name but not a destination and only contains one column you’ll get a failure notification.

# postfix reload

You now have two guesses as to what we’re doing in the final step above, having made those changes to our config files.

There May Be Trouble Ahead

To assist with troubleshooting the magical Postfix offers a welcome degree of help. Firstly you can run a standard Unix-type command to look in its logs, by using syntax along these lines:

# cat /var/log/mail.log | grep '(warning|error|fatal|panic):' | less +G -n

In Table One we can see the common types of errors along with a description of what they refer to.

Error Type

Description

panic

Consider this a critical fault which only a skilled coder can assist with. This is not a welcome error by any means and Postfix will halt having thrown all of its toys out of any nearby prams.

fatal

The common causes of a “fatal” error tend to be the result of missing files, broken permissions or some other config issue. Check your configuration and try starting up Postfix again. You will need to remedy the issue if you want Postfix to launch properly.

error

This indicates an error of varying types. Should a superstitious thirteen errors be encountered then Postfix will terminate and Skynet will take over.

warning

Any “warning” might be, as you would expect, an indication of an issue but not necessarily one which will cause you headaches in the immediate future.

One Postfix troubleshooting tool is a command that displays the default Postfix config so you can reference how things were previously configured if something is broken.

# postconf -d

Be warned that you’ll have screeds of config options scroll up your screen after running this.

Now onto my favourite troubleshooting command. When debugging it's highly useful to be able to display what changes you have made against prebuilt default values which are displayed with the above command. These are explicitly visible in the config file "/etc/postfix/main.cf" if I'm reading the docs correctly so you can hopefully correct mistakes there in the majority of cases. You can achieve this by running this exceptionally useful command as so:

# postconf -n

What about your queued e-mails? If you wanted to monitor any mails stuck in your queue then you can achieve this easily with this command:

# postqueue -p

An alternative is "mailq" (old-school sendmail style again) but I try to use the former to keep in with the other Postfix command names.

Running such a command might give you a response like this multiplied by the number of e-mails in yor queue obviously:

-Queue ID-       --Size-- ----Arrival Time---- -Sender/Recipient-------

3ED1624E13    12512 Thu Nov 11 11:11:11  support@chrisbinnie.tld

(connect to alt1.gmail-smtp-in.l.google.com[2607:f8b0:4002:c03::1b]:25: Connection timed out)

                                                                  linux-rules@gmail.com

You can process your MTA’s queue there and then (or “flush” the queue) by running this command:

# postqueue -f

The sendmail equivalent of “sendmail -q” (or equally “postfix flush” or “postfix -f”) is very similar and forces the MTA to try and send the mails in the queue again. I mentioned that Postfix has lots of options and I wasn’t exaggerating, there’s even a way of only allowing certain users to flush the queue from within your main config file:

authorized_flush_users

A minor caveat contained in the docs in relation to flushing the queue too often reads as follows:

“Warning: flushing undeliverable mail frequently will result in poor delivery performance of all other mail.”

As a last resort if you ever (really, really) need to delete your entire mail queue then you can run this devastatingly destructive command as follows:

# postsuper -d ALL

A more suitable approach is to reference an e-mail’s unique ID in the column shown as “Queue ID” above and then delete individual problem mails that may never be delivered for some reason but are slowing down your Mail Server (they could have very large attachments for example).

# postsuper -d 3ED1624E13

Needless to say there’s also a plethora of queue purging, queue length and allowed inbound e-mail size options available in addition if you want to tweak away to your heart’s content.

Summary

From the original SMTP handshakes to old-school E-mail Aliases and Postfix’s address redirection we’ve covered how to get up and running with virtual domains and virtual users in Postfix.

Trust me when I saw that we’ve only touched upon a tiny percentage of the excellent Postfix’s features however. There’s a mountain-sized number of features which we haven’t looked at. The next step would most likely be to get Virtual Mailboxes (which means that your e-mail users don’t need shell account access to your server to pick up their e-mail).

Linux Server Security

Figure Two: An abbreviated list of just some of the many functions available via the remarkable Postfix proving that there’s still lots more to learn about this excellent MTA

An abbreviated list (there are many more) of some of the many functions which Postfix offers can be seen in Figure Two. I would encourage you to look some of them up and experiment further with others in order to get the most from the exceptionally powerful MTA that is Postfix.

With this newly-found knowledge I trust your e-mail remains as robust a service as your users wish it to be.

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