Server and Web Security

1 :: Server Security

A :: Direct root access or root user disable

with Custom Port no. for SSH

OpenSSH is the implementation of the SSH

protocol. OpenSSH is recommended for remote
login, making backups, remote file transfer via scp
or sftp, and much more. SSH is perfect to keep
confidentiality and integrity for data exchanged
between two networks and systems.
However, the main advantage is server
authentication, through the use of public key
cryptography. From time to time there are rumors
about OpenSSH zero day exploit. Here are a few
things you need to tweak in order to improve
OpenSSH server security.
Default Config Files and SSH Port
/etc/ssh/sshd_config - OpenSSH server
configuration file.
/etc/ssh/ssh_config - OpenSSH client
configuration file.
~/.ssh/ - Users ssh configuration directory.
~/.ssh/authorized_keys or
~/.ssh/authorized_keys - Lists the public keys (RSA
or DSA) that can be used to log into the users
account
/etc/nologin - If this file exists, sshd refuses to
let anyone except root log in.
 /etc/hosts.allow and /etc/hosts.deny : Access
controls lists that should be enforced by tcp-
wrappers are defined here.
SSH default port : TCP 22

1: You can Disable OpenSSH Server

Workstations and laptop can work without

OpenSSH server. If you need not to provide the
remote login and file transfer capabilities of SSH,
disable and remove the SSHD server. CentOS /
RHEL / Fedora Linux user can disable and remove
openssh-server with yum command:
# chkconfigsshd of
# yum erase openssh-server

2: Always Use SSH Protocol 2 only

SSH protocol version 1 (SSH-1) has man-in-the-

middle attacks problems and security
vulnerabilities. SSH-1 is obsolete and should be
avoided at all cost. Open sshd_config file and make
sure the following line exists:
Protocol 2

3: Limit Users' SSH Access

By default all systems user can login via SSH using

their password or public key. Sometime you create
UNIX / Linux user account for ftp or email purpose.
However, those user can login to system using ssh.
They will have full access to system tools including
compilers and scripting languages such as Perl,
Python which can open network ports and do many
other fancy things. One of my client has really
outdated php script and an attacker was able to
create a new account on the system via a
phpscript. However, attacker failed to get into box
via ssh because it wasn't in AllowUsers.
Only allow root, vivek and jerry user to use the
system via SSH, add the following to sshd_config:
AllowUsers root vivek jerry
Alternatively, you can allow all users to login via
SSH but deny only a few users, with the following
line
DenyUserssarojanjali foo
You can also configure Linux PAM allows or deny
login via the sshd server. You can allow list of group
name to access or deny access to the ssh.

4: Configure Idle Log Out Timeout Interval

User can login to server via ssh and you can set an
idel timeout interval to avoid unattended ssh
session. Open sshd_config and make sure following
values are configured:
ClientAliveInterval 300
ClientAliveCountMax 0
You are setting an idle timeout interval in seconds
(300 secs = 5 minutes). After this interval has
passed, the idle user will be automatically kicked
out (read as logged out).

5: Disable .rhosts Files

Don't read the user's ~/.rhosts and ~/.shosts files.

Update sshd_config with the following settings:
IgnoreRhosts yes
SSH can emulate the behavior of the obsolete rsh
command, just disable insecure access via RSH.

6: Disable Host-Based Authentication

To disable host-based authentication, update

sshd_config with the following option:
HostbasedAuthentication no

7: Disable root Login via SSH

There is no need to login as root via ssh over a

network. Normal users can use su or sudo
(recommended) to gain root level access. This also
make sure you get full auditing information about
who ran privileged commands on the system via
sudo. To disable root login via SSH, update
sshd_config with the following line:
PermitRootLogin no

8: Firewall SSH Port # 22

You need to firewall ssh port # 22 by updating
iptables or other firewall configurations. Usually,
OpenSSH server must only accept connections
from your LAN or other remote WAN sites only.
Netfilter (Iptables) Configuration
Update /etc/sysconfig/iptables (Redhat and friends
specific file) to accept connection only from
192.168.1.0/24 and 202.54.1.5/29, enter:
iptables -A RH-Firewall-1-INPUT -s 192.168.1.0/24
-m state --state NEW -p tcp --dport 22 -j ACCEPT
iptables -A RH-Firewall-1-INPUT -s 202.54.1.5/29 -m
state --state NEW -p tcp --dport 22 -j ACCEPT
If you've dual stacked sshd with IPv6, edit
/etc/sysconfig/ip6tables (Redhat and friends
specific file), enter:
-A RH-Firewall-1-INPUT -s ipv6network::/ipv6mask
-m tcp -p tcp --dport 22 -j ACCEPT

