How do I...Harden security on Linux servers running Deki Wiki

Restrict access to the server

The first basic rule is to restrict user's connections to the system.

- Disable all remote connection daemons (telnetd, rshd, etc.) except SSHD. 

- Make sure that the SSH daemon is running :

# chkconfig sshd on

- Add your nominative user to the system :

# adduser mathieuo
# passwd mathieuo

- Disable direct root remote login by editing your "/etc/ssh/sshd_config"

 PermitRootLogin no

- Add sudo privileges to your nominative user by running "visudo" and adding this line :

mathieuo    ALL=(ALL)       ALL

 Using sudo, you should avoid to get any root shell. Whenever you need root privileges for a command, just use "sudo my_command"

MySQL basic security

Most MySQL server installations come with an empty administrator password, you may want to change it using the command :

$ mysqladmin -u root password "newpassword"

Also, if you're running a local MySQL server for your Deki Wiki database, you can restrict access to localhost only :

# Find your MySQL configuration file
$ locate my.cnf
/etc/my.cnf

# Edit your MySQL configuration to change the "bind-address" parameter under the [mysqld] section
$ sudo vi /etc/my.cnf 
...
bind-address = 127.0.0.1
... 
# Restart mysql
$ sudo service mysqld restart

Using this configuration, no remote MySQL access will be allowed. The Deki Wiki API will use "localhost" to communicate with the database.

if you're running Deki Wiki using a remote MySQL server you might want to look at using secure connections and also read this page.

Setting up IpTables firewall

I am not a huge fan of IpTables (packetfilter rules !) but as it is provided by default on RedHat distributions .. let's use it. Basically for Deki Wiki we just need to allow incoming HTTP connections and access to localhost. I will also add SSH for remote login and HTTPS.

- Activate IpTables

$ sudo chkconfig iptables on

- Set your (very basic) firewall rules in "/etc/sysconfig/iptables" (600 root:root)

 *filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow stateful mode
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept incoming SSH connections [optional]
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
# Accept HTTP connections
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
# Accept HTTPS connections [optional]
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 
# Accept all input from localhost
-A INPUT -s 127.0.0.1 -j ACCEPT
# Accept pings, but limit it to 1/s
-A INPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
COMMIT

- Restart the service

$ sudo service iptables restart

- Check your configuration

 $ sudo iptables -L -n -v
Chain INPUT (policy DROP 5 packets, 365 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  199 15987 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    2   160 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    0     0 ACCEPT     all  --  *      *       127.0.0.1            0.0.0.0/0           
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED icmp type 8 limit: avg 1/sec burst 5 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 130 packets, 16163 bytes)
 pkts bytes target     prot opt in     out     source               destination        

- From another point of your network, you can try a scan using NMAP

$ nmap -A my_server.my_domain

Starting Nmap 4.20 ( http://insecure.org ) at 2008-04-01 11:40 PDT
Interesting ports on my_server.my_domain :
Not shown: 1694 filtered ports
PORT    STATE  SERVICE VERSION
22/tcp  open   ssh     OpenSSH 4.3 (protocol 2.0)
80/tcp  open   http    Apache httpd 2.2.3 ((Red Hat))
443/tcp open  ssl/http Apache httpd 2.2.3 ((Red Hat))

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 37.301 seconds

 As you can see, all ports except 22, 80 and 443 are filtered by the firewall.

Using SELinux

SELinux (for Security-Enhanced Linux)  is provided by default on RedHat flavoured systems. A classic default policy looks like :

$ grep -v "^#" /etc/selinux/config 
SELINUX=enforcing
SELINUXTYPE=targeted
SETLOCALDEFS=0 

SELinux can be really restrictive, especially with httpd-like daemons. If SELinux is enabled on your system, you will need to run the following :

$ sudo setsebool -P httpd_can_network_connect true 
$ sudo setsebool -P httpd_builtin_scripting true

For more advanced tuning, you may check the httpd_selinux(8) manpage.

Running Deki Wiki over SSL

Configuring HTTPS access for Hayes is already described in this FAQ. The procedure has not changed much.

Basically, you will need to install SSL :

$ sudo yum install openssl mod_ssl

Create a certificate (self-signed here) :

$ sudo mkdir /etc/httpd/ssl ; cd /etc/httpd/ssl
$ sudo openssl req -new -x509 -days 720 -nodes -out /etc/httpd/ssl/apache2.pem  -keyout /etc/httpd/ssl/apache2.pem 

Change your "/etc/httpd/conf.d/deki-apache.conf" to include SSL :

 <VirtualHost *:443> 
 
	...
 	SSLEngine on 
	SSLCertificateFile /etc/httpd/ssl/apache2.pem 
	...

</VirtualHost> 

and finally restart Apache

$ sudo service httpd restart

You should now be able to connect to your Deki Wiki using HTTPS.

Running Deki Wiki API as a separate user

By default, the Deki Wiki API will run under the Apache user, it can be good to split privileges, especially if you're running other websites on the same server.

- Create a "dekiwiki" user which belongs to the "apache" group and use the same home directory

$ sudo useradd -s /bin/sh -d /var/www -M -g apache -c "Deki Wiki user" dekiwiki
$ sudo passwd dekiwiki

-  Set the "apache" user shell back to "/bin/false"

$ sudo usermod -s /bin/false apache

- Allow our "dekiwiki" user to manage the service by modifying the sudo configuration

$ sudo visudo
...
dekiwiki ALL=(root) NOPASSWD: /etc/init.d/dekiwiki
...

- Set permissions on files and directories

$ sudo chown -R dekiwiki:apache /var/www/dekiwiki /etc/dekiwiki /var/log/dekiwiki /var/www/.wapi
$ sudo chmod 755 /etc/dekiwiki /var/www/.wapi /var/log/dekiwiki /var/www/dekiwiki
$ sudo chmod 640 /etc/dekiwiki/*
$ sudo chmod 644 /var/log/dekiwiki/*
$ sudo chmod -R g+w /var/www/dekiwiki/skins/common/cache /var/www/dekiwiki/config

-  Stop the Deki Wiki service

$ sudo service dekiwiki stop

- Change the user name in the "/etc/init.d/dekiwiki" script 

$ sudo vi /etc/init.d/dekiwiki
...
DEKIWIKI_USER="dekiwiki"
...

-  Start the Deki Wiki service

$ sudo service dekiwiki start

Now the Deki Wiki API can run as the "dekiwiki" user.

Stay tuned with security alerts

As vulnerabilities appear every day, I would strongly advise you to suscribe to the CERT Security Alert feed. Stay tuned !