Sometimes, We get the following prompt, when we try to connect a server using SSH. We type “yes”, but is there a way to avoid this.
The authenticity of host ‘111.222.333.444 (111.222.333.444)’ can’t be established.
RSA key fingerprint is f3:cf:58:ae:71:0b:c8:04:6f:34:a3:b2:e4:1e:0c:8b.
Are you sure you want to continue connecting (yes/no)?
Use the -o option,
ssh -o “StrictHostKeyChecking no” user@host
# vim /etc/ssh/ssh_config
Host * –> line no 20, Uncomment the line
StrictHostKeyChecking no –> line no 31, Uncomment the line
# /etc/init.d/sshd restart
TCP Wrappers gives the possibility to control and protect the network services, limiting the access and registering (if you want to) all the connections to make the work of detecting and resolving problems easier. To setup TCP Wrappers you work with two access control text files, they are called: /etc/hosts.allow & /etc/hosts.deny. The format to write into these files is: ” daemon_list : client_list [ : shell_command ]”
# vim /etc/hosts.allow
sshd : 192.168.10.12/255.255.255.0 : spawn (echo -e “Connected from IP %h” | mutt -s “SSH Connection is Successful” firstname.lastname@example.org) : ALLOW
# vim /etc/hosts.deny
sshd : ALL : spawn (echo -e “Access denied to external SSH Connection from IP %h ” | mutt -s “Alert – SSH Connection Denied” email@example.com) : DENY
In cases where you have to disable the login to all users,except root, for example when you have to do a backup, you have to use pam_nologin.so
1) Edit the pam file for the service you want to control, in this example i modify ssh pam control file, located in /etc/pam.d/sshd & Add the line :-
# vim /etc/pam.d/sshd
account required pam_nologin.so
2) Create the /etc/nologin file, just do “touch /etc/nologin”
# touch /etc/nologin
This should disable the login from ssh. If you want to disable the login from terminal, modify the /etc/pam.d/login file.
3) To re-enable the login just remove /etc/nologin
# rm -rvdf /etc/nologin
You can forward ports with ssh like this:
# ssh -L 8888:localhost:80 user@remotehost
This will log you into remotehost as user, and port 8888 on your local machine will be tunnelled to port 80 on remotehost. If remotehost can see a machine that you can’t (for example, if it’s on an internal network), you can even do this:
# ssh -L 8888:internalhost:80 user@borderhost
This will log you in to borderhost, and localhost:8888 will be directed to internalhost:80, even though you may not be able to see internalhost directly yourself.
Although it is a security risks, it is possible to make OpenSSH listens on multiple port. To do that, you need to edit file and enable the “GatewayPorts” option.
# vim /etc/ssh/sshd_config
1. Look for the line that contain “Port 22”, and uncomment it if necessary, and add additional Port line to enable OpenSSH to listen to other ports. Like this:
2. The example will enable OpenSSH to listen to port 22,80,1025 simultaneously. Don’t forget to restart SSH service to enable the change by running:
# /etc/init.d/sshd restart
Warning: Running SSH on multiple port may cause security risk, you have been warned!
System-1 :- 192.168.1.5
System-2 :- 192.168.1.10
ssh-keygen creates the public and private keys
ssh-copy-id copies the local-host’s public key to the remote-host’s authorized_keys file and also assigns proper permission to the remote-host’s home, ~/.ssh, and ~/.ssh/authorized_keys.
Step 1: Create public and private keys using ssh-key-gen on local-host –> 192.168.1.5
192.168.1.5# ssh-keygen -t rsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): [Enter key]
Enter passphrase (empty for no passphrase): [Enter key]
Enter same passphrase again: [Enter key]
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is: 93:58:20:56:72:d7:bd:14:86:9f:42:aa:82:3d:f8:e5 firstname.lastname@example.org
Step 2: Copy the public key to remote-host –> 192.168.1.10 using ssh-copy-id
192.168.1.5# ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.1.10
Now try logging into the machine, with “ssh ‘192.168.1.10’”, and check in:
to make sure we haven’t added extra keys that you weren’t expecting.
Note: ssh-copy-id appends the keys to the 192.168.1.10’s .ssh/authorized_key.
Step 3: Login to remote-host without entering the password
192.168.1.5# ssh 192.168.1.10
Last login: Sun Nov 16 17:22:33 2011 from 192.168.1.5
[Note: SSH did not ask for password.]
[Note: You are on remote-host here]
If you want to receive email alert when someone makes a root login to the Server.
1. open the file /root/.bashrc
# vi /root/.bashrc
2. Scroll to the end of the file then add the following:
echo ‘ALERT – Root Shell Access (YourserverName) on:’ `date` `who` | mail -s “Alert: Root Access from `who | cut -d'(‘ -f2 | cut -d’)’ -f1`” email@example.com
As with all security it comes in layers. The more layers you add the more difficult it will be to gain access to your server. One of the first things you will want to do is harden sshd as it is a primary avenue to gaining access to your server.
Step 1: First of all we need to make a regular user, since we are disabling direct root login:
# useradd admin
# passwd admin
Step 2: Backup your current sshd_config
# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Step 3: Edit sshd_config file
# vi /etc/ssh/sshd_config
## Change to other port is recommended, etc 8875
## Sets listening address on server. default=0.0.0.0
## ListenAddress 192.168.0.1
## Enforcing SSH Protocol 2 only
# Protocol 1,2
## Disable direct root login, with no you need to login with admin user, then “su -” you into root
## Disables X11Forwarding
## Checks users on their home directority and rhosts, that they arent world-writable
## The option IgnoreRhosts specifies whether rhosts or shosts files should not be used in authentication
## RhostsAuthentication specifies whether sshd can try to use rhosts based authentication.
## Adds a login banner that the user can see
## Enable / Disable sftp server
#Subsystem sftp /usr/libexec/openssh/sftp-server
## Add users that are allowed to log in
Save the Files
Step 4: Add text to MOTD Banner file (/etc/motd)
# vi /etc/motd
Step 5: Restart the SSHD Daemon
# service sshd restart
If you are going to connect to a remote host computer using public-key authentication, you will have to generate your key pair before connecting.
Public-key authentication is based on the use of digital signatures. Each user creates a pair of ‘key’ files. One of these key files is the user’s public key, and the other is the user’s private key. The server knows the user’s public key, and only the user has the private key.
When the user tries to authenticate herself, the server checks for matching public keys and sends a challenge to the user end. The user is authenticated by signing the challenge using her private key.
Remember that your private key file is used to authenticate you. Never expose your private keys. If anyone else can access your private key file, they can attempt to login to the remote host computer as you, and claim to be you. Therefore it is extremely important that you keep your private key file in a secure place and make sure that no one else has access to it.
Do not use public-key authentication on a computer that is shared with other users. Generate keys only on your personal computer that no one else can access!
So lets get started, lets say you want to be able to ssh as your user “dude” to remote.com without passwords getting in your way…
# ssh firstname.lastname@example.org
and ssh will ask if you want to keep connecting, type “yes”, and then it should ask for your password and open a shell in dude’s home directory on remote.com, just like telnet. If this fails, there is a problem somewhere. Make sure ssh is installed on your end, and also make sure that remote.com is accepting ssh connections. If it’s not, you’re wasting your time.
Once ssh is functioning we will set up the keys so that it will no longer be necessary to send passwords. If you are curious about the theory of this then read up on “public key cryptography”.
Create your keys: You need to create private and public ssh keys and put them in the proper place with the proper permissions. In your home directory create a folder .ssh ($ mkdir .ssh), if there is none. Note that Windows may make it difficult for you to create a file starting with “.” if you try to do it with their tools; e.g. Windows Explorer. Next, create the keys with the command
# ssh-keygen -t dsa
The ssh-keygen program will ask for a passphrase, just hit the “Enter” key unless for some reason you know you want a passphrase. This creates the keys id_dsa and id_dsa.pub and puts them in .ssh/. The private key id_dsa must be readable only by you; change its permissions with
# chmod 600 .ssh/id_dsa
Put the public key on the remote computer: In this section we are assuming the remote computer is also running OpenSSH. Somehow, you must get the .ssh/id_dsa.pub key onto the remote computer, whether by email, ftp, carrying it over on a floppy (sneakernet), etc.; the cool way to do it is to use scp, which was installed along with ssh. Suppose the remote computer is named remote.com, and your account there is “dude”. To copy the file to remote, run
# scp .ssh/id_dsa.pub email@example.com:
Don’t forget the trailing colon. You will be asked for dude’s password on remote before the copying commences. The file will be copied to dude’s home directory on remote. Install the public key on the remote computer: (We assume the remote computer is running OpenSSH on Linux or UNIX!) Once id_dsa.pub is on the remote computer, login into the remote computer (you can use ssh to login with your password as described above). From your home directory (where you should see your newly arrived id_dsa.pub) create a .ssh folder if none exists. Then append your id_dsa.pub to a file in .ssh with
# cat id_dsa.pub >> .ssh/authorized_keys
This will create the file authorized_keys if none exists. The id_dsa.pub key may be removed from the remote computer’s home directory, if you like. The .ssh folder on the remote computer must have the correct permissions, you may set them with
# chmod 700 .ssh
Checking the password-less connection: Now the command
# ssh firstname.lastname@example.org
should give you a password-less connection to remote.com. Likewise, scp should be password-free. By the way, all the commands you do by first logging into the remote computer can be done remotely, one at a time, using ssh. For example, you can run run
# ssh email@example.com ls
and get a listing of your home directory files on the remote system.
By IPtables, We can secure SSH server against bruteforce attacks
:- Create a new table…
# iptables -N SSH_WHITELIST
:- On the input chain, mark new packets with the SSH ‘tag’
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH
:- Push new ssh connections through the SSH_WHITELIST table
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSH_WHITELIST
:- Limit 4 connections from an ip per 60 seconds, to be more strict, use 300 seconds.
:- Log connections that go over this limit and drop the packets.
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j ULOG –ulog-prefix SSH_brute_force
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j DROP
:- Check source IPs, if they match trusted hosts, remove SSH ‘tag’ and accept the traffic.
# iptables -A SSH_WHITELIST -s 10.0.1.1 -m recent –remove –name SSH -j ACCEPT
# iptables -A SSH_WHITELIST -s 192.168.88.0/24 -m recent –remove –name SSH -j ACCEPT
# /etc/init.d/iptables save
# chkconfig iptables on
Sometimes the sshd service may be fails, we have check everything, looked fine and reinstall of the service did not work either. There was no error shown at service start-up, but the service status showed it was down :
# /etc/init.d/sshd start
Starting sshd: [ OK ]
# /etc/init.d/sshd status
openssh-daemon is stopped
I checked the /var/log/secure logs to see what error is being thrown and it showed below error :
Sep4 13:54:54 vps sshd: fatal: daemon() failed: No such device
I had to do some search to find out which device its referring to in this error, it turned out that its related to /dev/null which is supposed to be a proper character device and not a regular file. In this case it was a regular file so I removed it and recreated the character device as below :
# rm -f /dev/null
# mknod /dev/null c 1 3
Once the character device is created the permissions should look like below :
# ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Jan 12 16:07 /dev/null
After this was confirmed that /dev/null is a proper character device , I restarted the service and it came up fine this time :
# /etc/init.d/sshd start
Starting sshd: [ OK ]
# /etc/init.d/sshd status
openssh-daemon (pid 27662) is running…
So if you came across this error for ssh service failure, then make sure that /dev/null is a proper character device, recreating that as proper character device should fix the issue.
If you are locked out and can’t SSH to your server, WHM Autofixer may help you! Read this to know more about WHM Autofixer. Here is process to restore SSH settings and access :-
1. Login to your WHM using the following URL:
Change the HOSTNAME-OR-IP as appropriate for you.
2. In the Autofixer interface, put the name safesshrestart as shown on the image.
WHM SSH Autofixer
3. Hit the Submit button.
This will restore your SSH configuration and restart your sshd! You should be able to login easily after that!
You may get blank terminal while accesing the remote server via SSH. Fix is very simple. Just execute the following command in the remote server.
# setterm -blank 0
If you screen was blanking this should prevent it. This is hardware related issue like overheating, bad motherboard etc.
To enable print last login information after login in to shell, we have to login in to shell as root user and make following changes in sshd_config file. Open sshd_config file in your favorite editor.
# vi /etc/ssh/sshd_config
find line “PrintLastLog” and change it from “No” to “Yes”.
Save and exit file. Restart the sshd service.
# /etc/init.d/sshd restart
Now open duplicate ssh session and check PrintLastLog option is working or not.
In a cPanel server, you may find logs are often stored differently comapring a control panel less server. Even Plesk saves logs in different paths. Here is a list of services and their log path that may help you finding the logs.
hostname should be resemble your hostname.
/var/log/xferlog (symlinked to /usr/local/apache/domlogs/ftpxferlog)
System (cron, syslog, named, etc)
Security (ssh, ModSecurity, etc)
1. Secure /tmp and /var/tmp
If they are running cPanel (I usually look for the ‘/scripts’ directory) then run /scripts/securetmp This will remount the ‘/tmp’ and ‘/var/tmp’ as ‘noexec’.
Sometimes cPanel has an issue with /tmp permissions. Run the following:
# ls -al /
if you see: drwxr-xr-x 5 root root xxxxx mon xx xx:xx /tmp
You’ll need to chmod the /tmp directory to 1777 in order to set the sticky bit.
# chmod 1777 /tmp
If they are not running cPanel you will manually need to mount the filesystems as nonexecutable. If the user has a separate partition for /tmp, you can simply remount it with noexec,nosuid options. You can edit /etc/fstab with this options, then type “mount –o remount /tmp”. You can then create a symbolic link from /var/tmp to /tmp (“ln –s /tmp /var/tmp”). Keep in mind you will need to backup any files in /var/tmp and move them to /tmp. Pay special attention to the MySQL socket, as it will like need to be recreated. After creating the symbolic link, remove the MySQL socket and recreate it:
# mount -o rw,noexec,nodev,nosuid,remount /tmp
# rm –rf /tmp/mysql.sock
# ln –s /var/lib/mysql/mysql.sock /tmp/mysql.sock
If they do not have a separate partition for /tmp, you will need to create a loopback filesystem. Issue the following series of commands:
# dd if=/dev/zero of=/dev/tmpMnt bs=1024 count=512000
# mke2fs /dev/tmpMnt
# mkdir /tmp.bak
# mv /tmp/* /tmp.bak/ (verify that dot-files are also moved)
# mount -o loop,noexec,nosuid,rw /dev/tmpMnt /tmp
# mv /tmp.bak/* /tmp/ (again, very that dot-files are also moved)
# rm -rf /tmp.bak
# chmod 1777 /tmp
# vi /etc/fstab (add: /dev/tmpMnt /tmp ext2 loop,nosuid,noexec,rw 0 0)
The above commands create a 512MB loopback filesystem for /tmp, then mounts it as non-executable. From here, you can create a symbolic link from /var/tmp as described above.
2. Secure /usr/local/apache/proxy
Remove the directory and create a symbolic link from it to a secured /tmp:
# rm -rf /usr/local/apache/proxy
# ln -s /tmp /usr/local/apache/proxy
3. Secure /dev/shm
/dev/shm is basically a ramfs. As it is world-writable we recommend unmount it or at least removing its permissions:
# umount /dev/shm (you cannot be in the directory when executing this command)
# vi /etc/fstab (comment out # the entry for /dev/shm)
# chmod o-w /dev/shm
4. Secure /var/spool/ directories
This will remove world write access.
# chmod -R o-w /var/spool
5. Make sure the machine is current on patches
If the machine has cPanel on it please make sure the pkgSkipList contains the following (run /usr/sbin/up2date –configure):
You can run /scripts/checkup2date and it will add these automatically.
From here it is usually best to let cPanel install some of the needed RPM’s it knows it needs. You can accomplish this by running /scripts/rpmup
Now you can go ahead and run /usr/sbin/up2date -l to see what packages are available for install/upgrade.
Right under ‘Fetching rpm headers…’ will be all the packages available to the server. To update these run
# /usr/sbin/up2date -u
Now under ‘The following Packages were marked to be skipped by your configuration:’ it will list the packages available but are being skipped by the skiplist above. We are mostly worried about the kernel. If you see a kernel listed here, run:
# /usr/sbin/up2date -uf kernel kernel-smp kernel-utils kernel-source
Once this has completed you will want to make sure we are booting the correct kernel. Run /bin/uname -r to see which kernel is booting currently. From here run /bin/vi /boot/grub/grub.conf and you should see the newly installed kernel and more than likley others kernels that were previously installed. If the customer was already running a RedHat kernel (usually something like ‘2.4.21-15.0.4-EL’) than it is usually safe to change it to boot the new RedHat kernel you just installed. It should be listed as the very first kernel, if so all you would do is change the ‘default=x’ to ‘default=0’. If the customer was running a customer kernel (something like ‘2.6.6’ or ‘2.4.26-grsecvx’) than you would want to leave the ‘default=x’ line set to the kernel they were booting before.
If the server is running cPanel make sure it has the latest stable version by typing:
Make sure you restart cPanel after this (if it installed a newer version) by running: service cPanel restart
6. Disable unnecessary services
Verify the runlevel that we are currently running in by running ‘runlevel’. This will more than likely be ‘3’. Run: /sbin/chkconfig –list | grep <insert runlevel number>:on
This will list all the services that are starting on boot for the runlevel.
Look for services that are not needed such as:
Note: do NOT disable ‘netfs’ as this will break /scripts/securetmp
Stop each service you find like so:
# /etc/init.d/<service name> stop
To disable the services run:
# /sbin/chkconfig –level 123456 <service name> off for each service.
7. Check for who has shell access and restrict accordingly
This will return only the users that have a valid login shell to the machine.
for i in `/usr/bin/chsh –list-shells | grep -v ‘(noshell|nologin)’`; do grep $i /etc/passwd; done
To lock the appropriate accounts down do the following:
# /usr/bin/chsh -s /usr/local/cpanel/bin/noshell <insert username>
8. Add new user for SSH login
# /usr/sbin/adduser -G wheel -d /home/<cxxxxx > -c “<cxxxxx>” -m < cXXXXX>
Change the Password for the new user to something random and hard to guess (letters and digits) (preferably 10 characters at least) You can use: password generator
Note: Make sure you tell the customer what you changed this to and update the hw object in Orbit.
9. Disable root login with SSH
Run the following
Change ‘PermitRootLogin yes’ to ‘PermitRootLogin no’ Make sure it is uncommented (take the ‘#’ out from the front of the line if it is there). This disables the ability to ssh into server as root. Customer must use newly created login and then ‘su’ to root if needed after login.
Change ssh port to 33988 to avoid Brute Force attacks on port 22.
Remove protocol 1 (leave the 2 next to protocol) and uncomment line.
Uncomment #Banner and change /some/path to /etc/motd
Save file and exit. (:x)
10. Displaying Login Banners
To display a warning banner, vi the /etc/motd file and paste the following:
# vi /etc/motd
Only authorized users may log into this commercial computer system. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to authorized sites, ISPs, and law enforcement personnel, as well as authorized officials of other agencies, domestic, foreign, and The Planet Information Security team. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of authorized site or The Planet Information Security team. Unauthorized or improper use of this system may result civil and criminal penalties. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use.
LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning under US CODE: Title 18, U.S.C.
11. Create the btmp file
As root, run
# /bin/touch /var/log/btmp
This will allow the user to type ‘lastb’ and display all ‘bad’ logins to the server.
The /etc/securetty file allows you to specify which TTY devices the root user is allowed to login on. Remove all ttys from /etc/securetty except tty1. Which means only root is allowed to login on tty1, forcing the user have to log in as wheel and su if they need more devices as root.
The file will look like this:
”’sometimes there will not be a ttS0.”’
13. Root email
LogWatch: An email gets sent out everyday that contains basic information about the server such as free space, bad login attempts to the machine, etc. It sends this report to root@localhost. If the customer does not ever check the mail on the server locally they will never see these emails. If they DO NOT have cPanel do the following to ensure they get emailed these reports ‘vi /root/.forward’. In this file put the customers primary email address in the only line in this file and save it out. This essentually forwards all of root’s email to this email address.
Note that if they are running Qmail you may need to edit /root/.qmail. Qmail uses a slightly different syntax: an ampersand (&) is placed before the e-mail address:
echo “&firstname.lastname@example.org” > /root/.qmail
14. Apache (optional)
Note: not entirely necessary since we are doing O/S Hardening and not application hardening
Run /bin/vi /etc/httpd/conf/httpd.conf (assuming this is where the running httpd.conf file is installed) and either add the following lines, or if they already exist, change them to reflect the following
ServerTokens Prod #This will tell Apache to hide all the modules it has installed and only report that they are running Apache as the webserver)
ServerSignature Off #This will tell Apache to not show what version of Apache is running on the server when someone hits a page not found,etc).
15. Enabling Password Restrictions
The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:
# vi /etc/login.defs
PASS_MAX_DAYS 60 Maximum number of days a password is valid.
PASS_MIN_DAYS 7 Minimum number of days before a user can change the password since the last change.
PASS_MIN_LEN n/a This parameter does not work. It is superseded by the PAM module “pam_cracklib”. See Setting Password Restrictions for more information.
PASS_WARN_AGE 7 Number of days when the password change reminder starts.
INACTIVE 14 Number of days after password expiration that account is disabled.
EXPIRE Account expiration date in the format YYYY-MM-DD.
Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files.
16. Setting Password Restrictions
The following example shows how to enforce the following password rules:
Minimum length of password must be 8
Minimum number of lower case letters must be 1
Minimum number of upper case letters must be 1
Minimum number of digits must be 1
Minimum number of other characters must be 1
Restrict the use of previous passwords
pam_cracklib.so minlen=8 Minimum length of password is 8
pam_cracklib.so lcredit=-1 Minimum number of lower case letters is 1
pam_cracklib.so ucredit=-1 Minimum number of upper case letters is 1
pam_cracklib.so dcredit=-1 Minimum number of digits is 1
pam_cracklib.so ocredit=-1 Minimum number of other characters is 1
/etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in bold:
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=26
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
NOTE: If the /etc/security/opasswd doesn’t exist, create the file.
# ls -l /etc/security/opasswd
-rw——- 1 root root 0 Dec 8 06:54 /etc/security/opasswd
17. SUID/SGID Audit
To search the entire system for SUID or SGID files, you can run the following command:
# find / -path /proc -prune -o -type f -perm +6000 -ls
To remove the setuid/gid bit for files do:
# chmod u-s (file) “OR”
# chmod g-s (file)
Only on the following files:
Also be sure to chmod 0 all the r-tools in /usr/bin. These are /usr/bin/rcp /rsh /rlogin, /telnet.
Then do ls –al (file) to confirm that suid/gid has been removed
18. World Writable Directory Audit
To search entire system for world writable directories, you can run the following:
# find / -path /proc -prune -o -perm -2 ! -type l -ls
The “! -type l” parameter skips all symbolic links since symbolic links are always world-writable. However, this is not a problem as long as the target of the link is not world-writable, which is checked by the above find command.
Be sure to chmod wget and permissions on var/spool/samba,mail, and vbox (world writable directories). Also check permissions on system binaries (telnet, etc).
19. Unowned Files Audit
# find / -path /proc -prune -o -nouser -o -nogroup
20. Kernel Tunable Parameters
add to the /etc/sysctl.conf configuration file to make the change permanent after reboots.
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1
#Increase the backlog q size
#Decrease the total time we keep half-open connections in #the backlog q to 9 seconds
#Disable IP Source Routing
net.ipv4.conf.all.accept_source_route = 0
#Enable IP Spoofing Protection
net.ipv4.conf.all.rp_filter = 1
#Enable Logging of Spoofed Packets, Source Routed #Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
To activate the configured kernel parameters immediately at runtime, use: (you can copy and paste)
# sysctl -p
21. Modify Permission/Ownership of sysctl.conf (Kernel Runtime Configurator)
# chown root:root /etc/sysctl.conf
# chmod 600 /etc/sysctl.conf
22. Audit permissions on key system log files in var/log
# ls -al /var/log
Remove the “other” groups read and execute permissions on log files. Most of these log files are owned by root but an audit still needs to be done to ensure integrity of log files.
23. Verify permissions on passwd, shadow, and group
# cd /etc
# ls -al group shadow passwd
Should return 644 permissions on passwd and group Should return 400 permissions on shadow (on cPanel boxes this should be 600)
24. Cron permissions
Restrict cron/at to authorized users by creating the cron.allow file. The cron.allow file only controls administrative access to the crontab command for scheduling and modifying cron jobs
# echo root > cron.allow
# echo root > at.allow
# echo nobody >> cron.deny
# echo nobody >> at.deny
# chown root:root cron.allow at.allow
# chmod 400 cron.allow at.allow
The system crontab files are accessed by only the cron daemon (which runs with superuser privileges) and the crontab command (which has setuid to root). Allowing regular users to read or modify system crontab files can lead to elevated privileges. Therefore, do the following countermeasures:
# chown root:root /etc/crontab
# chmod 400 /etc/crontab
# chown -R root:root /var/spool/cron
# chmod -R go-rwx /var/spool/cron
When you connect to an OpenSSH sshd server, it is configured by default to do a hostname lookup on your IP address.
If there are any issues with the DNS configuration on the host machine, or with the DNS server it is using, this can lead to a delay when logging in using ssh for around 30 seconds and making this change may introduce a security risk as full checking is no longer done on the hostname and IP address. It is very easy to switch this host name lookup function off in the sshd_config file.
On most Linux distributions, the sshd_config file will be at /etc/ssh/sshd_config,
This is correct for recent versions of sshd but older versions might use the following configuration option instead
After making the above change to the configuration file, it’s simply a matter of reloading the SSH daemon.
# /etc/init.d/sshd restart
UseDNS – Specifies whether sshd should look up the remote host name and check that the resolved host name
for the remote IP address maps back to the very same IP address. The default is “yes”.
Sometimes we manually need to run the logs for particular account in cPanel , we can easily do this via SSH Log in as root, For particular account only use following commands :-
and for all accounts