Modsecparse.pl cron job error

Scenario

The modsecparse.pl cronjob producing the following error

/etc/cron.hourly/modsecparse.pl:

DBI connect(‘modsec:localhost’,’modsec’,…) failed: Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2) at /etc/cron.hourly/modsecparse.pl line 19

Unable to connect to mysql database at /etc/cron.hourly/modsecparse.pl line 19.

 

Solution

Try reproducing the error by running the cron job manually:

#/etc/cron.hourly/modsecparse.pl

 

If it shows the same error, make sure the password used on the “my $dbpassword” 19th line in /etc/cron.hourly/modsecparse.pl matches the “modsec” password in MySQL.

my $dbpassword = ‘sample';

You can reset the “modsec” MySQL password by following these steps:

mysql > use modsec;
mysql > update user set Password=password(‘sample’) where User=’modsec';
mysql > flush privileges;
mysql > quit;

Also in WHM Click Service Manager -> Check enable mysql and mysql monitor boxes -> Save changes. It should solve problem.

mod_sec_cron

Post to Twitter Tweet This Post

Continue Reading

Disable mod_sec2 for a domain

Disabling Mod_security for an account was easier in Mod_security v 1.x, you just had to add the following lines in the .htaccess file for that account’s public_html directory :

SecFilterEngine Off
SecFilterScanPost Off

This will no longer work as Mod_security 2.x was been started to use in newer WHM/cPanel versions. In this article, we are going to review such a case and its solution

Case

A user was trying to copy an article (which was including certain URLs) and paste it in their Online Discussion forums. The following error were shown when they were trying to submit the post :

errorlive

When the content was Plain formatted (which means no type of formatting involved in it – no links embedded and such – just like plain text) they could submit it. Obviously this is something with Apache and hence the error_log has to be checked :

root@server:~ [/home]#tail -f /usr/local/apache/logs/error_log | grep 1xxx.174.208.127

[Mon Jan 07 17:14:11 2013] [error] [client 1xx.174.208.127] ModSecurity: Access denied with code 403 (phase 2). Pattern match “(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|” ?> ?<|” ?[a-z]+ ?<.*>|> ?”? ?(>|<)|< ?/?i?frame|\\%env)” at ARGS:quot;” style. [file "/usr/local/apache/conf/modsec_rules/10_asl_rules.conf"] [line "903"] [id "340147"] [rev "81"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Generic XSS filter"] [data "3990"] [severity "CRITICAL"] [hostname "my_domain.com"] [uri "/ko/portal/apps/discussions/creatediscussionview.php"] [unique_id "WQyvlUPkwtoAADKsDMwAAAAv"]
[Mon Jan 07 17:14:11 2013] [error] [client 1xxx.174.208.127] File does not exist: /home/sysbc/public_html/my_domain.com/403.shtml, referer: http://my_domain.com/ko/portal/home.php?main=discussview

 

A pattern in the URL is triggering the Mod_security rule. In this case, client demanded disabling it for his account, otherwise we wouldn’t have done it for security purposes.

Solution

Mod_security disabling is the solution, but remember for this account only. Lets take a look at the VirtualHost section of this domain :

<VirtualHost xx.xx.xx.xx:80>
ServerName my_domain.com
ServerAlias www.my_domain.com my_domain.com www
DocumentRoot /home/sysbc/public_html/mdom
ServerAdmin webmaster@my_domain.com
UseCanonicalName Off
CustomLog /usr/local/apache/domlogs/my_domain.com combined
CustomLog /usr/local/apache/domlogs/my_domain.com-bytes_log “%{%s}t %I .\n%{%s}t %O .”
## User sysprobc # Needed for Cpanel::ApacheConf
<IfModule mod_suphp.c>
suPHP_UserGroup ysb ysb
</IfModule>
<IfModule concurrent_php.c>
php4_admin_value open_basedir “/home/sysbc:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp”
php5_admin_value open_basedir “/home/sysbc:/usr/lib/php:/usr/local/lib/php:/tmp”
</IfModule>
<IfModule !concurrent_php.c>
<IfModule mod_php4.c>
php_admin_value open_basedir “/home/sysbc:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp”
</IfModule>
<IfModule mod_php5.c>
php_admin_value open_basedir “/home/sysbc:/usr/lib/php:/usr/local/lib/php:/tmp”
</IfModule>
<IfModule sapi_apache2.c>
php_admin_value open_basedir “/home/sysbc:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp”
</IfModule>
</IfModule>
<IfModule !mod_disable_suexec.c>
<IfModule !mod_ruid2.c>
SuexecUserGroup sysbc ysbc
</IfModule>
</IfModule>
<IfModule mod_ruid2.c>
RUidGid sysprobc sysprobc
</IfModule>
ScriptAlias /cgi-bin/ /home/ysbc/public_html/mdom/cgi-bin/

# To customize this VirtualHost use an include file at the following location
# Include “/usr/local/apache/conf/userdata/std/2/sysbc/my_domain.com/*.conf”

 

Take a look at the last 2 lines :

# To customize this VirtualHost use an include file at the following location
# Include “/usr/local/apache/conf/userdata/std/2/sysbc/my_domain.com/*.conf”

By default,the location /usr/local/apache/conf/userdata/std/2 exists. You will have to create the remaining path ysbc/my_domain.com

 

# mkdir -p  /usr/local/apache/conf/userdata/std/2/ysbc/my_domain.com

Create a file vhost.conf and add the following lines :

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

After this, you need to rebuild the Virtual hosts using the following command :
 
# /scripts/ensure_vhost_includes –user=<cPanel username>
 
Here it would be 
 
# /scripts/ensure_vhost_includes --user=sysbc
 
Alternatives

The above explained method entirely disables mod_security for a particular account, which is not recommended and safe. However there are other methods to do the trick.

root@server:~ [/home]#tail -f /usr/local/apache/logs/error_log | grep xx.xx.xx.xx

[Mon Jan 07 17:14:11 2013] [error] [client xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase 2). Pattern match “(< ?(?:(?:java|vb)?script|about|applet|activex|chrome)   ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|” ?> ?<|” ?[a-z]+ ?<.*>|> ?”? ?(>|<)|< ?/?i?frame|\\%env)” at ARGS:quot;” style. [file  "/usr/local/apache/conf/modsec_rules/10_asl_rules.conf"] [line "903"] [id "340147"] [rev "81"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Generic XSS filter"]  [data "3990"] [severity "CRITICAL"] [hostname "my_domain.com"] [uri "/ko/portal/apps/discussions/creatediscussionview.php"] [unique_id "WQyvlUPkwtoAADKsDMwAAAAv"]
[Mon Jan 07 17:14:11 2013] [error] [client xx.xx.xx.xx] File does not exist: /home/sysbc/public_html/mdom/403.shtml, referer:  http://my_domain.com/ko/portal/home.php?main=discussview

 

You can disable the rule only by adding the rule in .htaccess

<LocationMatch “.*”>
SecRuleRemoveById 340147
</LocationMatch>

Post to Twitter Tweet This Post

Continue Reading

Apache Abuse: Source IP identification

Scenario

Some times the webserver become loaded heavily due to large no. of inbound connections and makes the server sluggish or non-responsive. This is quite evident during DOS or DDOS attacks. You can use the following script to identify the IP and the no. of connections active on a server using the following commands

 

netstat -ntu | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n


or


netstat -plan | grep :80 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n

 

The output would look like the following

20  2.50.172.59
21  117.247.123.43
29   116.202.39.208
64  92.96.145.2
156  216.70.110.99

The first column represents the no. of connections while the second column represents the source IP

 

Post to Twitter Tweet This Post

Continue Reading

Fix Maldet “Lightning Scan” Issues

Scenario

Sometimes you will see a maldet scan gets finished at the very moment it was initiated. Moreover nothing will be detected after the ‘lightning scan’. Well, that’s not normal.

root@server [~]# maldet -b -a ~user

Linux Malware Detect v1.4.1
(C) 2002-2011, R-fx Networks <proj@r-fx.org>
(C) 2011, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(330625): {scan} launching scan of /home/usert to background, see /usr/local/maldetect/event_log for progress

root@server [~]# tail /usr/local/maldetect/event_log
Feb 13 04:06:35 server maldet(997832): {sigup} local signature set is version 201302097471
Feb 13 04:06:35 server maldet(997832): {sigup} latest signature set already installed
Feb 13 19:53:24 server maldet(330625): {scan} launching scan of /home/user to background, see /usr/local/maldetect/event_log for progress
Feb 13 19:53:24 server maldet(330625): {scan} signatures loaded: 10695 (8827 MD5 / 1868 HEX)
Feb 13 19:53:24 server maldet(330625): {scan} building file list for /home/user, this might take awhile…
Feb 13 19:53:26 server maldet(330625): {scan} file list completed, found 6574 files…
Feb 13 19:53:26 server maldet(330625): {scan} found ClamAV clamscan binary, using as scanner engine…
Feb 13 19:53:26 server maldet(330625): {scan} scan of /home/user (6574 files) in progress…
Feb 13 19:53:26 server maldet(330625): {scan} scan completed on /home/user: files 6574, malware hits 0, cleaned hits 0
Feb 13 19:53:26 server maldet(330625): {scan} scan report saved, to view run: maldet –report 021313-1953.330625

 

This is not usual, it would take atleast a minute to complete the scan, so there is something wrong with the Scan signatures. 

How it works

The Maldet signature databases update every night. If there is a connection issue or something with the remote host it’ll create a 0 byte file and break. Thus there is nothing to be compared against during that scan and that is why it ends so fast.

Fix

This is the command to fix this issue, read on to the explanation

root@server [~]# cd /usr/local/maldetect && rm -rf sigs/ && mkdir sigs/ && maldet -u

# cd /usr/local/maldetect && rm -rf sigs/ && mkdir sigs/ && maldet -u
cat: /usr/local/maldetect/sigs/maldet.sigs.ver: No such file or directory
Linux Malware Detect v1.4.1
(C) 2002-2011, R-fx Networks <proj@r-fx.org>
(C) 2011, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(350347): {sigup} performing signature update check…
maldet(350347): {sigup} could not determine signature version
maldet(350347): {sigup} signature files missing or corrupted, forcing update…
maldet(350347): {sigup} new signature set (201302097471) available
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/md5.dat
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/hex.dat
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/rfxn.ndb
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/rfxn.hdb
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/maldet-clean.tgz
maldet(350347): {sigup} signature set update completed
maldet(350347): {sigup} 10695 signatures (8827 MD5 / 1868 HEX)

 

This will remove the existing signatures from the directory /usr/local/maldetect and re-download those. maldet -u will update the signatures.

If this doesn’t work either, you may have to remove and re-install Maldet

Removing Maldet

There is no such script available, just do it manually

Kill the Maldet notify service first :

maldet -k

Remove the Maldet directory :

rm -rf /usr/local/maldetect

Remove the Cron file :

/etc/cron.daily/maldet

Re-installing Maldet is quite easy, follow the instructions at http://www.rfxn.com/projects/linux-malware-detect/

 

 

 

 

Post to Twitter Tweet This Post

Continue Reading

LDAP CONFIGURATION FOR USER AND GROUP CENTRALISED AUTHENTICATION ON UBUNTU LTS 12.04 – PART-3

TLS Authentication of LDAP sessions:

Till now all the sessions made by the LDAP client to the server is open and not encrypted. Its time to make our LDAP client-server sessions encrypted by some mechanisms. The most common encryption method includes Transport Layer Security (TLS) and/or Secure Sockets Layer (SSL) encryption.

Here, we are using own Certificate Authority (CA) and then create and sign our LDAP server certificate as that CA. The first step in the process is to obtain or create a certificate. Because slapd is compiled using the gnutls library, the certtool utility will be used to create certificates.  Now we install the gnutls-bin package by running the following command as root from the LDAP server:

root@ubuntuserver:]# apt-get install gnutls-bin

(Click To Enlarge Screenshots)

After the package is installed, we create a private key for the Certificate Authority (CA) by the following command:

root@ubuntuserver:]# sh -c “certtool –generate-privkey > /etc/ssl/private/cakey.pem”

The –generate-privkey option generates a private key and it is saved to file /etc/ssl/private/cakey.pem.

Now we create a template file /etc/ssl/ca.info to define the CA with the following entries as shown below:

root@ubuntuserver:]# : vi /etc/ssl/ca.info

============================================
cn = Support Sages
ca
cert_signing_key
============================================

Now create the self-signed CA certificate using the following command:

root@ubuntuserver:]# certtool –generate-self-signed –load-privkey /etc/ssl/private/cakey.pem  \
–template /etc/ssl/ca.info –outfile /etc/ssl/certs/cacert.pem

Note that we are using the –template option to pass the template file /etc/ssl/ca.info created before to define the template for our self-signed CA. The –load-privkey loads the CA private key file cakey.pem which we created earlier and the –outfile option creates the required self-signed CA  cert /etc/ssl/certs/cacert.pem

Now make a private key for the LDAP server by:

root@ubuntuserver:]# certtool –generate-privkey –outfile /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Replace ldapserver.int.sages.com in the slapd key filename with your server’s hostname.

To sign the server’s certificate with the CA, create the /etc/ssl/ldapserver.int.sages.com.info info file containing:

root@ubuntuserver:]# : vi  /etc/ssl/ldapserver.int.sages.com.info

=========================================================

organization = Support Sages
cn = ldapserver.int.sages.com
tls_www_server
encryption_key
signing_key
expiration_days = 3650
=========================================================

The expiration_days attribute define the number of days the cert is valid. The above certificate is good for 10 years.(Rough calculation)

Replace canonical name cn ldapserver.int.sages.com with your server’s hostname.

And now we create the server certificate with the following command:

root@ubuntuserver:]# certtool –generate-certificate –load-privkey /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem \
–load-ca-certificate /etc/ssl/certs/cacert.pem –load-ca-privkey /etc/ssl/private/cakey.pem \
–template /etc/ssl/ldapserver.int.sages.com.info –outfile /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem

In the above command we pass the template file ldapserver.int.sages.com.info using the –template option to define the template for our server cert as we did for creating our self-signed CA. The –load-privkey loads the servers private key file ldapserver.int.sages.com_slapd_key.pem which we created earlier, –load-ca-privkey loads our CA private key , –load-ca-certificate option passes the CA cert cacert.pem and the –outfile option creates the cert /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem.

Now we have a certificate, key, and CA cert installed. Use ldapmodify command to add the new configuration options to slapd tree. As we know that ldapmodify is a command to modify our DIT and we use LDIF file format for this. So we create an LDIF file certinfo.ldif with the following entries:

root@ubuntuserver:]# : vi certinfo.ldif

=========================================================================
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

=========================================================================
Note that the certificate file names should be configured correctly in the above file with respect to the certs you created for your hostname.

Now we use the ldapmodify command to add the data to the cn=config DIT and tell slapd that our TLS work via the slapd-config(cn=config) database.

root@ubuntuserver:]# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f certinfo.ldif

You can see an output as shown below:

===================================

modifying entry “cn=config”

===================================

Once this is done make usre that the follwing entry is uncomented in /etc/default/slapd file:

SLAPD_SERVICES=”ldap:/// ldapi:///”

Contrary to our popular belief, we do not need ldaps:// in /etc/default/slapd in order to use TLS encryption. You should have just:
SLAPD_SERVICES=”ldap:/// ldapi:///”

LDAP over TLS  works using StartTLS. STARTTLS is an extension to plain text communication protocols, which offers a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication. So here an existing LDAP session (listening on TCP port 389) becoming protected by TLS/SSL. Whereas LDAPS, like HTTPS, is a distinct encrypted-from-the-start protocol that operates over TCP port 636. We are using STARTLS for our encryption.

Now its time to set permissions and ownerships for our certificate files such that the openldap user gets access to these certificates:

root@ubuntuserver:]# adduser openldap ssl-cert

At times you will get an error mesasge as given below while excecuting the adduser command:
===================================
adduser: The group `ssl-cert’ does not exist.
===================================
To overcome this install the package ssl-cert by:

root@ubuntuserver:]# apt-get install ssl-cert

This installs the ssl-cert package which creates the ssl-cert group automatically. Now excecute the adduser command:

root@ubuntuserver:]# adduser openldap ssl-cert

Run the following commands to change the group and permissions:

root@ubuntuserver:]# chgrp ssl-cert /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem
root@ubuntuserver:]# chmod g+r /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Now restart slapd by:

root@ubuntuserver:]# /etc/init.d/slapd restart

If slapd restarts fine, then we can make sure that the TLS configurations are fine. Or if you run into troubles with the server not starting, check the /var/log/syslog. If you see errors like main: TLS init def ctx failed: -1, it is likely there is a configuration problem. Check that the certificate is signed by the authority from in the files configured, and that the ssl-cert group has read permissions on the private key.

Now we should configure our LDAP server to use TLS by editing the /etc/ldap/ldap.conf file as shown below:

===========================================
BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

===========================================
Now we should make our client use TLS authentication. This can be done by editing the configuration file /etc/ldap.conf on the LDAP client machine:

[ldapclient@ubuntuserver:]#   vi  /etc/ldap.conf

Make sure the following entries are uncommented :

======================
ssl start_tls
tls_checkpeer no
======================
These two entries in ldap.conf makes the client use TLS certs for encrypted sessions with our LDAP server. Lets check whether the session is using TLS using ldapsearch command.

You can use the ZZ switch to the ldapsearch utility to see if we are using encrypted sessions.

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

(-x disables SASL authentication, -Z tells to start TLS request (-ZZ to require successful response) , -h defines the hostname of our LDAP server)

But this command returns an error as show below:
========================================
ldapsearch -xZZ -h ldapserver.sages.com
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
========================================
Note that the ldapsearch is an ldap utility which we got when we installed ldap-utils package. And the ldap-utils uses /etc/ldap/ldap.conf file. So make sure the following entries are there in /etc/ldap/ldap.conf on LDAP client :
========================================
BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
========================================
Now run the ldapsearch from the LDAP client as follows:

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

You will see all our LDAP users from our LDAP server. If all the users are listed while using the -ZZ switch with ldapsearch command we can make sure that the session is encrypted for that listed users.

Post to Twitter Tweet This Post

Continue Reading

About this blog

This blog, acts as a knowledge repository for the world and is unofficial! Anything we find interesting in the cyber world will go here. Most cases, this blog will reflect the happiness of our staff in reaching successful solution to an issue (s)he worked on. A reference for other fellow SAGEs who come across similar issues later