01-2

004

Kh

oa

CN

TT

1/20

PH

ẠM

VĂ

N T

ÍNH

TCP WRAPPERS and XINETD TCP WRAPPERS and XINETD

01-2

004

Kh

oa

CN

TT

2/20

PH

ẠM

VĂ

N T

ÍNH

TCP Wrappers and xinetd TCP Wrappers and xinetd

Controlling access to network services is one of the most important security tasks facing a server administrator: •An iptables-based firewall filters out unwelcome network packets within the kernel's network stack. •TCP wrappers add an additional layer of protection by defining which hosts are allowed or not allowed to connect to "wrapped" network services. One such wrapped network service is the xinetd super server.

01-2

004

Kh

oa

CN

TT

3/20

PH

ẠM

VĂ

N T

ÍNH

TCP WrappersTCP Wrappers

• When a connection attempt is made to a TCP wrapped service, the service first references the hosts access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client host is allowed to connect. It then uses the syslog daemon (syslogd) to write the name of the requesting host and the requested service to /var/log/secure or /var/log/messages.

• If a client host is allowed to connect, TCP wrappers release control of the connection to the requested service and do not interfere further with communication between the client host and the server.

• Because TCP wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Linux are linked against the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.

01-2

004

Kh

oa

CN

TT

4/20

PH

ẠM

VĂ

N T

ÍNH

TCP Wrappers Configuration Files TCP Wrappers Configuration Files

• To determine if a client machine is allowed to connect to a service, TCP wrappers reference the following two files, which are commonly referred to as hosts access files: – /etc/hosts.allow– /etc/hosts.deny

• When a client request is received by a TCP wrapped service, it takes the following basic steps:

1.The service references /etc/hosts.allow. The TCP wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to step 2.

2.The service references /etc/hosts.deny. The TCP wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule is denies the connection. If not, access to the service is granted.

01-2

004

Kh

oa

CN

TT

5/20

PH

ẠM

VĂ

N T

ÍNH

TCP Wrappers Configuration FilesTCP Wrappers Configuration Files

1.Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.

2.Since the rules in each file are read from the top down and the first matching rule for a given service is the only one applied, the order of the rules is extremely important.

3.If no rules for the service are found in either file, or if neither file exists, access to the service is granted.

4.TCP wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately without restarting network services.

01-2

004

Kh

oa

CN

TT

6/20

PH

ẠM

VĂ

N T

ÍNH

Formatting Access Rules Formatting Access Rules

