Internet gateways are known to have the most threats in terms of server security. Basically, the traffic that is allowed through the network. When we speak of security, the first thing that comes into our mind is the storage of confidential data such as Credit Card nos. etc.

Also, Virus such as Worms or Trojans and preventions of any intrusions are part in Web Server security. Banking security, prevention of hacking attempts are all included in security provisioning. Any Web server that is connected to the internet has a direct threat.

In case of server breach, it can be used for spams, hacking other servers and running illlegal activities on the server. Infact, many illegal activities include DOS attacks to other web servers. A hacker can seriously damage a server without even the server owner knowing about it. We will learn more on Debian Server Security in this post. We can also set “honey pot” when we speak of server security. In this case, hackers are directly attracted to a honey pot. However, prior to setup a honey pot, make sure you have remote backup space in case to start from the basic. The first is to prevent unauthorized access to the server. Following are some of the security practices on servers :

- Operating System Security ardening
- Application configuration
- Perimeter security
- Physical security

Operating System Security Hardening :

- Disable all default accounts
- File system security configurations
- Strong and long accounts password
- In order to disable accounts, change default shell to /bin/false
- Change startup configuration
- Disable TCP/IP ports that are run to scan ports.
- File system security
- No usage of common names for groups to reduce the risk of hacks
- TCP wrappers to run Internet-related daemons
- Appropriate hosts.allow Configuration
- Not running GUI
- Log off from Server consoles when not required

Configurations of Applications :

Applications installation and configurations must be done with great care as they can be the source to server hack. Insecure applications can cause harm to your Debian dedicated web server. Applications may have vulnerability to buffer overflow attacks which provides access to hackers and security threats.

It’s advisable that you should notice the following points :

- Securing insecure applications
- Check for Application updates
- Application Port Opening – Only which is required
- Secure CGI Scripts
- SSI Security management
- Secure FTP Access for Uploads
- Blocking IPs
- Latest Security Measures.

With DebianOS, disable open ports which are not required through by renaming their S symlinks in runlevel directory. Debian boots into runlevel 2 default by command : cd /etc/rc2.d

Search for symlink S20ssh which opens port for remote console and enhnaces security. Rename symlinks with command : mv S20ssh _S20ssh and this can be done for S20exim4, S20lpd, and S21nfs-common. Run netstat -ap command for /sbin/portmap is the applications has sunrpc port 111 open. NFS requires RPC. We can disable portmap in this case. We can rename symlinks with the following command :

mv /etc/rc2.d/S18portmap /etc/rc2.d/_S18portmap
mv /etc/rcS.d/S43portmap /etc/rcS.d/_S43portmap

Once done, reboot your Debian Dedicated Web Server and then run netstat -a

- Configurations of chroot jail will allow applications directory appear from root of file system. Access to only applications that will reduce the risk to access the entire file system. Apache web server running on DebianOS can easily setup jail as we can use Apache module to complete the task. We can add one line to the configuration file by the following command :

apt-get install libapache-mod-chroot

This will install Apache modules and in case to select from packages or existing modules.conf, add the following link to modules.conf file :

/etc/apache/modules.conf file:

LoadModule choot_module /usr/lib/apache/1.3/mod_chroot.so

In this case, logs, CGI and directories are the same and we don’t need to create new directories or make any changes to the ownership of the directories.

Chroot Apache applications, Apache IDS module which will search for any threats and will block them. You can simply add the following line to /etc/apt/sources.list file :

http://etc.inittab.org/~agi/debian/libapache-mod-security/etch/

Once added, you can run the following command :

apt-get update

Apt will be aware of tge package at the website. In order to install and enable module, enter the following command :

apt-get install libapache-mod-security

Add the following line to /etc/apache/modules.conf :

LoadModule security_module /usr/lib/apache/1.3/mod_security.so

It will search for any threats, http / PHP requests and block them. We can also add rules to httpd.conf file in order to let it know to as what needs to be checked.

For starters, add the following lines to the bottom of your httpd.conf file:

# *** MODULE CONFIG
# Turn the filtering engine On or Off
SecFilterEngine On
# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On
# Unicode encoding check
SecFilterCheckUnicodeEncoding Off
# Only allow bytes from this range
SecFilterForceByteRange 0 255
# Only log suspicious requests
SecAuditEngine RelevantOnly
# Server masking -
# Don’t tell them it’s an Apache installation
SecServerSignature “Lotus-Domino/6.x”
# The name of the audit log file
SecAuditLog /var/log/apache/audit.log
# Debug level set to a minimum
SecFilterDebugLog /var/log/apache/modsec_debug.log
SecFilterDebugLevel 0
# Should mod_security inspect POST payloads
SecFilterScanPOST On
# By default log and deny suspicious requests
# with HTTP status 403
SecFilterDefaultAction “deny,log,status:403″

Adding Fileter rules :

