Check open ports:

How to identify the processes that are keeping ports open

Windows OS

For Windows operating systems, you can use netstat, which is included with the OS. On the scanned server, open command prompt. Run the command:

netstat -ano

This will list all the network connections on the machine. The last column shows the process ID of the process for the specific network connection. You will probably want to filter this down using the ‘find’ command. For example, if you only want to list the network connections on port 135, use:

netstat -ano | find “:135”

This will list a network connection in LISTENING mode and the id of the process that opened the connection. Use “tasklist /SVC /FI “PID eq xxx” to show the name of the process and service for process id xxx.
For example, if you want to list the information about processed id 7424, use:

tasklist /SVC /FI “PID eq 7424

DDos Detection Articles:

https://www.hivelocity.net/kb/how-to-check-if-your-linux-server-is-under-ddos-attack/

http://linuxaria.com/howto/how-to-verify-ddos-attack-with-netstat-command-on-linux-terminal

https://support.plesk.com/hc/en-us/articles/360000345633-How-to-diagnose-possible-DoS-or-DDoS-attack-on-Apache

A good way to check the connectons to mail ports is to use netstat:

# netstat -anp | grep :25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      2170/master
tcp6       0      0 :::25                   :::*                    LISTEN      2170/master
# netstat -anp | grep :465
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      2170/master
tcp6       0      0 :::465                  :::*                    LISTEN      2170/master
# netstat -anp | grep :587
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      2170/master
tcp6       0      0 :::587                  :::*                    LISTEN      2170/master

How to Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux

Always keep backups. So backup now to an offsite location.

Note the Linux kernel version running the following command:

# uname -r

Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
Type the following yum command:

# sudo yum update

You must reboot your Linux server using shutdown/reboot command:

# sudo reboot

Run the following dnf command if you are using a Fedora Linux:

# sudo dnf --refresh update kernel

OR

# sudo dnf update

Reboot the Linux box:

# sudo reboot

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

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.

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

Read More

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