5 Key Steps to Ensuring Database Security

Databases often contain extremely sensitive information that must be protected from security vulnerabilities and exploits. All organizations need to work on a continual basis to identify and remediate those vulnerabilities using a variety of tools that are available. In addition to doing monitoring and security assessments constantly, it is vital that the results are analyzed and properly audited so that an organization can not only ensure that its database security posture is sound, but also demonstrate compliance with regulations that demand high levels of security be applied to sensitive data.

THREATS TO DATABASE SECURITY

Almost all organizations use databases in some form for tracking information such as customer and transaction records, financial information, and human resources records. Much of the information contained in databases is sensitive and can be sold for cash or, such as in cases of theft by a disgruntled employee or by a hacker with political motivations, to cause the organization loss of business or reputation, especially if the organization is found to be in breach of regulations or industry standards that demand high levels of data security.

According to the 2012 data breach investigations report published by Verizon Business, 96% of records breached in 2011 were taken from database servers. Of these, 55% exploited default or guessable credentials and 40% the use of stolen login credentials. And, according to another study among data professionals conducted by Unisphere Research, a division of Information Today, Inc., for the IOUG little more than one-third of the 430 respondents install 37% critical patch updates within three months of their release.

According to technology vendor Application Security, Inc., the following are the top 10 threats related to databases:

  1. Default or weak passwords
  2. SQL injection
  3. Excessive user and group privileges
  4. Unnecessary DBMS features enabled
  5. Broken configuration management
  6. Buffer overflows
  7. Privilege escalation
  8. Denial of service
  9. Un-patched RDBMS
  10. Unencrypted data

5 DATABASE SECURITY ESSENTIALS

There are 5 key steps to ensuring database security, according to Applications Security, Inc.

  1. Isolate sensitive databases—maintain an accurate inventory of all databases deployed across the enterprise and identify all sensitive data residing on those databases.
  2. Eliminate vulnerabilities—continually assess, identify and remediate vulnerabilities that expose the database.
  3. Enforce least privileges—identify user entitlements and enforce user access controls and privileges to limit access to only the minimum data required for employees to do their jobs.
  4. Monitor for deviations—implement appropriate policies and monitor any vulnerabilities that cannot be remediated for any and all activity the deviates from authorized activity.
  5. Respond to suspicious behavior—alert and respond to any abnormal or suspicious behavior in real time to minimize risk of attack.

DATABASE SECURITY BEST PRACTICES

The first step for ensuring database security is to develop a database security plan, taking into account regulations such as Sarbanes-Oxley and industry standards such as the Payment Card Industry Data Security Standards with which the organization must comply. The use of a standard checklist is to be advised, rather than trying to develop a security plan from scratch. Examples of such as checklist include those available from the information assurance support environment website, sponsored by the U.S. Defense Information Systems Agency or the Center for Internet Security.

As part of the development of this plan, the organization should take an inventory of all databases within the organization’s network environment, which can be done more efficiently through use of vulnerability management technology that can automatically discover all databases and run scans to identify which contain sensitive information, such as financial information and customer data. The scans performed by such technology will also be able to assess database vulnerabilities and misconfigurations, identifying issues such as default or weak passwords, missing patches and poor access controls, and will look to identify which vulnerabilities can be exploited so that remediation can be prioritized. Most tools available will include built-in templates that incorporate the requirements of many best practice frameworks and regulatory compliance initiatives. Such tools should be used not only when developing a database security program, but on a continuous basis to identify new threats and vulnerabilities.

Database activity monitoring (DAM) tools will also aid in the process of reducing vulnerabilities by providing visibility in real time into all database activity. Such tools collect data, aggregate it and analyze the data to look for activities that are in violation of security policy or that indicate anomalies have occurred. According to the Gartner Group, the primary reason for deploying DAM technologies is to monitor the activity of privileged users such as database and system administrators, developers, and help desk and outsourced personnel, many of whom typically have unfettered access to corporate databases. To ensure that threats are minimized and the requirements of regulations are being complied with, DAM tools should be used to identify anomalous activities such as privileged users viewing sensitive data, altering log records, making unauthorized configuration changes or creating new accounts with super user privileges. They can compare activities performed with those authorized by change requests. In general, it is considered to be best practice to implement access controls based on the principle of least privilege to ensure that no one user has excessive access rights and those rights should be regularly audited.

Click here for full Story

How to Enable and Grant Remote Access to MySQL Database Server

