Limit Root Access

Limit the direct root access by making sure console entry in /etc/default/login is not commented out . Edit sshd.config and ssh.config to disable root access

If secure shell is being used to access the systems.

Sshd.config

Permit root login no

Permit empty password no

Allow hosts <host list>

Allow users <user list>

 

Ssh.config

Forward x11 no

Password authentication no

Host based authentication is more secure as it is based on private keys and public keys and only user with the keys are allowed to connect . Password authentication is less secure as they can be guessed or cracked by some programs .

Limit su capabilities

Allow only a few selected members of a group to use su to prevent any unauthorized access by guessing the root password . Create a system administrator’s group and change su owner to root and group to administrator’s group . Change su permissions to allow only member of this group an execute permission .

.rhosts ,.netrc hosts.equivalent are the files that provides access to the remote systems and should be monitored carefully .They should be checked regularly for any unauthorized entry or if not needed can be made with zero permission - chmod 0 . This will not allow creation of new file by the same name and put entries to gain access.

sulog file gives information about su login attempts to the system similarly a loginlog file can be created by touching /etc/loginlog which keeps all the login information . Besides last command also give useful information about the persons accessing the system.

3. Run level and network services

/etc/rc2.d and /etc/rc3.d directories have scripts starting at the booting time or when run level is changed . By default a number of services are started out of which only a few might be required . In most of the cases , particularly in production environment certain services are not required at all but provides various ports for gaining entry to the system .

Evaluate your system requirements and look at the rc scripts , disable the files that are not required by making letter capital in the beginning as ‘s’ . System requirements may vary from system to system but you should check if you don’t need following services & can disable them.

/etc/inetd.conf has entry for about fifty network services and most of them are started by default . While some of these services are not secure -telnet,ftp ,some of it are not required at all . These services can allow a intruder to get in by providing system information and ports. Services such as finger ,sysstat & netstat provide useful information about the users , system and network. Depending on the applications requirement some of these services should be stopped by commenting out corresponding entry in /etc/inetd.conf

ftp should be disabled and secure copy ,scp , should be used instead . But if you must use ftp then limit the users which can do a ftp to the system . /etc/ftpusers file can be created to keep the ftp user list .

IP module can be tuned to prevent forwarding , redirecting of packets and request for information from the system . These parameters can be set using ndd with the given value to limit these features .

#ndd -set /dev/ip ip_forward_directed_broadcasts 0

#ndd -set /dev/ip ip_forward_src_routed 0

#ndd -set /dev/ip ip_ignore_redirect 1

#ndd -set /dev/ip ip_ire_flush_interval 60000

#ndd -set /dev/ip ip_ire_arp_interval 60000

#ndd -set /dev/ip ip_respond_to_echo_broadcast 0

#ndd -set /dev/ip ip_respond_to_timestamp 0

#ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0

#ndd -set /dev/ip ip_send_redirects 0

#ndd /dev/ip <enter>

name to get/set ? ?

#ndd -get /dev/ip ip_respond_to_timestamp_broadcast

Add the following lines to /etc/system file to prevent the buffer overflow in a possible attack to execute some malicious code on your machine.

set noexec_user_stack=1
set noexec_user_stack_log=1

Depending upon the requirement all or a combination of all the above suggestions can be implemented . Certain application software, web servers etc have there own parameters for securing access and data . So besides solaris those parameters may have to be taken in consideration in addition to solaris parameters to secure system completely.

6. sadmind daemon  vulnerability : 

The sadmind daemon is used for  distributed system administration operations in  the Solstice AdminSuite  applications. In its default configuration  sadmind uses a set of clear text  Remote Procedure Calls (RPC) to authenticate between two machines. An attacker can  construct  RPC packets that allow them r to forge a valid client identity and get it validated . Once the sadmind client has authenticated, the hacker can  perform any command on the remote system even with root privileges .

Protecting against sadmind  vulnerability 

 sadmind is controlled through the file /etc/inetd.conf as per the following entry :

100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

In this configuration, sadmind uses cleartext hostnames and authentication credentials as the security level is default no security level .

There are two ways to deal with this situation :

1. Completely disable the sadmind in the inted.conf  if not required  by commenting out the sadmind line  or removing it altogather .

#100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind

Restart inetd:

# /usr/bin/pkill -HUP inetd

2. Increase the  level of security by requiring DES encryption for your authentication mechanism  by  adding  the '-S 2' flag to the end of the sadmind line in inetd.conf:

100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2

Restart inetd:

# /usr/bin/pkill -HUP inetd

7. Root Kit   :

The hackers in some cases  installs  a "root" kit  which changes various files in the system in order to gain super user privileges and  to conceal the compromise. 

You can determine with pkgchk  command if  certain files have changed : 

/bin/su 
/usr/sbin/ping 
/usr/bin/du 
/usr/bin/passwd 
/usr/bin/find 
/bin/ls 
/bin/netstat 
/usr/bin/strings 

If there is any error reported on any of these files then system is compromised . The best resort in these cases is to take system off the network and do a fresh operating system installation .

       srload :

srload is a part of  root kit  which is used to get the  non-standard SSH port  access  by the attackers . Compromised systems have a entry in /etc/inittab of following line 

SV:23:respawn:/usr/bin/srload -D -q

and may have  the following file modified along with other files : 

/etc/rcS.d/S30rootusr.sh

The immediate action for this is to disable the srload command by removing it from /etc/inittab after booting in single user mode  and removing srload command binary from /usr/bin  or any other location .