A locked gate is an obstacle, but a skilled attacker can easily defeat it. Now, what if this gate has 10 different kinds of locks, is rigged with an alarm, and leads to a mine field? Yeah, that would dissuade a vast majority of attackers. This approach to security is called Defense in depth. Server security experts use a similar approach called Layered security to keep out attackers.

Fort, moat and canons – Pretty hard to breach

From hiding critical information, to IP based access restrictions, there are a wide array of defenses that can be deployed on a server. So, even if an attacker manages to bypass one layer, there’ll always be another defensive layer to take its place.

Today, let’s take a look at how to secure a server using Layered security.

1. 1. 1. Protect and update system software

      Vulnerable software is perhaps the most popular way for hackers to gain access to a server. Software vulnerability results from using outdated or non-authentic software. Here are the various ways in which you can ensure your software packages are secure:

      • Update software packages periodically  – Configure the package management software (such as Yum) to send you notification when an update is available.
        

        Yum-Cron is a utility that’ll notify you when updates are available

      • Delete unwanted packages – Default OS installs contain packages you may not need. For eg. a database server need not have web server components.
      • Apply security updates ASAP – Auto updates can be configured for security updates. For eg., in Redhat compatible systems yum-security plugin can be used for this purpose.
      • Use only verified, authentic repositories – Get application repos only from official repositories cross verified using PGP signature.
        

        You can verify individual packages (like here) or set the updater to verify automatically before downloading

      • Protect your base repos from being overwritten – If you use multiple sources for your software, protect your core system libraries from accidental deletion. For eg., in RedHat compatible systems, you can use “yum-protectbase” for this purpose.

      Read : How to keep your systems updated and patched

   2. 2. Enforce strong user account security

      Why break down the door, if you have the key? Valid login details are the equivalent to getting a key to a well secured door. It is the path of least resistance and often over-looked by server administrators. Attackers use phishing, brute forcing, or social engineering to steal login details. Here are a few tips to secure user accounts:

      • • Prevent account setup with empty passwords – Configure the account setup policies and/or scripts so that a password is mandatory to setup an account.
        • Enforce use of strong passwords – Users tend to set easy to remember, short passwords, but it is often vulnerable to dictionary attacks. Enforce use of long passwords.
          

          Good passwords need not be hard to remember

        • Setup password expiry – The longer a password remains unchanged, the more time an attacker has to guess the right login combination. Force periodic password resets.
        • Prevent use of old passwords – Some attackers keep pilfering sensitive information using stolen passwords. Changing passwords periodically can block this, but it won’t work if the user sets the old password. So, prevent re-use of passwords.
        • Lock account after login failures – Hackers use automated tools that push in hundreds of passwords per minute to get a working combination. You can prevent it by setting the account to lock after a few login failures.
          

          For highly sensitive systems, set the lockout retries very low

        • Use IP restriction where possible – For sensitive users such as administrators, limit logins to a pre-approved set of IPs.
        • Restrict permissions of user accounts – Build a security policy that prevents users from listing other system users, or navigating out of their home directories.
        • Setup centralized authentication to avoid exploits via unused accounts – Old accounts or test accounts are a favorite loophole for attackers. Centralized user management systems such as LDAP can help you easily audit and remove old accounts.
        • Configure secure authentication systems to block password snooping on the network – Attackers can sniff our username/password pairs sent across networks. Use of secure authentication systems like Kerberos avoid sending passwords across the network, thereby foiling sniffing attacks.
        • Consider using 2 factor authentication – For critical accounts, such as administrative accounts, setup 2 step authentication.
      

      Google authenticator is a free 2FA solution

      • Educate users on good security practices – Publish a page on your website explaining how Phishing, Social Engineering, Trojans or other malware can be used to steal login details.

   3. 3. Lock down public facing services

      Much like how open windows are access points to a house, open ports are access points to a server. Unsecured ports and services are easy entry points for attackers. Here’s how you can lock down public facing ports:

      • Disable un-used services from auto-start – In a default OS installation, many services are set to auto-start. This will open ports to the public, which may not be secure. So, disable all services you do not need.
      • Enable SSL in all services – Many services such as Web, Mail, FTP, etc. require end-users to authenticate to access services. Attackers can steal these login details by listening to the traffic. To prevent this, enable encryption for all services.
        

        Services such as Let’s Encrypt provide free SSL certificates.

      • Monitor open ports and sockets – Many kinds of malware (such as RATs or Bots) open a communication link to their malicious handlers using non-standard ports. So, it is important to monitor if any new ports or sockets were opened without your knowledge.
      • Monitor for malware taking over standard service ports – Some malware are known to kill standard services such as FTP or POP3, and occupy their ports. A service listing will show nothing out of ordinary, nor will a firewall block such a port. Use specialized tools to monitor such “port hijacking”.

      Read : How Bobcares detects security and performance issues