9: Change SSH Port and Limit IP Binding

By default SSH listen to all available interfaces and
IP address on the system. Limit ssh port binding
and change ssh port (by default brute forcing
scripts only try to connects to port # 22). To bind to
192.168.1.5 and 192.168.1.6 IPs and to port 300,
add or correct the following line:
Port 300
ListenAddress 192.168.1.5
ListenAddress192.168.1.6

10: Use TCP Wrappers

TCP Wrapper is a host-based Networking ACL
system, used to filter network access to Internet.
OpenSSH does supports TCP wrappers. Just update
your /etc/hosts.allow file as follows to allow SSH
only from 192.168.1.2 172.16.23.12 :
sshd : 192.168.1.2 172.16.23.12
See this FAQ about setting and using TCP wrappers
under Linux / Mac OS X and UNIX like operating
systems.

11: Disable Empty Passwords

You need to explicitly disallow remote login from

accounts with empty passwords, update
sshd_config with the following line:
PermitEmptyPasswords no

12: Use Public/Private Keys for Authentication

First, create a public/private key pair on the client

that you will use to connect to the server (you will
need to do this from each client machine from
which you connect):
$ ssh-keygen -t rsa
This will create two files in your (hidden) ~/.ssh
directory called: id_rsa and id_rsa.pub The first:
id_rsa is your private key and the other: id_rsa.pub
is your public key.
Now set permissions on your private key:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa
Copy the public key (id_rsa.pub) to the server and
install it to the authorized_keys list:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Note: once you've imported the public key, you can
delete it from the server.
and finally set file permissions on the server:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
The above permissions are required if StrictModes
is set to yes in /etc/ssh/sshd_config
Ensure the correct SELinux contexts are set:
$ restorecon -Rv ~/.ssh
Now when you login to the server you won't be
prompted for a password
By default, ssh will first try to authenticate using
keys. If no keys are found or authentication fails,
then ssh will fall back to conventional password
authentication.
Once you've checked you can successfully login to
the server using your public/private key pair, you
can disable password authentication completely by
adding the following setting to your
/etc/ssh/sshd_config file:
# Disable password authentication forcing use of
keys
PasswordAuthentication no

B :: Default FTP disable

Usually customers using weak FTP passwords are
more susceptible to brute force attacks. We can
change the FTP port but its not going to solve the
problem. We strictly recommend all our clients to
use a strong FTP passwords. A strong password
comprises of upper case, lower case, numeric and
special characters.

You can do this by edinga ftp configuration file, for

this you will need root ssh access.
1) ssh to server with your favouritssh client.
2) Edit cpanel ftp configuration file.
Vi /usr/local/cpanel/bin/ftpupdate
and comment following line by placing #
at the starting of the line.
print FTPASS join( :, $ENT[0], $ENT[1],
$ENT[2], $ENT[3], $ENT[6], $ENT[7],
$ENT[8] ) . \n;

Now restart cpanel service.

/etc/init.d/cpanel restart.

C :: SSH and WHM access configured for

specific IPs

How To Restrict SSH Access

SSH access for your Linux server can be restricted using a
software firewall such as IPtables or ConfigServer Security &
Firewall "CSF".

If you are only running the default Linux firewall "IPtables",

then you should already have SSH access to your server
configured as per the best practices recommended for your
Linux Distribution.

For the following example, we will use CentOS as an example.

IP Restricting CentOS using IPtables:

If you only need remote access from singular IP addresses (say

from work to your home server), then consider filtering
connections at your firewall by either adding a firewall rule on
your router or in iptables to limit access on port 22 to only that
specific IP address. For example, in iptables this could be
achieved with the following type of command via SSH:

iptables -A INPUT -p tcp -s <ip address> --dport 22 -j

ACCEPT

IP Restricting CentOS using ConfigServer Security &

