The first configuration to be performed on any new server—especially any server with any exposure
(direct or indirect) to the public Internet)—is a security configuration.
There are nine basic measures to ensure servers are secure from unauthorized access or intercepted
communications:
1. Use secure and encrypted communication.
2. Disable root login and use Sudo.
3. Remove unused software, open only required ports.
4. Use the principle of least privilege.
5. Update the OS and installed software.
6. Use a properly-configured firewall.
7. Make sure log files are populated and rotated.
8. Monitor logins and block suspect IP addresses.
9. Use SELinux (Security-Enhanced Linux).
Your infrastructure is as weak as the weakest server; in many high-profile security breaches, one poorly-secured server acts as a gateway into the rest of the network. Don’t let your servers be those servers! Good security also helps you achieve the holy grail of system administration—100% uptime. In this chapter, you’ll learn about Linux security and how Ansible helps secure your servers,
following the basic topics above.
A brief history of SSH and remote access
In the beginning, computers were the size of large conference rooms. A punch card reader would merrily accept pieces of paper with instructions the computer would run, and then a printer would etch the results into another piece of paper. Thousands of mechanical parts worked harmoniously(when they did work) to compute relatively simple commands. As time progressed, computers became somewhat smaller, and interactive terminals became more user-friendly, but they were still wired directly into the computer being used. Mainframes came to the fore in the 1960s, originally used via typewriter and teletype interfaces, then via keyboards and small text displays. As networked computing became more mainstream in the 1970s and 1980s, remote terminal access was used to interact with the large central computers.
The first remote terminal interfaces assumed a high level of trust between the central computer and all those on the network because the small, centralized networks used were physically isolated from one another.
Telnet
In the late 1960s, the Telnet protocol was defined and started being used over TCP networks
(normally on port 23) for remote control over larger private networks, and eventually the public Internet. Telnet’s underlying technology (a text-based protocol to transfer data between different systems) was the basis for many foundational communications protocols in use today, including HTTP, FTP, and POP3. However, plain text streams are not secure, and even with the addition of TLS and SASL, Telnet was never very secure by default. With the advent of SSH (which we’ll get to in a bit), the protocol has declined in popularity for most remote administration purposes. Telnet still has used like configuring devices over local serial connections or checking if a particular service is operating correctly on a remote server (like an HTTP server on port 80, MySQL on port 3306, or munin on port 4949), but it is not installed by default on modern Linux distributions.
Plain text communications over a network are only as secure as the network’s weakest link.
In the early days of computer networking, networks were usually isolated to a specific
company or educational institution, so transmitting things like passwords or secrets in
plain text using the TCP protocol wasn’t such a bad idea. Every part of the network
(cabling, switches, and routers) was contained inside a secured physical perimeter. When
connections started moving to the public Internet, this changed.
TCP packets can be intercepted over the Internet, at any point between the client and server,
and these packets can easily be read if not encrypted. Therefore, plain text protocols are
highly insecure, and should never be used to transmit sensitive information or system
control data. Even on highly secure networks with properly-configured firewalls, it’s a bad
idea to use insecure communication methods like plain text rlogin and telnet connections
for authentication and remote control.
Try running traceroute google.com in your terminal. Look at each of the hops between
you and Google’s CDN. Do you know who controls each of the devices between your
computer and Google? Do you trust these operators with all of your personal or corporate
secrets? Probably not. Each of these connection points—and each network device and cable
connecting them—is a weak point exposing you to a man-in-the-middle attack. Strong
encryption is needed between your computer and the destination if you want to ensure
data security.
Comments
Post a Comment