• The format for both /etc/hosts.allow and /etc/hosts.deny are identical. Any blank lines or lines that start with a hash mark (#) are ignored, and each rule must be on its own line.

• Each rule uses the following basic format to control access to network services:

• <daemonList>: <clientList> [: <option>: <option>: ...]• <daemon list> — A comma separated list of process names

(not service names) or the ALL wildcard . The daemon list also accepts operators to allow greater flexibility.

• <client list> — A comma separated list of hostnames, host IP addresses, special patterns , or special wildcards which identify the hosts effected by the rule. The client list also accepts operators to allow greater flexibility.

• <option> — An optional action or colon separated list of actions performed when the rule is triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter logging behavior.

01-2

004

Kh

oa

CN

TT

7/20

PH

ẠM

VĂ

N T

ÍNH

Formatting Access Rules - ExamplesFormatting Access Rules - Examples

• The following is a basic sample hosts access rule:

vsftpd : .example.com

• This rule instructs TCP wrappers to watch for connections to the FTP daemon (vsftpd) from any host in the example.com domain. If this rule appears in hosts.allow, the connection will be accepted. If this rule appears in hosts.deny, the connection will be rejected.

• The next sample hosts access rule is more complex and uses two option fields:

sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied >> /var/log/sshd.log \ : deny

01-2

004

Kh

oa

CN

TT

8/20

PH

ẠM

VĂ

N T

ÍNH

Wildcards and Patterns Wildcards and Patterns

• The following wildcards may be used: –ALL — Matches everything. It can be used for both the

daemon list and the client list. –LOCAL — Matches any host that does not contain a period

(.), such as localhost. • The following is a list of the most common accepted patterns

for a client list entry: –Hostname beginning with a period (.) — Placing a period at

the beginning of a hostname, matches all hosts sharing the listed components of the name. The following example would apply to any host within the example.com domain:

ALL : .example.com–IP address ending with a period (.) — Placing a period at the

end of an IP address matches all hosts sharing the initial numeric groups of an IP address. The following example would apply to any host within the 192.168.x.x network:

ALL : 192.168.

01-2

004

Kh

oa

CN

TT

9/20

PH

ẠM

VĂ

N T

ÍNH

Patterns and OperatorsPatterns and Operators

• IP address/netmask pair — Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. The following example would apply to any host with an address of 192.168.0.0 through 192.168.1.255:

ALL : 192.168.0.0/255.255.254.0

• The asterisk (*) — Asterisks can be used to match entire groups of hostnames or IP addresses, as long as they are not mixed in a client list containing other types of patterns. The following example would apply to any host within the example.com domain:

ALL : *.example.com

• The EXCEPT operator allows specific exceptions to broader matches within the same rule.

ALL: .example.com EXCEPT cracker.example.com

ALL EXCEPT vsftpd: 192.168.0.

01-2

004

Kh

oa

CN

TT

10/2

0P

HẠ

M V

ĂN

TÍN

H

Access Control Access Control

• Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.

• For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com: •sshd : client-1.example.com : allow•sshd : client-2.example.com : deny• By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny. Some consider this an easier way of organizing access rules.

01-2

004

Kh

oa

CN

TT

11/2

0P

HẠ

M V

ĂN

TÍN

H

Shell Commands Shell Commands

• Option fields allow access rules to launch shell commands through the following two directives: spawn — This option directive can perform tasks to get more

information about the requesting client or create special log files using the echo command.

– In the following example, clients attempting to access Telnet services from the example.com domain are quietly logged to a special file:

in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h >> /var/log/telnet.log : allow

twist — This directive is often used to set up traps for intruders (also called "honey pots"). It can also be used to send messages to connecting clients. The twist command must occur at the end of the rule line.

– In the following example, clients attempting to access FTP services from the example.com domain are sent a message via the echo command:

vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!"

01-2

004

Kh

oa

CN

TT

12/2

0P

HẠ

M V

ĂN

TÍN

H

Expansions Expansions

• Expansions, when used in conjunction with the spawn and twist directives provide information about the client, server, and processes involved.

• Below is a list of supported expansions:

%a — The client's IP address.

%A — The server's IP address.

%d — The daemon process name.

%h — The client's hostname (or IP address, if the hostname is unavailable).

%H — The server's hostname (or IP address, if the hostname is unavailable).

%u — The client's username. If unavailable, unknown is printed.

01-2

004

Kh

oa

CN

TT

13/2

0P

HẠ

M V

ĂN

TÍN

H

XINETDXINETD

•Xinetd is a program used to start and stop a variety of Linux data communication applications. Some of these applications, such as Telnet, are installed by default in RedHat and Fedora Core Linux, others such as TFTP, need to be installed afterwards.

• xinetd Configuration Files

– /etc/xinetd.conf — The global xinetd configuration file.

– /etc/xinetd.d/ directory — The directory containing all service-specific files.

01-2

004

Kh

oa

CN

TT

14/2

0P

HẠ

M V

ĂN

TÍN

H

The /etc/xinetd.d/ Directory The /etc/xinetd.d/ Directory

• The files in the /etc/xinetd.d/ directory contains the configuration files for each service managed by xinetd and the names of the files correlate to the service. As with xinetd.conf, this file is read only when the xinetd service is started. In order for any changes to take effect, the administrator must restart the xinetd service.

• To get an idea of how these files are structured, consider the /etc/xinetd.d/telnet file: service telnet{ flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = yes}

01-2

004

Kh

oa

CN

TT

15/2

0P

HẠ

M V

ĂN

TÍN

H

Service Configuration FileService Configuration File

•service — Defines the service name, usually to match a service listed in the /etc/services file.

•flags — Sets any of a number of attributes for the connection. REUSE instructs xinetd to reuse the socket for a Telnet connection.

•socket_type — Sets the network socket type to stream. •wait — Defines whether the service is single-threaded (yes) or multi-

threaded (no). •user — Defines what user ID the process process will run under. •server — Defines the binary executable to be launched. • log_on_failure — Defines logging parameters for log_on_failure in

addition to those already defined in xinetd.conf. •disable — Defines whether or not the service is active. •only_from — Allows only the specified hosts to use the service.•no_access — Blocks listed hosts from using the service.

no_access = 10.0.1.0/24 •access_times — Specifies the time range when a particular service

may be used. The time range must be stated in 24-hour format notation, HH:MM-HH:MM.

01-2

004

Kh

oa

CN

TT

16/2

0P

HẠ

M V

ĂN

TÍN

H

The TELNET serverThe TELNET server

• Setting Up A Telnet ServerTo set up a Telnet server use the chkconfig command to activate Telnet.

root@bigboy tmp# chkconfig telnet on

• Verifying the telnet service by netstat comand

root@bigboy tmp# netstat -a | grep telnettcp 0 0 *:telnet *:* LISTEN

• Verifying the telnet service by chkconfig --list command

[root@bigboy tmp]# chkconfig --list | grep telnet

telnet: on

• Stopping A Telnet Server Use the chkconfig command to deactivate telnet, even after the next reboot.

[root@bigboy tmp]# chkconfig telnet off

01-2

004

Kh

oa

CN

TT

17/2

0P

HẠ

M V

ĂN

TÍN

H

Basic Telnet SecurityBasic Telnet Security

• Let Telnet Listen On Another TCP Port• 1) Edit a /etc/services file and add an entry for a new service. Call it

