Ozzie.eu

Love to code, although it bugs me.

Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

MySQL - basic network security

Having secured our MySQL server and created a personal account to allow for remote administration, we can take one step further on blocking unwanted access to our database server. For this example, we'll continue to use the Ubuntu 14.04.2 LTS Server installed and configured on the previous posts.
After booting up the server, running a network check for connections, lists our server listening on ports 22 and 3306 (mysql):
We also used the Uncomplicated Firewall,  a frontend for iptables, to check if the server's firewall is enabled. It's inactive and consequently all listening ports are available to the network.
Let's adopt the following policy:
  • SSH port is open to the network and available for sysadmin staff. Access control will be implemented on dedicated network firewalls;
  • MySQL port is closed and has to be authorized on demand, on a client machine adress basis.
This will allow the database administration team to know at all times who has access and from which hosts on the network. Furthermore, it prevents remote detection of the database server with tools like NMap.
First, lets add the inbound rule for SSH connection so we don't get locked out of the server:
Then lets enable the firewall and check it's status:
The test will be to connect MySQL Workbench from a remote server and wait for failure:

Afterwards, add a specific rule for the remote machine using the ufw utility and try again:

sudo ufw allow from 192.168.204.XXX to 192.168.204.132 port 3306

You should succeed and while you have the database session open, run netstat again on the server and validate your remote connection:

stuntman@MuSQL-Lab:~$ netstat -at
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 192.168.204.132:mysql *:* LISTEN
tcp 0 0 192.168.204.132:mysql 192.168.204.X:54617 ESTABLISHED
tcp 0 0 192.168.204.132:mysql 192.168.204.X:54618 ESTABLISHED
tcp 0 64 192.168.204.132:ssh 192.168.204.X:54483 ESTABLISHED
tcp6 0 0 [::]:ssh [::]:* LISTEN
stuntman@MuSQL-Lab:~$

Final check to see the firewall rules and get what hosts are authorized for remote access:
stuntman@MuSQL-Lab:~$ sudo ufw status
Status: active

To Action From
-- ------ ----
22/tcp ALLOW Anywhere
192.168.204.132 3306 ALLOW 192.168.204.X
22/tcp (v6) ALLOW Anywhere (v6)
On this blog, we've covered instance lockdown, user accounts lockdown and network lockdown. All these security concerns are of added value when facing production environments with sensitive data.

Creating user accounts on a secured MySQL server

After installing a MySQL database server and securing that installation with the mysql_secure_installation tool, you are locked out from remote access to perform any operation on the server. Since we all like the 'R' in RDBMS to stand for remote as well as relational, let's see how we can configure user credentials to provide remote access to the database server but still keep those credentials from providing local access.
Suppose you have a key user named James Bond to whom you want to give remote administration on the MySQL server. However, you don't want him to logon locally on the machine to perform any operations. This way you achieve three levels of security:
  • The credential only allows remote access;
  • You control from which remote computers the user can connect, by configuring rules on a network or server firewall;
  • IF it's a shared server, console access on the machine doesn't give access to the database engine.
First, let's open a terminal session on the server and a login with the mysql command line tool, using our root account:
shell> mysql -u root -p
Now, for the sake of this example, let's create a user account for James Bond and give him full privileges:
mysql> CREATE USER 'jamesbond'@'%' IDENTIFIED BY 'double0seven';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'jamesbond
'@'%' WITH GRANT OPTION;
Having set this up, if James Bond tries to login from any remote computer he can because we used the wildcard '%' to specify the user's machine. But he can also login from the local server. To prevent this from happening, we create a second account with the same username and password, but do not grant any permissions:
mysql> CREATE USER 'jamesbond'@'localhost' IDENTIFIED BY 'double0seven';
If the user then tries to login again from the local machine, he can. But isn't able to perform any operations or queries.

Securing your MySQL server