Firewall "CSF":
Note: If you are not familiar with IPtables and you are running
cPanel/WHM it is generally convenient to install CSF as it
includes a cPanel/WHM plugin for GUI management of firewall
settings. You can view documentation regarding CSF installation
here: http://configserver.com/cp/csf.html

ConfigServer How To:

For CSF you can either login to WHM and goto Plugins and
view the CSF configuration. From here you can select "Firewall
Allow IPs" and add in your IP address then save & restart.

Alternatively you can use SSH.

Whitelist or allow an IP address via SSH:

csf -a <ip address>

Example:

csf -a 202.18.64.12

You can also block access to the SSH port using CSF.

From WHM, goto CSF and select "Firewall Configuration".

Scroll down to the section for "Allow incoming TCP ports" and
remove port 22 from this list. Alternatively, remove your custom
SSH port.
From SSH:

1. Use your text editor eg vi or nano, to open /etc/csf/csf.conf

vi /etc/csf/csf.conf

2. Remove your SSH port eg. 22, from from the line containing
TCP_IN for allowed incoming TCP ports.

Once you have changed & restart CSF using following

command

csf -r

You can do this in Host Access Control area in WHM. It's the
easier way to do it and pretty straightforward to setup.

Simply put the following into WHM > Host Access Control
area:
Code:
Daemon Access List Action Comment
whostmgrdYourIP allow
whostmgrd all deny

D :: Software Firewall installed to monitor the

traffic and block unauthorized activity
E :: Mod Security enabled with custom rules
to block unauthorized http requests

What is ModSecurity?
ModSecurity is an open source intrusion detection and
prevention engine for web applications. Operating as an
Apache Web server module, the purpose of ModSecurity
is to increase web application security, protecting web
applications

ModSecurity Rules

cPanel supplies a few sample rules with the installation

done through WHM. Those rules apparently seem to work
well with cPanel/WHM servers. Rules need to be added
to /usr/local/apache/conf/modsec.user.conf. If you add
rules to modsec.conf you will need to be aware that this
file will be overwritten. The sample rules can be found at
/usr/local/apache/conf/modsec.user.conf.default. If you
want to work with these rules you will have to logon to
your server via SSH and type the following from the
command line:

cp /usr/local/apache/conf/modsec.user.conf.default
/usr/local/apache/conf/modsec.user.conf

You will then need to restart Apache to have the rules take
affect. You will be able to use the WHM build-in editor to
modify the configuration.
If you want to create your own rules you will need to follow
some basics. Please be aware that every rule consists of
5 parameters (Title, Description, Action, Focus, Rule). At
this point we do not recommed to use rules outside of the
ones that come with cPanel to avoid breaking your server

Whm> Mod Security > edit config

Mod security configuration will included in
/etc/httpd/conf/httpd.conf apache file.

Include /usr/local/apache/conf/modsec2.conf

Use the following link for more about mod security options and
rules.

http://www.modsecurity.org/documentation/modsecurity-
apache/2.5.5/modsecurity2-apache-reference.html#N109A9

F :: CloudLinux installed to limit the resource

uses for users

what is cloudlinux
CloudLinux is a commercially supported Linux
operating system interchangeable with CentOS. It
includes kernel level technology called LVE that
allows you to control CPU and memory on per
tenant bases. It is a bases for application level
virtualization. CloudLinux delivers advanced
resource management, better security and
performance optimizations specifically targeted to
multi-tenant hosting environment. This improved
performance helps hosting service providers and
datacenters provide better support to their
customers, reduce churn and save money.
How do memory limits work?

CloudLinux allows to set limit for virtual memory. If