1. 1. 4. Harden the system and network

      It is hard to get into a fully patched and updated system. However, there are cases where attackers exploit un-published vulnerabilities and get access to servers. A strong precaution against such a possibility is to harden the operating system and network.

      • Use Mandatory Access Control systems to block unauthorized operations – There are kernel patches in Linux and Mandatory Integrity Control features in Linux that restricts each user to a very limited set of operations. This effectively blocks an attacker from running any damaging exploits.
        

        SELinux is a popular Mandatory Access Control system in Linux

      • Tweak network parameters to block common network based attacks – Many common attacks such as Slowloris, Syn flood, or Spoofed packets exploit insecure default settings in operating systems. The network settings need to be adjusted to defend against these issues.

      Read : How to improve Linux server security using SELinux

   2. 5. Secure the filesystem

      The filesystem controls the access privileges of each user. By hardening the filesystem settings, any malware that’s uploaded to the server can be blocked from being executed. Here are a few tips:

      • Block execution of malware in user-accessible directories – Deny “execute” permission to any program file (aka “binaries”) uploaded to directories accessible by the end-user.
      • Block super-user privilege execution of scripts by users – Malicious users can access another user’s (or administrator) privileges if a special “set UID” or “set GUID” permission is given while creating the file. Configure the filesystem so that such files cannot be created in user-accessible directories.
        

        Here’s how the /tmp folder can be secured in Linux

      • Block access to unauthorized devices from user directories – Some filesystems allow creation of block devices or shortcuts to system devices. This can result in data breach. So, block such device access during filesystem initialization.
      • Prevent modification of system binaries – Core system binaries can be write protected by using special filesystem settings. Preventing modification at filesystem level can be an effective deterrent against core system infection.
      • Protect your operating system boot image – Every operating system uses a boot image to load the core functions. This image should be write protected to prevent malware infection.

        A lot of attacks rely on executing a malware on the server. In our server management services, filesystem hardening is one of the ways we prevent malware execution. We know it is effective because we routinely find malware uploaded to public accessible folders, but lying there un-executed. If not for filesystem hardening, those attacks would have succeeded.   

      Blessen Cherian
      Member of Executive Group, Bobcares

       

   3. 6. Enable firewall

      Almost all attacks happen over the network. So it makes sense to put use a security program that inspects the network stream, and blocks all accesses that look suspicious. This tool is called a firewall. Here are a few best practices to be followed while configuring a firewall.

      • Close all ports, and open only the ones you need – This is the most fundamental principle in network security. Block all, and allow only those you really want.
      • Block spoofed connections from internal address range – Block all network accesses that come in from the internet, but disguises itself as from the local network – it’s NOT a good customer.
      • Block malformed network connections (null packets, XMAS packets, etc.) – Good applications send in healthy, fully formed packets. Malicious actors send in packets not having the full information, or skewed structure.
      • Setup a brute force monitor to automatically block abusive IPs – Legitimate users do not send in hundreds of login requests per minute. Install a brute force monitor and block originating IPs.
      • Monitor port scanning behavior and block attacker IPs – Valid users come directly to a standard service port, and request information. Malicious users scan for any open ports. Block any IP that tries to connect to closed ports at random.
      • Enable SYN flooding protection – Malicious actors force servers to exhaust resources by opening connections, but not actually requesting any information. Block such instances by enabling SYN flood protection.
      • Disable or rate limit ICMP (Ping) connections – Ping is a reliable tool to debug network connectivity, but it’s features can be used for “ping flooding” attacks. So, rate limit how many ping packets (aka ICMP) packets can be received per second.
      • Consider blocking connections from Dynamic IP blacklists – There are real-time dynamic databases which lists IPs of malware infected computers. Consider proactively blocking these IPs to avoid attacks.

      Read : An easy way to enable firewall in Linux servers

