Archive for the tag 'Securing'

SBDavid

Securing vsftpd Server

The File Transport Protocol, or FTP, is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured.

vsftpd - A standalone, security oriented implementation of the FTP service.

Change the FTP Greeting Banner:

To change the greeting banner for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file:

ftpd_banner=[insert_greeting_here]

To simplify management of multiple banners, place all banners in a new directory called /etc/banners/.

To reference this greeting banner file for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file:

banner_file=/etc/banners/ftp.msg
SBDavid

Securing the Apache HTTP Server

Securing the Apache HTTP Server

The Apache HTTP Server is one of the most stable and secure services that ships with major Linux Server Distros.

Below is a few list of configuration options administrators should be careful using.

The Indexes Directive

This directive is enabled by default, but may not be desirable. To prevent visitors from browsing files on the server, remove this directive.

FollowSymLinks

This directive is enabled by default, be sure to use caution when creating symbolic links to the
document root of the Web server. For instance, it is a bad idea to provide a symbolic link to /.

The UserDir Directive

The UserDir directive is disabled by default because it can confirm the presence of a user account on the system. To enable user directory browsing on the server, use the following directives:

UserDir enabled UserDir disabled root

These directives activate user directory browsing for all user directories other than /root/. To add users to the list of disabled accounts, add a space delimited list of users on the UserDir disabled line.

Do Not Remove the IncludesNoExec Directive

Restrict Permissions for Executable Directories

Be certain to only assign write permissions to the root user for any directory containing scripts or CGIs. This can be accomplished by typing the following commands:

chown root[directory_name] chmod 755 [directory_name]
SBDavid

Securing Network Information Service

Securing Network Information Service

An NIS server has several applications. They include the following:

/usr/sbin/rpc.yppasswdd
Also called the yppasswdd service, this daemon allows users to change their NIS passwords.

/usr/sbin/rpc.ypxfrd
Also called the ypxfrd service, this daemon is responsible for NIS map transfers over the network.

/usr/sbin/yppush
This application propagates changed NIS databases to multiple NIS servers.

/usr/sbin/ypserv
This is the NIS server daemon.

To make access to NIS maps harder for an attacker, create a random string for the DNS hostname, such as fdfdfdfdfdfg.domain.com. Similarly, create a different randomized NIS domain name. This makes it much more difficult for an attacker to access the NIS server.

NIS listens to all networks, if the /var/yp/securenets file is blank or does not exist (as is the case after a default installation). One of the first things to do is to put netmask/network pairs in the file so that ypserv only responds to requests from the proper network.

Below is a sample entry from a /var/yp/securenets file:

255.255.255.0 192.168.0.0

This technique does not provide protection from an IP spoofing attack, but it does at least place limits on what networks the NIS server services

SBDavid

Securing Portmap service

Securing Portmap service

The portmap service is a dynamic port assignment daemon for RPC services such as NIS and NFS. It has weak authentication mechanisms and has the ability to assign a wide range of ports for the services it controls. For these reasons, it is difficult to secure.

NFSv4 no longer requires it. If you plan to implement a NFSv2 or NFSv3 server, then portmap is required.

It is important to use TCP wrappers to limit which networks or hosts have access to the portmap service since it has no built-in form of authentication.

Further, use only IP addresses when limiting access to the service. Avoid using hostnames, asthey can be forged via DNS poisoning and other methods.

Below are two example IPTables commands that allow TCP connections to the portmap service (listening on port 111) from the 192.168.0/24 network and from the localhost. All other packets are dropped.

iptables -A INPUT -p tcp -s! 192.168.0.0/24 –dport 111 -j DROP iptables -A INPUT -p tcp -s

To similarly limit UDP traffic, use the following command.

iptables -A INPUT -p udp -s! 192.168.0.0/24 –dport 111 -j DROP

Securing Services With TCP Wrappers and xinetd

TCP wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, which stand guard between an in-coming request and the requested service.

The benefits offered by TCP wrappers are enhanced when used in conjunction with xinetd, a super service that provides additional access, logging, binding, redirection, and resource utilization control.

For a thorough list of TCP wrapper functionality and control language, refer to the hosts_options man page.

To implement a TCP wrappers banner for a service, use the banner option.

This example implements a banner for vsftpd. To begin, create a banner file. It can be any-where on the system, but it must bear same name as the daemon. For this example, the file is called /etc/banners/vsftpd.

The contents of the file look like this:

Hello, %c All activity on ftp.serverbuddies.com is logged.

The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating.

For this banner to be presented to incoming connections, add the following line to the /etc/hosts.allow file:

vsftpd : ALL : banners /etc/banners/

« Prev