SecFilter /etc/passwd
SecFilter /bin/ls
SecFilter /bin/uname
SecFilter /usr/bin/whoami
SecFilter cd\x20/tmp
SecFilter wget\x20
# Block Santy.A worm
SecFilterSelective ARG_highlight %27
# Block drop table SQL injection attack
SecFilter “drop[[:space:]]table”
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply “text/html” as Content-Type
SecFilterSelective REQUEST_METHOD “!^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Type \
“!(^application/x-www-form-urlencoded$|^multipart/form-data;)”
# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD “^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Length “!^$”
# Require browser headers from all user agents
SecFilterSelective “HTTP_USER_AGENT|HTTP_HOST” “^$”
# Require Content-Length to be provided with every POST request
SecFilterSelective REQUEST_METHOD “^POST$” chain
SecFilterSelective HTTP_Content-Length “^$”
# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding “!^$”

Once done, please make sure you restart Apache with /etc/init.d/apache restart

Social Bookmarking

Applications and softwares required to setup LAMP clusters are packaged along with linux distributions. Following is an example where two servers run DNS which is the primary server and backup. This is ditributes between 3 web servers and 2 database servers.

The initial stage includes round-robin where DNS is a load-balancing solution which serves web requests for a hostname from different dedicated web servers. In this case, each web server has it’s own Public IP address.

Following is an example where the domain assignd the same hostname to each of three dedicated web servers but the IP addresses are completely different :

;
; Domain database for foo.com
;
domain.com. IN SOA ns1.domain.com. hostmaster.domain.com. (
2006032801 ; serial
10800 ; refresh
3600 ; retry
86400 ; expire
86400 ; default_ttl
)
;
; Name servers
;
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
;
; Web servers
;
www IN A 10.10.10.11
www IN A 10.10.10.12
www IN A 10.10.10.13

In DNS Server received requests from domain.com, one IP address will return for the first time, then a different IP address for the next request. In this case, Web server traffic is distributed among 3 web servers. However, due to DNS cache, resources may vary. This is just an solution to minimize load-balancing setup cost.

Web Server Configurations that is used in a cluster is the same as Apache Web Server Configuration with only one statement that content is the same with sycnhronization. Many use the option which is known as “rsync”.

We suggest you also create a new user account on each dedicated web server and it needs to have write permissions for Web content directory on each web server. Also, create SSH keys for the account and distribue the public keys to /home/syncer/.ssh directory on other 2 web servers. It also allows login without password to the user account and update data at each intervals.

The following rsync updates web content :

#!/bin/bash
rsync -r -a -v -e “ssh -l syncer” –delete /var/www/ webtwo:/var/www/
rsync -r -a -v -e “ssh -l syncer” –delete /var/www/ webthree:/var/www/

When a LAMP Cluster is setup, cookies needs to be checked as Apache stored cookies in /tmp directory. In case, a visitor views a session on Web Servers and if HTTP requests are managed by a different web server, the cookie won’t exist and it won’t function as required. Solution to this is shared cookie directory on Web Servers and should be done before setting up LAMP Clusters.

Another requirement of the setup is to send the data to the database master server and should be distributed between master and slave server.

Now, if we focus on Database servers, MySQL has a feature to maintain database on different servers. It is known as “log replay” which means a log is created on the master server which is read by a slave server and then applied to the database.

In this example, we will assign 2 database servers, one is Database Server 1 and Database Server 2.

In order to setup Master database server, you will need to create a replication account which is the user ID in MySQL which is utilized by slave servers which read the logs.

Following is an example :

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO copyslave@”10.10.10.0/255.255.255.0″ IDENTIFIED BY ‘copypass’;

You can also edit MySQL configuration which is located in /etc/my.cnf and then add the following :

# Replication Master Server (default)
# binary logging is required for replication
log-bin ( binary log file – required for applications )

# required unique id
server-id = 1 ( Master Server )

You can view new binary log file in MySQL directory with $HOSTNAME-bin.001. Here, MySQL will create new log files. In order to setup Slave Server, edit /etc/my.cnf and add the following :

# required unique id
server-id = 2
#
# The replication master for this slave – required
# (Master Database Web Server IP)
master-host = 10.1.1.21
#
# Slave Username
# to the master – required
master-user = copy

# Slave Password
# the master – required
master-password = copypass

# Lost Connection Check
master-connect-retry = 15

# binary logs
log-bin

Restart MySQL, slave server will connect to the master server and begin the replication process. At initial stage, it will create master.info file with all settings in the default directory which is /var/lib/mysql

In order to check if the replication is working, log in to the MySQL monitor and run show master status and then show slave status. There you need to check Slave_IO_Running and Slave_MySQL_Running. If both are Yes, then the replication process is working.

In case, the database web server loosed network connectivity, you can stop MySQL on the master as well as slave server, then dump master database and reload the database on the slave server and then start MySQL on master and slave server.

If there are any issues with the master database server, the slave database server can be configured as master database server by simply updating the IP address and MySQL configuration file. It is possible to easily setup LAMP cluster on dedicated web server hosting

Social Bookmarking