For reasons of security, remote access to MySQL database server is disabled by default because they are considered potential security threats. However, due to some reason, it is necessary to allow access from a remote location or web server. Let assume that we are making connection from remote web server IP called 192.168.0.3 for database called db1 for user user1 at remote MySQL server, 192.168.0.2, then we need to grant access to this IP address.

If the remote access is not enable you will get this error :

ERROR 1130 (HY000): Host ‘192.168.0.3’ is not allowed to connect to this MySQL server

IP Adress 1 : 192.168.0.2 – MySQL Server
IP Adress 2 : 192.168.0.3 – Web Server (Nginx or Apache)

Steps to Enable and Grant Remote Access to MySQL Database Server

1. Edit the my.cnf file :

# vim /etc/mysql/my.cnf

Comment out or remove below line :

#bind-address           = 127.0.0.1

2. The following command will allow access to the MySQL database(192.168.0.2) from a remote web server IP address(192.168.0.3):

mysql> create user 'user1'@'192.168.0.3' identified by 'PASSWORD';
mysql> grant all on db1.* to 'user1'@'192.168.0.3';

3. Test the connection from the remote web server :

# mysql -u user1 -pPASSWORD -h 192.168.0.2

4. Verify the user privileges for user1 :

mysql> select * from information_schema.user_privileges where grantee like "'user1'%";

5. In case you want to revoke all options the access from all machine or web server(192.168.0.3) only :

mysql> revoke all privileges, grant option from 'user1'@'%';
mysql> revoke all privileges, grant option from 'user1'@'192.168.0.3';

database

How to Calculate and List Sizes of MySQL / MariaDB Databases

Question :
I am finding the best way to calculate and list sizes of MySQL or MariaDB Databases ?

Answer :

In order to achive this, please do the following.

1. Enter to mysql root console:

# mysql -u root -p

2. Run the following SQL select query to calculate and list the sizes of all available databases in MySQL or MariaDB.

MariaDB [(none)]> SELECT table_schema AS "DB Name", SUM(data_length + index_length) / 1024 / 1024 AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema;

Output :

+--------------------+-------------+
| DB Name            | Size (MB)   |
+--------------------+-------------+
| wordpressdb        | 36.79408455 |
| information_schema |  0.14062500 |
| mysql              |  0.62723351 |
| oscommercedb       |  1.42187500 |
| performance_schema |  0.00000000 |
+--------------------+-------------+
5 rows in set (0.02 sec)

MariaDB [(none)]>

linux-banner

How To Get Email Alerts for SSH Login on Linux Server

Enable SSH server on a virtual private server (VPS) will expose the server to the internet and provide opportunities for hacking activities, especially when VPS still using root as a primary access. VPS should be configured with a email alert automatically to each successful login attempts via SSH server . VPS server owner shall be notified of any SSH server access log, such as who, when and which source IP address. This is an important security concern for server owners to protect the server from unknown login attempts. This is because if hackers use brute force to log into your VPS via ssh then it can be very dangerous. In this article, I will explain how to set up an email alert to all SSH login users on linux CentOS 6, CentOS 7, RHEL 6 and RHEL 7.

1. Login to your server as root user :

2. Configure at alert from source global definitions (/etc/bashrc). This will enabled for root and normal users :

[root@vps ~]# vi /etc/bashrc

Add the following at the bottom of the files.

echo 'ALERT - Root Shell Access (vps.ehowstuff.com) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" recipient@gmail.com

3. Optionally you can enable alert for root only :

[root@vps ~]# vi .bashrc

Add the following at the bottom of /root/.bashrc :

echo 'ALERT - Root Shell Access (vps.ehowstuff.com) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" recipient@gmail.com

Full Configuration file example :

# .bashrc

# User specific aliases and functions

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi
echo 'ALERT - Root Shell Access (vps.ehowstuff.com) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" recipient@gmail.com

4. Optionally you can enable alert for specify normal user (e.g skytech ) :

[root@vps ~]# vi /home/skytech/.bashrc

Add the following at the bottom of /home/skytech/.bashrc :

echo 'ALERT - Root Shell Access (vps.ehowstuff.com) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" recipient@gmail.com

fail2ban-security

How to Use Fail2ban to Stop/Prevent SSH Brute Force on Linux