1. 1. 7. Harden the web server

      A vast majority of attacks are directed at web servers. From web application vulnerabilities to server vulnerabilities, a wide range of security loopholes are exploited on a daily basis to access sensitive information. Here’s how you can keep your web server secure:

      • Prevent information disclosure – In its default configuration, most web servers display a lot of information about the version of the software, list of files in a directory, list of web server modules, etc.. Unless expressly disabled, this provides a wealth of information for an attacker to run a successful exploit.
      • Disable all un-wanted web server modules – Many web servers allow add-on modules to increase their feature set. But each module increases a server’s surface area for attacks. So, it’s best to disable modules that are not used regularly.
      • Audit and disable all features that can used to run system commands – Some web server features allow running of system commands. These features can be used in hack attempts. Disable such features if it’s not absolutely essential to your service.
      • Run user scripts as un-privileged processes – Some web servers run user scripts in web server’s ownership. This enables one user to access the data of all other users. So, it is best to enable user-mode execution (eg. using SuPHP) to limit attackers.
      • Enable DoS protection – Web servers are the most targeted service in DoS attacks. Setup and enable special DDoS protection modules to block abusive IPs.
      • Block common exploit attempts using a Web Application Firewall – There are a wide range of attack methods such as Cross Site Scripting (XSS), SQL injection, or CSRF that’s used to exploit web applications. Web Application Firewalls (WAFs) can be used to block such attacks, and even block known exploits using a signature database.
      • Enable upload time malware scanning – Use a malware scanner to block upload of spam scripts, bots, or other such malicious scripts. This should be enabled in all upload channels including web, FTP, web disk, file shares, etc.
      • Use malware signatures from multiple sources – A single vendor may not have all the recent malware or attack signatures. Use signatures from various sources to improve your firewall effectiveness.
      • Enable captcha in web forms to prevent brute forcing and comment spamming – Comment spams are a favorite way for attackers to execute SQL injection, or redirect unwary users to malicious websites. Enable captcha in all web applications to prevent bots from injecting malicious code.
      • Limit resources available to a single user – An attack on a website can easily cause resource usage spike, and cause the server to go down. Use resource limits for each user to prevent this possibility.
      • Use server hardening patches – Many web server modules are designed for feature richness, and not security. Use independent security patches (such as Suhosin for PHP) that can be used to harden the server.
      • Restrict permissions to prevent one user from seeing another user’s data – Some web servers allow web applications to navigate out of user’s home folder using symbolic links, lax permissions, etc. Secure all web server and filesystem settings to prevent data breach.
      • Force SSL (HSTS) if possible – Attackers can sniff web application login details by listening in on the web traffic. By enforcing HTTPS connection in all web requests, this risk can be minimized.
      • Monitor web traffic for anomalies – New exploits come out all the time. With due vigilance, new attacks (which may bypass your firewalls) can be detected and blocked early on. Monitor log files, web connections and web processes round the clock for abnormal activity.
      • Apply security patches ASAP – Setup a notification system to know about latest security patches, and apply them as soon as it is available.
      • Subscribe to vulnerability disclosures – Independent researchers announce security vulnerabilities all the time. Vendors may not be able to patch it fast enough. Being aware of such vulnerabilities will help you block an attack using alternate mitigation strategies until an official patch is available. Eg. See how we mitigated ImageTragick vulnerability.

      Read : An in-depth guide on how to secure your web server

   2. 8. Secure the database server

      Many attacks are crafted to finally get access to a database. For hackers, it’s like hitting a gold mine. Assuming that an attacker got past all other defenses, the database itself should be able to withstand information disclosure attacks. Here’s how you can improve database security.

      • Enforce a password for all database users – Never create a user with no password. Audit regularly to make sure all accounts have passwords.
      • Remove all default users and demo/test databases – Almost all database servers come with a few demo databases and users. These details are public information. It’s best to remove these accounts.
      • Restrict user privileges to only what’s needed – It is common practice to create database users with access to all tables in a database. This is really not needed in all cases. Give access to only minimum required tables, and limit privileges (SELECT, INSERT, etc.) to only that’s needed by that user. It’ll prevent data loss even if an exploit is attempted (see image below).
      • Change the name of admin user – The admin username of most database servers is public information. Change the admin username to prevent automated database attacks.
      • Restrict remote connections to only known IPs – Ideally remote access should be disabled. But if it’s absolutely required, restrict the access to only known IPs.
      • Do not store database backups on public locations – This is an all-too-common mistake. Application owners take database backups (prior to debugging, upgrades, etc.) and leave them in public accessible locations such as web folders, temporary partition, etc. Use your monitoring system to detect SQL dump files in public folders.
      • Keep the database server updated – Database upgrades can be cumbersome, but it’s not avoidable. Apply security patches as soon as it is available.

      Read : How to secure your database server

   3. 9. Ensure DNS server security

      It is the DNS service that shows people which server to connect to. By hacking DNS servers, attackers can direct ALL visitors of a domain to malware loaded servers. Attacks like DNS cache poisoning has been used in the past for these kind of attacks. Here’s how you can secure your DNS servers:

      • Prevent information disclosure – Knowing the server version and other settings can be a valuable starting point for an attacker to gain access to your DNS server. Hide server software information to prevent this.
      • Disable or Limit recursive DNS queries to block cache poisoning – Unless you are running a caching name server, disable recursive DNS queries.
      • Run the server as non-privileged user – Never run the DNS server under administrative user privileges. Create an un-privileged user, and run the server under restricted privileges.
      • Restrict zone transfers to slave servers – If you are running an authoritative name server, limit which servers can access DNS settings (aka Zone data) of each domain. Attackers can build directed exploits if they have access to this data.
      • Enable DNS Security Extensions (DNSSEC) – You can block cache poisoning (aka DNS spoofing) by digitally signing your DNS records using DNSSEC.
      • Keep the server updated at all times – Apply security patches as soon as they are available.

      Read : What is DNSSEC? How does it work?

