SSH Key generation for Security
We need to generate a pair of keys, on public for the server to encrypt the data and a private key, which is the only key that could decipher the encrypted data, and this private key is by definition should be kept private. There is many secure algorithm for encryption with different degree of encryption strength.
There is DSA and RSA, DSA is the standard encryption for the USA government, DSA keys has a 1024 size limit, whereas RSA is unlimited .
RSA key with a 2048 length, here are the steps.
$ ssh-keygen -v -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/buddies/.ssh/id_rsa): /home/buddies/.ssh/buddies_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/buddies/.ssh/buddies_rsa.
Your public key has been saved in /home/buddies/.ssh/buddies_rsa.pub.
The key fingerprint is:
66:d2:cc:7b:6a:62:f9:f5:c6:ef:69:fc:7b:87:0d:46 buddies@buddies
and then
$ chmod 600 /home/buddies/.ssh/buddies_rsa
$ scp /home/buddies/.ssh/buddies_rsa.pub buddies@myremote.server.com:/home/buddies/.ssh
on remote server we should do the following.
$ cat /home/buddies/.ssh/buddies_rsa.pub > /home/buddies/.ssh/authorized_keys
You will be asked for the login password on remote before the copying commences.
The file will be copied to login user home directory on remote (/home/buddies in that case).
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
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
Controlling Server Resources from denial of service using Xinetd
Another important feature of xinetd is its ability to control the amount of resources which services under its control can utilize.
It does this by way of the following directives:
cps = [number_of_connections] [wait_period] — Dictates the connections allowed to the service per second. This directive accepts only integer values.
instances = [number_of_connections] — Dictates the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.
per_source = [number_of_connections] — Dictates the connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.
rlimit_as = [number[K|M]] — Dictates the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.
rlimit_cpu = [number_of_seconds] — Dictates the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.
Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.
TCP Wrappers and Enhanced Logging
If certain types of connections are of more concern than others, the log level can be elevated for that service via the severity option.
For this example, assume anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place a emerg flag in the log files instead of the default flag, info, and deny the connection.
To do this, place the following line in /etc/hosts.deny:
in.telnetd : ALL : severity emerg
This uses the default authpriv logging facility, but elevates the priority from the default value of info to emerg, which posts log messages directly to the console.
