Mastering Red Hat Linux 9 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Mastering Red Hat Linux 9 [Electronic resources] - نسخه متنی

Michael Jang

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید









Controlling Access with TCP Wrappers



The best way to protect your system from crackers is to disable or uninstall as many services as possible. For example, a cracker can’t use the telnet command to break into your computer if you don’t have the Telnet server RPM installed.


If don’t need an xinetd service immediately, one option is to deactivate it in the /etc/xinetd.d directory. In most cases, it’s sufficient to leave all but required services disabled in the associated configuration files.


But some users need to get to their e-mail when they’re in remote locations, and some need Telnet. For those who need access to larger files from remote locations, FTP servers are still the most effective way to transfer files over the Internet.


You can configure access control to all of these services using TCP Wrappers.



Regulating Access



You can minimize risks to your Linux computer in two different ways. First, you can regulate users and/or computers allowed to access a service through its configuration files, some of which are located in the /etc/xinetd.d directory. Other files are associated with different services and we address them in later chapters. Alternatively, you can use TCP Wrappers to regulate computer access through the /etc/hosts.allow and /etc/hosts.deny files.


You can add various rules to these files. These rules are read in the following order:





TCP Wrappers reads the /etc/hosts.allow file. If access is explicitly allowed, access is granted.





TCP Wrappers reads the /etc/hosts.deny file. If access is explicitly denied, users from the specified computer are not allowed to start the service.





If the computer or IP address is not found in either file, access is automatically granted, and xinetd starts the service.





If the computer or IP address is found in both files, the rule in /etc/hosts.allow comes first.





For example, if you configure rules that explicitly open a service to computer A in /etc/hosts .allow and then denies it in /etc/hosts.deny, computer A gets access.


In addition, any changes that you save to either file take effect immediately. You don’t need to restart or reload the xinetd daemon.





The xinetd Firewall



A specific type of syntax is associated with /etc/hosts.allow and /etc/hosts.deny. First, as with other scripts, blank lines and comments that start with a # are not read. Each command line in these files should follow this configuration:



daemon: client: spawn command


In other words, when you specify a server daemon, you can associate it with a group of hostnames or IP addresses. When there is a match, you can also trigger a command, such as a message to the user or a log entry.


The simplest version of this command line is


ALL: ALL


which applies to all xinetd daemons and all computers. The options are complex, so it’s easiest to examine the options one at a time.



TCP Wrapper Daemons



You can specify individual daemons, but keep in mind that the name of the daemon may not be what you expect. For example, the name of the Telnet daemon is in.telnetd.


If you want to specify multiple daemons, just cite them together and separate the names of the daemons with a space. For example, the following line in /etc/hosts.deny blocks access to local Telnet and RSH servers to all users:


in.telnetd in.rshd: ALL


If in doubt on daemon names, refer to the configuration file in the /etc/xinetd.d directory. Each of these files includes the name of the daemon as the server variable.





TCP Wrapper Clients



You can specify the names of different computers, or client names, in TCP Wrappers commands by host or by IP address. Several wildcard parameters are available as well.


There are several ways to specify hostnames. You can specify them one at a time; for example, the following command prevents access to local RSH and Telnet servers from the computers named sugaree and delilah:


in.rshd in.telnetd: sugaree delilah


Or you can specify the fully qualified domain name (FQDN) of a computer, such as sugaree .mommabears.com. Wildcards are allowed with FQDNs; for example, just include the leading dot in .mommabears.com to apply the rule to all computers on the mommabears.com network.


It’s possible to specify different computers; for example, the following line applies the rule to all computers on the mommabears.com network except delilah.mommabears.com:


in.rshd: .mommabears.com EXCEPT delilah.mommabears.com


You can apply these principles to IP addresses; for example, the following line applies the rule to all computers on the 192.168.0.0 network except 192.168.0.102. Note the trailing dot in 192.168.0.; it applies to all computers with IP addresses between 192.168.0.0 and 192.168.0.255:


in.rshd: 192.168.0. EXCEPT 192.168.0.102





Note


CIDR notation such as 192.168.0.0/24 does not work in the /etc/hosts.allow or /etc/hosts .deny files.




Table 23.3 lists the wildcards that can be used in place of hostnames, FQDN, or IP addresses. They are fairly self-explanatory.































Table 23.3: TCP Wrapper Wildcards


Wildcard




Application




ALL




All computers, including the localhost.




EXCEPT




Exceptions to the rule.




KNOWN




Known computers—e.g., from DNS or /etc/hosts.




LOCAL




Computers with a single hostname; the name can’t include a dot.




PARANOID




Computers where the hostname or FQDN does not match the IP address.




UNKNOWN




Computers not in the /etc/hosts or DNS databases.






TCP Wrappers Commands



Normally, all attempts to start an xinetd service are automatically added to /var/log/messages. You can use the spawn command to run another shell command as well. For example, use the following command to send an alert e-mail to the noted address:


in.telnetd: ALL: spawn /bin/mail -s "Telnet security alert" mj@example.com


Another common use is to send a special message to a log file in /var/log that identifies the date and time when someone tried to access the service.








/ 220