1. 1. 10. Harden the SMTP server

      More than web services, people rely on mail services for their daily business operations. So, mail servers are a favorite target for attackers to spread trojans, virus, bots, phishing pages and other malware. Here’s how you can secure your SMTP server:

      • Prevent open relay – Allow only valid users to send mail through the server. SMTP authentication is the best way.
      • Block default web process from sending out mail – Hacked web applications are often used to send out spam and phishing mails. Prevent the default web user from sending out mails. Instead, run web applications under user privileges, and grant mail access to individual users.
      • Enable user identification mail headers – Enable logging of script information in mail headers. This will help you track abuse.
      • Enable sender and recipient validation – Accept only those mails that have a valid sender and recipient address. Many spam mails fail this check.
      • Rate limit outgoing mail per user – Limit the number of mails that can be sent by each user. 50 mails per hour is a decent limit for a small business. For users who send mass mails, increase the limit on a per-case basis.
      • Enable an alternate SMTP port – Get your mail server users to send out mails using an alternate SMTP port, such as “26” or “587”. This will help you block attempts at spam relay.
      • Enable TLS on all ports – Mails contain sensitive information. Enable TLS on all ports to prevent data sniffing.
      • Block connections that is not RFC compliant – Spammers try to send thousands of mails per minute. It is difficult for them to follow strict mail transfer protocols in relaying mail. So, enforce RFC compliance checks to block spam mails.
      • Setup connection limit per IP – There are cases where virus infected computers try to send spam mails using valid user login details. Setting a connection limit per IP will limit the number of spam sent out in such cases.
      • Scan outgoing messages for spam and virus – Many server admins think it’s enough to scan incoming mails for spam and virus. This can lead to poor IP reputation in case spam is sent out from a valid user’s account. It is best to enable outbound mail scanning to maintain good server reputation.
      • Consider using an anti-spam mail gateway – If you are a mail service provider with multiple mail servers, investing in an anti-spam mail gateway can offload the spam processing overhead to just one server.
      • Use multiple signature sources for span and virus checking – Get malware and spam signatures from multiple vendors. This will help you in achieving high anti-spam accuracy.
      • Consider blocking mails from blacklisted IPs – Realtime Block Lists (RBLs) use spam traps to detect spammer IPs. Use these lists to block connections from spamming IPs. Take care to use only reputable lists, as amateur lists can lead to valid mails being blocked.
      • Configure anti-spam DNS records like SPF, DKIM, etc. – Anti-spam DNS records helps remote name servers discard spam mail disguised as mails from your server.
      • Setup reverse DNS for all your interface IPs – Spammers use IP spoofing to send out mails. Many mail providers use reverse DNS to validate a sender IP. Setting up reverse DNS will help smooth delivery of your mails.
      • Subscribe for Sender Feedback Loops – Many big mail service providers notify you if a user tagged a mail sent from your server as spam. Subscribe to these reports, and investigate spam complaints.
      • Setup email IDs to report abuse – It’s a best practice to setup abuse reporting mail IDs such as “abuse@servername.com” that helps other server admins to send you reports of spamming from your server. It helps in quick spam source identification and mitigation.
      • Monitor all Realtime Block Lists for your mail IPs – Setup your monitoring systems to notify you if your mail server IP is listed in any Realtime Block Lists. Such a listing means your mails are being blocked all over the internet. Timely notification helps you mitigate the damage and quarantine the spam source.
      • Run the SMTP server as unprivileged user – A vulnerability in the mail server shouldn’t allow an attacker access to the full server. To make this happen, run the mail server as an unprivileged user.
      • Apply all available updates ASAP – Apply security patches as soon as they are released.

      Read : How to avoid prevent spam blacklists

   2. 11. Secure the POP/IMAP server

      POP/IMAP servers store all business mails. That’s a lot of sensitive information. So, POP/IMAP servers are often targets of directed attacks. Here’s how you can secure your POP/IMAP server:

      • Enable connection limit per IP – Brute forcing is a popular attack strategy to obtain username/password combination for an account. Limit login attempts and connections per IP to prevent this possibility.
      • Enforce strong passwords – Setup a password policy such that users cannot set weak passwords.
      • Consider using a centralized authentication system like LDAP – Using a centralized authentication system minimizes the possibility of old mail accounts lying unattended. These are easy targets for attackers to get into the system.
      • Enable TLS in all ports – Prevent sensitive data disclosure by enabling encryption in all ports.
      • Enforce strict user isolation – Restrict user permissions such that one user cannot get access to another user’s directory.
      • Keep the server updated always – Apply security patches as soon as it is available.

   3. 12. Ensure Remote Desktop security (for Windows servers)

      Windows servers provide the Remote Desktop feature to provide access over network to servers. It is encrypted by default. But there are known ways to break encryption, which can reveal sensitive information. Here’s how you can protect Remote Desktop access:

      • Avoid Remote Desktop where possible – Not all users need Remote Desktop. For eg. a website owner needs only a web management control panel. So, do not give Remote Desktop access unless it’s absolutely needed.
      • Restrict access to an approved list of IPs – Restrict connections to only those IPs that you know are customer IPs.
      • Change the listening port of Remote Desktop – Remote Desktop listens at port 3389. Change this port to block automated exploit attempts.
      • Consider using an RDP gateway – If you have multiple windows servers, using an RDP gateway will help you centrally manage who should be allowed access. This helps secure the servers better.
      • Consider using 2 factor authentication – For critical business systems (such as backup server), consider using 2-factor authentication for administrator access.
      • Setup an account lockout policy – Block brute force attempts by setting an account lockout after a few incorrect login attempts.
      • Keep your software updated – New vulnerabilities are discovered all the time. Update your system as soon as a patch is available.

