Posts Tagged ‘security’

Tightening up iptables for a dedicated DB server (MySQL and CentOS)

March 25th, 2009

In a typical high performing web servers environment I have a few web servers running apache/php and a separate DB server to support them. If the need ever comes to increase the capacity of the DB server it can easily be done via the MySQL clustering configuration. In any case, one of the most redundant tasks before setting up all servers is to tighten the security. In particular, setting the firewall is a repetitive task. Hence I am setting this page as a guide to myself and anyone who cares, Enjoy!

  1. SSH to the server, login as root
  2. type vi myiptables-mysql
  3. Insert the following commands:
    NOTE: you will need to insert the web server’s ip addresses where I placed <ip address#>. These are the ip addresses that MySQL queries will originate from.

    # iptables example configuration script
    # Flush all current rules from iptables
    iptables -F
    # Allow SSH connections on tcp port 22
    # This is essential when working on remote servers via SSH to prevent locking yourself out of the system
    iptables -A INPUT -p tcp --dport 22 -j ACCEPT
    iptables -I INPUT 1 -i lo -p tcp --dport mysql -j ACCEPT
    iptables -I INPUT 2 -i lo -p udp --dport mysql -j ACCEPT
    iptables -I INPUT 3 -i eth0 -p tcp --dport mysql -s <ip address1> -j ACCEPT
    iptables -I INPUT 3 -i eth0 -p tcp --dport mysql -s <ip address2> -j ACCEPT
    # Set default policies for INPUT, FORWARD and OUTPUT chains
    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -P OUTPUT ACCEPT
    # Set access for localhost
    iptables -A INPUT -i lo -j ACCEPT
    # Accept packets belonging to established and related connections
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    # Save settings
    /sbin/service iptables save
    # List rules
    iptables -L -v
  4. save and exit
  5. Allow the file to execute by typing this command: chmod +x myiptables-mysql
  6. Run the file by tying this command: ./myiptables-mysql
  7. Test it and Enjoy!

Security notice: yes, for an even tighter security it is possible to change the ports.

LAMP: Linux Apache MySQL PHP, Web Development ,

Securing Joomla! CMS based sites

December 3rd, 2008
Comments Off

Looks like turbulent water in the Joomla Security Forums, again. Let’s ignore this and focus on securing a Joomla installation:

1. Set the right file and folder permissions according to the Joomla guide:

Once your site is configured and stable, write-protect critical directories and files by changing directory permissions to 755, and file permissions to 644. There is a feature in Site –> Global Configuration –> Server to set all folder and file permissions at once. Test third party extensions afterwards, and carefully review the code of any extension that has trouble with such settings. Note: Depending on your server’s permissions, you may need to temporarily reset to more open permissions when installing more extensions with the Joomla! installer.

2. Think twice before installing an extension – do you really need it? Most security vulnerabilities come from third party extensions. Especially ones that are pre-release or ones that have not been updated lately.
3. Upgrade to the latest stable version of Joomla. The core team is hard at work for the community partly addressing security bugs and issues found. If you run a site based on an old version of Joomla – you are at risk because the security issues are well documented and available for anyone by exploring the tracker.
4. Change your admin username. Very basic security tip that is recommended for almost every server out there.
5. Avoid shared servers. Virtual hosting is great if you are not in a position to afford a VPS or a full dedicated server, but it is not secure.
6. Protect your DB. Use a user other than the root, and do not allow connections from outside the machine. Even better, block the MySQL port completely.
7. Use an SSL. Simple, when you login and submit your username and password without an SSL, the information is not encrypted between you and the server. Potentially dangerous for packet sniffing exploits or in todays world, if you decide to work from a WiFi/Hot Spot.
8. Separate your development from the production server. Avoid unclean code or left overs that may leave a back door.

9. Remove unnecessary files from the site: remove the XML RPC server part of Joomla if you are not planning on using it. This service allows desktop applications to post directly to the site. Essentially providing access via this protocol. And if you just moved the site from another server delete the zipped files, since they contain your passwords in an unencrypted form!

10. Monitor the logs for hack attempts. Who is trying to login to the administrator section when I was eating my turkey? :) you get the idea…

Content Management Systems, Joomla, Web Development , , ,

Hack attempt: SQL Injection Tagreting MS SQL Servers

August 19th, 2008
Comments Off

I noticed one of our client’s IIS web servers was getting a lot of SQL Injection attempts this past week. These attacks pass T-SQL code into querystring parameters in hopes that the application is not checking inputs.

Here’s the code: (I removed the SQL exec() statement and replaced it with print so you can see the unencoded SQL.)

DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C4152452040542
05461626C655F437572736F7220 AS VARCHAR(4000));

print @S;

This particular attack is well known and has been sighted in several variants:

Using the following web application best practices, we avoid getting hacked:

  • Application level:
    • Never trust user input (e.g. querystring or form posts). Always consider that user input may contain exploit code and check it appropriately.
    • Always use Stored Procedures and/or Parameterized database queries. Don’t build SQL queries using string concatenation.
    • Use typed variables when possible. Converting a querystring parameter to an integer before passing it to a SQL query can inhibit some attacks.
  • Database level:
    • Use limited database permissions. For example, for SQL Server, don’t let you application run under the “sa” user. The database user should only have permission in the particular database used by the application.
    • If possible, disable extended stored procedures such as xp_cmdshell.
    • Don’t use dynamic SQL. Dynamic SQL can be just as bad as building queries using string concatenation.
      Some DBAs have server-wide policies of no Dynamic SQL.

The application level is crucial. Since a web application may someday be moved to a new server, we can’t assume that the web server and database have been configured using best practices.

All layers of security are important, though: If you’re using a third-party or closed-source web application, you may not have access to application code. In that case, the Database and Web Server layers are your last defense against exploits in improperly written code.

.NET Framework, Web Development , , ,