Debian Dedicated Web Server Hosting and Security

May 4, 2009 / Dedicated Server Hosting vps hosting

Debian Dedicated Web Server Hosting Security

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 prevention 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