1. 1. 13. Secure the SSH server (for Linux servers)

      For dedicated servers, VPS or cloud servers in AWS, Google, etc. SSH is the favored way for administrative access. By default, many services give direct root access to customers. Unless locked down properly, attackers can exploit lax SSH settings, and get administrative access to the server. Here’s how you can secure SSH servers:

      • Disable direct root login – “root” has access to everything in the server. It is best to login as a normal user, and then use “sudo” to run commands in administrator mode. This leaves an audit trail as to who accessed the server, and which all commands were run as root.
      • Change SSH port – Prevent automated brute force attacks by changing the default SSH port to a random number.
      • Disable SSH protocol version 1 – SSH v1 has several vulnerabilities that can help an attacker steal sensitive information. So, use only protocol version 2.
      • Enable key based login – It is better to login using public/private key pair, than using a password. In this way, SSH can be accessed only from those computers that have a matching key. Take care to use only keys that are secured by a pass-phrase.
      • Disable port forwarding – Port forwarding can be exploited to bypass firewalls and get to sensitive systems that are not public accessible. If this feature is not needed, disable it.
      • Consider IP restriction – If possible get a list of known IPs from users, and restrict SSH login to those IPs.
      • Enable 2 factor authentication – For highly sensitive servers, consider using 2 factor authentication.
      • Configure idle time out – Attackers could get into servers from unattended systems. It is best to configure an idle time out so that users have to re-login if the session has been idle for too long.
      • Disable host-based authentication – SSH can be configured to allow password-less login from specific IPs. This is a security risk, and should be disabled.
      • Limit the IPs SSH listens to – SSH by default listens to all IPs in a server. This should be restricted to minimize attack surface area.
      • Hide SSH version – If the version of SSH is known, directed attacks can be crafted. So, disable this information.
      • Update SSH regularly – Apply patches as soon as they are available.

      Read : How Bobcares helps Linux server owners ensure high uptime and security

   2. 14. Ensure the SSL/Encryption security

      Everyone knows encryption is good, but not many know that there are weak encryption systems that can be easily cracked. Many servers by default use weak encryption methods, which lead to information disclosure. Here’s how you can secure your encrypted communication.

      • Disable weak ciphers – Ciphers are “steps” to encrypt a data. Some ciphers like DES and RC4 have known vulnerabilities. Replace these ciphers with strong ones like AES and GCM.
      • Disable SSL v2 and v3 – SSL protocols were found to have serious vulnerabilities like FUBAR, POODLE and DROWN. It is best to disable these in all your services.
      • Disable compression over TLS 1.0 – If your server uses TLS 1.0 (it’s recommended to use TLS 1.2), disable compression of HTTP requests, because that’s known to be vulnerable to CRIME exploit.
      • Use certificates of at least 2048 bit strength – The average desktop computer now has enough power to be a threat to encryption strengths less than 2048 bit. So, get certificates of only 2048 or higher.
      • Use encryption for all services – This seems like a moot point, but many server owners use encryption only on web services. It is best to encrypt all channels of traffic from your server.
      • Do not use self-signed certificates – Many think that self-signed certificates are safe, because it provides encryption anyway. This is not true. Self-signed certs always display an error, and end-users then tend to ignore warnings – even if it says there’s active snooping going on. So, it’s best to use certificates from valid certificate authorities. You can get free certs from Lets Encrypt.

      Read : Top 7 SSL/TLS deployment best practices

   3. 15. Enable intrusion detection

      Quick reaction to an intrusion or an intrusion attempt can help you limit any damage done on the server. Intrusion detection systems (IDS) monitor sensitive directories, logs and processes to notify you of un-usual behavior. Here are the things you should monitor.

      • Setup process monitoring – Configure your IDS to report any process that’s run off an unknown file, or from an unusual location.
      • Setup file change monitoring – Monitor system libraries and investigate any change of those files.
      • Setup directory access monitoring – Monitor directories that only the administrator can access. Investigate any access that you do not recognize.
      • Enable network monitoring – IDS tools like Snort can detect network traffic that contains malware. Use it to identify and block attack sources.

      Read : An introduction to different Intrusion Detection Systems
      How to setup Snort IDS

