What should you enter at the command prompt to check the tcp wrapper configuration on your system?

1. Home
2. Training Library
3. Cloud Computing Fundamentals
4. Courses
5. Network Security in Linux

Introduction

Network Security

Securing SSHD

Firewalls

TCP Wrappers

The course is part of this learning path

Description

In this course, you'll learn some techniques and strategies to secure network services. You'll also learn how the local firewall works in Linux and how to configure it. We'll talk about information leakage and ways to prevent it. Next, you'll learn how to test for open ports and perform port scans. You'll also learn about xinetd, what it does, and how to secure it. We'll also cover how to secure SSH. This course includes some guided demonstrations so that you can see the concepts being used in real-world environments.

Learning Objectives

• Learn how to secure SSH
• Understand the fundamentals of Linux firewall security, including configuring a firewall from the command line and setting up firewall rules
• Learn how to use TCP wrappers to secure your Linux system

Intended Audience

This course is intended for anyone who wants to understand how to secure their Linux systems.

Prerequisites

To get the most out of this course, you should already have a good working knowledge of Linux. If you want to brush up on your Linux skills, consider taking our Learn Linux in 5 Days learning path first.

Transcript

TCP wrappers are a host-based networking ACL system. Unlike the local Linux firewall, which can control whether or not a connection can be made to the system as a whole TCP wrappers only controls connections for services that are wrapped. A wrapped service is simply a network service that has been compiled against libwrap. To determine if a service is wrapped you can run the ldd command against it's binary. The ldd command displays, the shared libraries required by a given program to run. If we run ldd against sshd you can see that it is using libwrap. So it will honor any TCP ACL's we put into place again, comparing the TCP wrappers to the local Linux firewall. We know that the firewall can control access by IP address or network address. TCP wrappers can do that as well, however TCP wrappers can also control access based on DNS names. Another advantage to using TCP wrappers is that they are transparent to the client that is attempting to connection and to the service that is wrapped. One of the most popular TCP wrapped services is inetd or its current incarnation xinetd Xinetd is a super server, which listens for incoming network requests and then dispatches those requests to the proper service. TCP wrappers provide centralized management for multiple network services. For example, if you wanted to control access to SSHD. Imapd and services that are xinetd controlled you can do all of that in the exact same place. TCP wrappers uses a runtime configuration, meaning that any changes you make take effect immediately and no TCP wrap services need to be restarted or reloaded. Before we get into exactly how to configure TCP wrappers, let's look at the path network connections take. If a network connection makes it past the firewall then it's examined by TCP wrappers. If the connection is allowed by TCP wrappers, then the request is handed off to the proper service. If the connection is bound to a service that directly supports TCP wrappers, that connection is handed over directly to that service. If the request is bound to a service that xinetd manages xinetd starts the subprocess or subservice and hands over the request to it, there are two configuration files used to configure TCP wrappers. These files are etc/hosts.allow and etc/hosts.deny. They are also known as host access files. When a connection attempt is made to a TCP wrap service the host.allow file is examined. If a match is found in host.allow for the incoming connection access is granted. If no match is found then the host.deny file is checked. If a match is found in host.deny then the connection is blocked. A message will be written to the log file stating that the connection was refused. Typically this will be /var/log/messages, /var/log/syslog maybe /var/log/secure or even var/log/off.log depending on how you have your system logger configured. If there is no match found in either host.allow or host.denied, then access is granted. Let's talk about how to create these ACL's or rules. The format for a rule is the same. You can use the same format in the host.allow file and the same format in the host.deny file. Each rule must be on its own line. The format for a rule is a service followed by a colon followed by a client specification and optionally you can provide an action to take when the rule is matched. The service portion of a rule is actually the same name of the process that runs and accepts the network connections. For example, a valid service is SSHD. You wouldn't want to put SSH here because it's actually S-S-H-D that accepts the connections. If you want to list a multiple services you separate them with a common. So if you want the rule to apply to the SSHD and imapd services you would start the rule with sshd followed by a comma followed by imapd followed by a colon. And then the client specification The TCP wrapper configuration supports the use of wild cards, one wild card is all. So to apply the same action to all TCP wrap services use all in the services field. Again, the same rules can be used in both the host.allow and hosts.deny file. For example, if this rule all colon 10.11.12. 13 were present in the host.allow file. Then when a connection was attempted from 10.11.12.13 to any TCP wrap service, it would be allowed. Conversely, if that exact same rule were to be placed in the host.deny file connections attempted from 10.11.12.13 to any TCP wrap service would be denied. The client list can contain an IP address, a host name or a network specifications. If you want to provide more than one client, separate them by commas. Here's an example using a host name. This example matches connections, originating from jumpbox.example.com that are destined to the SSHD process. You can use patterns yeah wildcards in the client field as well. For example, to match SSH connections, originating from any client in the.example.com domain you would use sshd: .example.com. Starting a host name with a period will match any host sharing the same components listed in the rule. For example, to match hosts and the admin .example.com subdomain use .admin.example.com. Example matches would include server01.admin.example.com and webdev.admin.example.com. If you wanted to match hosts that start with jump box. In the example.com domain you would use jumpbox*.example.com that would match jumpbox4admins.example.com for instance to match hosts that start with jumpbox0 followed by exactly one character in the.example.com domain use jumpbox0?.example.com an example match would be jumpbox03.example.com. Again, the asterisk matches zero or more characters. And the question mark matches exactly one of them any character.

About the Author

Jason is the founder of the Linux Training Academy as well as the author of "Linux for Beginners" and "Command Line Kung Fu." He has over 20 years of professional Linux experience, having worked for industry leaders such as Hewlett-Packard, Xerox, UPS, FireEye, and Amazon.com. Nothing gives him more satisfaction than knowing he has helped thousands of IT professionals level up their careers through his many books and courses.

Covered Topics

How do you use TCP wrappers?

Which files do you configure in etc to set TCP wrappers use?

Which of the following files are used for configuring TCP wrappers choose all that apply?

Which of the following files does a TCP Wrapper check before starting a network daemon?