ASL error messages
Installation error messages
kernel-PAE.2.6.32-1.art.i686 is allowed multiple installs, skipping
This is a fairly serious error, it means someone has manually attempted to remove your kernel and has broken the package management record for the kernel. We do not recommend you ever uninstall a kernel. Linux has a boot loader that allows you to pick which kernel (or even operating system) you want to boot into. If you wish to switch kernels, dont uninstall a kernel or even replace it, just install another kernel and configure your system to log into it.
If your system has been broken in this manner, you will need to try and correct your package management record and to try to reinstall your kernel. The follow is a set of steps that may work, however if someone has manually removed your kernel its likely the system may be in a very abnormal state and these commands many not work. This type of error is not caused by ASL.
Step 1) Attempt to remove the kernel record from the package manager:
rpm -e kernel-PAE
or
yum remove kernel-PAE
Step 2) Attempt to manually reinstall the kernel
yum install kernel-PAE
Note: If your system requires that you do this, your system is in a very adverse state as the package management built into the OS will not allow this condition to occur. It can only occur if someone attempts to manually remove a kernel and does so in a manner that breaks package management. Your system may be in an abnormal condition, and we highly recommend you consider investigating whether other adverse conditions many exist on the system.
CREATE DATABASE failed; error: 'Can't create database 'tortix'; database exists'
This can only happen if the ASL database already exists, such as if ASL is being reinstalled on a system and the ASL data was not completely removed. If this occurs, you will need to manually remove the ASL database. To do that, log into mysql as your administrative user (root for example, but check with your OS vendor if you are not sure).
Step 1)
Drop the database by running this command in mysql:
drop database tortix;
Step 2)
Drop the "tortix" user by running this command in mysql:
drop user tortix;
Step 3)
Then run this command inside mysql:
flush privileges;
Step 4)
Then run the ASL installer again.
asl-firstboot reboots system
asl-firstboot has a simple network failsafe that will try to detect if the network on the system has been initialized correctly on the first boot of an ASL kernel. Its does this by comparing the exact network configuration that system had when ASL was installed, and if anything has changed it will attempt to reboot into the last known working kernel. If you change the network deliberately, after installing ASL but before rebooting the system for the first time the failsafe will incorrectly detect that the network has not been initialized correctly.
If this happens to you, just disable the failsafe by removing the init file:
rm /etc/init.d/asl-firstboot
If you did not change the network, then ASL is detecting that something is wrong with the network and it is not initialized as it did when ASL was first installed. You will need to either disable the failsafe, or investigate why the network is starting up correctly.
Error: Missing Dependency: libmysqlclient
This error means that your system has been incorrectly setup to exclude the installation of any package with "mysql" in the name. This library provides applications with the ability to speak SQL to a mysql database. These libraries are not actually part of mysql, are not used by mysql, and their installation will have no effect on mysql.
Therefore, if you are using some third party product that has excluded any package with "mysql" in its name from being installed on your system you will need to:
Step 1)
Run this command to temporarily bypass the broken and incorrect excludes configured for your system:
yum --disableexcludes=all upgrade asl asl-web mod_security ossec-hids
Step 2)
Report this as a bug to the makers of the product(s) that have configured this incorrectly on your system. No modern software package should exclude the installation of these packages, or even use package exclusion. These libraries have nothing to do with mysql and some software companies misconfigure the operating systems software management system to not allow the installation or upgrade of any package with "mysql" in the name. This configuration is incorrect to prevent MySQL from being installed or upgraded on your machine. You should report to the software vendor that they use proper package management, as the operating system will manage any software changes on the system to prevent conflicts.
Modern software does not need to make these changes, and any software package that does this should not be modifying your operating systems software management system. These changes will incorrectly break software updates on your system, and are not necessary for a properly packaged software solution.
tortixd errors
Error creating rule: Failed to resolve operator: detectSQLi
This means that you have an out of date ASL installation and you need to upgrade. Follow this process to upgrade ASL:
https://www.atomicorp.com/wiki/index.php/Upgrading_ASL
Table 'tortix.asl_user' doesn't exist
This means that you did not setup your ASL database. To manually setup the database simply run this command as root:
/var/asl/bin/ossec_database_setup.sh
It is safe to run this script multiple times.
Generic Errors
sh: /proc/sys/kernel/modules_disabled: Permission denied
This means you are using a VPS and do not have control of the kernel on your system. VPS systems do not have their own kernel, they use the host systems kernel. This message is expected on a VPS system.
Update Errors
HTTP Error 401: Authorization Required
See the FAQ below [1].
Error: ASL Key is not valid or has expired.
See the FAQ below [2].
The requested URL returned error: 401
See the FAQ below [3].
HTTP Error 401: Authorization Required Trying other mirror.
See the FAQ below [4].
Error: Your Username/Password is incorrect, or your account has Expired.
See the FAQ below [5].
HTTP request sent, awaiting response... 401 Authorization Required
Explanation:
This can mean:
- your license manager username and/or password is incorrect and you need to configure ASL to use the correct credentials, or
- you changed your license manager username and/or password is incorrect and you need to configure ASL to use the current credentials, or
- you do not have a license for ASL, or
- the license has expired, or
- you have exceeded your license (ASL is installed on more systems than your license allows).
The first three reasons are the most common, please see the solutions below:
If you are installing ASL for the first time
This means you have entered your credentials incorrectly, or you are attempting to install ASL on more systems that you have a license for.
Step 1
Check the License Manager to ensure your license(s) is/are up to date. You can access the license manager here:
https://www.atomicorp.com/support/license-manager.html
Step 2
Run the ASL installer. When asked to enter your "Enter subscription Username" and "Enter Subscription Password", enter the same credentials you used in step 1 to log into the license manager.
If you do not know what those credentials are, or you need to reset them, please visit this URL to reset your subscription credentials:
https://www.atomicorp.com/support/license-manager.html
Step 3
If you are still getting this error, remove the asl.repo file from this directory:
/etc/yum.d/
rm /etc/yum.d/asp.repo
Then run the ASL installer again.
If not installed ASL, have not installed ASL completely, or have a failed install
Follow the procedure at the URL below:
If you have successfully installed ASL on the system
Step 1)
Check the License Manager to ensure your license(s) is/are up to date. You can access the license manager here:
https://www.atomicorp.com/support/license-manager.html
Step 2)
If your licenses are up to date, check to make sure you have ASL configured to use your current license manager username and password.
Sub Step 1) Log into the ASL GUI
Sub Step 2) Click on Configuration
Sub Step 3) Click on ASL Configuration
Sub Step 4) Check to make sure the USERNAME and PASSWORD variables are set to your license manager credentials (that is the same username and password you use to log into the license manager and support portal.
Sub Step 5) Then click the "Update" button to update your configuration.
Sub Step 5) Run the update process.
Alternatively, you can manually edit the file /etc/asl/config, and change the USERNAME and PASSWORD values. Then run the command "asl -s -f" as root to set your configuration, and "aum -u" to update.
Error: Another instance of ASL appears to be running, exiting...
You may also see this error:
Another instance of ASL is running
This means that either another instance of ASL is running (only one instance can run at a time), to check if this the case run this command as root:
ps auxwww | egrep " asl| aum" | grep -v grep
If ASL is running you should see an entry similar to this:
root 7578 7.0 0.4 81476 17796 pts/7 S+ 14:55 0:00 asl -s
Or this:
root 7578 7.0 0.4 81476 17796 pts/7 S+ 14:55 0:00 aum -u
If you do not see an ASL instance running, first check to make sure you have not run out of drivespace in /var. If ASL can not write to the /var partition, due to lack of space, this error can occur. Once the out of space condition has been corrected, remove this file:
/var/asl/tmp/asl.lock
This system is not licensed for this feature
If you get an error message like this:
This system is not licensed for this feature. Please click here to get a license for the ASL T-WAF
Just run this command as root to install the T-WAF:
yum install asl-waf-module
ASL reports that grsecurity is not installed
Solution:
You must reboot your system to use the ASL kernel, which includes grsecurity. Default OS kernels do not include any stack protection, grsecurity or PAX features.
To tell which kernel you are running, as root execute this command:
uname -a
ASL kernel Critical not detected
See above.
Kernel GRsecurity support High not found
Solution:
You must reboot your system to use the ASL kernel, which includes grsecurity. Default OS kernels do not include any stack protection, grsecurity or PAX features.
To tell which kernel you are running, as root execute this command:
uname -a
If you are a VPS customer you can use a separate kernel from the host machine, which means you will not be able to use the ASL kernel. This is a security risk for your VPS and you are encouraged to contact your hosting provider for information about how they will protect your virtual server from attacks through the host server. If your hosting provider is unwilling to meet your security needs we encourage you to contact some of the fine hosting companies that use ASL and who post regularly to these forums.
If you are running a PAE system you will need to install one of our testing PAE kernels. PAE allows a 32 bit system to access memory beyond the limits of a 32 bit architecture, its sort of a hack to get around the system not being 64 bit. As a result, these kernels require more work for our kernel development team. If you are in a rush, we recommend you use a 64 bit architecture to access memory beyond 4 GB. Normal 32 bit and 64 bit kernels are fully supported.
We are working hard to finish testing of PAE kernels and will keep you informed of its progress.
Checking service for authorized_keys: not found [FAILED]
Answer:
This means that when you installed ASL you did not configured your system to use keys for SSH logins, but is instead configured to only use passwords. Passwords are less secure than keys as keys are a simple for of a two factor authentication system, something you have and something you know.
You can not define admin users for password only based authentication. Please see these settings:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ADMIN_USERS
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#SSH_PASSWORD_AUTH
Note: If you do not know how to create SSH keys for a user please see the SSH keys article.
Valid Admin users detected: no [HIGH]
This means that when you installed ASL you did not configured your system to use non-privileged accounts for logins. This means that you allow root logins to your system which is very dangerous and should be disabled. All users, including admins, should always log into a unique account for each person so that you will know logged into your system, and then those non-privileged users can su to root, or can use sudo to run privileged commands.
Checking username directory : not found [FAILED]
This means that you have defined an ADMIN_USER that does not have a /home directory on the system. For an ADMIN_USER to be valid the following must be true:
- The user must exist
- The user must have a home directory
- The users home directory must have a .ssh subdirectory
- The permissions on the .ssh subdirectory must be valid
- The user must have a valid SSH key installed on the system
Please see this configuration option for additional information:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ADMIN_USERS
WARNING: SSH will not be reconfigured at this time.
This means either:
1) that you did not configure SSH when you installed ASL, so ASL will not reconfigure SSH per your instructions
Or
2) You told ASL to make changes to your SSH configuration, and ASL has not done this because they would prevent you from logging into the system
Most commonly this occurs if an ADMIN_USER is not defined, or if an ADMIN_USER is defined that the user does not have a valid SSH key installed on the system. Please see this configuration option for details:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ADMIN_USERS
FAILED: Remote root logins are still permitted: [HIGH]
Answer:
This means that when you installed ASL you did not configured your system to use non-privileged accounts for logins. This means that you allow root logins to your system which is very dangerous and should be disabled. All users, including admins, should always log into a unique account for each person so that you will know logged into your system, and then those non-privileged users can su to root, or can use sudo to run privileged commands.
FAILED: Password authentication is enabled: [HIGH]
Answer:
This means that you did not configured SSH when you installed ASL to disallow password based logins. ASL will ask you to configure SSH to use key based authentication as it is more secure. If you tell ASL not to configure this ASL will report this as a high risk vulnerability.
/etc/cron.hourly/asl: Error: ASL has not been configured
First check to make sure that ASL was configured after installation. To configure ASL run this command:
asl -c
If you did configure ASL, check to see if the line CONFIGURED=yes is at the bottom of /etc/asl/config. If that is missing from your /etc/asl/config file just add this line back in:
CONFIGURED=yes
Critical Risk: POSIX ACL support was not detected. The T-WAF module cannot be supported in this environment. Please consult your vendor documentation for further assistance on enabling POSIX ACLs.
ASL will test the /var filesystem to see if its supports ACLs. This error means your operating system does not support ACLs on the /var filesystem.
Discussion
POSIX ACLs allow Linux systems to use fine grained control on file permissions. POSIX ACLs are required in ASL if you want to use the T-WAF, and are are documented as a pre-requisite at the URL below:
https://www.atomicorp.com/wiki/index.php/ASL_prerequisites#POSIX_ACL_support
The T-WAF is only used optionally to protect remote web services you configure, and non-Apache web services on the local system, such as other webservers (NGINX, LiteSpeed, etc.). Apache is protected with a special module, and does not require the T-WAF.
If your system does not support ACLs you can not use the T-WAF. The T-WAF allows you to configure local and remote web services to protect with the ASL WAF. This is separate from the embedded WAF ASL will install in Apache. The embedded WAF does not require POSIX ACL support.
Specifically this error can be caused if:
1) You are not using the ASL kernel, and are using a kernel that does not support ACLs, and/or
2) your /var file system is mounted on a filesystem that does not support ACLS, and/or
3) your /var file system has ACL support disabled, and/or
4) your operating system has disabled or crippled ACL support in Linux.
This does not have any impact on the apache embedded WAF, however if you wish to use the T-WAF you will not be able to do so without ACL support.
Solutions
Step 1) Check your kernel
Make sure you are running the ASL kernel, the ASL kernel fully supports ACLs for the file systems documented at the link below:
https://www.atomicorp.com/wiki/index.php/ASL_prerequisites#POSIX_ACL_support
Other vendors kernels may not support ACLs.
Step 2) Check your file system TYPE
Make sure your /var file system supports POSIX ACLs. A full list of file systems that the ASL kernel supports with ACLs are available on the ASL prerequisites page.
You can check how your filesystems are mounted by running the command "mount" as root. For example
# mount /dev/md0 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/md1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw)
The fifth field will tell you what filesystem you are using. In the example above, the / filesystem is using "ext3".
Step 3) Check to see that the file system is mounted with ACL support
Make sure your /var file system is mounted with ACL support.
Check your /etc/fstab file. A normally mounted partitiion will look something like this:
/dev/md0 / ext3 defaults 1 1
The fourth field lists the mount options. If your system is using "defaults", then on many systems this means that ACL support should be enabled. However, your file system may be using a distribution that has changed your defaults, and thereby disabled ACL support.
If you believe this is your case, attempt adding acl to the as in the example below:
/dev/md0 / ext3 defaults,acl 1 1
If your system is not using the term "defaults", then your system does not have ACLs enabled. For example:
/dev/md0 / ext3 noatime,nodiratime 1 1
In the previous example, the defaults are not used, so ACLs are not enabled. You would need to add acl support to the filesystem options, as in the example below:
/dev/md0 / ext3 acl,noatime,nodiratime 1 1
If changing your /etc/fstab does not work, then either your kernel does not support POSIX ACLs (the ASL kernel support ACLs), you are not using a filesystem that supports ACLs for your /var directory, or your OS has been crippled to not support ACLs. If you are sure your file system is mounted with ACL support enabled, your file system supports ACLs, and that you are using a kernel that supports POSIX ACLs, check with your OS vendor to determine what may be missing from your OS to support POSIX ACLs.
Note: If you change your root partition mount options, you may need to reboot the machine to safely remount the filesystem. Although there are ways to remote the filesystem "on the fly", in general it is safer to just reboot the system.
If you want to try to remount a partition with acl support, run the command below as root. Be sure to change "/" to the mount point you are changing. For example, if you want to remount your root partition, you would use "/". If you had a dedicated /var partition (not directory) you would change that to "/var".
mount / -o remount,acl
Remounting filesystems while the system is running is not recommended.
You can test the file system to ensure it supports ACLs by using the test documented at the link below:
https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Testing_manually
Step 4) Check your virtualization solution
If you are using a virtualization solution, and you are using the ASL kernel and your file system both supports and is mounted with ACL support please contact your virtualization vendor to determine what in their virtualization solution may be preventing you from using ACLs in your file system. This is a basic Linux filesystem capability, and is supported in all Linux distributions, however some virtualization vendors have been known to disable this.
Testing manually
Once you believe you have your system fixed, and you have ASL installed, you can run this command as the root user to test to see if your /var filesystem supports ACLs:
touch /var/asl/tmp/testfile;/usr/bin/setfacl -m g:root:rw /var/asl/tmp/testfile; echo $?
If your system supports ACLs you see the number "0" returned from that command. For example:
touch /var/asl/tmp/testfile;/usr/bin/setfacl -m g:root:rw /var/asl/tmp/testfile; echo $? 0
If you get any other number than 0, that means the /var filesystem does not support ACLs on your system. For example:
touch /var/asl/tmp/testfile;/usr/bin/setfacl -m g:root:rw /var/asl/tmp/testfile; echo $? 1
See the URL below for solutions:
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Solutions
Not Found: The requested URL /asl/index.php was not found on this server.
Solution:
This means the ASL GUI is missing or was not installed on your system. You can check to see if its installed with this command run as root:
rpm -q asl-web-gui
If the rpm is missing re-install it with:
yum install asl-web-gui
modsecurity errors
ModSecurity: Access denied with code 400. Too many threads
Please see this article:
https://www.atomicorp.com/wiki/index.php/HIDS_31102
Request Body Parsing Failed. Multipart parsing error: Multipart: writing to /somedirectory failed:
See the above article. This means you ran out of drive space and the session died so hard Apache gave up and crashed the session.
Solution:
Free up some drive space.
ModSecurity: Error reading request body: Connection reset by peer
This error message means that the client killed the connection. This error is not caused or generated by modsecurity or the server. This error message is simply reporting that the connection was reset by the client before it completed.
By default apache does not log these errors (even though they occur), however modsecurity will log these errors as they may be indications of malicious activity. This error is normally benign, but you should investigate any large occurrences of this error.
ModSecurity: Request body (Content-Length) is larger than the configured limit
Change this setting in the ASL GUI to the maximum value you wish to set.
MODSEC_REQUESTBODYLIMIT
Note: This is set in bits. Therefore, if you want to set the limit by bytes you will need to compute for bits.
For example:
1 gigabit is 134217728
1 gigabyte is 1073741824 (or 8 times a gigabit, which is 134217728)
The default is 1 gigabit, or 134217728
32 bit systems note: There is a hard limit in apache itself of 2Gb on 32 bit platforms. Apache supports file sizes greater than 2 Gb on 64 bit platforms where Apache is built with large file support. Versions of Apache that are not compiled with 64 bit offsets (large file support), or are operated on 32 bit platforms will have a 2GB maximum limit. This 2GB hard limit is not enforced by modsecurity nor is it something ASL establishes, this is an internal limit in apache. Keep in mind this is also request body limit, not a response body limit.
httpd: ModSecurity: WARNING Using transformations in SecDefaultAction is deprecated
This means that you are using out of date rules. If you are using Atomicorp rules, then this means you are not using the latest real time rules. The latest real time rules do not use transformations in the SecDefaultAction.
If you are using third party rules, this means that the rules contain a transform function in the SecDefaultAction setting. This is a deprecated setting.
ModSecurity: Found another rule with the same id
This means that you have a modsecurity rule with the same id. All of our rules have unique id's, and ASL configures modsecurity to only load our rules once.
This error can only occur for one of two reasons:
1) Something has configured apache to load the modsecurity rules twice.
This can only happen if you have used a third party product to install modsecurity (example: cpanels easyapache), or a third party modsecurity management tool that enables, disables, configures and loads rules. Do not use any third party tools to setup, install or configure modsecurity. Disable these tools, and re-run the ASL installer to ensure that modsecurity is setup correctly. You should only use ASL to install modsecurity, and to manage your modsecurity rules, configuration, upgrades and installation.
If you have used any third party tools to install, configure or manage modsecurity uninstall the tools and contact the developers of that software to make sure the changes they have made have been completely removed. ASL is not supported with third party modsecurity tools or installations, and these third party tools are not necessary when using ASL. You may need to reinstall ASL in some cases. If the following does not reconfigure modsecurity to a working configuration, you will need to reinstall ASL:
Step 1) Remove all third party modsecurity tools
Step 2) If you used a third party tool to install modsecurity, including installing modsecurity from your control panel uninstall modsecurity and disable its installation from your third party tool.
Step 3) If this is a new install:
Once you have confirmed that you have removed any previous modsecurity installation, re-run the ASL installer.
Step 3) If this is an existing working installation:
Once you have confirmed that you have removed any previous modsecurity installation,
As root run these commands:
aum -uf
asl -s -f
2) You have other rules that are using the same id's already assigned to other rules.
If you are using third party or custom rules, check to make sure they have unique id's. Modsecurity requires a unique id for each rule. The range 300000-399999 is used by our rules, do not use this range for any custom rules, and if you have third party rules with these id's be sure to remove these rules.
If you have used our delayed rules in the past, and setup modsecurity yourself or had a third party setup modsecurity for you, make sure that installation is completely removed from your system. The ASL installer will attempt to do this, but as not all installations are the same or follow the same conventions it may be possible your modsecurity installation deviates from the standards, and is not removable by ASL.
clamd/clamav messages/errors/issues
LibClamAV Warning: RWX mapping denied
This means that you are eithe running a very out of date versions of clamav or someone or something has replaced clamav on your system with either an old, or very crippled version of clamav. You will need to ensure that your system is up to date, and that any third party versions of clamav have been removed.
LibClamAV Warning: Bytecode: disabling JIT because PaX is preventing 'mprotect' access.
This means that you are eithe running a very out of date versions of clamav or someone or something has replaced clamav on your system with either an old, or very crippled version of clamav. You will need to ensure that your system is up to date, and that any third party versions of clamav have been removed. Do not follow the advice of this error message, this will open your system up to a root level compromise. This error occurs only when older versions of clamav are installed, or someone has replaced clamav on your system with crippled version. The ASL version of clamav does not have this bug, and will not require you to open this root level hole in your system.
/usr/bin/modsec-clamscan.pl is not installed on the server.
This means that someone has removed parts of ASL. You will need to reinstall ASL and remove whatever software is removing parts of ASL.
Exec: Execution failed while reading output: /usr/bin/modsec-clamscan.pl (End of file found)
This means that someone has either removed clamav, or disabled the TCP service for clamd. Please see this article for assistance:
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Cannot_re-connect_to_Clamd
Note: If you are using a third party clamav installation you will need to remove it. ASL is only supported with clamav provided with ASL
Error: CLAMAV_ENABLE_DAZUKO set to enabled, but Kernel Malware detection module was not detected.
This can happen for one of two reasons:
1) The system is not running the ASL kernel. Please see the kernel article for information on installing and booting the ASL kernel.
2) The system is running the ASL kernel, but does not have the dazuko package installed.
Check to see if the dazuko package is installed:
rpm -qa | grep dazuko
If dazuko is installed, you should see an output similar to this:
dazuko-kmod-common-2.3.9-6.36 kmod-dazuko-2.3.9-6.36 kmod-dazuko-2.6.32.59-24.art.x86_64-2.3.9-5.24
2a) If dazuko is not installed
Install dazuko:
yum -y install kmod-dazuko dazuko-kmod-common
2b) If dazuko is installed
Check to make sure you have the latest version installed along with the ASL kernel. There should be an package installed on the system with the same kernel version as the ASL kernel running on the system. For example, if kernel 2.6.32.59-24 is installed and running on the system, you must also have a package called "kmod-dazuko-2.6.32.59-24.art.x86_64-2.3.9-5.24" installed on the system.
clamd[12345]: lstat() failed on:
Examples:
clamd[28775]: lstat() failed on: /var/www/vhosts/example.com/httpdocs/index.php
This means that a third party product has changed the systems antimalware configuration. Specifically, its changed the user that clamd runs as. Make sure that anytime you install or upgrade any software that you run asl in scan and fix mode. ASL will look for misconfigurations, vulnerability and holes that third party software may introduce in the system. Just run this command as root, and in this case if you have enabled CLAMAV in the ASL configuration ASL will automatically fix this issue:
asl -s -f
If you have not enabled CLAMAV, please do so in the ASL Configuration.
Note: clamav installations that are not managed by ASL are not supported.
If you have installed a third party version of clamav, please remove it and reinstall the ASL version of clamav. It has been specifically modified for the advanced needs for ASL, and a generic version of clamav will not work properly. You can run this command, as root, to reinstall clamav:
yum reinstall clamav clamd clamav-db
Note: Make sure you do not have any third party yum repositories enabled that publish their own clamav rpms, or if you do make sure you exclude clamav from those repositories. Third party clamav installations are not supported.
clamd[12345]: stream(127.0.0.1@1234): Some.Virus.Found
Example:
May 10 09:38:26 host1 clamd[843180]: stream(127.0.0.1@1945): Atomicorp.PHP.eval.raw.request.base64_decode.20120217165003.UNOFFICIAL FOUND
Explanation:
An application asked clamd to scan a file via the TCP "stream" method, and clamd reported that the file appeared malicious. The "stream" service is a TCP service. It allows an application to send an object to the clamd server via TCP and to ask the object to be analyzed. All that clamd will see if the IP address of the source (in this case localhost). If an application chooses not to log that its done this, theres not much else you can do to look into this. clamd only sees the request.
Only one ASL component uses the streaming method, that is the web upload scanning component. However, if it detects a malicious file it will also log a WAF event 351000 which will tell you the domain and application involved. If you do not see this event, in the ASL GUI, it means some other NON-ASL component on your system asked for an object to be scanned, and that object has been found to contain malware. You will need to find out what application(s) on your system do this and
Recommendations:
Only use ASL components to scan for malware. We recommend that the realtime Anti virus malware protection system in ASL be activated. If it is not, then ASL will not be able to stop all malware that may be on the system (upload scanners can only scan what they can see, and there may be other ways to upload content to your system, for example, an attacker can just SSH to the system and manually type in the malware and that would bypass any upload scanner, so use the realtime malware protection system!).
If you are seeing clamd messages such as these, that may mean that the realtime malware protection system is not active on your system. The realtime malware protection system requires that you run the ASL kernel, if you are not using the ASL kernel then will not be able to use the realtime malware protection system. Please see the Anti_virus page for documentation on enabling the realtime antimalware system.
With this said, a stream event such as the one in the example above does not mean necessarily mean that the file was on the system. An application can be sent a file, in memory (for example, if you were uploading a file to a web server it may store the file in memory first), and the application can then ask clamd to examine it and based on the response it gets from clamd can then decide what to do with this. clamd can not force the application to do anything with the file, as clamd is neither handling the file nor is is it managing it when the stream method is used. clamd just tells the application using the stream method if the file is, or is not, a malicious piece of software. At this point its up to the application to do something.
ASL, for example will both do something, and it will log that it did it, when the file was, and what was done with it. Its entirely possible if you see these events that the application that requested the file to be scanned rejected the file (which is what would be expected of a rational application, otherwise whats the point), but the application just may not bother to log that it did this.
The real time malware protection in ASL however can and will prevent all malicious software being saved on the system, from being executed, modified, etc. If thats not active, then ASL has "one hand tied behind its back" when it comes to malware. Again, we recommend you enable the realtime malware protection system if you are using the ASL kernel.
If you want to see if there is anything malicious on your system, you can do so by running the command described at the URL below as root:
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#How_can_I_scan_for_malware.3F
As mentioned before, with a STREAM event that does not mean that the file was on the system. More often than not it means it was not on the system as most applications that use the stream method use this for uploads, streaming the file to clamd, and if clamd says its virus they will block the upload .
If you are using a third party application that uses the stream method, and its not logging anything else (such as that it blocked the file somehow), then we recommend you scan your system. If you do not find any malware then you have an application thats scanning things, but isnt logging what it did if it found a virus.
connect(127.0.0.1:3310): Connection refused
See Cannot re-connect to Clamd below.
connect(): Connection refused
See Cannot re-connect to Clamd below.
ERROR: Can't connect to clamd: No such file or directory
See Cannot re-connect to Clamd below.
End of file found
See Cannot re-connect to Clamd below.
Cannot re-connect to Clamd
This error can occur if the clamd daemon is not running, if it has been removed by a third party product, if it has been incorrectly configured by a third party, or if local firewall rules prevent connections to clamds.
Various applications on the system communication with clamd (freshclam, FTP, apache, etc.). If they can not communicate with clamd, for example if clamd is not running, not listening on a socket or TCP port, or if a firewall is blocking it, the application will generate a connection error. This errors means that one or more of these conditions exists on your system. ASL can not create this condition, so if this has happened on your system you may need to perform some troubleshooting to determine the cause so you can implement the correct fix.
Step 1)
Check to make sure you have ASL configured with clamd enabled. The correct setting in the ASL gui is:
CLAMAV_ENABLED="yes"
Step 2)
If this setting is set to yes, then check to make sure clamd is configured to listen on an IP address that the application can access. By default this is set to 127.0.0.1. We do not recommend you change this, but if you have setup your interfaces in a non-standard manner you may need to do this.
Step 3)
Also check to make sure you do not have any third party installations of clamd or clamav components. These may conflict with the ASL installed clamav components. You only need one installation of the clamav components, and ASL will install and manage all of these components for you. If you have installed third party clamav components you may also have a corrupt installation. Please remove any third party clamav components. If you have used a package managed copy of clamv, you may be able to remove the third party installation by finding the packages name and using "yum remove packagename" to remove the package. Please contact the vendor for the third party clamav installation for assistance with removing their packages.
If you have a source installation of clamav, then you will need to contact the third party vendor for assistance with removing their software.
Once you have removed any third party clamav installations reinstall the ASL clamav components:
yum reinstall clamv clamd clamav-db
Step 4)
Check to make sure the clamd service is running:
ps auxwww | grep clamd
If the service is running, try running an application that will interact with clamd, for example the signature updater:
freshclam
If you still get a connection refused error, then check your firewall rules to ensure that freshclam can communicate with clamd on the system. You will also want to check to make sure that clamd is both listening via TCP and via a socket. If it is not, then you have a non-ASL configured copy of clamd running. Run this command to try to fix this non-ASL configuration:
asl -s -f
If this still does not resolve the issue, and you have installed a third party clamav installation please ensure that you have removed all traces of third party installations of clamav. This condition can not occur with an ASL managed installation, and some other product is interfering with your installation.
Your ClamAV installation is OUTDATED
See the FAQ below:
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#This_version_of_the_ClamAV_engine_is_outdated.
This version of the ClamAV engine is outdated.
First, don't panic, this is not an error and nothing is wrong with your system. This just means that a newer version of the clamav engine is available, and this message means that the version of clamav engine you have installed is not the latest. The simple solution is to upgrade to the latest clamav release, vy running this command as the root user:
yum upgrade clamav
Sometimes we may not release a clamav update immediately to do some additional testing, if your system will not upgrade to the latest clamav, and you have an active license, please be patient and we will release a new engine when we believe it is stable. If you wish you skip the stable releases, just install testing yum repository.
/usr/bin/modsec-clamscan.pl (The timeout specified has expired)
This means that the clamd daemon is either not running, or a response from the daemon has timed out. The later can occur if the system is heavily overloaded to such an extent that the clamd daemon is unable to process the request quickly enough.
Troubleshooting:
1) Check that the clamd service is running:
Run this command as root:
ps auxwww | grep clamd
If clamd is running, you should see something similar to this:
root 29859 0.0 6.8 471680 419364 ? Ssl 12:28 0:00 clamd
If clamd is running and the event happened in the past its possible clamd was not running at the time and was started by the system process watchdog. In that case, monitor to the system to see if the clamd service was stopped.
If clamd is not running, start clamd with this command as root:
/etc/init.d/clamd start
2) Check the load, CPU usage and memory available on the system at the time the event occurred. If the system was overloaded, add additional resources to compensate for system load.
LibClamAV Warning: Detected duplicate databases /var/clamav/main.cvd and /var/clamav/main.cld, please manually remove one of them
This can occur if an update is interrupted and clamav does not have a chance to clean up after itself.
Solution:
Remove either the /var/clamav/main.cvd or /var/clamav/main.cld file.
You can also remove both, if you do that run the command "freshclam" as root after you do that.
FATAL: Error inserting dazuko
Example:
FATAL: Error inserting dazuko (/lib/modules/2.6.32.60-35.art.x86_64/extra/dazuko/dazuko.ko): Operation not permitted
Cause:
1) If you are using the ASL kernel
This is a harmless error. It simply means that ASL is attempting to insert the module, which is already inserted. You can confirm if the module is already inserted by running this command as root:
lsmod | grep dazuko
If you see output similar to this:
dazuko 34523 3 redirfs 57062 1 dazuko,[permanent]
You can ignore this error. If you do not see output similar to this, and instead get no output from this command it means the module is not loaded. You will need to reboot your system (and ensure you are rebooting in the ASL kernel) to force the module to load.
2) If you are not using the ASL kernel
Non-ASL kernels do not support the realtime anti-malware system. You must be using an ASL kernel to use this feature.
ERROR: Clamuko: Dazuko -> Can't include path
This generally occurs if you are not running the ASL kernel, and you do not have the dazuko kernel module installed.
Solution:
1) First ensure that you are running the ASL kernel. See the kernel article for troublshooting kernel installation issues.
2) Ensure that the dazuko module is loaded:
As root run this command:
lsmod | grep dazuko
If dazuko is installed, you will see output similar to this:
dazuko 34523 3 redirfs 57062 1 dazuko,[permanent]
If you do not see output similar to this, then the dazuko module is not loaded.
3a) If you are not running the ASL kernel
You must be running the ASL kernel to use the dazuko module. Please see the kernel module for assistance with ensuring the ASL kernel is installed and how to boot into the ASL kernel.
3b) If you are running the ASL kernel
Please follow the instructions on the Anti_virus page for installing the dazuko module. Once the module is installed, you will likely need to reboot your system. Please follow this checklist again to ensure the module is loaded.
If the dazuko module is loaded, and you still get this error:
1) This means that clamd is not running as root. Please ensure that clamd is running as root.
2) The directory does not exist.
3) SELinux is enabled, and the SELinux policy is not setup to allow clamd to perform real time antimalware analysis. Please contact your Operating System vendor for assistance with their SELinux policies.
If neither of these are true in your case, please contact support and send us the output of all commands used in this troubleshooting process and the results of these steps.
rkhunter errors and messages
Warning: Suspicious file types found in
This means that rkhunter has found files on your system that are suspicious. They may, or may not be malicious and you should investigate the contents of these files to ensure they are legitimate.
Warning: Suspicious file types found in /dev:
This means that rkhunter has found files on your system that are suspicious. They may, or may not be malicious and you should investigate the contents of these files to ensure they are legitimate.
Recently, udev has started using text files in /dev. The Filesystem Hierarchy Standard (FHS) for all Linux based systems does not allow text files in /dev, so text files should not be present which is why rkhunter may report these as suspicious. Before you assume that these files are not malicious, you should as described above investigate that they are not.
If you are sure they are not malicious, you can ignore files by editing rkhunter.conf on your system and adding lines like these, for each file you know is not malicious and want to ignore:
ALLOWDEVFILE="/dev/.udev/some/specific/file/being/reporting/by/rkhunter/you/want/to/ignore"
ALLOWDEVFILE="/dev/.udev/some/specific/file/being/reporting/by/rkhunter/you/also/want/to/ignore"
Checking file <somefile> [ No update ]
This is a normal message, it simply means there are no new updates available. This is not an error, and you do not need to take any actions.
Warning: No output found from the lsmod command or the /proc/modules file:
This can happen if you are using a virtualization solution, such as VPS technologies, that do not provide you with your own kernel.
Warning: The kernel modules directory '/lib/modules' is missing or empty.
This can happen if you are using a virtualization solution, such as VPS technologies, that do not provide you with your own kernel.
Warning: Package manager verification has failed:
If rkhunter is reporting:
The file modification time has changed
This means that since the last time rkhunter ran the file modification on the reported file has changed. This can mean that either:
1) The files modification time has legitimately changed, either through an update or some third party action
2) An unauthorized change has occurred to the files permissions, which could be malicious or accidental
You should investigate the file modification on the file. The best way to do this is to use the ASL file integrity manager which will tell you what files have changed on your system, and what they previously were.
The file permissions have changed
This means that since the last time rkhunter ran the file permissions on the reported file have changed. This can mean that either:
1) The files permissions have legitimately changed, either through an update or some third party action
2) An unauthorized change has occurred to the files permissions, which could be malicious or accidental
You should investigate the file modification on the file. The best way to do this is to use the ASL file integrity manager which will tell you what files have changed on your system, and what they previously were.
The file group has changed
This means that since the last time rkhunter ran the group ownership on the reported file have changed. This can mean that either:
1) The group permissions have legitimately changed, either through an update or some third party action
2) An unauthorized change has occurred to the files permissions, which could be malicious or accidental
You should investigate the file modification on the file. The best way to do this is to use the ASL file integrity manager which will tell you what files have changed on your system, and what they previously were.
Warning: Hidden ports found
This means that something has a port open (or is holding it in a state to prevent other applications from binding to the port). This can happen for one of two reasons:
1) A malicious application or rootkit has a port open and is hiding it from the OS
2) A non-malicious application is holding the port in a "hidden" state to prevent other applications from binding to the port
The application port reserve will do this for some reserved ports, such as port 631. You may see an alert like this:
Warning: Hidden ports found: Port number: TCP:631
You will want to check if your system is using portreserve and if its truly configured to do this. Most servers do not need to use portreserve. portreserve is not part of ASL is not supported by Atomicorp, contact your OS vendor for assistance with portreserve.
Warning: Unable to check for passwd file differences: no copy of the passwd file exists.
This means that rkhunter has not previously generated a passwd file to compare with this run of rkhunter. If you are certain that this should exist, this means that:
1) An authorized party has removed this information from the system. This can occur if rkhunter was removed, these data files were removed, or if a major change in rkhunters design requires a new data format to be used.
2) An unauthorized party has removed this information from the system. An attacker may want to remove this information so that rkhunter will not report recent changes to the passwd file.
If you believe an unauthorized party has removed this information from your system, your system may have experienced a root level compromise. Additional forensics will be necessary to determine the root cause.
Warning: Unable to check for group file differences: no copy of the group file exists.
See "Warning: Unable to check for passwd file differences: no copy of the passwd file exists." above.
Warning: The SSH configuration option 'PermitRootLogin' has not been set.
This means that SSH is not configured specifically to allow or deny root logins. SSH will default to the defined behavior for your vendors implementation of sshd. In most cases, this means that SSH will allow root access.
Warning: The SSH and rkhunter configuration options should be the same
This means that SSH is configured to either allow or deny root logins, and rkhunter is set to the opposite. For example, you may see this reported from rkhunter:
SSH configuration option 'PermitRootLogin': yes Rkhunter configuration option 'ALLOW_SSH_ROOT_USER': no
rkhunter does not enforce your SSH configuration, like ASL does. So if you have configured ASL to manage your ssh settings, you can ignore this warning if SSH is set to your liking. If you wish to use rkhunter to notify you of your SSH settings, then you will need to make sure rkhunter is configured to match your ssh settings. ASL does this automatically for its vulnerability management system, as ASL will both configure SSH to your liking, will enforce these settings and will notify you if this condition presents any risks.
We recommend you disable this capability in rkhunter as it is redundant to the alerting system in ASL, and as ASL has the capability to configure SSH based on what you configure ASL to do, whereas rkhunter does not have this capability.
Please see these settings in ASL for more information about SSH:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#SSH_daemon_configuration
Warning: Suspicious file types found in /dev: <somefile> ASCII text
rkhunter, by default, follows the conventions laid out for /dev. /dev is not supposed to contain ASCII text files, however one element of some RHEL and Centos systems is known to do this: udev. For those systems you may see alerts such as this:
/dev/.udev/db/input:event4: ASCII text /dev/.udev/db/input:event0: ASCII text /dev/.udev/db/input:js0: ASCII text /dev/.udev/db/input:event3: ASCII text /dev/.udev/db/input:mouse2: ASCII text /dev/.udev/db/input:event1: ASCII text /dev/.udev/db/input:event2: ASCII text /dev/.udev/db/input:mouse1: ASCII text /dev/.udev/db/net:eth1: ASCII text /dev/.udev/db/net:eth0: ASCII text /dev/.udev/db/usb:1-2: ASCII text /dev/.udev/db/usb:usb1: ASCII text /dev/.udev/db/serio:serio0: ASCII text
These are benign, however these are also not an error in rkhunter. rkhunter uses the standards set for /dev correctly, and is correctly alerting on this non-standard condition.
If you do not see these alerts for udev, then malicious code may be on your system.
Warning: The file '/foo/bar' exists on the system, but it is not present in the rkhunter.dat file.
rkhunter has a file integrity checking system. ASL has its own indepdent and more robust file integrity checking system, and does not use this part of rkhunter, although its still activated for those users that have custom scripts that use rkhunter. If you wish to use this capability in rkhunter, you will have to periodically update rkhunters file integrity checking system based on your own best judgement if these changes are authorized. ASL does this automatically for its own file integrity checking system, so you may also just want to disable this in rkhunter or ignore these warnings.
If you want to use this part of rkhunter, then you will need to:
1) confirm that the file is in fact legitimate 2) the change was authorized 3) update the rkhunter database to reflect this. The command to update the database is:
rkhunter --propupd /path/to/file
Warning: The file '/foo/bar' does not exist on the system, but it is present in the rkhunter.dat file.
rkhunter has a file integrity checking system. ASL has its own independent and more robust file integrity checking system, and does not use this part of rkhunter, although its still activated for those users that have custom scripts that use rkhunter. If you wish to use this capability in rkhunter, you will have to periodically update rkhunters file integrity checking system based on your own best judgement if these changes are authorized. ASL does this automatically for its own file integrity checking system, so you may also just want to disable this in rkhunter or ignore these warnings.
If you want to use this part of rkhunter, then you will need to:
1) confirm that the file is in fact legitimate 2) the change was authorized 3) update the rkhunter database to reflect this. The command to update the database is:
rkhunter --propupd /path/to/file
Warning: Suspicious file types found in /dev:
This could be a sign of an intrusion. So read this section carefully. rkhunter will look for files in suspicious places that should not be there. Previously, text files should never have been seen in /dev. Recent changes to udev have caused udev to store data in /dev that are text files. This is the only known legitimate application that will do this. Here is an example of a udev text file:
/dev/.udev/db/class@misc@tun: ASCII text
If you see this, it generally means that you need to upgrade rkkhunter, and overwrite your rkhunter .conf file with rkhunter.conf.rpmnew file which contains new directives to address this. To perform this upgrade, follow this process and run these commands as root:
Step 1) yum -y upgrade rkhunter
Step 2) cp /etc/rkhunter.conf.rpmnew /etc/rkhunter.conf
Step 3) asl -s -f
If you see text files that are not associated with udev, this may be an indication that your system has been compromised.
proftp errors
CRITICAL:3:a programming/runtime error on proftp upgrade
If you receive an error like this:
psa-proftpd-1.3.3e-1.el5.art.x86_64.rpm | 2.0 MB 00:04 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : psa-proftpd 1/1 CRITICAL:3:a programming/runtime error CRITICAL:3:a programming/runtime error error: %trigger(psa-triggers-10.10.1-cos5.build1010110207.15.noarch) scriptlet failed, exit status 3 error: %trigger(psa-triggers-10.11.0-cos5.build1011110331.11.noarch) scriptlet failed, exit status 3 Installed: psa-proftpd.x86_64 0:1.3.3e-1.el5.art
This is not caused by ASL. psa-triggers is a piece of software from Parallels company and is not part of psa-proftp and has no adverse impact on the installation of Atomicorps psa-proftp or its upgrade. Please report this bug to Parallels if you have issues with this error and their software.
Detailed Explanation:
In Linux systems that support RPMs software can be installed to "monitor" changes in other software and then require and force the system to take additional, unrelated and external actions. When that software is installed they can require "triggers" to be executed when that software is changed, upgraded, installed, etc. These triggers are not part of the software, and are not even included in it. Its part of the larger software management system of the operating system, and is something a third party piece of software can require for any piece of software. These triggers are outside the control of the software itself or its authors.
In this case, when proftp is upgraded, another package (Plesk) has configured the system to require that if the package "psa-proftpd" changes that the "psa-triggers" package must also be run. This is neither requested by proftp, its package or its upgrade. Its completely outside of the package itself. Because of this, in this case proftp is upgraded successfully, however the third party software (Plesk in this case) has a bug that causes an error with the external "psa-triggers" package (and not with proftp or the upgrade). As a result, this does not effect the psa-proftp software, as per the message:
Installed: psa-proftpd.x86_64 0:1.3.3e-1.el5.art
The software was installed/upgraded successfully.
The error message:
CRITICAL:3:a programming/runtime error CRITICAL:3:a programming/runtime error error: %trigger(psa-triggers-10.10.1-cos5.build1010110207.15.noarch) scriptlet failed, exit status 3 error: %trigger(psa-triggers-10.11.0-cos5.build1011110331.11.noarch) scriptlet failed, exit status 3
Is reported from the external and unrelated psa-triggers package from Parallels. This has no effect on the Atomicorp psa-proftp package install, nor does it prevent or effect its installation, upgrade or change. This message is external to the upgrade of proftp and it is not related to any software from Atomocorp.com.
This is a bug in Plesk, and is not something in ASL or proftp, nor is it something the proftp package from Atomicorp requests or executes.
Report this to the vendor as a bug in their software (in the example above, this is a bug in PSA 10).
Fatal: unknown configuration directive 'ClamAV' on line 1 of '/etc/proftp-asl.conf'
Explanation:
This means that you are not using the Atomicorp version of Pro FTP. You are using some other parties version of proftp that does not include malware upload support.
Some products (such as PSA miroupdates), will install a different version of proftp over the Atomicorp version. These vendors will also not update your rpm repository, so checking your installed packages will also not show this change and will appear to report that the atomicorp version of proftp is install, it is not.
This error is conclusive proof the system is not running the Atomicorp version of psa-proftp.
Solution:
Reinstall the Atomicorp version of Proftp:
yum reinstall psa-proftpd psa-proftpd-xinetd
If you attempt to resinstall our version of proftp, and you get an error from yum similar to this:
yum reinstall psa-proftpd psa-proftpd-xinetd Loaded plugins: fastestmirror Setting up Reinstall Process Loading mirror speeds from cached hostfile * addons: centos.kiewel-online.ch * atomic: www7.atomicorp.com * base: centos.kiewel-online.ch * extras: centos.kiewel-online.ch * rpmforge: ftp-stud.fht-esslingen.de * updates: centos.kiewel-online.ch Installed package psa-proftpd-1.3.3c-3.el5.art.x86_64 not available. Installed package psa-proftpd-xinetd-1.3.3c-3.el5.art.x86_64 not available. Nothing to do
This means that you have either configured yum to either exclude you from installing proftp, you have yum priorities setup, you have disabled the asl repository or you have third party repositories also configured on the system that is throwing off yum and not allowing it to install the software it needs.
Steps to troubleshoot your yum configuration:
Step 1)
Disable all third party repositories.
Step 2)
Remove yum priorities if its installed:
yum remove yum-priorities
Step 3)
Check your yum configuration to make sure you do not have anything excluded. Exclude entries are sometimes added to /etc/yum.conf or in your /etc/yum.repos.d/ directory, and will look similar to this example:
exclude=psa-proftp*
Remove these entries.
Step 4)
Check to make sure the asl respository is enabled. The ASL respository is stored in the /etc/yum.repos.d directory in a file titled "asl.repo". In that file are three asl "channels", there are:
- asl-2.0
- asl-2.0-testing
- asl-2.0-bleeding
Ensure that under the asl-2.0 heading that you see a line like this:
enabled=1
That means the channel is enabled. You do not need to enable the asl-2.0-testing or asl-2.0-bleeding channels. Those channels are for beta and test software, and are not supported.
A working configuration will look like similar to this:
[asl-2.0] name=Atomicorp - - Atomic Secured Linux 2.0 baseurl=http://username:password@atomicorp.com/channels/asl-2.0/centos/5/x86_64 enabled=1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt gpgcheck=1 [asl-2.0-testing] name=Atomicorp - - Atomic Secured Linux 2.0 (TESTING) baseurl=http://username:password@atomicorp.com/channels/asl-2.0-testing/centos/5/x86_64 enabled=0 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt gpgcheck=1 [asl-2.0-bleeding] name=Atomicorp - - Atomic Secured Linux 2.0 (BLEEDING) baseurl=http://username:password@atomicorp.com/channels/asl-2.0-bleeding/centos/5/x86_64 enabled=0 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt gpgcheck=1
Do not change any other settings in this file.
Step 4) Attempt to reinstall again
yum reinstall psa-proftpd psa-proftpd-xinetd
If this still fails, it may because your system had a very old version of psaproftp, and you need to upgrade. In which case, run this command as root:
yum upgrade psa-proftpd psa-proftpd-xinetd
mod_evasive
Tuning mod evasive
Please see the Mod_evasive article.
cpanel and mod_evasive
Currently mod_evasive does not work with cpanel. You may be able to install it manually, but ASL will not be able to manage it and this is not a supported configuration. We are working with cpanel to support mod_evasive.
mod_evasive works with and is supported with all other platforms.
[file "mod_evasive20.c"] [line 246] [level 3] client denied by server configuration:
Please see the Mod_evasive article for detailed information about this message, and how to tune or disable this component for your needs.
Apache errors messages
[warn] module security2_module is already loaded, skipping
This error means that apache has tried to load mod_security twice, and is refusing to do so. This is worth investigating because ASL will never try to do this, and this error means that someone or something else has configured apache to do this twice. This could mean that there are two (or more) modsecurity configurations on the system, which will in fact be loaded by apache. Although the module is not loaded, the configuration options will be which could cause all sorts of problems with the system.
Again, ASL will never configure the system to do this, so if you see this error it means someone or something else has added another modsecurity configuration to the system which could cause severe performance problems, could disable key settings, or enable other settings that may conflict with the configuration of modsecurity.
If the module is just configured to load twice, and there are no configuration options then this error may be harmless.
Address already in use: make_sock: could not bind to address [::]:80
This is a generic error generated by Apache. This message occurs if apache (or some other process) is bound to port 80. This error is not caused by ASL.
In some cases, such as when apache is restarted, the apache init script may not actually shut apache down before starting it. In some other cases, such as if the system is running a processor manager, or a process watchdog, they may restart apache during the restart cycle if Apache takes a long time to stop (the apache "graceful" option may take a long time to shut down all child processes, and this can occur). The process manager may incorrectly (or depending on how you look at the situation, correctly) detect that Apache is "down" and restart it automatically, before the Apache init script can start Apache. This will result in this error which is technically incorrectly.
This can also occur if some other process is listening on port 80. In all cases, when this error message is generated by apache, it means that apache tried to start and tried to bind to port 80 only to find something else (possibly apache) already listening on port 80.
Check to see if apache is already running, by running this command as root:
ps auxwww | grep httpd
If apache is running, you will see an output similar to this:
root 30070 0.0 11.2 572444 227872 ? Ss 16:01 0:01 /usr/sbin/httpd apache 30338 0.0 10.6 445936 215880 ? S 16:01 0:00 /usr/sbin/httpd apache 30339 0.2 13.1 652036 266176 ? S 16:01 0:09 /usr/sbin/httpd apache 30340 0.1 12.7 633744 256844 ? S 16:01 0:09 /usr/sbin/httpd apache 30341 0.2 12.7 641456 257528 ? S 16:01 0:09 /usr/sbin/httpd apache 30342 0.2 12.7 641852 257364 ? S 16:01 0:10 /usr/sbin/httpd apache 30343 0.2 12.7 635864 256688 ? S 16:01 0:09 /usr/sbin/httpd apache 30344 0.2 12.9 644080 261692 ? S 16:01 0:10 /usr/sbin/httpd apache 30345 0.2 12.9 644012 261632 ? S 16:01 0:10 /usr/sbin/httpd apache 30346 0.2 12.4 634564 251056 ? S 16:01 0:12 /usr/sbin/httpd apache 32012 0.1 12.8 644100 259272 ? S 16:31 0:04 /usr/sbin/httpd apache 32013 0.1 12.7 643804 256628 ? S 16:31 0:04 /usr/sbin/httpd apache 32014 0.1 12.6 641456 255712 ? S 16:31 0:04 /usr/sbin/httpd apache 32015 0.1 12.9 645856 262424 ? S 16:31 0:05 /usr/sbin/httpd apache 32016 0.1 11.5 631772 233776 ? S 16:31 0:04 /usr/sbin/httpd apache 32017 0.1 12.7 641424 258196 ? S 16:31 0:04 /usr/sbin/httpd
If you see apache running, you can ignore this error. However, you may want to restart apache again just to make sure whatever changes were applied to apache, to cause it need to be restarted, were applied.
If you do not see apache running, try starting it again. If you continue to get this error, then something else is running on port. You can find out what is listening on port 80 with this command:
netstat -anp | grep :80 | grep LISTEN
The output will look like this:
tcp 0 0 :::80 :::* LISTEN 30070/httpd
The last field "300070/httpd" lists the process ID and process name that is listening on port 80.
Kernel Messages/Errors
What do the PAX alerts for software in /usr/libexec/paxtest mean?
These messages are benign, and you can ignore them.
Examples:
Example if you are running an ASL kernel:
PAX: execution attempt in: <anonymous mapping>, 53181000-53184000 53181000 PAX: terminating task: /usr/libexec/paxtest/anonmap(anonmap):1234, uid/euid: 0/0, PC: 53181000, SP: 23498723984 PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PAX: bytes at SP-4: 12345465682347509817324059871340598734
You may also see messages such as this:
kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/paxtest/execheap[execheap:5854] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/paxtest/execheap[execheap:5853] uid/euid:0/0 gid/egid:0/0
Example if you are not running an ASL kernel:
kernel: anonmap[12345]: segfault at 00002aaaaaaab000 rip 00002aaaaaaab000 rsp 00007fff457153f8 error 15
Discussion
If you see these log messages for any of these programs:
/usr/libexec/paxtest/anonmap /usr/libexec/paxtest/execbss /usr/libexec/paxtest/execdata /usr/libexec/paxtest/execheap /usr/libexec/paxtest/execstack /usr/libexec/paxtest/mprotanon /usr/libexec/paxtest/mprotbss /usr/libexec/paxtest/mprotdata /usr/libexec/paxtest/mprotheap /usr/libexec/paxtest/mprotshbss /usr/libexec/paxtest/mprotshdata /usr/libexec/paxtest/mprotstack /usr/libexec/paxtest/shlibbss /usr/libexec/paxtest/shlibdata
These are caused as part of ASL's built in kernel vulnerability scanner. These messages in syslog are normal and harmless and you can ignore them. They mean the vulnerability scanner is working correctly. These messages do not cause any harm to the system, and are perfectly safe.
If you are running an ASL kernel you are immune to the vulnerabilities the scanner will test for and the "PAX:" messages indicate that ASL is working normally and safely.
If you are not running an ASL kernel you will not see the PAX: messages, which means you are vulnerable to some of these tests. The ASL GUI will report the specific vulnerabilities, you can also get a report from the command line by running this command as root:
asl -s
The solution to kernel level vulnerabilities is to run the ASL kernel. Standard Linux kernels are not immune to all kernel exploits and vulnerabilities.
Can I suppress these events so they are not logged?
No. These are generated by the kernel itself, and suppressing these events would mean that you wouldnt be notified of an actual attack on your system either. These messages mean that the kernel is working correctly, and this is an important part of the health management system in ASL.
kernel: ASL_INVALID_INPUT
This message simply means that a packet came in that the kernels firewall has detected as a packet not associated with a valid stateful connection. Most often this happens when a packet comes in "late" and the session is either already torn down, or the session has "moved past" this point and does not need this packet and the packet is out of sequence. These messages can generally be ignored, as they are simply the byproduct of the imperfect nature of IP.
Generally you will see them for cases where a session is shutting down:
Nov 28 19:11:44 host kernel: ASL_INVALID_INPUT IN=eth0 OUT= MAC=<snip> SRC=1.2.3.4 DST=5.6.7.8 LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=51535 DF PROTO=TCP SPT=59190 DPT=30000 WINDOW=0 RES=0x00 RST URGP=0
(this is a "reset" packet, telling the server the client is killing the session, but the session is already gone so the kernel doesnt need this packet)
You may see them for other cases, where a session got our of sync.
ASL can log these packets just in case something more serious is occurring, where an attacker is trying to trick the stateful firewall. You do not need to take any action if you see these messages, these just mean that the stateful firewall is ignoring these packets and if this were an attack, it is being blocked. You can also ignore this for legitimate connections, as ASL will not shun on these types of events. Non-malicious traffic is far too common, and we do not recommend you ever shun on these types of events.
denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0
The kernel is just reporting that an application tried to core dump, and that you have your system configured to prevent core dumps. When an application core dumps that means it died and its trying to record its state for debugging.
ASL does not configure or enforce this, its just reporting an event. Non-ASL kernels do not have the ability to report core dumps. This information can help you to debug a potential bug in an application, or it may indicate that someone is trying to compromise your system by crashing an application.
Please contact your OS vendor for instructions about how to allow applications to core dump if you want to analyze the core dump to see why the application died. We have also put together a courtesy wiki Apache article which explains how to configure your system to allow core dumps and how to analyze them for your system. Please contact your application vendor with specific questions about why a particular application may have died and generated a core dump.
denied resource overstep by requesting 12345 for RLIMIT_*
This means that your operating system has a limit configured for something, and your system has exceeded this limit.
ASL does not cause this, the ASL kernel also does not cause this. ASL neither sets nor enforce these limits, it just reports when the operating system has been configured with a limit, when the limit has been exceeded, and if the operating system has prevented an application from exceeding a limit.
Normal Linux kernels do not report when limits are exceeded. This special reporting capability in ASL makes sure you know when your operating system is enforcing one of these limits. With other kernels, you will have no notice that your OS has preventing something working because you have exceeded a limit on your operating system. However, regardless of what kernel you are using your operating system will still enforce whatever limits you have configured it to enforce, regular kernels just wont tell you that you have exceeded some limit configured in your OS.
Please contact your OS vendor for instructions about how to configure your systems limits. You may also need to contact your application vendor with specific questions about why a particular limit is inappropriate for your application, and what they recommend you set the limit to.
grsec: banning user with uid xx until system restart for suspicious kernel crash
This means a process did something very bad to the kernel and could be an attack on your system.
This message is generated via a special exploit protection feature in the ASL kernel. When a kernel protection alert is triggered due to highly suspicious activity in the kernel (from KERNEXEC/UDEREF/USERCOPY, not just any event) or an OOPs occurs due to bad memory accesses, instead of just terminating the offending process (and potentially allowing a subsequent exploit from the same user), the kernel will take one of two actions:
- If the user was root, this will lock out the system - if this is happening with root, very bad things are happening on the system.
- If the user was non-root, ASL will log the attempt, terminate all processes owned by the user, then prevent them from creating any new processes until the system is restarted.
This deters repeated kernel exploitation/bruteforcing attempts and is useful for later forensics.
kernel: grsec: chdir to
If you are using the ASL kernel, means that you have enabled this option in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#AUDIT_CHDIR
This option is not enabled by default, and we do not recommend you enable this option if you do not know what you are doing.
If you are using a third party kernel, please contact the vendor of that kernel for assistance. It is possible they have enabled this by default in their kernel. ASL does not enable this by default.
grsec: From xx.xxx.xxx.xxx: use of CAP_SYS_ADMIN in chroot denied
This means that an application within a chroot tried to use the SYS_ADMIN linux capability. This means the application is trying to do things that would allow the application to escape the chroot. Denying applications in a chroot this capability prevents them from escaping the chroot and prevents them from compromising the system. Allowing them to have this capability means that the chroot essentially does not exist, as the application can just request root level privileges it wants, and can simply move outside the chroot.
Allowing applications within a chroot to have this capability is extremely dangerous and should not be granted.
However, if you need to open this hole in your system please disable this protection in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#CHROOT_CAPS
WARNING: Disabling this protection will make it possible for applications to escape chroots. See this article for more information:
https://forums.grsecurity.net/viewtopic.php?f=7&t=2522
grsec: denied untrusted exec of /path/to/some/application
See below.
grsec: denied untrusted exec
The application is not being allowed to run because ASL is configured to prevent it from running.
Specifically, ASL includes a feature called Trusted Path Execution. When Trusted Path Execution (TPE) is fully enabled (which is the default), it will only allow applications owned by root to run on the system that are not modifable by any other user except root. This protects the system from malicious software that may try to change these applications or to replace them with malicious versions. We do not recommend you disable TPE.
If you get this message, that means the application is owned by an untrusted user. This helps to prevent untrusted users from uploading software to the system, which could include trojans, malware and rootkits. This also prevents untrusted users from changing applications, replacing them with a trojan or otherwise tampering with them. By default the only trusted user on the system is root. If you have an application (or an application in a directory) owned by an untrusted user ASL will not allow it to be executed. You can tune ASL or the application to allow it to run by using one of the four documented methods below. They are in order or most secure to least secure:
Option 1. Change the ownership of the file and its directory, and parent directories to root.root and make sure the file and ensure directory it is in are not writable by other users (including the root group). Here is an example you will need to adapt to your system:
Note: If you do not know what is meant by changing a files ownership to root.root, please contact a qualified system engineer to do this for you. root.root means the user and group must be root. These are example commands to achieve this:
chown root.root /path/to/directory/of/application chown root.root /path/to/application chown root.root /path/to/ chown root.root /path/ chroot root.root / chmod -R og-w /path/to/application
Always make sure the parent directories are also owned by root:root. This is the most common issue, some broken applications are known to change key operating systems directories ownership from root:root to something else. We've even seen cases where someone changed the ownership of / to something other than root. Thats extremely dangerous and something else thankfully will protect the system from.
For example, here is an application that will not run with TPE in the fully secure mode because the directory is not set to root.root nor is the application:
drwxrws--- 2 psaadm swkey-data 4096 May 8 02:32 restart -r-s--x--- 1 root swkey-data 9240 May 4 05:58 plesk-key-handler
In this example, the directory is owned by psaadm and swkey-data. These are not set to the root user, so the kernel in the fully secure TPE mode will will not trust this application to run because those users could modify, replace or otherwise tamper with this application and are not trusted by the kernel. To get these applications to run (and you will need to discuss this with your application vendor if the application can run in such a secure manner) the directory and application would need to be owned by the root user and the root group, and must be writable only by the root user (not the root group).
If you can not set an application to run correct as root.root, then you need to configure ASL into a less secure mode. This also means that you will need to accept the risk of running your application and system in a less secure and protected mode. To do this, simply configure ASL to be less secure using options 2-4. This situation is rare, and only a few vendors seems inclined to run their applications in this less secure manner.
In some cases, you can work around this by moving the application to a trusted directory and making sure the directory it is in is owned by root.root. For example, for a setuid script owned by "testuser":
[testuser2@ac2 ~]$ pwd /home/testuser2 [testuser2@ac2 ~]$ id uid=510(testuser2) gid=510(testuser2) groups=510(testuser2) [testuser2@ac2 ~]$ cat ~testuser/sensitive_file cat: /home/testuser/sensitive_file: Permission denied [testuser2@ac2 ~]$ /usr/local/trusted_apps/special_cat ~testuser/sensitive_file This data can only be read by setuid [testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/special_cat -rwsr-xr-x 1 testuser testuser 23132 Dec 17 19:45 /usr/local/trusted_apps/special_cat
As you can see from this example, there is a setuid program called special_cat (its a copy of /bin/cat in this example) that is setuid to testuser. testuser2 tried to open the file ~testuser/sensitive_file with "cat", but can not because testuser2 must use the setuid program "/usr/local/trusted_apps/special_cat" to read those files.
The key to making this work with the secure ASL kernel is to ensure that the directory in which the application is place must be owned by root.root, and the application itself can still be owned by the untrusted user "testuser":
[testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/ total 36 drwxr-xr-x 2 root root 4096 Dec 17 19:53 . drwxr-xr-x 12 root root 4096 Dec 17 19:53 .. -rwsr-xr-x 1 testuser testuser 23132 Dec 17 19:45 special_cat
This helps prevent malicious users from uploading programs to the system that you do not want because nothing can be added to that directory except by root. This also helps to prevent users from running programs you don't trust in ways that can compromise the security of your system, such as with spam bots or tools to compromise your system such as malware. The key is to make sure no one can modify the file except the user that owns it, and that the file is in a directory that only root can modify or place new files in. This helps to prevent path poisoning attacks and uploading of malicious software to your system.
Again, if you do understand how to do any of these tasks, please contact a qualified systems administrator to do this for you.
Option 2: Change ASLs behavior so that this restriction only applies to untrusted users. You can do that by turning off this feature, called Trusted PAth Exectuion (TPE) so that it only applies to users in the "untrusted" group:
echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all
Keep in mind that this is considerably less secure than option 1. This means all the users on your system, except users in the "untrusted" group, will be trusted unless you specifically tell ASL not to trust them. You can see a listing of untrusted users by running this command as root:
grep untrusted /etc/group
The standard list of untrusted users currently is:
untrusted:x:1005:lp,sync,shutdown,halt,mail,news,uucp,operator,games,gopher,ftp,nobody,vcsa,nscd,sshd,rpc,rpcuser,nfsnobody,mailnull,smmsp,pcap,apache,xfs,ntp,mysql,webalizer,named,alias,qmaild,qmaill,qmailp,qmailq,qmailr,qmails,popuser,psaadm,psaftp,mailman
There are system users, that is users that programs run as. We do not recommend you change these users.
NOTE: You can only change this proc setting (/proc/sys/kernel/grsecurity/tpe_restrict_all) on boot if you have configured ASL to lock the kernel (the default setting is to lock the kernel). Once the boot process reaches stage S99 the kernel is locked and you can not change the security settings. So you will need to set this on boot via a custom init script.
If you want to set an ASL kernel setting, such as /proc/sys/kernel/grsecurity/tpe_restrict_all (or any other), you will need to create a custom init script such as:
/etc/init.d/asl-custom
A simple script to do this would look like
#!/bin/bash echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all
Then you will need to link it depending on the runlevel your system is set as. If you do not know what this means, please consult an experienced Linux administrator. Most systems are set to run at run level 3.
ln -s /etc/init.d/asl-custom /etc/rc3.d/S98asl-custom
init is not part of ASL, its part of your operating system, and if you have additional questions about how to configure your operating system or how to write init scripts please contact your operating system vendor. You can read our primer on customizing your kernel in the Installing custom kernel modules with ASL wiki article. This includes a primer on init.
And last but not least, you need to set the script to be executable in Linux. To do that, as root, you need to run this command:
chmod u+x /etc/init.d/asl-custom
Option 3. Remove the user from the untrusted group in /etc/group (we do not recommend you do this).
If your application is running as an untrusted user, you can change the configuration of ASL to trust this user. The default users are system processes such as apache that should NEVER be trusted by the system. This makes it easy for an attacker to upload a trojan to the system. However, if you must run an application in insecure manner as apache then you would remove that user from this group. ASL will not be able to protect the system from uploaded trojan by this user.
Option 4: Turn off all TPE protections (not recommended and very insecure)
This option completely disables the TPE system and makes it possible for any user to upload anything and run it on the system. Although ASL does have real time malware detection and protection this system is not 100% foolproof and disabling TPE is extremely insecure and will make it possible for an attacker to upload malicious code to your system that even ASL may not be able to detect and then run it.
To disable TPE you will need to change this proc setting:
/proc/sys/kernel/grsecurity/tpe
To "0"
echo 0 > /proc/sys/kernel/grsecurity/tpe
This also must be done on boot as with option 3.
If you are unsure of how to do any of these custom things on your system please contact us. Our professional services team would be happy to help you configure your custom applications for your system.
GRsecurity ACL database: not found [INFO]
This simply means you do not have any GRSEC rules set. This is just an information alert and does not mean anything is wrong with your system.
denied RWX mmap of
This means this program is attempting to either perform a dangerous operation, that could cause your system to be compromised, or someone is trying to break into your system and the ASL kernel is preventing this program from doing this.
This may also occur with malicious applications, or very vulnerable applications.
solutions
1) Most Secure
Fix the application so it does not need to open this hole in your system.
2) Secure
In some cases it may be possible to tell the application to not try to open this hole in your system. As root, run this command:
execstack -c /path/to/application_or_library
Example:
execstack -c /opt/dell/srvadmin/sbin/dsm_om_connsvcd
If this does not work, your application may require that this hole be opened in the system. Therefore see Option 3 below.
3) Very Insecure
Warning: Always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious backdoored copy!
To allow an application to open this hole in your system, run this command as root:
paxctl -m /path/to/application_or_library
Example:
paxctl -m /opt/dell/srvadmin/sbin/dsm_om_connsvcd
Note: See the article https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Note_on_vulnerable_libraries for guidance on finding vulnerable libraries that attempt to open this hole in your system.
does not have a PT_PAX_FLAGS program header, try conversion
Run this command:
/sbin/paxctl -c /path/to/your/application
mprotect(): 13 (Permission denied)
Examples:
01:01:01 host kernel: grsec: From 1.2.3.4: denied RWX mprotect of /lib64/ld-2.5.so by /usr/local/cpanel/3rdparty/php/53/bin/php-cgi[php-cgi:25915] uid/euid:32003/32003 gid/egid:32003/32003, parent /usr/local/cpanel/cpsrvd-ssl[cpsrvd-ssl:25913] uid/euid:32003/32003 gid/egid:32003/32003
discussion
This means an application is trying to do something dangerous on your system. Specifically, the ASL kernel protects your system by restricting the mprotect() system call which makes it difficult for an attacker to bypass stack protection systems. This makes it impossible for an attacker to change protection of a specific memory region, for example to mark it as executable if it wasn't originally executable, or to create a new writeable and executable memory mapping using the mmap() call. Without this feature, all the "Stack Protection and "non-executable memory regions" security features used today are more or less useless, as the attacker just change the permissions on your Stack protection to allow them to compromise the system. Unlike other systems, ASL protects you from this vulnerability.
This protection in the ASL kernel is critical to making stack protection meaningful. Therefore, if encounter this message, the application has been stopped from doing something very dangerous to your system. It may not be trying to compromise it, but it is making it much easier for an attacker to compromise your system in the future if it were allowed to do this. Therefore, you should carefully consider if you want to allow an application to do this. If you allow an application to do this you are opening your system to stack and heap based attacks through that application.
It is important then to ensure that your your application absolutely needs this capability, and that if it does and you want to allow it that you can trust the application, and that you are certain that the application is not going to be used by an attacker to compromise your system.
Applications that work with untrusted data, such as scanners and servers shouldn't be allowed to do this unless you know that they have no other vulnerabilities associated with this issue.
solutions
1) Most Secure
Fix the application so it does not need to open this hole in your system.
2) Secure
Remove the flag from the library that is trying to open this hole in your system. As root, run this command:
execstack -c /path/to/application_or_library
3) Very Insecure
Warning: Always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious copy.
To allow an application to open this hole in your system, run this command as root:
paxctl -m /path/to/application_or_library
Note on vulnerable libraries
In some cases, such as with PHP, you may need to use strace to find the specific library that is opening this hole in your system as your application may not be trying to open this hole in your system. You can do this by running this command as root:
strace -fF /path/to/app
Example:
strace -fF /usr/local/cpanel/3rdparty/php/53/bin/php-cgi
Will produce a very verbose output as strace tells your what the application is doing. Once the application is prevented from opening this hole in your system it will stop running. Therefore, you want to look at the final output of the strace, which in the case of the example above will look similar to this:
open("/usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\33\3\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1082328, ...}) = 0
mmap(NULL, 2145168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x6ad6faf57000
mprotect(0x6ad6fb042000, 1048576, PROT_NONE) = 0
mmap(0x6ad6fb142000, 118784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xeb000) = 0x6ad6fb142000
mmap(0x6ad6fb15f000, 15248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6ad6fb15f000
mprotect(0x6ad7081c1000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)
Whats important to note is that the library "/usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so" is trying to open a hole in tje system and ASL is stopping it:
mprotect(0x6ad7081c1000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)
In some cases this may be a root level hole which will cause the entire system to be compromised.
To prevent the application from opening this hole in your system, run this command as root:
execstack -c /usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so
To allow it to open this hole in your system you will need to tell ASL to let this application make your system vulnerable to a compromise via this hole for this application or library. We do not recommend you open this hole. Its rare that an application needs to do this, so we recommend you close it, and then test your application to see if it works properly. If it does work properly you do not need this hole opened in your system.
Warning: Before you allow an application to open this hole, always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious copy.
paxctl -m /usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so
grsec: denied RWX mprotect
If you see log messages that involve the ASL paxtest application suite, for example:
grsec: denied RWX mprotect of /usr/libexec/paxtest/shlibtest2.so
This is harmless, please see this FAQ:
For all other applications, please continue reading:
If you see log message like this:
Jan 1 12:00:00 server kernel: grsec: denied RWX mprotect of /lib64/ld-2.12.so by /usr/local/cpanel/3rdparty/php/53/bin/php-cgi[php-cgi:3726] uid/euid:0/0 gid/egid:0/0, parent /usr/local/cpanel/bin/admin/Cpanel/logaholic[logaholic:3715] uid/euid:0/0 gid/egid:0/0
This means an application is trying to do something dangerous on your system, and ASL is preventing it from doing this. This could be an attempt to compromise your system or simply a very vulnerable or poorly constructed application thats operating in a dangerously insecure manner, which would allow users to do bad things to your system including compromising it. You should report this as a vulnerability to the application developer.
If you want to allow this application to do this dangerous thing on your system, you can configure ASL to allow this. Continue reading if you wish to open this hole ASL is alerting you to:
Explanation
Specifically, ASL protects you system by restricting the mprotect() system call which makes it difficult for an attacker to bypass kernel stack protection systems used on Linux systems. Normal Linux kernels do not protect against this, so its trivially easy to beat the stack protection systems they use, and attackers know this.
This protection makes it impossible for an attacker to change protection of a specific memory region, for example to mark it as executable if it wasn't originally executable, or to create a new writeable and executable memory mapping using the mmap() call. Without this feature, all the "Stack Protection and "non-executable memory regions" security features used today are more or less useless, as the attacker can just change the permissions on your Stack protection to allow them to compromise the system. Unlike other systems, ASL protects you from this critical vulnerability.
This protection in the ASL kernel is critical to making stack protection meaningful. Therefore, if you encounter this message, the application has been stopped from doing something very dangerous to your system. It may not be trying to compromise it, but it is making it much easier for an attacker to compromise your system in the future if it were allowed to do this. Therefore, you should carefully consider if you want to allow an application to do this. If you allow an application to do this you are opening your system to stack and heap based attacks through that application and no amount of kernel protection will protect you. It is also not necessary for applications to do this with modern programming techniques, and is rarely seen and never with properly developed applications.
It is important then to ensure that your your application absolutely needs this capability before you open this hole in your system. If it does and you want to allow iit do this, this means that you are completely trusting the application, and you should only do this if you know the application can never be used to compromise your system.
Applications that work with untrusted data, such as log processing tools, data scanners (virus and antispam) and application daemons should never be allowed to do this.
solutions
See the article https://www.atomicorp.com/wiki/index.php/ASL_FAQ#solutions_2 above.
kernel: grsec: From x.x.x.x: denied ptrace of
The ASL kernel includes countermeasures to prevent ptrace exploitation. It has always had this capability as part of the RBAC system. In newer versions of ASL a capability has been added to make this protection global so that you do not have enable, or develop policies for the RBAC system. Some rare applications may need to perform ptrace operations that will trigger this protection, exploits can also trigger this so its best to investigate if this behaviour is normal.
Solution:
First ensure that this behaviour is expected and non-malicious for your application. If your application must do this, you will need to disable global ptrace protection. To do this, you will need to set this condition as part of your /etc/sysctl.conf file:
kernel.grsecurity.harden_ptrace = 0
ASL normally locks all grsecurity settings so they can not be reset during runtime, unless you have disabled this safeguard (not recommended, this makes it possible for an attacker to disable all your ASL kernel security settings) you will also need to reboot the system for this change to take effect. sysctl will not change grsecurity kernel settings if the kernel is in its secure and default state.
If you still wish to restrict ptrace capabilities, but wish to only allow it for your application, you will need to enable the RBAC system and configure a policy for your system. this is an advanced task, and will require tuning the policy for your unique system and needs. ASL can auto-generate a complete starter policy for the system, but you must configure it manually to meet your needs as ASL will develop a least privilege policy for the entire system. This means that during the learning period you define only the behavior that occurs during that period will be allowed. This has the added advantage of being very easy to develop a very secure policy for the system, and the disadvantage of creating a very secure policy for the system. In practice, you will want to further tune the policy based on your needs, as the policy generate will be least privilege for every aspect of the system. For further information about the self learning RBAC, please see this article
NOTE: Plesk requires that this protection be disabled. Please contact Parallels for a full explanation for why that product requires this protection to be disabled.
kernel: grsec: denied ptrace of /usr/bin/sw-engine-cgi
Parallels tries to prevent users from debugging certain Parallels products. It does this by trying to ptrace itself to detect a debugger. The ASL kernel contains protections to prevent ptrace exploits, and controls which users can use this function call. The kernel will block this function, and the Parallels products does not correctly catch this condition, and instead erroneously reports this as the user running a debugger. This is a bug in Parallels products.
If you are using a version of Plesk that has this bug, and there is no fix available from Parallels for this bug, please follow this process to disable this protection on your system.
Note: This workaround is for those users that want to run Parallels products with this bug. This will require you to disable this protection in your kernel. This will be correctly reported as a vulnerability in the system.
To disable ptrace exploitation protection:
When running ASL 3.0 and up simply log into ASL, click on the Configuration tab, and select the "ASL Configuration" menu option.
Then scroll down to Kernel
And change the "HARDEN_PTRACE" entry from "yes" to "no". If you kernel is set to lock itself on boot (this is the default), you will need to reboot your system for this setting to take effect.
If you are not running ASL 3.0, please add this to your/etc/sysctl.conf file:
kernel.grsecurity.harden_ptrace = 0
And reboot the system.
grsec: process /usr/bin/foo attached to via ptrace by
This is an informational message and can be ignored. ASL will log ptrace activity to help you detect any potentially malicious ptrace actions. To disable this logging run this command as root:
echo 0 > /proc/sys/kernel/grsecurity/audit_ptrace
You will need to set this to occur on boot, or add this to your/etc/sysctl.conf file:
kernel.grsecurity.audit_ptrace = 0
And reboot.
error: unknown error 22 setting key
When running sysctl -p this error occurs:
error: unknown error 22 setting key 'some.sysctl.setting'
Explanation:
By default the ASL kernel doesn't allow allow certain security parameters in the kernel to be modified. This prevents attackers from disabling kernel protections, such as stack protections and allowing the kernel to be modified on the fly. If you wish to modify these security settings, there are two options:
1) Set these security kernel settings and reboot the system.
2) Configure ASL to allow your kernel to be modified at any time.
This is NOT recommended. Allowing kernel security settings to be changed on a running system makes it possible for an attacker to disable ASL kernel level protections, to install rootkits and to otherwise compromise the security of the system. This is similar to allowing a user to disable antivirus on the system, if a user can disable antivirus so can a virus. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this as occurred. We highly recommend you set any kernel security settings you need, reboot the system and let ASL lock the kernel.
If you wish to use to make your kernel insecure and to allow these security settings to change on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.
insmod: error inserting /path/to/module -1 Operation not permitted
See the below FAQ, modprobe: FATAL: Error inserting somemodule (/path/to/module.ko): Operation not permitted.
modprobe: FATAL: Error inserting somemodule (/path/to/module.ko): Operation not permitted
Solution:
By default the ASL kernel will prevent the loading of new kernel modules into the kernel, during runtime, once the system has booted up. It will allow kernel modules to be loaded during boot, but once your system has finished the boot up process, when ASL will allow you to load kernel modules, ASL will then lock the kernel preventing any new kernel modules from being loaded into the kernel. This is to protect the kernel from kernel level rootkits, as it prevents hackers from modifying your kernel and hiding rootkits and malware on your system. Runtime kernel module loading is very dangerous, isnt something most users need, and its extremely unusual to require on a server. We do not recommend you disable this protection.
You have two options if you are using this protection. These are listed in order of secure to insecure.
1) (Secure Option) Set the modules to load at boot and reboot your system.
This article: Installing custom kernel modules with ASL provides more information about setting up custom modules to load before ASL locks the kernel down.
2) (Insecure Option) Configure ASL to allow your kernel to be modified at any time.
This is NOT recommended.
Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this has occurred or to remove the rootkit. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if kernel module loading is prevented at runtime.
If you wish to configure your kernel to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.
Warning: cannot open /proc/net/dev
Question:
Unprivileged users can not open the full proc table, and when I tun top or when I run ifconfig I do not see all the information.
Answer:
ASL contains additional safeguards to prevent non-privileged users from reading the full proc table. If you wish to allow a user to see the full proc table, simply add the user to the "procread" group in your /etc/group file and this safeguard will be disabled for that user.
If you do not know how to add users to a group in Linux, or how to edit your /etc/group file, please contact your OS vendor for assistance.
Example
error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied
This means that you have an application installed with a serious vulnerability. The Secure ASL kernel is preventing this application from opening a hole in your system.
Some application developers may configured their applications insecure to use what is referred to as an "executable stack". An executable stack allows an attacker to inject raw code into your system, bypassing your operating systems entire security model. This is a well known and widely used method of compromising systems completely.
Configuring an application in this manner dangerously opens your system to full compromise. Very few, if any applications actually require this insecure state to operate, and often times configuring applications in this manner is done by the application developer in error. You can reconfigure these applications to not do this by following the process below.
The ASL kernel protects you from this dangerous mistake by not allowing these applications to configure your system into this extremely insecure condition.
There are three options for dealing with this critical vulnerability, from most secure to least secure:
Option 1: (Most secure option)
ASL will not allow these applications to punch holes in your system, and running the command below will remove that label from the application so it will run properly and securely.
execstack -c /path/to/application
Sometimes vendors will do this to the libraries the application uses, and not the binary calling it. If you see a log message with a ".so" in it, that indicates a library has been insecurely configured by your vendor. Here is an example:
'error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied'
In which case you may have to remove this vulnerablity from the library itself. You can do this by using the "execstack" comannd and the "-c" switch, which stands for "clear". This command will remove the setting, or clear it, from the application that is causing this critical vulnerability. For example:
execstack -c /opt/splunk/lib/libcrypto.so.0.9.8
If you aren't sure which binary or library has the stack execute bit set, you can run this command to query the file:
execstack -q /opt/splunk/lib/libcrypto.so.0.9.8
If you see this:
- /lib/libcrypto.so.0.9.8e
The "-" means that file is safe, and does not have the stack execute bit set, in which case the binary calling the library is the likely culprit and you would want to query that file and remove the flag from it.
If you see this:
X /opt/splunk/lib/libcrypto.so.0.9.8
The X means stack execution is allowed, which also means X marks the spot for attacking your stack - which ASL will not allow. To close the vulnerability in the above example, remove the stack execute flag from the library by running this command as root:
execstack -c /opt/splunk/lib/libcrypto.so.0.9.8
We also recommend you contact your application vendor and ask them to remove these flags from their applications. They are not necessary with modern Linux kernels, and are bad and unsafe practices which will expose your system to compromise if you are not running ASL. If you are running ASL, you will need to reconfigure these applications per the instructions here.
Option 2:
Some applications require this vulnerable condition during installation. If you are unfortunate enough to have one of those applications, and the application vendor is not willing to fix their application, reboot the system into a non-secure kernel (a non ASL kernel) and install your application. Then reboot the system into the ASL kernel and follow the instructions in Option 1 to fix the vulnerable applications.
Option 3: (Insecure option)
We do not recommend you use this option.
It is possible to disable all stack protection in the ASL kernel so that it will not be enforced by default and only on executables marked explicitly. No executables are marked in this manner by ASL by default, as by default ASL automatically protects all executables. If you wish to use this option you will need to mark the executables you wish to protect.
Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various kernel protection features at runtime via the entries in /proc/sys/kernel/pax.
iptables: Unknown error 18446744073709551615
Issue:
iptables: Unknown error 18446744073709551615
Solution:
This error is not caused by ASL. There are two causes to this, one is an out of date version of iptables that is not fully compatible with your kernel. Your solution is to upgrade iptables to at least version 1.4.7.
The other cause for this error is that an iptables module is not loaded into the kernel, or that the module is no longer part of netfilter. Netfilter is the actual firewall in Linux and it does change. Older firewall scripts may require modules that no longer exist in Linux. iptables is just the command line tool that interacts with Netfilter. If you get an iptables error such as this one that means iptables tried to do something that netfilter either does allow or does not understand (you dont have that module loaded). On VPSs this can occur if the host kernel does not have the module loaded as VPSs do not control the kernel and therefore can not load any additional iptables modules dynamically.
The solution is to find out what module is missing. Unfortunately iptables won't tell you what module it may need, so we recommend you contact the party that created your firewall script or tool for assistance.
iptables: Unloading modules: iptable_mangle iptable_nat [FAILED]
When using the secure kernel in the default and secure mode, modifications to the kernel are not allowed. This includes loading and unloading modules.
This error is benign and you can ignore this.
kernel: ASL Active Response
This is a normal message that ASL will log if an IP addressed has been shunned, or firewalled off by ASL. This will occur if you have configured ASL's Active Response to "yes", and an event is triggered that exceeds the minimum event level threshold you have configured. Once that occurs ASL will log if any additional network traffic comes from that host, and it will limit this to one log message per minute for that IP address to prevent flooding of the systems logs.
grsec: denied kernel module auto-load of net-pf-10
Thats not an error, that means something on your system is trying to enable IPv6, you have IPv6 disabled on boot and ASL is configured to prevent modifications to the kernel after boot. By default the ASL kernel doesn't allow loading kernel modules at runtime to protect the system from kernel level rootkits. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system.
4 options to resolve this in order of most secure to least secure:
1) Ignore the message - it is harmless and no harm will come to your system from this message
2) If you do not want to enable IPv6, find the application and disable whatever in the application is trying to enable IPv6 dynamically
3) Enable IPv6
4) Configure ASL to allow your kernel to be modified at any time.
Options 2 and 3 you will need to discuss with your OS vendor, those are not part of ASL and are not supported by us.
Option 4, this option is NOT recommended. Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect, remove and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you to even detect that this as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.
If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this as critical vulnerability in the system.
kernel: grsec: denied resource overstep by requesting
The kernel is reporting that you have configured your system to deny a resource change in an application. The ASL kernel does not cause this, it just reports it. A non-ASL kernel, such as the default kernel used in most versions of Linux, does not have the ability to report when this occurs (the application just silently fails without any log message).
denied modification of module state
This means that you have configured ASL to protect your kernel from any changes. This is the default setting for ASL, and prevents attackers from inserting malicious code into your kernel. Dynamic modifications to running kernels are dangerous, and many operating system prevent this now (such as 64 bit Windows, and Windows Server.). If you wish to open this hole in your system please see the article #Can't install kernel modules.
denied use of iopl() by
ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by logging into the ASL GUI, click on the Configuration tab, then select ASL configuration. Scroll down to DISABLE_PRIVILEGED_IO and set this to "no". Then press the update button.
If ASL is configured to prevent changes to the kernel during run time, that is the setting ALLOW_kmod_loading is set to no (this is the default, and recommended setting), then you will need to reboot the system for this change to be applied to the system. We do not recommend you change ALLOW_kmod_loading to yes, that will open your system up to kernel level rootkits.
Or you can appending this to /etc/sysctl.conf
kernel.grsecurity.disable_priv_io = 0
And reboot your system.
grsec: denied open of /dev/port
ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by appending this to /etc/sysctl.conf, and rebooting your system:
kernel.grsecurity.disable_priv_io = 0
mysql errors/messages
Can't connect to MySQL server on '127.0.0.1'
This means that OSSEC can not connect to mysql on your system. OSSEC, a component in ASL, uses TCP to connect to your mysql server. Configure mysql to listen on port 3306 on 127.0.0.1 on your system.
Step 1. Check to make sure mysql is running, and that its listening on IP address 127.0.0.1.
To check if mysql is running, run this command as root:
ps auxwww | grep mysql
You should see a similar result to this:
root 17813 0.0 0.0 65988 852 ? S Mar19 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql mysql 17930 0.5 6.5 551972 264788 ? Sl Mar19 116:55 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
If you do not see a result similar to this, mysql is not running on your system. Start mysql. If you require assistance with mysql, please contact your Operating System or database vendor. If you have neither, please post in the community support section of our forums.
Also check to make sure mysql is listening on TCP port 3306 and IP address 127.0.0.1:
netstat -anp | grep 3306
A correctly configured mysql will look similar to this:
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5543/mysqld
Or this:
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 5543/mysqld
If you do not see either 0.0.0.0 or 127.0.0.1 in the fourth column then you may have mysql configured to listen on a specific IP address. You have two choices:
Option A) Configure mysql to listen on all addressed
Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:
/etc/init.d/mysqld restart
Option B) Configure ASL to connect to mysql on a different IP address
Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.
Step 2. Make sure you dont have "skip-networking" in you /etc/my.cnf file.
Check for the line "skip-networking" in your /etc/my.cnf file:
grep skip-networking /etc/my.cnf
If you have this line, remove that line from /etc/my.cnf and save the file.
Restart mysql and restart OSSEC. Run these commands as root:
/etc/init.d/mysqld restart
/etc/init.d/ossec-hids restart
Check to make sure mysql is listening:
netstat -anp | grep 3306
A correctly configured mysql will look similar to this:
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5543/mysqld
Or this:
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 5543/mysqld
If you do not see "tcp" in the first column, and LISTEN in the fifth mysql is not configured to listen for TCP connections.
If you only see any entry like this:
unix 2 [ ACC ] STREAM LISTENING 38593710 /var/lib/mysql/mysql.sock
mysql is not configured to listen on a TCP port.
Step 3: check to make sure mysql is listening on port 3306 and IP address 127.0.0.1:
A final test to see if mysql is listening on loopback is to telnet, from the system that mysql is running on (not from a remote system), to the loopback interface:
telnet localhost 3306
You should see something like this:
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 4 5.0.77>
If you can not connect to mysql, check to make sure that you do not have any lines in /etc/my.cnf that contain "bind-address". If you do:
Option A) Configure mysql to listen on all addressed
Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:
/etc/init.d/mysqld restart
Option B) Configure ASL to connect to mysql on a different IP address
Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.
Step 4. If mysql is listening on port 3306 and on 127.0.0.1, and you still can not connect to it on loopback (127.0.0.1)
This is most likely caused by local firewall rules. Disable your firewall to see if you can connect to mysql:
/etc/init.d/iptables stop
If you can connect to mysql, then your firewall rules need to be adjusted to allow connections to mysql on localhost. Please see the ASL_firewall documentation.
Step 5: Your mysql credentials may be invalid.
Please see the FAQ, Access denied for user 'tortix'@'localhost' (using password: YES), below to reset your mysql credentials.
The server requested authentication method umknown to the client
See the ASL 3.2 release notes:
https://www.atomicorp.com/wiki/index.php/Atomic_Secured_Linux#MySQL
mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication.
See the ASL 3.2 release notes:
https://www.atomicorp.com/wiki/index.php/Atomic_Secured_Linux#MySQL
MYSQL reports a table is "is marked as crashed and should be repaired"
This error is not caused by ASL. That means mysql was not shut down cleanly or that it crashed. You may have other crashed databases.
The server requested authentication method umknown to the client
See the ASL 3.2 release notes:
https://www.atomicorp.com/wiki/index.php/Atomic_Secured_Linux#MySQL
This error is not caused by ASL. That means mysql was not shut down cleanly or that it crashed. You may have other crashed databases. Please follow the process documented by mysql to repair a crashed database.
The follow are some links to get you started:
For mysql 5.0:
http://dev.mysql.com/doc/refman/5.0/en/myisam-repair.html
For mysql 5.1:
http://dev.mysql.com/doc/refman/5.1/en/myisam-repair.html
For mysql 5.5:
http://dev.mysql.com/doc/refman/5.5/en/myisam-repair.html
===== Option 1 =====
If this involves one of ASLs tables, we have added in logic to the database rotation system to try to fix crashed tables. This method is not fool proof.
As root, not via sudo, run this command:
/var/asl/bin/asl_db_rotate
That will trigger the message from MySQL that the table is crashed:
ASL DB Rotate: Locking failed - Table './tortix/data' is marked as crashed and should be repaired
That will then trigger a self healing event in ASL to fix the table, if possible. Keep in mind that if MySQL was shut down incorrectly or crashed, MySQL tables can be severly corrupted and this Self Healing method may not work. If it does work, you will see an event "60912" in your /var/ossec/logs/self-healing.log log file. You can search for this event with this command:
grep "tortix.data repair" /var/ossec/logs/self-healing.log
If the Self Healing event worked, your output will look similar to this:
Table Op Msg_type Msg_text tortix.data repair note
If you do not see any events, or if the table is still marked as crashed, then the Self Healing method was not successful because the MySQL table is severely corrupted. See Option 2 below for other methods to repair a corrupt MySQL database.
Option 2
If Option 1 does not work or if a non-ASL table is crashed please follow the process documented by mysql to repair a crashed database.
The follow are some links to get you started:
For mysql 5.0:
http://dev.mysql.com/doc/refman/5.0/en/myisam-repair.html
For mysql 5.1:
http://dev.mysql.com/doc/refman/5.1/en/myisam-repair.html
For mysql 5.5:
http://dev.mysql.com/doc/refman/5.5/en/myisam-repair.html
OSSEC
OSSEC directories
/var/ossec/queue/diff/local
This directory is used to store "diffs" of files that have changed, and that the user has configured ASL to monitor. "diffs" are special files that record the differences between changes to a file. ASL will report these differences when a monitored file has changed. This allows the user to both be notified that a change as occurred, which may not be authorized, and to also see the specific changes that have occurred to the file compared with a previous version.
OSSEC messages
ERROR: Cannot open GeoIP database: '/etc/GeoIP.dat'.
You can ignore this message. This feature is not currently used and this message is expected when events occur. The message is harmless and you can ignore it.
OSSEC-dbd Reports: Lost connection to MySQL server during query
This indicates that the timeout parameter for mysql is either too short, or the database server is under considerable load. To increase the timeout period:
1) Edit /etc/my.cnf
2) Add or modify the "wait_timeout" variable
[mysqld] wait_timeout=28800 interactive_timeout = 28800
3) restart mysql
/etc/init.d/mysqld restart
ERROR: Queue '/queue/alerts/ar' not accessible: 'Connection refused'.
OSSEC is a cross platform system.
If this error message is generated when OSSEC is run on a non-Windows platform, you can safely ignore this message. This simply means the Windows AR queue is not available, which is expected with run on a non-Windows system.
ERROR: Unable to connect to active response queue.
OSSEC is a cross platform system.
If this error message is generated when OSSEC is run on a non-Windows platform, you can safely ignore this message. This simply means the Windows AR queue is not available, which is expected with run on a non-Windows system.
Active response command not present: '/var/ossec/active-response/bin/restart-ossec.cmd'.
OSSEC is a cross platform system.
If this error message is generated when OSSEC is run on a non-Windows platform, you can safely ignore this message. This simply means the Windows AR command, restart-ossec.cmd, is not installed on the system. Which is expected on non-Windows platforms.
ERROR: Error executing query 'SELECT id FROM location WHERE name = 'host->/var/log/mysqld.log' AND server_id = '1' LIMIT 1'. Error: 'MySQL server has gone away'.
This generally means that mysql is either misconfigured or under heavy load. The most likely scenario is that the maximum number of connections that mysql will allow has been exceeded. Please increase the maximum on your system. You can do that by increasing "max-connections" in your mysql configuration, which is normally stored in /etc/my.cnf.
Other misconfigurations of mysql can also cause it "go away", which means that mysql has killed the connection. Check your mysql error logs and contact your OS or database vendor for additional support. A misconfigured database will have other effects on your system, and if ASL is unable to communicate successfully with your database your system has serious problems with the database.
Also, check your mysql logs to make sure you don't have any errors, a corrupt database can also cause this to occur.
ERROR: Error connecting to database 'localhost'(ossec): ERROR: Unknown MySQL server host 'localhost' (3).
This means that your system does not know what the IP address for "localhost" is. This is a default special server name that all systems use to refer to themselves, and the IP address for localhost is 127.0.0.1. Check your systems /etc/hosts file and ensure you have an entry for localhost. Below is an example of a localhost entry:
127.0.0.1 localhost.localdomain localhost
Also check the permissions on your /etc/hosts file to ensure that it is world readable. A correct configured systems /etc/hosts file will have the following permissions:
-rw-r--r--. 2 root root 866 Mar 31 18:26 /etc/hosts
If this does not work we recommend you use "127.0.0.1" as this would indicate that something is wrong in your OS that is preventing OSSEC from resolving localhost, and is beyond the scope of what we support.
Could not establish mysql connection
Please see the FAQ Can't connect to MySQL server on '127.0.0.1 below.
Starting ossec-hids: [FAILED]
Please see the article below:
Command executed: /sbin/service ossec-hids restart
This message means that the host intrusion detection system will not start. This generally means one of the following:
- The HIDS has been shut down manually, and is being automatically restarted by ASL
- The HIDS has been automatically restarted by ASL to install updates to the HIDS
- The HIDS or a part of the HIDS is not running correctly and has been restarted by ASL to fix this condition.
- The HIDS has run into a condition that is preventing it from starting.
See the section "Solutions" below for assistance if the HIDS will not start.
If this condition is continuing to occur, that is you get many alerts within a minute or two of each other, that means ASL is not able to restart the HIDS. If you get an email with this alert, and series of these alerts within a minute or two of each other then ASL is not able to start the HIDS.
The most common cause of this condition is when the ossec-dbd process has a problem communicating with the systems database server, or the tables it uses are corrupt or crashed. This means that either the database server (mysql) is not listening on the configured IP address and port, the database is overloaded and is rejecting connections (or is over tuned and is dropping connections), or a table has been corrupted and can no longer be updated or accessed.
Solutions
1) ASL not up to date
Upgrade ASL per the upgrade procedure:
Then run this command:
services ossec-hids restart
2) Mysql problems
First, check your mysql logs first to determine if you have any corrupt databases that require repair.
grep -i error /var/log/mysqld.log
Note: Some control panels disable mysql logging, or may change the location of the mysql log file.
The HIDS will not start correctly to log events to the database if the tables it is using are corrupt. If there are no mysql errors, check the log below for any error messages:
/var/ossec/logs/ossec.log
Then check this FAQ for guidance on those specific errors (just use your browsers search function to look for those messages on this page). In most cases OSSEC will not start because there is a problem communicating with the systems database or the HIDS rules are not up to date.
3) HIDS rules are not up to date
Run these commands as root:
aum -u
asl -s -f
4) Corrupt database
A corrupt table in database ASL is using will cause start up errors.
See this FAQ: https://www.atomicorp.com/wiki/index.php/ASL_FAQ#MYSQL_reports_a_table_is_.22is_marked_as_crashed_and_should_be_repaired.22
5) Firewall rules do not allow connection to the database
Temporarily clear your firewall rules:
service asl-firewall stop
service iptables stop
If OSSEC can start now, you have configured a firewall rule that is blocking database connections. You will need to remove this rule.
If OSSEC still can not start, your firewall rules are likely not the cause.
6) /etc/hosts file incorrectly configured
An incorrectly configured /etc/hosts file can cause issues with startups. For example, using a hostname for the database that is not resolving or is not in the /etc/hosts file. "localhost" is the most common missing record, see #4 below)
Also, a missing or incomplete localhost entry in /etc/hosts (localhost should resolve to 127.0.0.1) can cause this issue.
7) Database improperly configured
A non-optimally tuned database that is rejecting connections can cause start up issues. Please see the recommended minimum configuration for mysql at this URL:
https://www.atomicorp.com/wiki/index.php/ASL_prerequisites#MySQL_Configuration
Equally, over tuning mysql can cause it to drop connections. If you believe this is happening to you, please contact a qualified MySQL consultant for assistance configuring your database.
8) Overloaded Mysql
An overloaded database that is dropping, closing or rejecting connections sporadically. If you believe this to be the case, you will need to either allocate more resources for your database, or remove load.
9) MySQL not listening for TCP
A database that is not listening on a TCP port or the same port that you have configured ASL to use. Check to make sure your MySQL server is listening on port 3306 on the IP address you have configured ASL to use as its database server.
10) MySQL not listening on configured IP
A database server that is listening on a different IP address from the one configured for ASL can cause start up errors. Check to make sure your MySQL server is listening on port 3306 on the IP address you have configured ASL to use as its database server.
ossec-syscheckd: ERROR: Unable to add directory to real time monitoring:
This error means that the system either:
1) Has run out file descriptors.
This is known to occur on VPS systems, where a limit has been set. Increase the limits on your VPS. Please contact your VPS vendor to determine how to do this with your VPS solution.
2) Does not support inotify
Non ASL kernels may not support the modern inotify capability in Linux. This allows files to monitored in real time. Please ensure that your system is running the ASL kernel.
3) You have reached the limit for watches on your system
The kernel sets a limit, which can be changed, on the number of real time files that can be monitored. This setting is:
/proc/sys/fs/inotify/max_user_watches
In most cases, the default is 8192. Which means the system can watch 8192 files in real time for changes. In practice, that is a lot of files, and should be adequate for the systems key software and configuration files. If you are watching additional directories, in real time, such /home, /var/www and so on, where the system may have tens of thousands of files you will want to increase this number. You can do that either temporarily by changing that value with a command such as this (run as root of course):
echo 16384 > /proc/sys/fs/inotify/max_user_watches
Or, you can set this permanently by modifying your systems /etc/sysctl.conf file by adding an entry such as the one below, which increases the limit to 16384:
fs.inotify.max_user_watches = 16384
If you do not have a /proc directory or an /etc/sysctl.conf, then this means you are using a virtualization technology that does not allow you to tune the kernel. Please contact your virtualization vendor for assistance with this.
4) The final option is to reduce the number of directories, and therefore files you have ASL configured to monitor. Please log into the ASL GUI, click on the "ASL" tab, then click on "File Integrity", then select the "Options" button. This will pull up the configuration screen to set which directories or files to monitor. Select the "Directories" button, and configure according to your needs.
ossec-analysisd: INFO: Reading decoder file etc/decoders.d/01-asl-decoder.xml
This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:
aum -u
asl -s -f
ERROR: Duplicated decoder with prematch: 'smtpauth-failed'.
This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:
aum -u
asl -s -f
ERROR: Error loading decoder options.
This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:
aum -u
asl -s -f
ERROR: Configuration error at 'etc/decoders.d/01-asl-decoder.xml'. Exiting.
This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:
aum -u
asl -s -f
psmon
Checking for psmon installation: not installed [FAILED]
psmon is not supported with cpanel installations. If your system is running cpanel you will not be able to use the process monitor.
Command executed: /sbin/service something restart
This means that psmon has restarted a process that you have configured your system to start on boot. ASL does not configure what services your system will start on boot. ASL will check the processes that you have configured to start on boot, and will monitor them to make sure they continue to run. If a service dies, ASL will automatically restart it.
If you dont want to monitor this service
If you do not want ASL to monitor a process, then you need to disable that process on boot. The built in OS command to do this is:
chkconfig --del servicename
And then reset the ASL policy to not monitor this service any longer:
asl -s -f
segfaults
Examples:
Jun 8 09:14:16 system kernel: php[5963]: segfault at a801cecc ip a800809b sp bff43d70 error 7 in ld-2.5.so[a8001000+1b000]
23:00:43 system 12 30104 [notice] child pid 26148 exit signal Segmentation fault (11)
exit signal bus error
ASL gives you more visibility into your systems errors, so in the case of segfaults ASL is not actually causing them its just reporting them (which the system didnt actually do very well before ASL was installed).
Segfaults can be indications of a minor or serious problem with a web application, for example, if the segfault was with apache or they can mean that an application died because of a buggy module, or a bug in apache itself. In other cases, a segfault may be caused by a systems configuration. And in still others, it could be an actual hardware problem.
Its not possible to explain here what may be causing your application to segfault. segfaults are a very generic error, however to help you we have provided this courtesy section to explain these non-ASL errors and to provide some cases where we have a good idea of the cause and a solution. In those cases where the issue is generic we provide a guide for tracking the source of a segfault.
If you are using the secure ASL kernel:
Step 1)
Determine what application is causing the segfault. If you are using our secure kernel, it will tell you the exact application that did this, for example if PHP segfaulted you will an error like this:
Jun 8 09:14:16 system kernel: php[5963]: segfault at a801cecc ip a800809b sp bff43d70 error 7 in ld-2.5.so[a8001000+1b000]
The kernel is indicating that "php" process 5963 segfaulted, and the library and position in memory where this occurred.
Step 2) Look at the subsections below for solutions to commonly known segfaults.
If you are not using our kernel
Your problem is a little more complex, as your system will not log what caused the segfault. Unfortunately, you may have to do some detective work to find out what application is causing the segfault. Please review the final subsection, "apache segfaults" which links to an article that provides generic guidance for tracking down the source of segfaults through core dump analysis.
php segfaults
Example error messages:
Jun 8 09:14:16 system kernel: php[5963]: segfault at a801cecc ip a800809b sp bff43d70 error 7 in ld-2.5.so[a8001000+1b000]
Jun 8 09:14:11 system kernel: grsec: From 207.46.13.89: Segmentation fault occurred at a622eecc in /usr/bin/php[php:5952] uid/euid:590/590 gid/egid:590/590, parent /usr/local/apache/bin/httpd[httpd:5684] uid/euid:99/99 gid/egid:99/99
$ /usr/bin/php -v Segmentation fault
Discussion:
Some third party PHP modules, such as ioncube and Zend Optimizer are sometimes built in a very insecure manner, that introduces a vulnerability into the system that can lead to full compromise of the server. When they are loaded, they will attempt to open a hole in the system that can lead to full server compromise. The ASL kernel can detect when these applications attempt to open this hole, and will prevent them from doing so. This will cause php to segfault, because these insecurely configured libraries are correctly prevented from opening a hole in your system.
The solution (described below) is to just set the libraries to not attempt to open this hole, and to report this as a bug to your PHP vendor. These libraries do not need to be configured in this insecure manner to work correctly, it is both unnecessary and introduces a very large hole in your system that attacks can use to compromise the entire server.
ASL will try to detect these libraries when they are installed and fix them on installation. With package managed systems this happens automatically.
However, if you have a customized php install or have installed php from source (as happens with CPanel), then ASL can not manage this software dynamically and fix these broken and insecure libraries. You will need to find the insecure third party library that PHP is loading. In most cases this will be the ioncube and zend optimizer libraries, and in a package managed system (Such as Centos and Redhat) they are normally stored in locations such as (this is not a complete list):
/usr/lib64/php/ioncube/ /usr/lib/php/ioncube/
On non-package managed systems, such as cpanel systems, where the the package managed versions of PHP have been replaced with source compiled builds that location may be different. For example, cpanel usually compiles PHP and places it in locations similar to this (these may change, please contact cpanel or the party that build PHP from source for more information):
/usr/local/IonCube/ /usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ /usr/local/Zend/ /usr/local/Zend/lib/Guard-5.5.0/php-5.3.x/ (This is not a complete list, you will need to check what external libraries your source built PHP has installed).
One trick to find these libraries is to use your systems "locate" command. For example, you can use this command to find the ioncube libraries:
locate -i ioncube | egrep ".so$" | grep lib
And this one to find the zend libraries:
locate -i zend | egrep ".so$" | grep lib
Solutions
Step 1) Determine if PHP is vulnerable
There are two conditions in which ASL can be associated with a segfault of PHP, and both of these involve conditions when PHP is doing something very dangerous and unnecessary, and ASL is preventing PHP from compromising your system. In short, if you are using the secure ASL kernel, and you are using an improperly configured version of PHP that is dangerously misconfigured and has a serious root level vulnerability in it, ASL will stop PHP from opening this hole in your system and PHP may generate a segfault. ASL will also log the actual vulnerabilities, which is described in more detail below.
If both of these are true, you are using the ASL kernel and you have a dangerously misconfigured PHP, then the ASL kernel will detect this dangerous vulnerability in PHP when PHP attempts to open this hole, and the ASL kernel will prevent PHP from compromising your system. Run this command to see if PHP is trying to compromise your system with this command, run as root:
egrep -i "denied rwx|mmap|mprotect" /var/log/messages
If you see any error messages that say either:
mprotect(): 13 (Permission denied)
denied RWX mmap of
Then your system has this dangerous vulnerability, and ASL is protecting your from it. We highly recommend you fix this vulnerability. Please see the articles below for solutions to these vulnerabilities, and follow them for next steps:
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#mprotect.28.29:_13_.28Permission_denied.29
https://www.atomicorp.com/wiki/index.php/ASL_FAQ#denied_RWX_mmap_of
If you do not find either the mprotect or mmap error messages occurring on your system check and you have not disabled the option at the link below, then ASL is not associated with the cause of your segfaults, and ASL is not causing them.
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#RWXMAP_LOGGING
If you do see these events logged, then your system has this dangerous PHP vulnerability. Move on to step 2 below.
Step 2) Fix the vulnerability in PHP
Option 1) Use a package managed PHP
This is the easiest and best option. If your control panel company or system administrators are using source built versions of PHP, insist that they do not put execstack on their libraries. Its not needed and its very insecure. Doing so will open your system up to compromise, as as said before there is no need to dangerously misconfigure these libraries in this manner. They work just fine without it.
Option 2) Run ASL is scan and fix mode
ASL will look for php.ini files in standard locations and will analyze them to attempt to find any libraries that are included via your php.ini. If the insecure libraries are included via php.ini (which is usually the case, but not always especially with third party and source built PHP installs) ASL will then remove the unnecessary and highly insecure executable bit flags on those libraries. Just run this command as root to do this:
asl -s -f
Option 3) Clear the "executable stack" switch on these libraries manually
If ASL can not find your php.ini file, or if your libraries are loaded via some non-standard method you will need to manually remove these insecure flags from the libraries.
Simply run this command as root:
execstack -c /path/to/library
for example, if you wanted to fix the library "/usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ZendOptimizer.so" you would run this command as root:
execstack -c /usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ZendOptimizer.so
Or, if you want to fix the library "/usr/local/IonCube/ioncube_loader_lin_5.2.so", you would run this command as root:
execstack -c /usr/local/IonCube/ioncube_loader_lin_5.2.so
To find these libraries, assuming its ioncube and Zend that are causing this and not some other library, you can use these commands that are typically included with your operating system to typically find them:
locate -i ioncube | egrep ".so$" | egrep "lib|zendopt"
locate -i zend | egrep ".so$" | egrep "lib|zendopt"
locate -i zend | grep -i optimizer | egrep ".so$"
If you are using a third party PHP install, as with cpanel, these libraries may be stored in non-standard locations such as:
/usr/local/cpanel/3rdparty/php/53/zendopt/
Therefore you may need to use a broader search pattern, and you will need to contact CPanel to see where they may have installed these libraries.
Note: Check to make sure you have the "locate" command installed on your system.
Option 3) Quick method
This may work, if the vulnerable libraries are ioncube and zend. If you have other vulnerable libraries, you will need to find those libraries and follow the entire process in Option 3. You should also report this as a vulnerability to your PHP vendor.
execstack -c `locate -i ioncube | egrep ".so$" | grep lib`
execstack -c `locate -i zend | egrep ".so$" | grep lib`
execstack -c `locate -i zend | grep -i optimizer | egrep ".so$"`
If the vulnerable libraries are not ioncube and zend, then this will not work.
Option 4) Use an insecure kernel
This is the least secure option, is not necessary, and is recommended. This will leave your system open to root level compromise due to the vulnerability in PHP.
If you want to do this, you would simply use your the stock insecure kernel that came with your OS.
A secure kernel, such as the ASL kernel, will not allow libraries to do very unsafe things. This protects you from compromise by proactively protecting you from vulnerabilities in applications that do very dangerous things. An insecure kernel will not protect you from these things, and also will allow applications to do dangerous things on your system, and will make it possible an attacker to compromise your system
Tomcat segfaults
Solution: Tomcat uses Java, and Java performs certain actions that violate stack protection security models. To allow Tomcat to run in this manner, you simply need to run chpax to configure tomcat and Java to be allowed to do anything they want on your system, and to turn off all security protections for Java. This vulnerability exists on all platforms, with or without ASL, if you want to run Java.
/sbin/chpax -ps /path/to/java/bin/java
/sbin/chpax -ps /path/to/tomcat/
You may also need to configure certain tomcat support tools to run without protection as well, gcj-dbtool is one such case:
chpax -emrspx /usr/bin/gcj-dbtool
gcj-dbtool segfaults
Please see the above FAQ question.
execheap segfaults
See this article:
execstack segfaults
execbss segfaults
execdata segfaults
shlibbss segfaults
shlibdata segfaults
anonmap segfaults
apache segfaults
Examples:
[Fri Feb 1 01:00:00 2011] [notice] child pid 12345 exit signal Segmentation fault (11)
Or
kernel: grsec: From 1.2.3.4: Segmentation fault occurred at 0000003000003dbc in /usr/sbin/httpd[httpd:15804]
These are usually caused by a buggy web application, APR, or an apache module such as an accelerator, or other module. They are not caused by ASL. We have put together a courtesy page at the link below to assist you with these generic errors:
Other examples:
Sep 23 01:43:27 srv1 kernel: grsec: From 1.2.3.4: Segmentation fault occurred at 00000063000079bf in /usr/local/apache/bin/httpd[httpd:31167] uid/euid:99/99 gid/egid:99/99, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
This generally occurs with systems that do not use a package managed version of apache, or apache compiled from source.
Some third party apache modules, such as ioncube and Zend Optimizer set their libraries to allow the stack to be executable (a very huge security vulnerability the kernel will prevent, and a setting that is not necessary for this libraries to work). These libraries do not need to be configured in this very insecure state to work. When apache tries to load these libraries the kernel will prevent these libraries from calling a special function, mprotect, in an insecure manner. This will cause apache to segfault.
ASL will try to detect these libraries when it is installed and fix them on installation. With package managed systems this happens automatically.
However, if you have an apache install compiled from source (as happens with cpanel), then ASL can not manage this software dynamically and fix these broken libraries. You will need to find the insecure third party library that apache is loading. In most cases this will be the ioncube and zend optimizer libraries, and in a package managed system (Such as Centos and Redhat) they are normally stored in locations such as (this is not a complete list):
/usr/lib64/php/ioncube/ /usr/lib/php/ioncube/
On non-package managed systems, such as cpanel systems, where the the package managed versions of PHP have been replaced with source compiled builds that location may be different. For example, cpanel usually compiles and installs these libraries and places them in locations similar to this (these may change, please contact cpanel or the party that build apache from source for more information):
/usr/local/IonCube/ /usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ /usr/local/Zend/ /usr/local/Zend/lib/Guard-5.5.0/php-5.3.x/ (This is not a complete list, you will need to check what external libraries your source built apache has installed).
Solutions:
Option 1) Use a package managed apache
This is the easiest and best option. If your control panel company or system administrators are using source built versions of apache, insist that they do not put execstack on their libraries. Its not needed and its very insecure.
Option 2) Clear the "executable stack" switch on these libraries.
Simply run this command as root:
execstack -c /path/to/library
for example, if you wanted to fix the library "/usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ZendOptimizer.so" you would run this command as root:
execstack -c /usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ZendOptimizer.so
Or, if you want to fix the library "/usr/local/IonCube/ioncube_loader_lin_5.2.so", you would run this command as root:
execstack -c /usr/local/IonCube/ioncube_loader_lin_5.2.so
cpanel errors
Error from ssl wrapper: Unable to produce a valid Apache configuration file
Additionally, these errors may be found in the cpanel error log:
/usr/local/cpanel/logs/error_log:
[2012-04-05 19:18:33 +1000] warn [ssladmin] Unable to produce a valid Apache configuration file. at bin/ssladmin line 201 [2012-04-05 19:18:33 +1000] warn [cpanel] Cpanel::AdminBin::adminrun(ssl) set error in context ssl [2012-04-05 19:18:33 +1000] warn [ssl::install] Encountered error in ssl::install: Error from ssl wrapper: Unable to produce a valid Apache configuration file.
This is caused by an insufficient amount of memory being allocated to the cpanel process. The allocated amount of memory can be changed from within WHM as follows:
1) In the menu on the left, click on "Tweak Settings".
2) In the main frame, click on the "System" tab.
3) Increase the value for "Max cPanel process memory".
An increase of 64MB should generally be enough, but this may vary depending on your system, the amount of domains you have on the system, etc. If an increase of 64MB is inadequate, keep increasing the limit by 32MB increments.
Generic Errors/Issues
abrtd errors
abrtd is a product by Redhat.
It is not used, required, configured or managed by ASL. If you are having issues with abrtd, please contact Redhat for assistance. The most common condition with abrtd is that it incorrectly guesses that paxtests are application crashes, and tries to collect information about them. They are not application crashes, and paxtest is performing normally. Please contact Redhat for assistance with ABRT.
If you wish to disable ABRT, run these commands as root:
service abrt-ccpp stop service abrtd stop service abrt-oops stop chkconfig --del abrtd chkconfig --del abrt-ccpp chkconfig --del abrt-oops
Redactor: not installed
If you are using cpanel:
The redactor is not supported on cpanel.
If you are not using cpanel, and are using ASL:
This means someone has uninstalled the redactor from your system. Please run the ASL installer again to ensure it reinstalled and configured correctly.
package mod_security is not installed
If you are using cpanel:
cpanel does not use package management. They have chosen to compile apache from source, and all its modules. Therefore, modsecurity must be compiled from source on your system and no package management can be used and you not see mod_security installed via rpm or yum on your system. Please direct any questions about this decision to cpanel.
If modsecurity really is not installed in cpanel, then run the ASL installer again to ensure it is reinstalled and configured correctly. Do not install modsecurity from cpanel.
If you are not using cpanel, and are using ASL:
This means someone has uninstalled modsecurity from your system. Please run the ASL installer again to ensure it reinstalled and configured correctly.
If you are not using cpanel, and not using ASL:
You will need to manually install modsecurity on your system. Please see the URL below:
https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules
PHP Startup: Unable to load dynamic library '/var/asl/usr/lib64//php/modules/sqlite3.so'
This is caused when someone or something has downgraded sqlite on your system to an older incompatible version. ASL will never do this.
Note: If you are using a control panel that is not using package management, please report this as a bug to your control panel vendor. Proper package management will prevent software from being overwritten and downgraded, and no reputible software company should be putting our software that does not use package management. The failure to use software management tools built into your operating system is both dangerous, and unnecessary amd is what causes this kind of problem.
Solution 1
Reinstallation of sqlite is one effective method for fixing this.
This command, run as root, can be used to restore sqlite on your system:
yum reinstall sqlite
If this does not resolve your issue, see Solution 2 below.
Solution 2
To try to combat this on systems where package management is not used, we've added in code to ASL to work with older versions of sqlite where possible. Not all older versions of sqlite are compatible, and a minimum version of 3.6.x is required.
To ensure all of ASL is up to date, run this command as root:
yum upgrade asl-php
You must have at least version 5.4.19-17 of asl-php installed.
PHP Web application reports "Could not open socket"
This may be because you have disabled the fsockopen PHP function, and your application requires this function. To re-enable this function in ASL, log into the ASL GUI, click on Configuration, scroll down to ALLOW_fsockopen, set it to "yes" and then click update.
If this does not resolve your issue, please contact your web application developer for assistance.
PHP web application reports "file_get_contents (etc) failed to open stream: operation failed
This happens when you either configure PHP to disable fopen for URLs, or you have configured ASL to do this. By default, ASL will not disable any PHP functions. See these two configuration options:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#PHP_URL_FOPEN
To re-enable this function in ASL, log into the ASL GUI, click on Configuration, scroll down to PHP_URL_FOPEN , set it to "yes" and then click update.
If this does not resolve your issue, please contact your web application developer for assistance.
cannot open database /var/lib/rpm and db3-error from dbenv_open
This a serious error with your operating systems software management system. This is not caused by ASL and is not something ASL can fix.
This either means that you do not have permission to access the software management system, or if you do have permission it means your operating systems software management database is corrupt or missing. Please contact your OS vendor for assistance with this issue.
Yum was not detected. Attempting to resolve..
This means that yum, the package management system built into modern Linux rpm based Linux systems, such as Redhat, Fedora and Centos is missing. This is a key and vital part of the system that makes it not only possible to install software, but also to make sure the system is up to date and properly patched. ASL will try to install yum if its missing, but if it can not you will need to discuss this issue with your OS vendor.
yum is an internal part of the OS, and if its missing something is seriously wrong with the system and should be resolved before trying to install any software.
Error: Missing Dependency: httpd-mmn = 20051115 is needed by package
This means that the system is running a non-package managed version of Apache, such as with cpanel or directadmin and your system has been configured to not allow package management or dependency resolution via a package manager. ASL will generally attempt to work around this, but in some cases this may not be possible. Please report this as a bug to your control panel vendor as disabling package management is a very bad software engineering practice.
Access denied for user 'tortix'@'localhost' (using password: YES)
This means that the credentials you have supplied to ASL to log into the mysql database are incorrect. During installation ASL will ask for credentials to create the databases it needs using the databases admin user, and later will ask what non-privileged account it should create to log into the database. Please ensure that you have configured ASL to use the non-privileged account information you instructed the installer to create during installation. You can change the database account and username information ASL uses by becoming root on your system and editing this file:
/etc/asl/config
then change these variables to the non-priviliged account you created during installation for ASL:
OSSEC_DATABASE_USERNAME
OSSEC_DATABASE_PASSWORD
For example, if you instructed ASL during installation to use the username "tortix" and the password "password" these settings would look like this:
OSSEC_DATABASE_USERNAME="tortix"
OSSEC_DATABASE_PASSWORD="password"
Save the file, and then run this command as root:
asl -s -f
If you did not setup the databases ASL uses correctly, run the following commands as root:
/var/asl/bin/database-setup
service ossec-hids restart
If ASL still can not log into the tortix database, this means that the mysql credentials ASL is using have been changed outside of ASL. Please follow this process to restore them manually
Step 1: Log into mysql as your administrative user
The administrative user in mysql is the most privileged user in mysql. This user can create users, change password and carry out other "super user" functions. By default this user is "root, but may be different for your system. For example, the user is "admin" on Plesk systems. ASL does not setup or configure this user. If you do not know what the user is, or what that users password is please contact the parties that setup mysql on your system.
Run this command:
mysql -u <admin user name> -p
For example:
mysql -u root -p
mysql will then ask for the admin users password, type it in. If you successfully log in, you will see this:
mysql>
If you have not successfully logged in, you will see this:
ERROR 1045 (28000): Access denied for user 'youradminusersname'@'localhost' (using password: NO)
ASL does not set or configure the administrative user for mysql, so if you do not know the username or password for this account, contact the parties that setup mysql on your system.
Step 2: Change the password for tortix
Enter this command into mysql, changing OSSEC_DATABASE_USERNAME and OSSEC_DATABASE_PASSWORD to the appropriate values for your system.
Example:
If OSSEC_DATABASE_USERNAME was configured on your to "tortix" and OSSEC_DATABASE_PASSWORD was configured to "mypassword", you would enter the command:
SET PASSWORD FOR 'tortix'@'localhost' = PASSWORD('mypassword');
Step 3: Flush mysqls privileges table
Type this command into mysql:
flush PRIVILEGES;
Your password is now reset. You can now quit from mysql with the command quit.
ossec-dbd(5202): ERROR: Error connecting to database 'localhost'(tortix): ERROR: Unknown MySQL server host 'localhost' (0).
Check to ensure you are not using "skip-networking" in /etc/my.cnf, OSSEC chroots and because it does so, cannot use the regular mysql socket to communicate to the database. It requires a TCP connection over the loopback IP address. Likely mysql has been configured to not listen on the loopback IP (skip-networking) or firewall rules are blocking connections to it.
ERROR: Invalid SMTP Server: localhost
This means your system is missing an entry for localhost and the operating system can not determine what the IP address for localhost is. This is a serious error on the system and will have adverse impact on other systems.
Recommended solution
1) Determine how the localhost entry was removed, this may be indicative of other serious problems with your system
2) Add a localhost entry to /etc/hosts
127.0.0.1 localhost.localdomain localhost
If this does not solve your problem with missing localhost entries you may more serious problems with your system that are beyond the scope of ASL. localhost is a standard name used on all operating systems, and all operating systems are configured with a localhost entry. If yours is missing your system has been modified from the OS vendors standard working configuration.
Horde webmail is reporting: "There was an error sending your message: Failed to open sendmail [/var/qmail/bin/sendmail] for execution."
Option 1) The host secure choice and frankly the easiest option is to configure horde to use SMTP and not to call the sendmail binary. This post in the support forum details how to configure horde to use SMTP[6]. Some versions of horde also require that you enable pfsockopen and fsockopen, you will need to enable these functions if horde still does not work after SMTP mode. We recommend you test horde first to make sure you actually need these functions, rather than enabling them in advance. They can create a hole in PHP if they are enabled, and should only be enabled if you know need them.
Option 2) Horde can run in one of two modes, the default is to use exec() and/or popen() to send mail. This mode is less secure. If you do not want to use SMTP, just enable those functions in the ASL Configuration and you are setup. Some versions of horde also require that you enable pfsockopen and fsockopen, you will need to enable these functions if horde still does not work after enabling exec and popen. We recommend you test horde first to make sure you actually need these functions, rather than enabling them in advance. They can create a hole in PHP if they are enabled, and should only be enabled if you know need them.
You can also enable those functions just for specific applications or virtual domains. This post in the support forums details how to only allow functions for webmail [7]. The escapeshellcmd function also needs to be available or sending mail will fail without any error messages.
Cant get or send mail with webmail application
This can happen if a webmail application is written in PHP and requires a PHP function that has been disabled based on either your ASL configuration, or was manually disabled in your PHP configuration file (php.ini). Most webmail clients require these functions to be enabled in PHP at a minimum:
- exec
- popen
Some webmail clients will also require these functions:
- pfsockopen
- fsockopen
If you are using horde, please see the FAQ above for an additional more secure option, which uses SMTP instead of the exec and popen functions.
What does the following alert mean and what should be done?
Message: [file "/etc/httpd/modsecurity.d/05_asl_scanner.conf"] [line "37"] [id "351000"] [rev "1"] [msg "Malicious File upload attempt"] [severity "CRITICAL"] Access denied with code 403 (phase 2). File "/tmp/12345" rejected by the approver script "/usr/bin/modsec-clamscan.pl": 0 Unable to parse clamscan output [WARNING: Can't connect to clamd.] Action: Intercepted (phase 2) Stopwatch: 12345 12345 (12345* 12345 -) Producer: 200811121208. Server: Apache/2.0.63 (CentOS)
This means that clamd is not running on the system. Please check to make sure that clamd is running. You can do that by executing the following command as root:
ps auxwww | grep clamd
If you do not get a result like this:
[root@www3 clamav]# ps auxwww | grep clamd clamav 21142 0.0 8.5 203064 173996 ? Ss 04:21 0:04 clamd
clamd is not running. To start clamd simply run this command:
/etc/init.d/clamd start
Error: Cannot retrieve repository metadata (repomd.xml) for repository: plesk. Please verify its path and try again
Solution:
http://www.atomicorp.com/channels/plesk/README
The plesk third party RPM archive has moved! Running the installer again will reconfigure your system to use the new channel.
wget -q -O - http://www.atomicorp.com/installers/atomic |sh
Metadata file does not match checksum
This is not an ASL error, that error is generated by your Operating Systems package management system. Please contact your OS vendor for assistance. The information that follows is provided as a courtesy. This tool is not part of ASL, is not used by ASL and is not supported by Atomicorp.
This generally means your yum cache has corrupt or old data in it, you need to clear your yum cache.
Method 1)
Run this command as root:
yum clean metadata
Method 2)
yum clean all
Method 3)
If the previous two methods do not work, and you have fastestmirror installed you may need to rebuild your cache:
yum makecache --disableplugin=fastestmirror
Method 4)
If you still can not get yums cache cleared you may need to disable fastestmirror:
vi /etc/yum/pluginconf.d/fastestmirror.conf
And set "enable=0"
Method 5)
If your package management database seems corrupt, you can try to rebuild it with this command run as root:
rpm --rebuilddb
This is generally not required unless you have killed an rpm operation or had a crash during an rpm operation.
Method 6)
Remove fastestmirror (if you have it installed):
yum remove yum-fastestmirror
Package psa-tomcat-configurator needs mod_jk, this is not available.
See this post on the Plesk forums: http://forum.swsoft.com/showthread.php?t=56344
This is not an ASL or ART issue.
Rule: 30104 fired (level 12) -> Apache segmentation fault
Solution:
This means that apache is experiencing a recoverable memory error. We have found that mod_memcache seems to cause this. Turning it off has worked for many users.
Also, see this wiki article for more information on apache debugging:
http://www.atomicorp.com/wiki/index.php/Apache
Java is stopped by PAX
Solution: Java performs certain actions that violate stack protection security models. To allow JAVA to run in this manner, you simply need to run chpax this way:
/sbin/chpax -ps /path/to/java/bin/java
DEBUGGER DETECTED... Bye!
This message is generated by Parallels programs that attempt to detect if the user is running the Parallels program through a debugger. If you are not running a debugger, and you are running the ASL kernel this is most like caused by the a bug in the Parallels program that incorrectly detects this condition. The FAQ article above provides a solution to workaround this bug in Parallels products.
You can also read more about the kernels ptrace exploitation protections.
Deleting old audit records
Solution:
/usr/bin/find /var/asl/data/audit -maxdepth 1 -type d -ctime +7 -exec /bin/rm -rf {} \;
Change the number “7” to the number of days of audit records you wish to keep.
up2date issues
up2date_client.up2dateErrors.CommunicationError: Error communicating with server.
This means that Redhats up2date client can not communicate with the Redhat update servers. Please contact Redhat for assistance with this error.
Error communicating with server. The message was:
When running yum update or yum upgrade this error occurs:
Loading "installonlyn" plugin
Loading "rhnplugin" plugin
There was an error communicating with RHN.
RHN support will be disabled.
Error communicating with server. The message was:
Error Message:
Please run rhn_register (or up2date --register on Red Hat Enterprise Linux 3 or later)
as root on this client
Error Class Code: 9
Error Class Info: Invalid System Credentials.
Explanation:
An error has occurred while processing your request. If this problem
persists please enter a bug report at bugzilla.redhat.com.
If you choose to submit the bug report, please be sure to include
details of what you were trying to do when this error occurred and
details on how to reproduce this problem.
Solution:
This is not an ASL error. This means that your system is configured to use Redhat Update Network and you do not have valid credentials to use their server. Contact Redhat support for assistance.
yum update errors
When running yum update or yum upgrade this error occurs:
Setting up Upgrade Process
Setting up repositories
http://atomicorp.com/channels/asl-2.0/c ... repomd.xml: [Errno 14] HTTP Error 401: Authorization Required
Trying other mirror.
Error: Cannot open/read repomd.xml file for repository: asl-2.0
Solution:
This means that your system is not configured with a valid ASL subscription account. Please check your username and password in your asl configuration and check to make sure your subscription is up to date.
Tomcat is stopped by PAX
Solution: Java performs certain actions that violate stack protection security models. To allow JAVA to run in this manner, you simply need to run chpax this way:
/sbin/chpax -ps /path/to/java/bin/java
There are unfinished transactions remaining.
The error continues:
You might consider running yum-complete-transaction first to finish them. The program yum-complete-transaction is found in the yum-utils package.
This is not an ASL error, that error is generated by your Operating Systems package management system. This error means that your operating systems package management system was previously used to install, remove and/or upgrade software, and the last transaction was not completed. This has left the package management system of your operating system in an incomplete state, and is preventing software from being properly installed, upgraded and/or deleted.
This tool is not part of ASL, is not used by ASL and is not supported by Atomicorp. Please contact your OS vendor for assistance with issues with your OSes package management system. The information that follows is provided as a courtesy only.
If you want to install this tool, please follow the instructions generated by yum. Specifically, this message is stating that the tool yum-complete-transaction is part of the "yum-utils" package:
The program yum-complete-transaction is found in the yum-utils package. To install that package you need to run this command as root:
yum -y install yum-utils
You need to install that package to use that tool. This tool is part of the overall system that allows you to (among other things) pause & resume upgrades.
If you dont know where a component comes from you can use "yum provides /path/to/file" (wildcards accepted) to search.
Once this tool is installed, you can tell your OSes package management system to complete the last incomplete transaction with this command:
yum-complete-transaction
Error: Missing Dependency: httpd-mmn = 20051115 is needed by package
This means that the system does not have apache installed. If you have installed apache via a non-package managed means (such as from source code). Contact your apache vendor for assistance with this error.