1. 1. 16. Setup malware scanning

      All services and the server devices should be free from malware. For that setup malware scans on all incoming and outgoing network traffic, and on media devices. Here are some best practices.

      • Setup upload time scanning – Any upload, whether it be via Web, FTP, Web disk, File shares, or SSH, it should be scanned for malware content.
      • Configure process scanning – Setup the anti-malware tools to detect malicious behavior in running programs.
      • Setup malware scanning based on filesystem change – When a malware is uploaded, it needs to be written on to the disk. Setup the anti-malware to monitor filesystem changes, and trigger a file scan when a new file is detected.
      • Use multiple anti-virus database – A single database cannot cover all possible viruses. Use multiple vendors to ensure high probability of virus detection.
      • Schedule periodic full server scanning – What if some malware escaped upload time scanning (before your anti-virus signatures were updated)? You can clean them with periodic full server scanning.

      Read : How to detect malicious code injected in websites

   2. 17. Setup logging and auditing

      Logging all system events can help you detect service mis-configuration, and attack attempts. This information can be used to further harden your server. Here are the top information you need to log.

      • Enable file access monitoring – Log which all users tried to access system files or executable scripts and programs.
      • Enable login monitoring – Log the IP, time and username of all login attempts.
      • Enable critical events monitoring – Log system reboots, high loads, or any other event that’s out of ordinary.
      • Setup alerts for unusual log entries – Setup your monitoring system to alert you if unusual entries are found in the log file.
      • Setup command logging – Record all commands issued by users.
      • Log the events to a remote server – In the event of a server breach, an attacker will clear all log files. So, setup your system to relay all log entries to a remote server with only “update” permission.

      Read : How remote logging service was made resilient to failures

   3. 18. Setup a fool proof backup system

      Security is not complete unless you plan for everything. The worst case scenario is that an attack or a hardware failure caused all data to be lost. For you to be able to quickly recover from such an event, backups are mandatory. Here are some backup best practices:

      • Backup daily – Take backups as frequently as possible – at least once a day.
      • Take incremental backups – Reduce load on the server by taking incremental backups.
      • Setup an off-site backup – Copy your backups to a remote server, so that even if your current servers are unreachable, you can restore your site on a different server.
      • Restrict access to backup server – Your backups contain all your business data. Enable multi-factor authentication, and minimize the number of people who have access to it.
      • Monitor your backup process – Monitor the backup process for successful completion. Investigate if the process returns any errors.
      • Test backup integrity periodically – Try restoring data at random at least once a week. This will ensure that the backups will work when needed.

      Read : 7 best practices in maintaining server backups

