IT server security cheat sheet

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 user’s 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 tcpwrappers 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-themiddle 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 --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 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 whostmgrdYourIP allow whostmgrd all deny

Comment

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/modsecurityapache/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 && 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, it’s 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 I’m publishing/advertising two fixes, the first from cPanel’s 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-symboliclinks-non-root-users-202242-p2.html#post996441 This is a cPanel specific patch, but should be adaptable to other control panel varieties. On cPanel, you’ll need to run cPanel’seasyapache 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 tcpwrappers 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 software 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. It’s 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: deny from all This will make it harder for your database username and password to fall into the wrong hands in the event of a server problem.