Linux Server Security

Hack and Defend

Chris Binnie

• Publisher: Wiley
• Year: 2016
• Print ISBN: 9781119277651
• eBook ISBN: 9781119277644
• Edition: 1
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

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.

• Master hacking tools and launch sophisticated attacks: perform SQL injections, deploy multiple server exploits and crack complex passwords.
• Defend systems and networks: make your servers invisible, be confident of your security with penetration testing and repel unwelcome attackers.
• Increase your background knowledge of attacks on systems and networks and improve all-important practical skills required to secure any Linux server.

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.

Chapter 1
Invisibility Cloak

Imagine that you could hide a server from the Internet but still have access to your ISP's superior bandwidth. Without making any changes, you would be able to securely use it as a file repository, among many other things.

You'd also have full access to the command line so that you could start and stop or even install any services that you wanted to use. The choice would be yours, whether you ran those services briefly and then closed them down, or left them running and visible to the outside world for a period of time.

This is possible to achieve using a technique called port knocking. You can disguise your server by closing all network ports to the outside world, genuinely making it invisible. The single port that you might choose to open up at will, by using a prearranged “door-knock,” could be for your SSH server or for some other service. In this chapter, you'll see how you can create an invisible server along with some options that you might want to consider.

Background

By disguising the very existence of a server on the Internet, at best you can run a machine in private, and at worst, even if its existence is known, you will reduce the attack surface that an attacker can target by limiting the time ports are open and even partially visible.

Probing Ports

Before beginning, let's take a closer look at network ports on a server, so you'll have a frame of reference. If you've ever used security tools such as Nmap, then you may be familiar with the initially confusing premise that some ports appear to be closed when in fact they are not. Nmap makes the distinction between whether a nonopen port has a service (a daemon) listening behind it or not.

Nmap refers to closed ports as those that don't have a daemon listening behind them but do appear to be open or at least potentially available. If Nmap refers to filtered ports, it means that a firewall of some kind is preventing access to the IP address that is scanning the system in question. This is partly to do with TCP RST packets, and there are also three other states that Nmap reports back on: unfiltered, open|filtered, and closed|filtered. If you want more information on how these states are different, go to https://nmap.org/book/man-port-scanning-basics.html.

Confusing a Port Scanner

Now that you know how ports may present themselves to port scanners, let's look at how to obfuscate the response you give back in order to confuse sophisticated port scanning techniques. The most obvious tool of choice, thanks to its powerful feature set, would be the kernel-based firewall Netfilter, more commonly known as iptables.

Here's how it works. For TCP packets, you want to manipulate how you respond to port probes by using iptables to generate a REJECT request. For other protocols you want to simply DROP the packets. This way, you get closed, not filtered, responses from Nmap. Based on what I've gathered from most online opinions (and it seems that this argument is both contentious and changeable), a closed port is the best response that you can hope for. This is because you're not openly admitting to blocking any ports with a firewall, nor is the port simply open because a daemon is running behind it.

To explain a little further, under normal circumstances, an unreachable port would usually generate an ICMP Port Unreachable response. You don't want these errors to be generated, however, because that would mean a server was listening on that port in the first place and you would give your server's presence away. The tweaked REJECT response that you want to generate instead is applied as follows:—reject-with tcp-reset. This helps you to respond as if the port were unused and closed, and also not filtered.

You simply append this snippet to the end of each of your iptables rules:

-j REJECT—reject-with tcp-reset

By using this technique, you're simply making sure you're not giving away unnecessary information about your system.

Note that in the port knocking example that you're about to look at, you won't be using that iptables option. This is because you won't be running additional services to your SSH server. However, this background information will help you understand how an attacker might approach a machine's ports and how you can apply a—reject-with tcp-reset option to other services.

There is some debate about using iptables DROP versus REJECT responses in your rules. If you're interested, you'll find some insightful information on the subject at

www.chiark.greenend.org.uk/∼peterb/network/drop-vs-reject.

Installing knockd

Now that you are armed with some useful background information, I'll walk you through how to install a port knocker on your server. As we continue you might consider which services you may wish to run hidden from the Internet at large. There might be an occasion to run a web server or a mail server on an unusual port for a few hours, for example.

Packages

Let's look at installing the package that will give your system port knocking functionality. Called knockd, this package is installed in different ways depending on your system.

On Debian derivatives you install the package as follows:

# apt-get install knockd

On Red Hat derivatives you install it as follows:

# yum install knockd

A main config file controls most of the config required for knockd. On a Debian Jessie server, this file resides at /etc/knockd.conf. Take a look at Listing 1.1, which shows my main config file, to see how knockd works.

---

Listing 1.1 The main config file. The port sequences and (importantly) -I INPUT have been altered from the defaults

[options] UseSyslog [openSSH] sequence = 6,1450,8156,22045,23501,24691 seq_timeout = 5 command = /sbin/iptables -I INPUT -s %IP% -p tcp—dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 3011,6145,7298 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp—dport 22 -j ACCEPT tcpflags = syn

---

Changing Default Settings

In Listing 1.1, you can see a section for setting up your options at the top. The other two sections are the actions that you want to perform when knockd opens up SSH access or when you shut down your port access. Both sections also include the default port knocking sequence to trigger those actions under the sequence option. After installing knockd, I immediately changed those ports from the defaults to avoid reducing the effectiveness of my server security. The defaults are ports 7000, 8000, and 9000 to open up SSH access and ports 9000, 8000, 7000 to close access. As you can see, I've added more ports to open up the access so someone will be less...

Table of contents

• Cover
• Introduction
• Chapter 1: Invisibility Cloak
• Chapter 2: Digitally Fingerprint Your Files
• Chapter 3: Twenty-First-Century Netcat
• Chapter 4: Denying Service
• Chapter 5: Nping
• Chapter 6: Logging Reconnoiters
• Chapter 7: Nmap's Prodigious NSE
• Chapter 8: Malware Detection
• Chapter 9: Password Cracking with Hashcat
• Chapter 10: SQL Injection Attacks
• End User License Agreement