1. 19. Ensure physical security

   Many businesses now use cloud servers from AWS, Google or Azure. For these users, physical security may not be relevant. But for companies that still use on-premise or co-located servers, physical security is still important. Here are some best practices:

   • Implement physical entry controls – Only authorized personnel with identification should be able to access your servers.
   • Set a BIOS password – No one should be able to change BIOS settings (which can determine boot device, etc.) without a password.
   • Set a boot loader password – Anyone can get super user access by passing boot parameters during server boot up. To prevent this, set a boot loader password.
   • Enable authentication for administrator mode access – Set a password for even emergency mode access.
   • Disable boot-up via USB, DVD or CD – This should be disabled by default, unless activated via BIOS.
   • Disable interactive boot up – Some operating systems such as RedHat allows a user at the terminal to decide which services to start. This can cause an attacker to disable firewall or other security services, and gain access to the server.
   • Monitor server access – Monitor and audit any activity near your server using motion-sensing cameras.

2. 20. Audit and re-harden your servers regularly

   As long as you have data to protect, there will be people trying to steal it. That’s the truth about security. Attackers constantly find new ways to breach security, and new vulnerabilities to exploit. That is why it is important to audit your server defenses periodically, analyze various security events, and re-harden the server. Here are a few things to look for:

   • Confirm if the server is updated – See if all patches are applied, and if not, resolve all issues (technical or business).
   • Verify if all disclosed vulnerabilities are patched – Go through all security advisories and make sure no patches or mitigation steps were missed out.
   • Analyze server events and take action – Go through all critical server events and see if all attacks were blocked as you planned. If not, take corrective actions.
   • Confirm if backups are working fine – Analyze backup logs, and results of backup restore tests. Take corrective action if any issues are noted.
   • Test responses to security events – See if your 24/7 security monitoring team has reacted as planned to security events. Verify if those actions were adequate. Make changes as needed.
   • Verify if the server is secured against new forms of attack – Evaluate the server defenses to see if it can stand up to new forms of attack as disclosed in security channels.
   • Analyze if changes in business functions necessitate new defenses – Some business changes require more in-depth security. For eg. if your company has started storing medical records, you may need to encrypt device drives, or perform penetration testing on your applications. So, make changes to your security model as applicable.

     Periodic top-down security audits are an important part of our server management services. Our security experts try to bypass the server defenses by using popular attack tools loaded with latest exploit methods. By playing the role of an attacker, our experts gain valuable insight into how the server can be further secured against new threats.   

   Sojish Krishnan
   Member of Executive Group, Bobcares

    

In short..

Much like how a fort is secured by a moat, canons, archers and steep walls, effective server security can be ensured only with multiple layers of defenses. Today we’ve seen how to secure a server using Layered security. By securing each sub-system of a server, an attacker will have an uphill task to breach server security – which is enough to encourage them to seek other easier targets.

Bobcares helps online businesses of all sizes achieve world-class security and uptime, using tried and tested solutions. If you’d like to know how to make your server more reliable, we’d be happy to talk to you.