Page 1 of 1

Linux: 7 tips to enforce your server Rate Topic: -----

#1 alpha02  Icon User is offline

  • Sexy DIC God
  • member icon

Reputation: 46
  • View blog
  • Posts: 803
  • Joined: 20-May 06

Posted 29 January 2012 - 02:43 PM

*
POPULAR

After having hosted my customers' websites for a few years and finding out what the vulnerabilities of many servers were, I've decided to share a few techniques on how you can properly secure your Linux box to avoid seeing a message like:

Hax0red by t3am ...


… on your front page. A few hackers experiment the XSS injection technique, but since this is mostly about patching the holes in your PHP scripts, I'm not going to cover this part. By the way, this tutorial was made and tested using a CentOS 6.2 box, but it can be adapted to whatever distribution you have. All right, let's get started.

Tip #1: Open only the ports you need and do NOT forget Ipv6

Most of the hackers will try attacking your box through Ipv6 connections. People tend to configure their Ipv4 firewall (often, iptables) very well, but they forget about the Ipv6 one.

The ports you might need are 21 for FTP, 22 for SSH, 80 for HTTP, 443 for secure HTTP, and a few high ports for passive FTP connections. All the firewall configuration is located in the text file /etc/sysconfig/iptables. Here is an exemple of a basic configuration of iptables:

# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 56000:57000 -j ACCEPT
-A INPUT -j DROP
COMMIT


The above code opens the ports 21, 22, 80 and 443. Also, the ports 50000 to 51000 will be open to let passive FTP through. If no rule is matched, the packet is simply DROPPED. Why not rejected with an error message? Because you don't want your server to reply to a hacker scanning a serie of servers for port 21 with the message “I'm here but you won't get in”, you just want your server to be stealth.

Unlike many people may think, changing the FTP and SSH ports does not really increase your security level. Any serious hacker will use a tool such as nmap to scan your system and find an open port where a SSH daemon is listening. Do not forget to configure your FTP server to use the passive ports you desire.

Do NOT forget the /etc/sysconfig/ip6tables file, this is where the Ipv6 rules are.

Tip #2: Always use secure FTP and disable anonymous login

First of all, you should not allow anonymous users to login. For this tip, I'll be using pure-ftpd as an example because I really recommend this FTP server. All the configuration lies in /etc/pure-ftpd/pure-ftpd.conf. You should, at least, modify the lines as follow:

AnonymousOnly no
NoAnonymous yes
PassivePortRange 50000 51000
TLS 2


What does that do? Basically, you disallow anonymous login, you set the passive port range to whatever you specified in your firewall configuration, and you FORCE the user to use TLS. You want a secure server, not a machine hacked beacause some individual in the middle sniffed your FTP password.

The next step is to create your SSL certificate for FTP connections. No need to purchase anything from an issuer. A self-signed certificate will do the trick, since your FTP server will only be used by you. You trust your own server, right? Anyway, let's install the openssl package (whether it's apt-get or yum, and create a self-signed certificate:

# yum install openssl
# mkdir /etc/ssl/private
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem


You will be prompted to enter some info, then the certificate will be created. Restart pure-ftpd to commit changes. Now, you HAVE to use TLS to login. Il Filezilla, it is FTP with explicit SSL (ftpes).

For more secutiry you could go with virtual users, but this is beyond the scope of this tutorial.

Tip #3 : Disable dangerous PHP functions

While we're at it, why not make a few tweaks in your php.ini file? Do you really need functions such as exec, eval, and any other thing a hacker will more than happy to play with? Let's do a few tweaks:

safe_mode = On
expose_php = Off
open_basedir = /var/www
disable_functions = "apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode"


This turns on the safe mode, and sets open_basedir. What's that? Well, if you no want malicious code to use include(../../../../somefile) elsewhere in your system, set the basedir to your website's root.

And most importantly, disable all the dangerous functions listed above. Changes are slim that you will need those functions. PHP is a powerful language. If you REALLY need those functions for a serious reason, allow them, but otherwise keep them blocked.

Tip #4: Disable unused services

Do you really need Telnet on your web server, RSH and all those things? Don't just disable them, remove their packages. Keep the strict minimum such as SSH and FTP.

Also, please remove that VNC server thing. This is a server, not a gaming machine or a desktop. The desktops, window systems such as Gnome and KDE should not be here.

# yum groupremove “X Window System”
# yum groupremove “GNOME Desktop Environment”


There you go. The less services running you have, the least are your chances of getting rooted. Basically, any communication between you and your server should be encrypted, except standard HTTP.

Also check your config in /etc/ssh/sshd_config, you should use ONLY protocol 2 connections. The protocol 1 has some known security issues.

Tip #5: Set a maximum number of connections per timespan for SSH

If you have a SSH daemon running on port 22 and no firewall rule to prevent attacks, chances are that somebody will brute-force that port to find your root password. Moreover, the SSH server on some Linux distributions do not log the attemps by default, leaving you with no way of knowing you are under attack. A simple firewall rule can go as follow:

-A INPUT -m state –state NEW -p tcp –dport 22 -m limit –limit 3/min –limit-burst 3 -j ACCEPT


You can do the same for FTP. This works as follow:
A limit of 3 connection attempts (SYNs) per minute are allowed on port 22.
The rule will be enforced after 3 connections.

