How to remove malwares and virus from Linux servers

 

Linux servers are renowned for their resilience and security. However, even the most robust systems can fall prey to malware. When malicious software breaches your Linux server's defences, knowing how to eliminate it is paramount. In this comprehensive guide, we will walk you through the steps necessary to remove malware from your Linux server, including utilizing the helpful tools like 'rkhunter', 'clamav'.

 

However, prevention is better than cure. We will take a quick look into few other tools like 'Snort' for intrusion detection and 'Aide' for system integrity checks.

 

1. Isolate and Assess the Damage

Your initial step when dealing with malware is to isolate the infected server. Disconnect it from the network to prevent further contamination and assess the extent of the damage. Look for signs of unauthorized access, altered or deleted files, and unusual system behavior.

 

2. Identify the Malware

Accurate identification of the malware is crucial. Use trusted antivirus or anti-malware tools compatible with Red Hat Linux, such as ClamAV or rkhunter, to scan your server. These tools can detect known malware signatures, though be mindful of false positives when taking action.

 

2.1 Install ClamAV Antivirus and scan the server.

You need to enable the EPEL repository for installing software like ClamAV and rkhunter.

 

    # yum --enablerepo ol8_developer_EPEL install clamav clamav-update

 

Once installed you need to update the ClamAV antivirus database using:

 

# freshclam 

 

 

Then, you should do a full scan of the server using the following command:

 

        # clamscan -r /

 

ClamAV will print a scan summary after the scan is finished.

 

2.2. Install rkhunter and scan the server

The 'rkhunter' is a specialized tool for detecting rootkits and other intrusions. This tool is adept at detecting rootkits, which are often used by malware to maintain unauthorized access to a system. 'RkHunter' can provide an extra layer of security by identifying any suspicious activities.

 

You can install it on your Linux server using (RedHat based falvours):

 

# yum --enablerepo ol8_developer_EPEL install rkhunter

 

Scan your server for rootkits and malwares using:

 

# rkhunter --check

 

The RkHunter will first analyse the system binaries, libraries and strings for any known infections. Then it will check for rootkits, ports known for being used for trojans and backdoors, start-up files for malwares and so on. It will also perform various other security checks on the server. 

 

And finally, it will print a summary of the results.

 

3. Quarantine and Backup

Once the malware is identified, quarantine infected files.

Take backups of important files before any further actions, but keep in mind that the backed up files could be infected. Backups serve as a safety net, allowing you to recover in case of unforeseen issues during the removal process.

 

4. Manual Inspection

Some malware may evade automated detection. Thoroughly inspect critical system files and directories manually. Look for suspicious changes, new files, or unexpected processes running on your Linux server.

 

5. Disable Unnecessary Services

Disable or shut down any unnecessary services or applications on your server. Malware often exploits vulnerabilities in these services. Keep your software and the operating system of the server up to date to patch known vulnerabilities.

 

6. Remove Malicious Code

If you've identified the malware's code within your server, remove it. Caution is crucial during this process, as editing system files can be risky. Seek expert advice if you're uncertain.

 

7. User Accounts and Permissions

Review user accounts and permissions on your Linux server. Disable or remove suspicious or unnecessary accounts. Reset the passwords for all accounts and enforce strong password policies.

8. Intrusion Detection System

Implement an Intrusion Detection System (IDS) to monitor server activity and detect any unusual behavior. Linux supports various IDS solutions; you can consider using Snort or Suricata.

 

We shall review how to install and configure Snort on Linux systems on another post.

 

9. System Integrity Checks

Regularly perform system integrity checks on your Linux server using tools like AIDE (Advanced Intrusion Detection Environment) to detect any file changes.

 

# yum install aide

 

Initialize aide database

# aide --init

 

 

Check for any changes in the system using the following command.

 

# aide --check 

 

As you can see I created a file testfile.txt and aide detected it.

 

At times, the only option would be to restore from a good known backup or rebuilding the system from scratch. Prevention is always better than cure and you should follow all the security best practices like applying patches, updates and making use of good AntiVirus, Rootkit, IDS are crucial steps. Always prioritize proactive security measures to protect your server.

 

Depricated SSL/TLS Protocols and Ciphers you should not use

 As cybersecurity threats evolve, older SSL/TLS protocols and ciphers that were once considered secure have become deprecated due to vulnerabilities and weaknesses. Here are some of the deprecated SSL/TLS protocols and ciphers:

Deprecated SSL/TLS Protocols:

1.     SSLv2: SSL version 2 is highly insecure and has numerous vulnerabilities, including susceptibility to various attacks like the BEAST attack. It's considered completely obsolete and should not be used.

2.     SSLv3: SSL version 3 is also deprecated due to vulnerabilities like POODLE (Padding Oracle On Downgraded Legacy Encryption). It's no longer considered secure.