Brute-force break-in attempts are quite frequent against the SSH server. However, there is an open source software that can help you deal with this problem automatically, namely fail2ban. Fail2ban provides a way to protect private virtual server( VPS ) from malicious behavior by intruders or hackers automatically. This program works by scanning through log files and respond to unsuccessful login attempts and repeated login attempts. Here are the steps on how to implement fail2ban and steps have been tested on CentOS 6, CentOS 7, RHEL 6 and RHEL 7.

1. Install fail2ban :

# yum install fail2ban -y

2. Make a copy of original config file :

# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

3. Update jail.local configuration file :

# vi /etc/fail2ban/jail.local

Add as below :

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=receipient@gmail.com, sender=fail2ban@ehowstuff.com, sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

4. Configure the prefered “bantime”, “findtime” and “maxretry” before a host get banned :

# vi /etc/fail2ban/jail.local

Update to the following :

..
..
# "bantime" is the number of seconds that a host is banned.
bantime  = 7200

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 3
..
..

5. Verify sshd filter file :
You can verify the default sshd filter file.

# vi /etc/fail2ban/filter.d/sshd.conf

6. Restart fail2ban :

# service fail2ban restart

7. After a few hours of implementation, fail2ban start capturing and banned for such violence and attempts to guess the password for my VPS. Look at the log at path /var/log/secure for monitoring :

# tail -f /var/log/secure
Mar  3 13:37:59 rn sshd[30681]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:38:02 rn sshd[30681]: Failed password for root from 115.231.218.57 port 2919 ssh2
Mar  3 13:38:05 rn sshd[30681]: Failed password for root from 115.231.218.57 port 2919 ssh2
Mar  3 13:38:07 rn sshd[30681]: Failed password for root from 115.231.218.57 port 2919 ssh2
Mar  3 13:38:09 rn sshd[30681]: Failed password for root from 115.231.218.57 port 2919 ssh2
Mar  3 13:38:12 rn sshd[30681]: Failed password for root from 115.231.218.57 port 2919 ssh2
Mar  3 13:38:13 rn sshd[30681]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:38:48 rn sshd[30702]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:38:50 rn sshd[30702]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:38:52 rn sshd[30702]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:38:54 rn sshd[30702]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:38:56 rn sshd[30702]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:38:58 rn sshd[30702]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:38:58 rn sshd[30702]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:39:00 rn sshd[30704]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:39:02 rn sshd[30704]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:39:04 rn sshd[30704]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:39:07 rn sshd[30704]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:39:09 rn sshd[30704]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:39:11 rn sshd[30704]: Failed password for root from 115.231.218.57 port 3090 ssh2
Mar  3 13:39:12 rn sshd[30704]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57  user=root
Mar  3 13:39:24 rn sshd[30708]: Invalid user admin from 115.231.218.57
Mar  3 13:39:24 rn sshd[30708]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57
Mar  3 13:39:26 rn sshd[30708]: Failed password for invalid user admin from 115.231.218.57 port 2898 ssh2
Mar  3 13:39:27 rn sshd[30708]: Failed password for invalid user admin from 115.231.218.57 port 2898 ssh2
Mar  3 13:39:30 rn sshd[30708]: Failed password for invalid user admin from 115.231.218.57 port 2898 ssh2
Mar  3 13:39:33 rn sshd[30708]: Failed password for invalid user admin from 115.231.218.57 port 2898 ssh2
Mar  3 13:39:35 rn sshd[30708]: Failed password for invalid user admin from 115.231.218.57 port 2898 ssh2
Mar  3 13:39:35 rn sshd[30708]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.231.218.57

8. Fail2ban start to ban and unban after two hours :

# tail -f /var/log/messages
Mar  3 13:38:13 rn fail2ban.actions[25912]: WARNING [ssh-iptables] Ban 115.231.218.57
Mar  3 13:38:58 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:39:12 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:39:33 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:39:43 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:39:56 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:40:20 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:40:30 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:40:41 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 13:40:51 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:30:32 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:30:46 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:31:35 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:32:34 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:32:51 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:33:02 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:33:32 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:33:43 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:33:54 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:34:06 rn fail2ban.actions[25912]: INFO [ssh-iptables] 115.231.218.57 already banned
Mar  3 15:38:14 rn fail2ban.actions[25912]: WARNING [ssh-iptables] Unban 115.231.218.57

9. All the ban action followed by the email trigger as per screenshot :
fail2ban-1

fail2ban-security

10. Check the Which IP already listed in the ban list :