stelnet. • # Local services

stelnet 7777/tcp # "secure" telnet• 2) Copy the telnet configuration file called /etc/xinetd.d/telnet and

call it /etc/xinetd.d/stelnet: [root@bigboy tmp]# cp /etc/xinetd.d/telnet /etc/xinetd.d/stelnet• 3) Edit the new /etc/xinetd.d/stelnet file. Make the new service

stelnet and add a port statement for TCP port 7777. service stelnet{ flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = no port = 7777}

01-2

004

Kh

oa

CN

TT

18/2

0P

HẠ

M V

ĂN

TÍN

H

Basic Telnet SecurityBasic Telnet Security

• 4) Use chkconfig to activate stelnet.

• [root@bigboy tmp]# chkconfig stelnet on

• 5) Check to make sure your server is now listening on port 7777 with the netstat command.

• [root@bigboy tmp]# netstat -an | grep 777

tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN

• Let Telnet Allow Connections From Trusted Addresses

service telnet{ flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = no only_from = 192.168.1.100 127.0.0.1 192.168.1.200}

01-2

004

Kh

oa

CN

TT

19/2

0P

HẠ

M V

ĂN

TÍN

H

The TFTP Server Software The TFTP Server Software

• Installing the TFTP ServerMost RedHat and Fedora Linux software products are available in the RPM format. Downloading and installing RPMs isn't hard( the RPM's filename usually starts with the word "tftp-server" followed by a version number like this: tftp-server-0.33-3.i386.rpm).

• Configuring The TFTP Server 1.The first step is to the configuration file /etc/xinetd.d/tftp and set

disable to "no". service tftp{

socket_type = dgramprotocol = udpwait = yesuser = rootonly_from = 192.168.1.1server = /usr/sbin/in.tftpdserver_args = -s /tftpbootdisable = no

}

01-2

004

Kh

oa

CN

TT

20/2

0P

HẠ

M V

ĂN

TÍN

H

The TFTP Server SoftwareThe TFTP Server Software

• In this example, xinetd will only allow the TFTP server to accept connections from the router / switch / firewall with an address of 192.168.1.1. You can extend this list with commas in between or just comment it out al together for global access.

2. Create a /tftpboot directory with global read write privileges[root@bigboy tmp]# chmod 777 /tftpboot

3. Restart xinetd[root@bigboy tmp]# /etc/init.d/xinetd restartStopping xinetd: [ OK ]Starting xinetd: [ OK ]