3.     TLS 1.0: TLS 1.0 is deprecated because it's vulnerable to attacks like BEAST and POODLE. It lacks some modern security features found in newer TLS versions.

4.     TLS 1.1: TLS 1.1 is considered weak and is also deprecated in many security-conscious environments.

Deprecated SSL/TLS Cipher Suites:

1.     RC4: The RC4 cipher is deprecated due to multiple vulnerabilities, including biases that allow for practical attacks. It's recommended to avoid using RC4 in favor of stronger ciphers like AES.

2.     DES (Data Encryption Standard): DES is considered weak due to its small key size, making it vulnerable to brute-force attacks. It's deprecated in favor of stronger encryption algorithms.

3.     3DES (Triple Data Encryption Standard): While 3DES was once considered secure, its key length and vulnerability to certain attacks make it deprecated in favor of more robust encryption algorithms.

4.     EXPORT Cipher Suites: These cipher suites were designed to comply with export restrictions on encryption technology in the 1990s. They have extremely weak key lengths and are deprecated.

5.     NULL Cipher Suites: These cipher suites provide no encryption, making data transmission completely insecure. They should never be used.

6.     Anon Cipher Suites: Anonymous cipher suites don't require the server to present a digital certificate, making them susceptible to man-in-the-middle attacks. They are deprecated for security reasons.

7.     Cipher Suites with Weak Key Lengths: Cipher suites with key lengths less than 128 bits (e.g., 40-bit or 56-bit keys) are deprecated due to their vulnerability to brute-force attacks.

It's crucial to keep your SSL/TLS configurations up to date and avoid using deprecated protocols and ciphers to maintain a high level of security for your web services. Most modern web browsers and servers have deprecated these older protocols and ciphers as well, and it's essential to configure your systems to use only strong, secure options to protect against potential security threats.

 

TLS/SSL Cipher Suites and TLS handshake process

The foundation of secure communication on the internet relies heavily on TLS/SSL cipher suites. These suites dictate the algorithms used to encrypt and decrypt data, ensuring that sensitive information remains private and protected. In this article, we'll delve into the world of TLS/SSL cipher suites, examining how they work, their components, and their importance in establishing secure connections.

Understanding TLS/SSL Cipher Suites

A cipher suite is a combination of cryptographic algorithms that determine how data is secured during transmission over a network. Each TLS/SSL connection negotiates a cipher suite, allowing both the client and the server to agree on the encryption and authentication methods to be used. A typical cipher suite consists of several components:

1.     Key Exchange Algorithm: This component is responsible for securely exchanging encryption keys between the client and server. Common key exchange methods include Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDHE), and RSA.

2.     Authentication Algorithm: This algorithm verifies the authenticity of the server's digital certificate. The most widely used authentication method is RSA, although ECDSA (Elliptic Curve Digital Signature Algorithm) is gaining popularity.

3.     Symmetric Encryption Algorithm: Symmetric encryption relies on a single shared key for both encryption and decryption. Common symmetric encryption algorithms include AES (Advanced Encryption Standard), 3DES (Triple Data Encryption Standard), and RC4 (Rivest Cipher 4).

4.     Message Authentication Code (MAC) Algorithm: MAC algorithms ensure message integrity by verifying that data has not been tampered with during transmission. HMAC (Hash-based Message Authentication Code) is a popular choice.

5.     Hash Function: Hash functions are used for various purposes, such as generating digital signatures and verifying the integrity of transmitted data. Common hash functions include SHA-256 (Secure Hash Algorithm 256-bit) and SHA-384.

The TLS Handshake Process

To establish a secure connection using a specific cipher suite, the TLS handshake process takes place:

1.     ClientHello: The client initiates the connection by sending a "ClientHello" message to the server. This message includes information about the cipher suites it supports.

2.     ServerHello: The server responds with a "ServerHello" message, selecting a cipher suite from the list provided by the client.

3.     Key Exchange: If necessary (as determined by the chosen cipher suite), the client and server exchange key information securely.

4.     Certificate Verification: The server presents its digital certificate to the client for verification. The client checks the certificate's authenticity using its list of trusted Certificate Authorities (CAs).

5.     Session Key Generation: Both the client and server use the exchanged key information to derive a session key, which will be used for symmetric encryption.

6.     Finished: Finally, both parties exchange "Finished" messages to confirm that the handshake was successful. Subsequent data is encrypted and decrypted using the derived session key.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy is a property of certain key exchange methods (such as DHE and ECDHE) that ensures that even if an attacker obtains the long-term private key, they cannot decrypt past communications encrypted with session keys. This enhances security and privacy.

Choosing the Right Cipher Suite

The choice of cipher suite is essential for security. It depends on factors like the sensitivity of the data being transmitted, the server's security configuration, and performance considerations. Strong, up-to-date cipher suites are recommended to ensure the highest level of security.

 

