Install rkhunter on CentOS 6.6

Rootkit Hunter (rkhunter) is a Unix-based tool that scans for rootkits, backdoors and possible local exploits. Rootkits are self-hiding toolkits secretly installed by a malicious intruder to allow that user to gain access to the server. Rootkit Hunter offers protection by comparing SHA-1 hashes of important files with known good ones in a online database as well as:

MD5 hash compare
Look for default files used by rootkits
Wrong file permissions for binaries
Look for suspected strings in LKM and KLD modules
Look for hidden files
Optional scan within plaintext and binary files

yum install rkhunter

Check the version

# rkhunter --versioncheck
Rootkit Hunter version 1.4.2

Checking rkhunter version...
  This version  : 1.4.2
  Latest version: 1.4.2

Manual Scan

# rkhunter -c

Or,

# rkhunter -c -l /var/log/rkhunter.log

Automate Rootkit Hunter

Rkhunter can be setup to run checks every day so that we always have up-to-date information about intrusions. This can be accomplished by creating a cronjob.
2.1 Create Cron File

Create the run-file in the following location (RHEL based distributions only):

#nano -w /etc/cron.daily/rkhunter.sh

Install into shell script

#!/bin/sh
(
/usr/bin/rkhunter --versioncheck
/usr/bin/rkhunter --update
/usr/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s 'rkhunter Daily Scan Report (ServerNameHere)' your@email.here

Set Execute Permissions

Set execute permission on the file you have just created:

# chmod 755 /etc/cron.daily/rkhunter.sh

The cron utility will run once daily, and if a threat is detected, the rkhunter command itself will email our user to alert them. If no problems were found, no email will be received.

Rootkit Hunter configuration

The configuration file for rkhunter can be found at:

# /etc/rkhunter.conf

SSHD Root Logon

The parameter ALLOW_SSH_ROOT_USER tells rkhunter whether or not the root user is allowed to ssh into the system. This is unset by default in the rkhunter.conf file. Rkhunter will complain about this on every run. If you have disabled root login, you should set this parameter to “no”.

ALLOW_SSH_ROOT_USER=no

If you need root login over SSH, you should change this parameter to “yes” so that rkhunter can check this and will mark this setting as valid:

ALLOW_SSH_ROOT_USER=yes

Security practices recommend disabling root login.

Update rkhunter

To check the currently installed version enter the following:

# rkhunter --versioncheck

Run the updater by issuing the following command:

# rkhunter --update

With our database files refreshed, we need to tell rkhunter to check the current values and store them as known-good values:

# rkhunter --propupd

kernel: Firewall: *SYNFLOOD Blocked*

CSF Firewall is blocking these attacks in /var/log/messages


Feb 25 02:13:33 servidor kernel: Firewall: *SYNFLOOD Blocked* IN=eth1 OUT= MAC=00:25:90:de:d3:d5:00:19:e8:f4:7a:3f:08:00 SRC=120.43.114.117 DST=64.150.187.59 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=21531 DF PROTO=TCP SPT=4760 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0

Check with

# netstat -alntp | grep SYN | wc -l

You have set the following in your csf configuration but having such a setting, we definitely block SYN connections but legit connections as well.


SYNFLOOD = "1"
SYNFLOOD_RATE = "1/s"
SYNFLOOD_BURST = "3"

With the above settings, you will see a drop down in SYN connections but you won’t be able to browse your websites as well since it blocks legit clients as well.

The proper solution for the heavy attacks is a Hardware Firewall OR CloudFlare.

So if the attack is too heavy, go for any of the above 2 options since re-installation and blocking ports won’t solve the problem.

Ghost Vulnerability

A very serious security problem has been found and patched in the GNU C Library called Glibc. It was announced on 27th January 2015.

Here are the affected Linux distros:

  • RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
  • CentOS Linux version 5.x, 6.x & 7.x
  • Ubuntu Linux version 10.04, 12.04 LTS
  • Debian Linux version 7.x
  • Linux Mint version 13.0
  • Fedora Linux version 19 or older
  • SUSE Linux Enterprise 11 and older (also OpenSuse Linux 11 or older versions).
  • SUSE Linux Enterprise Software Development Kit 11 SP3
  • SUSE Linux Enterprise Server 11 SP3 for VMware
  • SUSE Linux Enterprise Server 11 SP3
  • SUSE Linux Enterprise Server 11 SP2 LTSS
  • SUSE Linux Enterprise Server 11 SP1 LTSS
  • SUSE Linux Enterprise Server 10 SP4 LTSS
  • SUSE Linux Enterprise Desktop 11 SP3
  • Arch Linux glibc version <= 2.18-1

Read More to Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Ubuntu Linux
Continue reading Ghost Vulnerability

Install and Configure Monit on CentOS 6.6

Monit is not available from the system base repositories, you need to add and enable third party epel repository to install monit package under your RHEL/CentOS systems.


# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# sudo rpm -Uvh epel-release-6*.rpm

Install Monit

# yum install monit

Monit has it’s web interface that runs on port 2812 using web server. To enable web interface you need to make changes in monit configuration file.


# nano /etc/monit.conf

Uuncomment the following section and add the IP address or domain name of your server, allow anyone to connect and change monit user and password or you can use default ones.


 set httpd port 2812 and
     use address localhost  # only accept connection from localhost
     allow localhost        # allow localhost to connect to the server and
     allow admin:monit      # require user 'admin' with password 'monit'
     allow @monit           # allow users of group 'monit' to connect (rw)
     allow @users readonly  # allow users of group 'users' to connect readonly

Restart Monit

# /etc/init.d/monit start

Add Monit to start at boot

# chkconfig monit on

in /etc/monit.d

Add httpd

# nano /etc/monit.d/httpd
check process httpd with pidfile /var/run/httpd/httpd.pid
start program = /etc/init.d/httpd start
stop  program = /etc/init.d/httpd stop
if failed host 127.0.0.1 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout
#Use for specific host
#if failed host domain.com port 80 protocol HTTP
#    then restart
#if totalmem > 75% for 2 cycles then restart

Add mysql

#nano /etc/monit.d/mysql
check process mysqld with pidfile /var/run/mysqld/mysqld.pid
start program = "/etc/init.d/mysqldd start"
stop  program = "/etc/init.d/mysqld stop"
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout

Nginx

check process nginx with pidfile /var/run/nginx.pid
start program = "/etc/init.d/nginx start"
stop program = "/etc/init.d/nginx stop"

Check the syntax

# monit -t

Restart monit

# service monit restart

You can verify that monit service is started by checking log file.


# tail -f /var/log/monit
[BDT Apr  3 03:06:04] info     : Starting monit HTTP server at [localhost:2812]
[BDT Apr  3 03:06:04] info     : monit HTTP server started
[BDT Apr  3 03:06:04] info     : 'tecmint.com' Monit started
[BDT Apr  3 03:06:04] error    : 'nginx' process is not running
[BDT Apr  3 03:06:04] info     : 'nginx' trying to restart
[BDT Apr  3 03:06:04] info     : 'nginx' start: /etc/init.d/nginx

Troubleshoot Network Scanning on Plesk Server

For abuse issues that involve your server host sending emails with complaints that your server is conducting network scanning.

What is Network Scanning?

Network scanning is a process of identifying active hosts on a network, either for the purpose of attacking them or for network security assessment. It laymans terms, if your hosting provider has sent you an email then your system is compromised and has a script on it that is scanning other systems.

The tool that can detect outgoing portscans is tcpdump.

Install tcdump:

yum install tcpdump -y

Run

# tcpdump -i eth0 -w dump 

and then, with a lot of calm, read the dump details matching the packets sent in those dates.

Ask your users for their IPs also, if static.

Look to /var/log/auth.log and last -100 to see if someone abused your system, check for suspicious cron jobs, look into the /root directory if something strange appeared. In these cases a tool that hashize the system files (like tripwire) would be important.

It is recommended that a virus or rootkit tool be used to scan the websites on the server for any shell scripts or exploits that may have allowed for outbound SSH attacks.

We have an article on installing and using ClamAV ( http://geekdecoder.com/clamav-on-centos-6/ ).

For plesk – I would recommend running on /var/www/vhosts (e.g. clamscan -ir /var/www/vhosts/ –log=/root/clamscan-01.07.2015.txt).
For cpanel – I would recommend running on /home (e.g. clamscan -ir /home –log=/root/clamscan-01.07.2015.txt).

Rkhunter is another scanning tool that may identify any uploaded malicious files ( http://www.tecmint.com/install-linux-rkhunter-rootkit-hunter-in-rhel-centos-and-fedora/ ).

Once any found shells are removed, if it were within /var/www/vhosts for plesk or /home for cpanel, it’s likely that the exploit was through one of the sites. If the file was found within a site’s document root, I would update any licensed or open source software to remove potential vulnerabilities.

Also, to disable any outgoing SSH usage if the scans were ssh scans(and if you do not use SSH from the server, it resolves the symptom immediately), a firewall rule can be added (iptables -I OUTPUT -p tcp –dport 22 -j DROP).

Joomla protection

How to start protecting your Joomla Site

  1. Always keep Joomla core up-to date
  2. Always make sure you run the latest patched versions of extensions
  3. Make sure you choose strong passwords for all logins
  4. Check your own website for vulnerabilities
  5. Always check the webserver’s log files for potential hack attempts
  6. Secure your server if you host your Joomla website on a VPS or even a dedicated server
  7. Create a list of all extensions you use and try to monitor them. For example you can use Google or security websites for staying informed about the latest vulnerabilities. Only use secure extensions.
  8. Use SEO for URL’s. Activate the SEO features, use SEF URLs
  9. Furthermore most tools and scanners are not able to work with search engine friendly URLs
  10. This might be a big surprise, but with these measures you already gained a decent protection level.
  11. The last things to do would be to rename the Joomla backend folder from “administrator” to may be “admin_acp_1234567” in order to prevent script kiddies and scanners from finding your Joomla backend.
  12. And, last but not least, protect the PHPMyAdmin login (if you have any) with .htaccess files. You can’t do this with the Joomla admin control panel since some components need to have access to administrator/components.)

Source: http://www.exploit-db.com/papers/15780/

Brute Force Attack cPanel

Check the logs:

# nano /var/log messages
PAM-hulk[13813]: Brute force detection active: 580 LOGIN DENIED

Check

cphulkd.log at /usr/local/cpanel/logs


# nano /usr/local/cpanel/logs/login_log
72.177.xxx.xx - root [11/04/2014:05:48:13 -0000] "POST /login/?login_only=1 HTTP/1.1" DEFERRED LOGIN whostmgrd: brute force attempt (user root) has locked out IP 72.177.xxx.xx

Sandworm Vulnerability Affects All Microsoft Operating Systems

On Tuesday, October 14, 2014, iSIGHT Partners and Microsoft announced a Zero-Day vulnerability named “Sandworm” found in all versions of Microsoft Windows and Windows Server 2008 and 2012.

The vulnerability has been exploited in a small number of cyberespionage attacks against NATO, energy companies, a US academic organization and many others. Microsoft has since created a patch and released it as one of their security updates (CVE-2014-4114.).

If you have enabled automatic updating, the Microsoft security update will be downloaded and installed automatically. If you have not, it is critical that you run the security update from Microsoft, as well as all other important security updates through the Windows Updater immediately.

If you would like to learn more about the Sandworm vulnerability, in-depth information can be found on iSIGHT Partners blog and Microsoft’s Security TechCenter.

Fail2Ban Setup on CentOS 6.6

Because fail2ban is not available from CentOS, we should start by downloading the EPEL repository:

rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Follow up by installing fail2ban:

yum install fail2ban

The default fail2ban configuration file is location at /etc/fail2ban/jail.conf. The configuration work should not be done in that file, however, and we should instead make a local copy of it.


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

After the file is copied, you can make all of your changes within the new jail.local file. Many of possible services that may need protection are in the file already. Each is located in its own section, configured and turned off.

Set up a few rules on a plesk server with CentOS

SSH

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=10222, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, sender=admin@domain.com, sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

* Notice ssh is set up on port 10222

ProFTP

[proftpd-iptables]

enabled  = true
filter   = proftpd
action   = iptables[name=ProFTPD, port=ftp, protocol=tcp]
           sendmail-whois[name=ProFTPD, dest=admin@domain.com]
logpath  = /var/log/secure
maxretry = 5

* Notice the log location. This is for a Plesk server as proftpd logs to /var/log/secure
Restart fail2ban

# service fail2ban restart

Postfix

# This jail forces the backend to "polling".
[sasl-iptables]

enabled  = true
filter   = postfix-sasl
backend  = polling
action   = iptables[name=sasl, port=smtp, protocol=tcp]
           sendmail-whois[name=sasl, dest=admin@domain.com]
logpath  = /usr/local/psa/var/log/maillog

Postfix

[postfix-tcpwrapper]

enabled  = true
filter   = postfix
action   = hostsdeny[file=/etc/fail2ban/hosts.deny]
           sendmail[name=Postfix, dest=admin@domain.com]
logpath  = /usr/local/psa/var/log/maillog
bantime  = 300

Apache Auth

[apache-tcpwrapper]

enabled  = true
filter   = apache-auth
action   = iptables[name=apache, port=apache, protocol=tcp]
           sendmail-whois[name=apache, dest=admin@domain.com]
logpath  = /var/log/httpd/error_log
#           /home/www/myhomepage/error.log
maxretry = 6