Everything is stored in the form of database today. It may be the health records or your credit card details. Databases – contain data, and data such as credit card information is valuable to criminals.
The increasing pressure of compliance regulations and security policies makes the deployment of high-level database protection a must-have for any organization. Security of the database servers depends on network security, operating system and physical security and so on. It continues to be a big list but it’s important to learn how to secure your database server first.
For those looking for ways to advance database security, here are some best practices to secure your database server
Disable Public Network Access to Database Servers:
We store business applications in the databases. In a real world, the end users don’t need access the database directly so, it is essential to block all public network access to database servers unless we are a hosting provider. Setting up gateway servers (SSH tunnels or VPN) for remote administrators will be ideal.
Lock Down Default Accounts:
Considering Oracle database server here. Post database install, the Oracle database configuration assistant (DBCA) automatically locks and expires the majority of the default database user accounts.
If an Oracle database is manually installed, the DBCA never executes, and those dangerous default privileged accounts are never locked and expired. By default, their password is the same as their username. These will be the very first credentials that a hacker will attempt to use to connect to the database. As a best practice, configure each of these accounts with a strong unique password, and if they are not required, they should be locked and expired.
Regularly patch your Database servers:
Keep patches current. The need for proper database patch management is a mandatory security practice because attackers are actively looking for new security flaws in database systems, and new malware and viruses appear every day. A timely deployment of current versions of database service packs, cumulative updates and critical security hotfixes will advance the stability of database performance.
Ensure Physical Database Security:
Avoid using a shared web server if your database holds sensitive information. While it may be easier, and cheaper, to host your site with a hosting provider you are essentially placing the security of your information in the hands of someone else.
Do not leave the database backups in publicly accessible locations:
Avoid keeping the database backups in publicly accessible locations like web folders, temporary partition, etc.
Remove all unnecessary privileges:
Access needs to be provided to minimum required tables and privileges (SELECT, INSERT, etc.) should be limited to only what’s actually required by the user. Avoid creating users with access to all tables available in the database.
Encrypt Application Files and Backups:
It’s better to encrypt all application files and their backups for security so that hacker can’t access the configuration file through application vulnerability.
Require all database connections to use a strong SID:
The Oracle System ID, or SID is a unique value that is required for all clients to connect to the Oracle database. Since SIDs can be brute forced using tools like Metasploit modules, OAT, OAK, SIDGuess incorporating strong SID name is very important to make the attacker difficult to crack.
Web Application Firewall and Malware Scanner:
We need to set up Web Application Firewalls like NAXSI, ModSecurity, etc. for blocking all common web application exploits. These firewalls can be integrated with malware scanners (ClamAV) to secure from attacks propelled from within the server.
Use different Admin User Name:
Attacker might know the admin user name & can easily guess the password and gain access. Many database servers set the admin username by default and then have to face the consequences. Example: In the case of MySQL, it’s “root”. For additional security, it’s better to change the admin username.
Discard all Default Users and Demo-test Databases:
Demo databases & and Demo-test Databases are public information and therefore, anyone can access our server using these details to collect the database as well as user information. Delete these databases once we create our own.
Perform Regular Database Security Assessments:
Every secure configuration could be easily detected with an automated database vulnerability tool. Regular assessment by using tool like “McAfee Security Scanner” will help in identifying risk.
Enable Password Management for all Oracle Logins:
Oracle provides fairly robust password management for Oracle logins. Unfortunately, none of these are applied in the default Oracle account profile. In Oracle, logins are assigned an account policy through an Oracle profile. Every login can only be applied one Oracle profile. If no Oracle profile is specified when the login is created, it is assigned the default Oracle profile.
There are many other additional ways that can be used to secure database servers. Securing database servers should be an ongoing process.