applications inside LVE try to use more then the limit set, they
will be prevented from doing so. And the application that
requested memory from OS that caused it to go over limit, will
most likely fail (because it wasn't been able to allocate memory).
The memory limit is for sum of virtual memory used by all
applications. Also, please, note, that it is virtual memory, not
physical memory. Multiple processes often share a lot of
physical memory, yet they don't share virtual memory. As the
result you would need much more virtual memory than physical
memory. This is why it is important to leave virtual memory
limit high enough.
Each time LVE hits a memory limit, we increment memory fault
counter for that LVE. You can find out which LVEs are hitting
memory limits by running:
# lveinfo --by-fault=mem --display-username
--period=1d
Which Control Panels are supported?
CloudLinux works with following control panels:

cPanel

Plesk

HostingController

ISP Manager

InterWorx

DirectAdmin

H-Sphere

Webmin

Confixx

Why use CloudLinux for shared hosting?

With CloudLinux you can achieve better stability for your
environment. LVE technology in CloudLinux makes sure that
single site cannot bring down or slow down the whole server.
Without LVE, any site can start using too much CPU, and cause
all other sites on the server to slow down.
LVE will slow down the offending site, but all other sites will
continue to work.
Additionally LVE allows you to clearly see which sites uses
majority of resources. That would allow you to manage such
sites and achieve much higher server utilization, and density in
your shared hosting environment.

How to install cloudlinux?

The process for installing CloudLinux on your cPanel server is

quite easy to follow and generally only takes a couple of
minutes. Please use the step-by-step directions outlined below to
get CloudLinux installed.

Login to your cPanel/WHM server using SSH

Next, run the following command via SSH:

wget
http://repo.cloudlinux.com/cloudlinux/sources/cln/cpanel2c
l &&
sh cpanel2cl -k <activation_key>&&
reboot

Adjust the times outlined in BOLD to their correct values

After your server has rebooted, please run (via SSH):

# /scripts/easyapache --build
G :: Disable wget, find and lynx for normal
users

Wget, find and lynx are used by hackers to scan

the server. So, this commands will disable for
normal users. You can do it with following steps;

First check the wget, lynx and find binaries path by

using the command.

whichwget
which lynx
which find

The above command will provide wget, lynx and

find binaries path.

/usr/bin/wget
/usr/bin/lynx
/usr/bin/find

NOTE :: These path may change server to server

Now add the new group which is actually used to

enable wget, lynx and find binaries for specific
users only.

groupadd xyz
Now change the group for the wget, lynx and find
binaries.

chgrp xyz /usr/bin/wget

chgrp xyz /usr/bin/lynx
chgrp xyz /usr/bin/find

Disable the wget, lynx and find binaries.

chmod 710 /usr/bin/wget

chmod 710 /usr/bin/lynx
chmod 710 /usr/bin/find

If we want to enable above binaries for specific

cPanel User, please execute following command;

For example, we want to enable the wget binary to

the test123 user then run the following command.

usermod -G xyz test123

H :: Disabled Sym link

There is a serious security hole in the way that Apache handles

symlinks on shared servers.

This allows an exploited account on a server to view .php files

owned by other accounts, thus escalating a single-account
exploit to potentially many accounts on the one server. This
post describes how to plug these holes very portably.
Rather disappointingly, for various reasons to do with ownership
of the problem, nobody has taken responsibility for this hack
which is nearly as serious as the old suphp/DSO issue which
allowed much the same sort of exploit (ie allowed users to read
other users PHP files).

The exploit, in general terms, is to create a symbolic link file

(egpublic_html/fred.txt) pointing to a wp-config.php file
(eg/home/otheracct/public_html/wp-config.php) which contains
database user and password which will occasionally be the
cpanel username/password. The file is then readable via a web
browser and the hacker proceeds. If the user has been unwise
enough to use their cpanel username/password for the database,
its even worse for the account.

Fixes
At present there are two possible fixes
1. In .htaccess or global httpd.conf, add
SymLinksIfOwnerMatch
2. Change permissions on config .php files (or all
executable/data files) to be mode 600
Both of these have weaknesses #1 as exploiter can often
simply disable SymLinksIfOwnerMatch by overwriting
.htaccess, #2 as users have to remember to secure their files and
many users will not even know this is needed.
Important point: changing permissions blocks the symlink
hack in the kernel. The weakness with changing permissions is
only if you leave it up to users; if you enforce restricted
permissions on .php files I believe the protection is 100%.

Below Im publishing/advertising two fixes, the first from

cPanels forum a few years ago. There are other fixes that are
more involved that change the way the kernel works. While
these also resolve the issue, installing both of these fixes is
currently a 100% protection.

Fix 1 Forcing SymLinksIfOwnerMatch to

always be on:
Steven of Rack911 has published an easyapache patch which
adds the file /scripts/before-apache-make to force
SymLinksIfOwnerMatch to be always on. This largely mitigates
the issue, although there is apparently a race condition which
can be exploited to work around the patch. Still, it makes the
hole harder to exploit as is.

tinyurl.com/symlink-patch (tinyurl created by me) or the actual

link:
http://forums.cpanel.net/f185/how-prevent-creating-symbolic-
links-non-root-users-202242-p2.html#post996441

This is a cPanel specific patch, but should be adaptable to other

control panel varieties. On cPanel, youll need to run
cPanelseasyapache or other httpd rebuild process after installing
the patch file. This avoids the quick and easy skript kiddie
exploits, but does not avoid the race condition (which would be
a lot harder to exploit and may not yet be fully in the wild).

Fix 2 periodically force .php file permissions

to be mode 600
php-mode-fast this should be run hourly to change all new
*config*.php files from /etc/cron.hourly. It changes permissions
on the most obvious and easily found configuration files.

php-mode-600 this should be run daily from

/etc/cron.daily. It changes all PHP files on the
server to remove group and all read permission.

I :: Enabled TCP wrapper

tcp-wrappers: Almost all of the services provided

through inetd are invoked through tcp-wrappers by
way of the tcp-wrappers daemon, tcpd. The tcp-
wrappers mechanism provides access control list
restrictions and logging for all service requests to
the service it wraps. It may be used for either TCP
or TCP services as long as the services are invoked
through a central daemon process such as inetd.
These programs log the client host name of
incoming telnet, ftp, rsh, rlogin, finger etc....
requests. Security options are access control per
host, domain and/or service; detection of host
name spoofing or host address spoofing; booby
traps to implement an early-warning system. From
Linux System Security

TCPD Benefits
1. Logging - Connections that are monitored by tcpd are
reported through the syslog facility.
2. Access Control - tcpd supports a simple form of access
control that is based on pattern matching. You can evern
hook the execution of shell commands / script when a
pattern matches.
3. Host Name Verification - tcpd verifies the client host
name that is returned by the address->name DNS server by
looking at the host name and address that are returned by
the name->address DNS server.
4. Spoofing Protection
How do I Find Out If Program Is Compiled
With TCP Wrappers Or Not?
To determine whether a given executable daemon
/path/to/daemon supports TCP Wrapper, check the man page, or
ennter:

$ ldd /path/to/daemon | grep libwrap.so

If this command returns any output, then the daemon probably
supports TCP Wrapper. In this example, find out of if sshd
supports tcp wrappers on not, enter:
$ whereissshd
Sample Output:

sshd: /usr/sbin/sshd
/usr/share/man/man8/sshd.8.gz
$ ldd /usr/sbin/sshd | grep libwrap.so

Sample Output:

libwrap.so.0 => /lib64/libwrap.so.0

(0x00002b759b381000)
ldd is used to see if libwrap.so is a dependency or not. An
alternative to TCP Wrapper support is packet filtering using
iptables.

Important Files

tcpd- access control facility for internet

services.

/etc/hosts.allow - This file describes the

names of the hosts which are allowed to use
the local INET services, as decided by the
/usr/sbin/tcpd server.

/etc/hosts.deny - This file describes the

names of the hosts which are NOT allowed to
 use the local INET services, as decided by
the /usr/sbin/tcpd server.

If the same client / user / ipis listed in both

hosts.allow and hosts.deny, then hosts.allow
takes precedence and access is permitted. If
the client is listed in hosts.allow, then is access
permitted. If the client is listed in hosts.deny,
then access is denied.

tcpdchk andtcpdmatch- test programs for

tcpd
Syntax (format) Of Host Access Control Files
Both /etc/hosts.allow and /etc/hosts.deny uses the following
format:

daemon_list :client_list[ : shell_command ]

Where,

daemon_list - a list of one or more daemon

process names.

client_list- a list of one or more host names,

host addresses, patterns or wildcards that will
be matched against the client host name or
address.
WildCards
The access control language supports explicit wildcards (quoting
from the man page):
 ALL The universal wildcard,
always matches.
LOCAL Matches any host whose name does not
contain a dot character.
UNKNOWN
Matches any user whose name is
unknown, and matches any host
whose name or address are unknown.
This pattern should be used
with care: host names may be
unavailable due to temporary name
server problems. A network address will
be unavailable when the
software cannot figure out what type
of network it is talking
to.
KNOWN Matches any user whose name is
known, and matches any host whose
name and address are known. This
pattern should be used with
care: host names may be unavailable due
to temporary name server
problems. A network address will be
unavailable when the soft-
ware cannot figure out what type of
network it is talking to.
PARANOID
Matches any host whose name does
not match its address. When
tcpd is built with -DPARANOID (default
mode), it drops requests
 from such clients even before looking
at the access control
tables. Build without -DPARANOID
when you want more control
over such requests.
TCPD Configuration Examples
Set default policy to to deny access. Only explicitly authorized
hosts are permitted to access. Update /etc/hosts.deny as follows:
# The default policy (no access) is
implemented with a trivial deny file
ALL: ALL

Above will denies all service to all hosts, unless they are
permitted access by entries in the allow file. For example, allow
access as follows via /etc/hosts.allow:

ALL: LOCAL @devels

ALL: .nixcraft.net.in EXCEPT
boobytrap.nixcraft.net.in

Log and deny access (booby traps) - we do not allow

connections from crackers.com:

ALL : .crackers.com \
: spawn (/bin/echo %a from %h attempted
to access %d >> \
/var/log/connections.log) \
 : deny

A Typical UNIX Example

Allow access to various service inside LAN only via
/etc/hosts.allow:

popd : 192.168.1.200 192.168.1.104

imapd : 192.168.1.0/255.255.255.0
sendmail : 192.168.1.0/255.255.255.0
sshd : 192.168.1.2 172.16.23.12
Deny everything via /etc/hosts.deny:

ALL : ALL
Reject All Connections
Restrict all connections to non-public services to localhost only.
Suppose sshd and ftpd are the names of service which must be
accessed remotely. Edit /etc/hosts.allow. Add the following
lines:

sshd ,ftpd : ALL

ALL: localhost
Save and close the file. Edit /etc/hosts.deny. Add the following
line:

ALL: ALL
Default Log Files
TCP Wrappers will do all its logging via syslog according to
your /etc/syslog.conf file. The following table lists the standard
locations where messages from TCP Wrappers will appear:
 1.AIX - /var/adm/messages
2.HP-UX - /usr/spool/mqueue/syslog
3.Linux - /var/log/messages
4.FreeBSD / OpenBSD / NetBSD -
/var/log/messages
5.Mac OS X - /var/log/system.log
6.Solaris - /var/log/syslog
Use the following command to view logs:
# tail -f /path/to/log/file
# grep 'ip' /path/to/log/file
# egrep -i 'ip|hostname' /path/to/log/file

How Do I Predicts How The Tcp Wrapper

Would Handle a Specific Request For Service?
Use tcpdmatch command. predict how tcpd would handle a sshd
request from the local system:
tcpdmatchsshdlocalhost
The same request, pretending that hostname lookup failed:
tcpdmatchsshd 192.168.1.5
To predict what tcpd would do when the client name does not
match the client address:
tcpdmatchsshd paranoid
Replace sshd with in.telnetd, or ftpd and so on. You can use all
daemon names specified in inetd.conf or xinetd.conf file.
How do I Examines My TCP Wrapper Config
File?
Use tcpdchk command toexamines your tcp wrapper
configuration and reports all potential and real problems it can
find.
tcpdchk
tcpdchk -v

A Note About TCP Wrappers and Firewall

You need to use both (firewall and tcpd) to fight

against crackers.

TCP Wrappers are most commonly employed to

match against IP addresses and host level
protection.

Never configure TCP Wrappers on firewall host.

Put TCP Wrappers on all UNIX / Linux / BSD

workstations.

Do not use NIS (YP) netgroups in TCP Wrappers

rules.

Put TCP Wrappers behind a firewall systems as

TCP Wrappers is no substitute for netfilter or pf
firewall.
 TCP Wrappers does provide increased security
as firewall cannot examine encrypted
connections (read as packets).

J :: Automatic vulnerability Scanner(ClamAV,

ChkrootKit and Maldet)

K :: SSL implementation on all services

Short for Secure Sockets Layer, a protocol developed by

Netscape for transmitting private documents via the Internet.
SSL uses a cryptographic system that uses two keys to encrypt
data a public key known to everyone and a private or secret
key known only to the recipient of the message. Both Netscape
Navigator and Internet Explorer support SSL, and many Web
sites use the protocol to obtain confidential user information,
such as credit card numbers. By convention, URLs that require
an SSL connection start with https: instead of http

:.

Another protocol for transmitting data securely over the World

Wide Web is Secure HTTP (S-HTTP). Whereas SSL creates a
secure connection between a client and a server, over which any
amount of data can be sent securely, S-HTTP is designed to
transmit individual messages securely. SSL and S-HTTP,
therefore, can be seen as complementary rather than competing
technologies. Both protocols have been approved by the Internet
Engineering Task Force (IETF) as a standard.

If you need an SSL certificate, you can either purchase one from
(mt) Media Temple or install a third-party certificate yourself.
You can purchase a certificate from any certifying authority that
provides Apache certificates. Regardless of which provider you
choose, the basic steps for your (mt) Media Temple server are
the same.
1. Generate a CSR (certificate request).
2. Submit the CSR to your third-party certifying authority,
and fill out their requested information.
3. Receive the certificate (and any chain certificates, if
necessary) from your certifying authority.
4. Import the certificate and any chain certificates to your (mt)
Media Temple server.
===============================
===============================
How to configure the ssl certificate on the service
(http, exim., pop, imap, ftp)
Step 1.Goto the location /etc/ssl/certs
Step2. Create the file via \*.securehostdns.com.crt
and copy the certificate and save the file
Step3. Create the file vi \*.securehostdns.com.csr
and copy the csr and save the file
Step 4.Goto the location /etc/ssl/private
Step 5 create the file \*.securehostdns.com.key and
copy the private key and save the file
Step 6 Login into the whm panel of the server
Step 7 goto Home SSL/TLS Install an SSL
Certificate and Setup the Domain
Step 8: Enter the SSL Certificate into the first box
and hit the tab button. After hitting the tab button,
all information related to CSR and public key will be
displayed.
Step 9: Now, enter username as nobody and IP of
the hostname in IP Address field.
Step 10 Now, click on Submit button at the top
and wait for the message of successful installation
of SSL Certificate.
Step 11 goto at Home Service Configuration
Manage Service SSL Certificates
Step 12 Now, Click on "Install new Certificate"
option in front of the each services one by one.
After click on said option, you will get a window to
enter the certificate.
Step 13 :: Enter the SSL Certificate into the first
box and hit the tab button. After hitting the tab
button, all information related to CSR and public
key will be displayed.
Step 14 Now, click on Submit button at the top and
wait for the message of successful installation of
SSL Certificate. After successful installation, service
will restart.
Its all Done.

2 :: Web Security(Open Source)

A :: Vulnerabilities in Open Source

Vulnerabilities of open source could be defined as

program or script that allows an attacker to bypass
normal open source settings. To avoid such
problems, keep your CMS updated to latest
versions. Older version of open source contains old
functions and scripts which can be easily hacked.
Also keep your all plugins updated and if you are
not using any specific plug-in, delete it from the
system.

B :: Secure configuration file

Configuration file contains database information
like database name, database username, and
password. By default configuration file has
permission which means a normal user can easily
read your configuration file. So, set the permission
of the file to 400 which will disable other users to
read it.

C :: Rename the administrative account

When open source is installed on a System by

default; it uses and sets username "admin" as the
administrator of the CMS. For better security it's
not suggested to use "admin". After installation you
can create a new user with administrator rights
and delete "admin".

D :: Secure Database related to Open Source

Open source is database dependent application for

which you need to have a database and database
user. For open source installation, you simply
create a database with user but securing database
is also useful for securing you CMS.

Following are a few tweaks to secure database

D.1 :: Grant limited access to a database user:

Create a user to access this database only and
grant limited access to SQL commands on this
database (select, insert, delete, update, create,
drop and alter).
D.2 :: Pick a strong database password

E ::Directories should not be left open for

public browsing

It is not safe for your site by letting people know

what plugins you have, or what versions they are.
If there is some known exploit that is linked to a
plugin, it could be easy enough for someone to use
it to their advantage. Just add this line in your
.htaccess file in your root:
Options All Indexes
F :: Stop worrying about your configuration
file
Keep your database username and password Safe
by adding the following to the .htaccess file at the
top level of your CMS install:
<FilesMatch ^configuration file name$>deny
from all</FilesMatch>
This will make it harder for your database
username and password to fall into the wrong
hands in the event of a server problem.