TCP Wrappers and xinetd

Controlling access to network services is one of the most important security tasks facing a server administrator. Fortunately, under Red Hat Linux there are a number of tools which do just that. For instance, an iptables-based firewall filters out unwelcome network packets within the kernel's network stack. For network services that utilize it, 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. This service is called a super server because it controls connections to a subset of network services and further refines access control.

TCP Wrappers

The TCP wrappers package (tcp_wrappers) is installed by default under Red Hat Linux and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP wrapped service is one that has been compiled against the libwrap.a library.

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.

In addition to access control and logging, TCP wrappers can activate commands to interact with the client before denying or releasing control of the connection to the requested network service.

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

To determine if a network service binary is linked against libwrap.a, type the following command as the root user:

 strings -f | grep hosts_access

 More about TCP Wrappers:

here, here and here

TCP Wrapper - An introduction

TCP Wrapper is a host-based Networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes.

The original code was written by Wietse Venema in 1990 to monitor a cracker's activities on the Unix workstations at the Dept. of Math and Computer Science, Eindhoven University of Technology, the Netherlands[1] maintained it until 1995, and on June 1, 2001, released it under its own BSD-style license.

The tarball includes a library named libwrap that implements the actual functionality. Initially, only services that were spawned for each connection from a super-server (such as inetd) got wrapped, utilizing the tcpd program. However most common network service daemons today can be linked against libwrap directly. This is used by daemons that operate without being spawned from a super-server, or when a single process handles multiple connections. Otherwise, only the first connection attempt would get checked against its ACLs.

Using TCP Wrappers to secure Linux

TCP Wrappers can be used to GRANT or DENY access to various services on your machine to the outside network or other machines on the same network. It does this by using simple Access List Rules which are included in the two files /etc/hosts.allow and /etc/hosts.deny .

Let us consider this scenario: A remote machine remote_mc trying to connect to your local machine local_mc using ssh.
+ reading

20 Linux Server Hardening Security Tips

Securing your Linux server is important to protect your data, intellectual property, and time, from the hands of crackers (hackers). The system administrator is responsible for security Linux box. In this first part of a Linux server security series, I will provide 20 hardening tips for default installation of Linux system.

#1: Encrypt Data Communication
#2: Minimize Software to Minimize Vulnerability
#3: One Network Service Per System or VM Instance
#4: Keep Linux Kernel and Software Up to Date
#5: Use Linux Security Extensions
#6: User Accounts and Strong Password Policy
#7: Disable root Login
#8: Physical Server Security
#9: Disable Unwanted Services
#10: Delete X Windows
#11: Configure Iptables and TCPWrappers
#12: Linux Kernel /etc/sysctl.conf Hardening
#13: Separate Disk Partitions
#14: Turn Off IPv6
#15: Disable Unwanted SUID and SGID Binaries
#16: Use A Centralized Authentication Service
#17: Logging and Auditing
#18: Secure OpenSSH Server
#19: Install And Use Intrusion Detection System
#20: Protecting Files, Directories and Email

+ here

Updating from Factory to openSUSE 11.2

As Stephan Kulow announced recently openSUSE 11.2 is now build in a separate project and openSUSE Factory contains changes that will not go into openSUSE 11.2. Therefore if you followed so far openSUSE Factory via e.g. “zypper dup” and want to switch to 11.2, you have to change the repositories that you are using. If you installed openSUSE 11.2 RC1, you have already the right repositories for 11.2 setup.

+ here

BASH Script – Blank Out CC Details

Here’s a quick one liner, can’t think why anyone would ever have any use for it, but maybe the principle itself could be of use to someone! This will take a file containing listings of 16 digit numbers, i.e. 1234123412341234 and replace it with XXXXXXXXXXXX1234

[Keep reading here]

Disabling console login for a linux box

Part of the linux hardening strategy is to disable the login from the console, if you are paranoid enough you would like to disable the root login from the console.

This is accomplished though the use of PAM.

1) Open the /etc/pam.d/login

And comment the first line and add this line after it:

2) Add this line to the file /etc/security/access.conf

And finially, when i try to login from the tty2 this is that happens:

mount server reported tcp not available

On the log you have: Using NFS over UDP can cause data corruption.

Make sure that the portmap service is up on the Server:
rpcinfo -p


Resolved :)

undefined symbol: _dl_cpuclock_offset

# ls
ls: relocation error: /lib/i686/libpthread.so.0: undefined symbol: _dl_cpuclock_offset

/lib/i686 # ls lib
libc.so.6        libm.so.6        libpthread.so.0

rpm -ivh ./glibc-2.2.5-233.i686.rpm

Resolved it.

cannot get shared lock on database

To resolve this i had to look which were the process taking the database:

lsof | grep /var/lib/rpm/packages.rpm

And then killed it with the SIGKILL signal.

User password expiration

Like in AIX, on Linux it is important to control the users passwords expiration.  The password expiration information is stored in /etc/shadow.

Inspect the password expiration from one user:

# chage -l simpleuser

Minimum:        0
Maximum:        90
Warning:        7
Inactive:       -1
Last Change:            Feb 19, 2009
Password Expires:       May 20, 2009
Password Inactive:      Never
Account Expires:        Never

Inspect the password expiration from all the users:

for i in `cat /etc/passwd | awk -F: '{print $1}'`; do echo "UserName:${i}"; chage -l $i|grep "Password Expires" ;done

Disable the password expiration from one user:

# chage -I -1 -m 0 -M 99999 -E -1 simpleuser

Which languages are installed in a SuSe Linux ?

Some differences exist between linux versions, on redhat, to know which are the installed languages you have to do a cat from /etc/sysconfig/i18n.

On SuSe this info is in /etc/sysconfig/languages.
cat /etc/sysconfig/languages | grep "installed_lang"

Recovering a broken Linux Operating System part (3/3)

The last way to recover a broken system to which you do not have normal access is with help of the installation media cd.  For example on SuSe 11 it is like this:

1) Insert the boot cd and write "repair=1" in the boot options. Press enter.

2) This window appears for a few seconds:

 

3) You get root access by simple typing "root" and press enter:

4) The partitions wouldn't be mounted.  Mount them and start repairing: