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


# 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 ( ).

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 ( ).

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).

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.)


Check the logs:

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


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

# nano /usr/local/cpanel/logs/login_log - 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

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.

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

rpm -Uvh

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



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

* Notice ssh is set up on port 10222



enabled  = true
filter   = proftpd
action   = iptables[name=ProFTPD, port=ftp, protocol=tcp]
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


# This jail forces the backend to "polling".

enabled  = true
filter   = postfix-sasl
backend  = polling
action   = iptables[name=sasl, port=smtp, protocol=tcp]
logpath  = /usr/local/psa/var/log/maillog



enabled  = true
filter   = postfix
action   = hostsdeny[file=/etc/fail2ban/hosts.deny]
logpath  = /usr/local/psa/var/log/maillog
bantime  = 300

Apache Auth


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

Whitelisting is setup in the jail.conf file using a space separated list.

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not                          
# ban a host which matches an address in this list. Several addresses can be                             
# defined using space separator.                                                                        
ignoreip =

# This will ignore connection coming from common private networks.
# Note that local connections can come from other than just, so
# this needs CIDR range too.
ignoreip =


The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store ortransmit credit card information maintain a secure environment. Essentially any merchant that has a Merchant ID (MID).

General requirements for compliance

Intrusion Drevention Systems
Intrusion Prevention Systems
Dedicated IP addresses
PCI Cage

According to The Register, a serious vulnerability in SSL v3 will be disclosed tomorrow on October 15th. Some people are recommending disabling SSL v3 in various daemons until further notice.

A vulnerability in the design of SSL version 3.0. 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.

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today.

Detection (Linux)

The following script can be run against the server in question. The command will return ‘SSL 3.0 enabled’ if vulnerable and ‘SSL 3.0 disabled’ if not.


ret=$(echo Q | timeout 5 openssl s_client -connect “${1-`hostname`}:${2-443}” -ssl3 2> /dev/null)
if echo “${ret}” | grep -q ‘Protocol.*SSLv3’; then
if echo “${ret}” | grep -q ‘Cipher.*0000’; then
echo “SSL 3.0 disabled”
echo “SSL 3.0 enabled”
echo “SSL disabled or other error”

NOTE: This script takes the hostname of the server to check as the first argument and an optional port as the second. By default it will check the local system, port 443.

To avoid this vulnerability, Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, however it is strongly recommended against.

To mitigate this vulnerability as it affects httpd, set the SSLProtocol directive as follows in /etc/httpd/conf.d/ssl.conf:

Note: This directive must either be located at the topmost level of the configuration file, or inside the default virtual host configuration for an address.

Option 1: Disable SSLv2 and SSLv3 (Enable everything except SSLv2 and SSLv3)
SSLProtocol All -SSLv2 -SSLv3

Option 2: Disable everything except TLSv1.x

On RHEL 7 or RHEL 6.6 and later:
SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2

On other platforms:
SSLProtocol -All +TLSv1

Then restart httpd:

# service httpd restart

For Microsoft
Test your web server for SSLv2
What you are looking for is:
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No

For Nginx – there are other files to edit:


Rebuild after any changes

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Other Resources:


Products Affected:

Product/Channel Fixed in package Remediation details
Red Hat Enterprise Linux 7 bash-4.2.45-5.el7_0.2 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6 bash-4.1.2-15.el6_5.1 Red Hat Enterprise Linux
bash-4.1.2-15.el6_5.1.sjis.1 Red Hat Enterprise Linux
bash-4.1.2-9.el6_2.1 Red Hat Enterprise Linux 6.2 AUS
bash-4.1.2-15.el6_4.1 Red Hat Enterprise Linux 6.4 EUS
Red Hat Enterprise Linux 5 bash-3.2-33.el5.1 Red Hat Enterprise Linux
bash-3.2-33.el5_11.1.sjis.1 Red Hat Enterprise Linux
bash-3.2-24.el5_6.1 Red Hat Enterprise Linux 5.6 LL
bash-3.2-32.el5_9.2 Red Hat Enterprise Linux 5.9 EUS
Red Hat Enterprise Linux 4 bash-3.0-27.el4.2 Red Hat Enterprise Linux 4 ELS


Check the version:

[root@server]# rpm -qa | grep bash

Diagnostic Steps:

Exploit 1 (CVE-2014-6271)

There are a few different ways to test if your system is vulnerable to shellshock. Try running the following command in a shell.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see “vulnerable” you need to update bash. Otherwise, you should be good to go.

Exploit 2 (CVE-2014-7169)

Even after upgrading bash you may still be vulnerable to this exploit. Try running the following code.

env X='() { (>' bash -c "echo date"; cat echo ; rm -f echo

If the above command outputs the current date (it may also show errors), you are still vulnerable.

Exploit 3 (???)

Here is another variation of the exploit. Please leave a comment below if you know the CVE of this exploit.

env -i X=' () { }; echo hello' bash -c 'date'

If the above command outputs “hello”, you are vulnerable.

Exploit 4 (CVE-2014-7186)

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

A vulnerable system will echo the text “CVE-2014-7186 vulnerable, redir_stack”.

Exploit 5 (CVE-2014-7187)

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"

A vulnerable system will echo the text “CVE-2014-7187 vulnerable, word_lineno”.

Run update:

[root@server ~]# yum update bash
Loaded plugins: downloadonly, fastestmirror, priorities
Loading mirror speeds from cached hostfile
epel/metalink                                            |  16 kB     00:00
 * base:
 * epel:
 * extras:
 * updates:
base                                                     | 3.7 kB     00:00
extras                                                   | 3.3 kB     00:00
updates                                                  | 3.4 kB     00:00
updates/primary_db                                       | 5.3 MB     00:00
81 packages excluded due to repository priority protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated
---> Package bash.x86_64 0:4.1.2-15.el6_5.1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

 Package       Arch            Version                   Repository        Size
 bash          x86_64          4.1.2-15.el6_5.1          updates          905 k

Transaction Summary
Upgrade       1 Package(s)

Total download size: 905 k
Is this ok [y/N]: y
Downloading Packages:
bash-4.1.2-15.el6_5.1.x86_64.rpm                         | 905 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : bash-4.1.2-15.el6_5.1.x86_64                                 1/2
  Cleanup    : bash-4.1.2-15.el6_4.x86_64                                                                                                                                                        2/2
  Verifying  : bash-4.1.2-15.el6_5.1.x86_64                                                                                                                                                      1/2
  Verifying  : bash-4.1.2-15.el6_4.x86_64                                                                                                                                                        2/2

  bash.x86_64 0:4.1.2-15.el6_5.1


[root@server ~]# rpm -qa | grep bash

Test after update:

[root@server ~]# env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

For Ubuntu Systems:

apt-get update; apt-get install --only-upgrade bash

For Arch Linux:

pacman -Sy bash

A reboot is not required after the update.