Announcement Announcement Module
No announcement yet.
Server Security Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Server Security


    The term security – or the phrase Server security - refers to techniques for ensuring that data stored in a system cannot be read or compromised by any individuals without authorization
    The effort to secure a server is a continuous process; where the security threats needs to be analyzed and then protect the server from each new one of them on a daily basis

    Securing a server by all means will not assure that the server is not prone to attacks; as new vulnerabilities are evolving day by day – of which some are immediately identified while some takes time
    That being said, security is the degree of resistance to, or protection from - harm

    How to make a Linux Server Secure

    A server admin plays the basic role in securing a server
    The most common server securing steps include:
    Implementing and configuring a firewall like CSF or APF
    Enabling Brute Force protection
    Securing SSH service
    TMP hardening
    FTP Hardening & Apache Hardening
    PHP Tightening
    Host.conf and Sysctl.conf hardening
    Implementing Mod Security
    Implementing Mod Evansive
    System Integrity Monitor

    Types of Vulnerabilities

    Sql Injection
    Cross site scripting (XSS)
    CSRF Attack
    Exposure of version information
    Recent Vulnerabilities

    Sql Injection

    SQL injection is a technique where malicious users can inject SQL commands into an SQL statement, via web page input.
    SQL injection can be prevented if you adopt an input validation technique in which user input is authenticated against a set of defined rules for length, type, and syntax and also against business rules.

    To prevent SQL injections we will have to use something called prepared statements which uses bound parameters. Prepared Statements do not combine variables with SQL strings, so it is not possible for an attacker to modify the SQL statement. Prepared Statements combine the variable with the compiled SQL statement, this means that the SQL and the variables are sent separately and the variables are just interpreted as strings, not part of the SQL statement.

    Cross site scripting (XSS)

    The hacker will exploits vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.
    It allows an attacker to embed malicious Javascript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data.
    So xss an attacker will exploit the trust a user has in a website.

    The simplest and arguably the easiest form of XSS protection would be to pass all external data through a filter which will remove dangerous keywords, such as the infamous <SCRIPT> tag, JavaScript commands, CSS styles and other dangerous HTML markup

    Cross Site Request Forgery(CSRF)

    CSRF attacks include a malicious exploit of a website in which a user will transmit malicious requests that the target website trusts without the user’s consent.
    In XSS, the hacker takes advantage of the trust that a user has for a certain website. On the other hand, in CSRF the hacker takes advantage of a website’s trust for a certain user’s browser.

    For example in a chat forum, an attacker posts a message which contains an image tag or an HTML image element. However, the source of the image contains a link which performs an action on a victim’s bank website account. So, instead of an image file the attacker has included a link that performs a bank transaction. Below is an example of the image tag containing a rogue URL.

    A prevention measure could be the implementation and inclusion of tokens in a user’s (current) session. Tokens are long cryptographic values that are difficult to guess. These will be generated when a user’s session begins and will be associated with this particular user’s session. This challenge token will be included in each request, which will be used by the server side to verify the legitimacy of the end-user’s request.

    In order for an attacker to forge an HTTP request, they would have to know the particular challenge value (token) of the victim’s session. The disclosure of the challenge token in the URL (GET requests) should be done wisely and with awareness of the CSRF attack. So in the previous example even if the victim has clicked on the image tag, as long as the attacker didn’t know the token he will not forge the http request.

    Exposure of version information

    An attacker can search for specific security vulnerabilities for the version of Apache identified within the SERVER header.

    Configure your server to prevent information leakage from the server.

    For example we can disclose the php version hiding by adding the below in php.ini file

    expose_php = Off
    register_globals = Off

    Recent Vulnerabilities
    a) Heartbleed : This was a vulnerability that exploits the Heartbeet extension of Openssl. As heartbeat extension was only availble from openssl version 1.0.1
    Fortunately a security patch has been released and we have updated the openssl inorder to apply this patch.

    b) Shellshock :
    Known as the “Bash Bug” or “ShellShock,” the GNU Bash Remote Code Execution Vulnerability could allow an attacker to gain control over a targeted computer if exploited successfully.The vulnerability affects Bash, a common component known as a shell that appears in many versions of Linux and Unix. Bash acts as a command language interpreter. In other words, it allows the user to type commands into a simple text-based window, which the operating system will then run.

    This also can be fixed by updating the bash in the server.

    c) Poodle : POODLE SSLv3.0 vulnerability . This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. SSL 3.0 is nearly 18 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

    This vulnerability can be fixed by disabling the Sslv3 in httpd.conf
    SSLProtocol All -SSLv2 -SSLv3

    Keeping Track of Server Security

    Apart from all these security implementations, one should do a penetration testing to check the server vulnerabilities Rather, to check the possibility of getting a server hacked, one should think and proceed like a hacker. Then only the security holes can be identified Hacking techniques include the very basic tools too


    Security can only be guaranteed by maintaining the server health Proper daily research on new vulnerabilities And finally analyzing a server by trying to intrude in to it; just like a hacker
    Last edited by JinoJoseph; 26th March 2015, 09:18 AM.