This will considerably slow the rate of possible connections on port 22, making it harder to brute-force. As stated earlier, you should do the same for your FTP port. These two are vulnerable to brute-forcing.

Tip #6: Choose a strong password for everything

If you are the kind of person that often uses qwerty as a password (or azerty in France), that section is for you. How long does it take to brute-force? Not very long since this is very likely to appear in a dictionnary-based attack. A tool I can recommend you is the password generator located at www.strongpasswordgenerator.com.

Use uppercases, lowercases, digits and symbols. A password like 47qj229f2 is NOT appropriate. A good example of a password can be:

B3'Y06gN++C>,@*ckt!|/K

Do not go less than 16 characters. Do not use the same password for FTP and SSH. I hope you get the point here. And if you can, change them often.

Tip #7: Allow MySQL connections from your internal network only

You should keep your MySQL server locked to the exterior world. This way, only connections from inside your server farm will be accepted. If somebody can access your SQL machine from the outside, chances are that your data will be compromised. The firewall rule is:

-A INPUT -m state –state NEW -p tcp –dport 3306 -s 192.168.0.1/24 -j ACCEPT


This way, port 3306 connections have to come from the inside. Of course, change 192.168.0.1/24 to whatever you network (and subnet mask) is. You will thank yourself.

This is it for now. As servers appear and hackers find new techniques to infiltrate your data, the need for additional protection is here. Of course, this is not an exhaustive list of possible security flaws but a guide to help you get started. Many other technologies such as port knocking and load balancing play a role in security, but this is out of the scope of this article.

Any comments regarding this article? Feel free to post, however please do not PM me with programming questions, ask them in the forums instead.

Is This A Good Question/Topic? 6
  • +

Replies To: Linux: 7 tips to enforce your server

#2 papadoo1  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 9
  • Joined: 20-January 12

Posted 01 February 2012 - 09:13 AM

Very helpful post! Now time to unearth my server (*papadoo1 starts digging...)
Was This Post Helpful? 0
  • +
  • -

#3 baavgai  Icon User is offline

  • Dreaming Coder
  • member icon

Reputation: 5642
  • View blog
  • Posts: 12,359
  • Joined: 16-October 07

Posted 01 February 2012 - 10:16 AM

Excellent.

Tip #2 is interesting. At that point I'd probably just use SSH and SCP and leave off the FTP entirely.
Was This Post Helpful? 0
  • +
  • -

#4 Motoma  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 452
  • View blog
  • Posts: 796
  • Joined: 08-June 10

Posted 02 February 2012 - 01:25 PM

Agree entirely with baavgai, if you have SSH open and want file transfer, just use SCP as most clients support both both protocols; don't forget, you can stop file transfer user accounts from logging in by setting their shell to scponly.

Additionally, if you are going to leave SSH open to the world, I strongly recommend using a tool like denyhosts or fail2ban.
Was This Post Helpful? 1
  • +
  • -

#5 reveal  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 10
  • Joined: 14-February 13

Posted 17 July 2013 - 08:24 AM

Here are 59 CHMOD commands admins should use also to help enforce your server.

chmod o= /usr/bin/last
chmod o= /usr/bin/lastlog
chmod o= /usr/bin/w
chmod o= /usr/bin/who
chmod o= /usr/bin/chsh
chmod o= /usr/bin/sudoedit
chmod o= /usr/bin/smbmnt
chmod o= /usr/bin/traceroute6
chmod o= /bin/umount
chmod o= /bin/ping6
chmod o= /bin/ping
chmod o= /usr/bin/finger
chmod o= /bin/mount
chmod o= /usr/bin/top
chmod o= /sbin/umount.cifs
chmod o= /sbin/mount.cifs
chmod og-rwx /etc/rc*
chmod og-rwx /usr/bin/last
chmod og-rwx /usr/sbin/lastlogin
chmod og-rwx /var/log/messages
chmod og-rwx /var/log/maillog
chmod og-rwx /log/maillog
chmod og-rwx /bin/lastlogin
chmod go= /usr/bin/telnet
chmod go= /bin/netstat
chmod go= /bin/telnet
chmod go= /usr/bin/locate
chmod go-r /bin
chmod go-r /etc
chmod go-r /home
chmod go-r /sbin
chmod go-r /usr
chmod go-r /usr/bin
chmod go-r /usr/local
chmod go-r /usr/local/bin/
chmod go-r /usr/local/sbin
chmod go-r /usr/sbin
chmod go-r /usr/src
chmod go-r /usr/src/sys
chmod go-r /usr/src/sys/i386/conf
chmod go-r /var
chmod go-r /var/log
chmod go-r /src/sys/i386/conf
chmod go-r /src/sys
chmod 700 /boot
chmod 700 /dist
chmod 700 /rescue
chmod 700 /root
chmod 711 /home
chmod o+x-r /mnt
chmod 0 /proc/net/netlink
chmod 660 /var/log/wtmp
chmod 660 /var/run/utmp
chmod 660 /var/log/btmp
chmod 660 /var/log/faillog
chmod 660 /var/log/lastlog
chmod 660 /var/log/lastlogin
chmod 511 /bin/bash
chmod +x `which sudo`
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1