TLS Cipher Suites

Cipher Suite	Key Exchange Algorithm	Authentication Algorithm	Symmetric Encryption Algorithm	MAC Algorithm	Hash Function
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	ECDHE	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	ECDHE	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	DHE	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	DHE	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_GCM_SHA384	RSA	RSA	AES-256-GCM	HMAC-SHA384	SHA-384
TLS_RSA_WITH_AES_128_GCM_SHA256	RSA	RSA	AES-128-GCM	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_CBC_SHA256	RSA	RSA	AES-256-CBC	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_128_CBC_SHA256	RSA	RSA	AES-128-CBC	HMAC-SHA256	SHA-256
TLS_RSA_WITH_AES_256_CBC_SHA	RSA	RSA	AES-256-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_AES_128_CBC_SHA	RSA	RSA	AES-128-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_3DES_EDE_CBC_SHA	RSA	RSA	3DES-EDE-CBC	HMAC-SHA1	SHA-1
TLS_RSA_WITH_RC4_128_SHA	RSA	RSA	RC4 (128-bit)	HMAC-SHA1	SHA-1

 

Please note that this table includes various combinations of key exchange, authentication, and encryption algorithms. The choice of cipher suite depends on factors like security requirements, server and client compatibility, and performance considerations. Additionally, it's crucial to stay updated with the latest security standards and recommendations when configuring TLS cipher suites for your web services.

TLS/SSL cipher suites are the building blocks of secure communication on the internet. By defining the encryption, authentication, and key exchange methods used during the TLS handshake, cipher suites enable secure data transmission and protect users from eavesdropping and data tampering.

 

SSL/TLS Certificate Chain Validation in HTTPS

The use of SSL/TLS (Secure Sockets Layer/Transport Layer Security) encryption is fundamental to the security of internet communication. When you connect to an HTTPS website, your browser engages in a complex process of validating SSL/TLS certificates to ensure secure and trustworthy data transfer. In this article, we'll unravel the mystery behind SSL/TLS certificate chain validation and how it works to secure your online interactions.

The Importance of SSL/TLS Certificates

SSL/TLS certificates play a pivotal role in the encryption and authentication of data transmitted over the web. They provide three essential functions:

1. Encryption: Certificates facilitate the encryption of data between your browser and the web server, ensuring that any intercepted data remains unreadable.
2. Authentication: Certificates verify the identity of the website you're connecting to. This prevents attackers from impersonating legitimate websites.
3. Integrity: Certificates ensure that data exchanged between your browser and the web server hasn't been tampered with during transit.

The SSL/TLS Certificate Chain

The SSL/TLS certificate chain is a hierarchical structure comprising multiple certificates that establish trust between your browser and the website's server. Here's how it typically works:

1. Root Certificate Authority (CA):
• At the top of the chain is the Root CA certificate. These are well-known and trusted entities, like VeriSign or Let's Encrypt, that issue certificates.
• Your operating system or browser comes pre-installed with a list of trusted root CAs.
2. Intermediate Certificate Authorities:
• Below the root CA are intermediate CAs. These CAs are also trusted but are used by the root CAs to issue certificates.
• The website owner obtains a certificate from one of these intermediates, not directly from the root CA.
3. Server Certificate:
• The website's server certificate, also known as the end-entity certificate, is signed by one of the intermediate CAs.
• This certificate contains the server's public key and its hostname.

Certificate Chain Validation Process

When you connect to an HTTPS website, your browser performs the following steps to validate the certificate chain:

1. Receipt of Server Certificate:
• The server sends its certificate to your browser when you initiate an HTTPS connection.
2. Validation of Signature:
• Your browser checks the signature on the server's certificate. It uses the public key of the issuer (an intermediate CA) to verify the signature.
• If the signature is valid, the server's certificate is considered trustworthy so far.
3. Issuer Verification:
• Your browser checks if the issuer of the server certificate (the intermediate CA) is in its list of trusted CAs. This is where the chain begins.
4. Validation of Intermediate Certificate:
• Your browser proceeds to validate the intermediate certificate using the same process as the server certificate.
• It checks the signature and verifies that the intermediate CA is trusted.
5. Repeat Process for Root CA:
• The process continues until your browser reaches a root CA certificate. This final certificate must be in your browser's trusted list.
• If the root CA certificate is trusted, the entire certificate chain is validated.
6. Hostname Verification:
• Your browser also checks if the hostname in the server certificate matches the hostname you're trying to access. This prevents man-in-the-middle attacks.
7. Encryption Key Exchange:
• If all steps pass, your browser and the server exchange encryption keys, and secure communication begins.

SSL/TLS certificate chain validation is a complex but essential process that ensures the authenticity and security of HTTPS websites. By verifying each certificate in the chain, starting from the server certificate and ending with a trusted root CA, your browser establishes trust and encrypts data for secure communication.