[edit]Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration
This means that either mod_ssl is not installed on the system, or someone or some third party product has removed the mod_ssl package from the system. Run this command as root to install mod_ssl:
yum install mod_ssl
[edit]ERROR 3 (HY000) at line 3: Error writing file './some/file' (Errcode: 28 - No space left on device)
This means your file system has run out of space. Please see the disk space requirements at the link below:
https://www.atomicorp.com/wiki/index.php/ASL_prerequisites#ASL_disk_space_requirements
[edit]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
[edit]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.
[edit]Generic Errors
[edit]mod_sed requires httpd
If you are using cpanel, you can not install mod_sed as an rpm. Please run the ASL installer, cpanel compiles everything for Apache from source, and the use of the ASL installer to install mod_sed is the only supported method.
[edit]An error occurred attempting to open file /var/asl/data/updates_pending.log
This file should be owned by the root user and root group, and it should also have user and group read and write permissions, as in the example below:
-rwxrwx--- 1 root root 81 Jan 1 00:00 /var/asl/data/updates_pending.log
Note: If you are using third party SELinux rules, check to make sure your SELinux rules are not preventing ASL from writing to this file.
[edit]yum is reporting rpm is already installed
1) Remove the duplicate entry.
Example:
rpm -e gradm-2.9.1-22.el5.art --nodeps
2) Regenerate the rpm database
Example:
rm -f /var/lib/rpm/__db.00* && rpm --rebuilddb
3) reinstall the package
Example:
yum reinstall gradm
[edit]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.
[edit]Update Errors
[edit]HTTP Error 401: Authorization Required
See the FAQ below [1].
[edit]3 303 Core::distributed_update Invalid user credentials
See the FAQ below [2].
[edit]Error: ASL Key is not valid or has expired.
See the FAQ below [3].
[edit]The requested URL returned error: 401
See the FAQ below [4].
[edit]HTTP Error 401: Authorization Required Trying other mirror.
See the FAQ below [5].
[edit]Error: Your Username/Password is incorrect, or your account has Expired.
See the FAQ below [6].
[edit]3 303 Core::distributed_update Invalid user credentials
See the FAQ below [7].
[edit]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:
[edit]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/amember/member
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/amember/member
Step 3
If you are still getting this error, run these three commands as root:
rm -rf /etc/asl
rm /etc/yum.d/asl.repo
rm /etc/yum.d/tortix-common.repo
Then run the ASL installer again.
[edit]If you have a failed install
Follow the procedure at the URL below:
[edit]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/amember/member
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 Settings
Sub Step 3) Click on ASL Configuration
Sub Step 4) Check to make sure the License Username and License 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, not the credentials you use to log into the ASL web console).
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#USERNAME
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#PASSWORD
Sub Step 5) Then click the "Save Changes" 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.
[edit]Error: Another instance of ASL appears to be running
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
[edit]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
[edit]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
[edit]ASL kernel Critical not detected
See above.
[edit]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.
[edit]
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.
[edit]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.
[edit]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
[edit]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
[edit]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.
[edit]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.
[edit]/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
[edit]ERROR: '/usr/bin/setfacl -m
Please see the article below this one.
Examples:
ASLCommon::cmd_system ERROR: '/usr/bin/setfacl -m g:apache:rwX,d:g:apache:rwX /var/asl/data/audit >/dev/null 2>&1 (1)'
[edit]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.
[edit]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.
[edit]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. Please ask your kernel vendor if they support POSIX 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.
[edit]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_error_messages#Solutions
[edit]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
[edit]modsecurity errors
[edit]Error creating rule: Could not add entry "0" in line 96 of file /etc/asl/whitelist to IP list'
Please the article below.
[edit]Syntax error on line 31 of /usr/local/apache/modsecurity.d/00_asl_whitelist.conf
For example, if you see an error similar to this:
Error creating rule: Could not add entry "209.23.243.1908.8.8.8" in line 7 of file /etc/asl/whitelist to IP list'
That means you have an invalid entry in your /etc/asl/whitelist file. The format for the file is one IP or one CIDR per this, for example:
10.0.0.0/8 1.2.3.4 8.8.8.8
Make sure you only have one entry per line, and then run this command as root to reset your whitelist:
asl -s -f
[edit]Cannot load /usr/local/apache/modules/mod_security2.so
This means that something/someone has removed mod_security from system. ASL will not do this. To fix this please follow the process below:
Step 1) Run this command as root:
aum -uf
Step 2) Test the apache configuration
service httpd configtest
If the reinstallation has been successful you should see an output similar to this:
Syntax OK
If you see that the configtest was successful, you can restart apache with this command:
service httpd restart
If this did not reinstall mod_security on your system, then you will need to run the ASL installer again as more serious damage has been done to your system. The installer will attempt to repair the damage that has been done to your system. Do not uninstall ASL. It is safe to run the installer multiple times. Run the command below:
wget -q -O - https://updates.atomicorp.com/installers/asl |sh
If neither of those resolves the issue for you please contact support with the output of the commands in this article so we can see what may be wrong with your system.
[edit]ModSecurity: Access denied with code 400. Too many threads
Please see this article:
https://www.atomicorp.com/wiki/index.php/HIDS_31102
[edit]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.
[edit]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.
[edit]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.
[edit]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.
[edit]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.
[edit]clamd/clamav messages/errors/issues
[edit]ERROR: Can't initialize the internal logger =
This means another clamd process is running that has locked the clamd.log file. Or permissions on the file or its directory do not allow clamd to read and/or write to the file. Check to see if you have an additional third party clamd running on your system and remove it. Check the permissions on the log files and directory. IF you have not changed the defaults of clamd, then the permissions should look like this:
drwxr-xr-x 2 clamav clamav 4096 Jun 26 04:23 . drwxr-xr-x 23 root root 4096 Jul 1 04:37 .. -rw-r--r-- 1 root root 0 Jun 26 04:23 clamd.log -rw-r----- 1 root root 139593 Jul 1 17:06 freshclam.log
[edit]Starting Clam AntiVirus Daemon: ERROR: /var/log/clamav/clamd.log is locked by another process
See the article above "ERROR: Can't initialize the internal logger"
[edit]Heuristics.Structured.CreditCardNumber
This is caused when the user enables the CLAMAV_StructuredDataDetection option. This means that clamd has detected data in a file that appears to be a credit card.
This option is not enabled by default in ASL. Please see the documentation at the URL below:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#CLAMAV_StructuredDataDetection
[edit]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.
[edit]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.
[edit]/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.
[edit]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_error_messages#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
[edit]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.
[edit]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.
[edit]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/Using_ASL#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.
[edit]connect(127.0.0.1:3310): Connection refused
See Cannot re-connect to Clamd below.
[edit]connect(): Connection refused
See Cannot re-connect to Clamd below.
[edit]ERROR: Can't connect to clamd: No such file or directory
See Cannot re-connect to Clamd below.
[edit]End of file found
See Cannot re-connect to Clamd below.
[edit]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.
[edit]Your ClamAV installation is OUTDATED
See the FAQ below:
[edit]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.
[edit]/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.
[edit]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.
[edit]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.
[edit]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.