# iptables -L
..
..
Chain fail2ban-NoAuthFailures (1 references)
target     prot opt source               destination
REJECT     all  --  141.101.98.8         anywhere            reject-with icmp-port-unreachable
REJECT     all  --  108.162.210.231      anywhere            reject-with icmp-port-unreachable
REJECT     all  --  108.162.221.246      anywhere            reject-with icmp-port-unreachable
REJECT     all  --  108.162.238.35       anywhere            reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

How to Install EPEL Yum Repository on Linux CentOS 7 / RHEL 7

Epel yum repository is an open source centos yum repository or rpm repository for developers and system administrators to perform the installation of RPM packages via yum on their virtual private server (VPS) or dedicated server.

EPEL yum repository is redhat yum repository for CentOS and additional yum repository for the existing CentOS repository.

It provides 100 % high quality software packages for Linux distributions, including RHEL (Red Hat Enterprise Linux), CentOS and Debian, and all packages maintained by Fedora repo team.

1. Prepare EPEL repository for RHEL 7/CentOS 7 64 bit (epel centos 7/epel rhel 7) :

# sudo rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7
# # sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm

Example :

# sudo rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7
# sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
Retrieving https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:epel-release-7-9                 ################################# [100%]

In CentOS 7, an alternative way to install the EPEL repo is by using the command yum :

# sudo yum install epel-release -y

2. Command to verify that the EPEL repository is enabled.

# sudo yum repolist

Sample output :

# sudo yum repolist
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.linode.com
 * epel: ftp.osuosl.org
 * extras: mirrors.linode.com
 * updates: mirrors.linode.com
repo id                                                       repo name                                                                                 status
base/7/x86_64                                                 CentOS-7 - Base                                                                            9,363
epel/x86_64                                                   Extra Packages for Enterprise Linux 7 - x86_64                                            11,046
extras/7/x86_64                                               CentOS-7 - Extras                                                                            200
nginx/x86_64                                                  nginx repo                                                                                    41
updates/7/x86_64                                              CentOS-7 - Updates                                                                           438
varnish-4.1/x86_64                                            Varnish Cache 4.1 for Enterprise Linux                                                        31
repolist: 21,119

3. Install httpd package using epel repo option –enablerepo=epel :

# sudo yum --enablerepo=epel install httpd

EPEL Yum Repository

How to Change the WordPress URLs in MySQL Database

Before this I have experienced issues in wordpress migration of servers moving from the test server with an unregistered domain URL (www.ehowstuff.local) to the new virtual private server (VPS) with a registered domain (www.ehowstuff.com). After struggling to do research on google, I found the steps below that save a lot of time.

Step 1 : Update ‘siteurl’ and ‘home’ :

Select the WordPress database :

mysql> use wordpressdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

Check current value for ‘siteurl’ and ‘home’ :

mysql> SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');
+-------------+----------------------------+
| option_name | option_value               |
+-------------+----------------------------+
| home        | http://www.ehowstuff.local |
| siteurl     | http://www.ehowstuff.local |
+-------------+----------------------------+
2 rows in set (0.00 sec)

Update the value for ‘siteurl’ and ‘home’ :

mysql> UPDATE wp_options SET option_value = 'https://webhostinggeeks.com/howto' WHERE option_name IN ('siteurl', 'home');
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

Check the updated value for ‘siteurl’ and ‘home’ :

mysql> SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

+-------------+--------------------------+
| option_name | option_value             |
+-------------+--------------------------+
| home        | https://webhostinggeeks.com/howto |
| siteurl     | https://webhostinggeeks.com/howto |
+-------------+--------------------------+
2 rows in set (0.00 sec)

Optionally you can use below query to achieve step 1:

mysql> UPDATE wp_options SET option_value = replace(option_value, 'http://www.ehowstuff.local', 'https://webhostinggeeks.com/howto') WHERE option_name = 'home' OR option_name = 'siteurl';

Step 2 : Update the guid value in wp_posts table :

mysql> UPDATE wp_posts SET guid = replace(guid, 'http://www.ehowstuff.local','https://webhostinggeeks.com/howto');

Step 3 : Update the post_content value in wp_posts table :

mysql> UPDATE wp_posts SET post_content = replace(post_content, 'http://www.ehowstuff.local', 'https://webhostinggeeks.com/howto');

Step 4 : Update the meta_value value in wp_postmeta table :

mysql> UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.ehowstuff.local', 'https://webhostinggeeks.com/howto');

wp-wall