After installing a MySQL database server, like the one I posted earlier, if it's going to be a production environment than you should consider securing the instance by eliminating some of the basic vulnerabilities that come with a generic install.
Fortunately MySQL and MariaDB already come with a tool for that purpose, called mysql_secure_installation. This program enables to perform the following improvements to the security of your installation:

  • set a password for root accounts.
  • remove root accounts that are accessible from outside the local host.
  • remove anonymous-user accounts.
  • remove the test database (if exists), which by default can be accessed by anonymous users.

Be advised that as of MySQL 5.7.2, this tool is an executable binary available on all platforms. Before version 5.7.2, it was a script available only for Unix and Unix-like systems.
Invoking the tool without any arguments:
shell> mysql_secure_installation
The script will prompt you to determine which actions to perform:
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we'll need the current
password for the root user. If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

You already have a root password set, so you can safely answer 'n'.

Change the root password? [Y/n] n
... skipping.

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
... Success!

By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
- Dropping test database...
ERROR 1008 (HY000) at line 1: Can't drop database 'test'; database doesn't exist
... Failed! Not critical, keep moving...
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!
You can find what there is to know in terms of options from the official documentation:




Malware Response Guide

Through Microsoft’s Security newsletter, I learned about a great resource which is the Infrastructure Planning and Design (IPD) Guide for Malware Response.
Cc162838.image1(en-us,TechNet.10).jpg
It helps with planning the best and most cost-effective response to malicious software for your organization. This free guide provides methodologies for the assessment of malware incidents, walks through the considerations and decisions that are pertinent to timely response and recovery, and describes approaches to investigating outbreaks and cleaning infected systems.
The Malware Response Guide includes the following content:
  • Step 1: Confirm the Infection. This step involves taking actions to immediately contain an infection. Information is gathered from the user and about the system to help assess the breadth of the problem.
  • Step 2: Determine the Course of Action. This step involves determining the risk to data, performing backups before proceeding with the chosen course of action, if required, and deciding whether to examine the malware’s effects on the system. Also, decide whether to clean the malware, restore system state, or rebuild the system
  • Step 3: Attempt to Clean the System. This step involves putting the system cleaning plan into effect. Attempting to remove the malware using automated tools such as antimalware products are performed.
  • Step 4: Attempt to Restore the System State. This step involves attempting to restore the system state, and evaluating the restored system for the effectiveness of malware removal.
  • Step 5: Rebuild the System. This step involves either rebuilding the system from image or by reinstalling the operating system. Also, restoring the user settings and data are performed, and evaluating the activities performed for effectiveness.
  • Step 6: Conduct Post Attack Review. This step focuses on post-attack items to consider for lessons learned.
You can get the download of the IPD guide for Malware Response here.

Microsoft Security Tools and Guidance

Binary matrix with glowing security lockAdvanced Persistent threats are a hot security topic lately. According to Wikipedia, APT usually refers to a group, with both the capability and the intent to persistently and effectively target a specific entity. The term is commonly used to refer to cyber threats, in particular that of Internet-enabled espionage using a variety of intelligence gathering techniques to access sensitive information.
A modern attack performed by APT is the “Pass the Hash”. According to a whitepaper from Microsoft, while performing a PtH attack, an attacker obtains elevated read/write permission to privileged areas of volatile memory and file systems, which are normally only accessible by system-level processes on at least one computer. Second, the attacker attempts to increase access to other computers on the network by:
  1. Stealing one or more authentication credentials (user name and password or password hash belonging to other accounts) from the compromised computer.
  2. Reusing the stolen credentials to access other computer systems and services.
    This sequence is often repeated multiple times during an actual attack to progressively increase the level of access that an attacker has to an environment.
Returning to the subject of this post, while going through Microsoft’s community information, I gathered quite interesting resources regarding security tools and guidance.
Regarding free assessment tools from Microsoft, as well as protection software, there’s a really nice compilation on the “Irish IT Professional” technet blog. You get to know tools like Microsoft Security Compliance Manager, Microsoft Baseline Security Analyzer and Microsoft Security Assessment Tool.
Regarding security tools for footprinting, internal auditing anf guidance, you should check out the Security Tools Community Edition page, on Microsoft’s Technet Wiki.
Finally, you might want to follow the Microsoft Security Blog.
Photo Credit: JustEvents via Compfight cc