Atomic FAQs

To address this ERROR run this command as the root user on the OSSEC hub:

/var/ossec/bin/syscheck_update -a

Then restart OSSEC with this command:

service ossec-hids restart

Users have two options to make custom rule modifications to ASL rules.

Option One

Use the ASL Web Interface. For further documentation please visit https://wiki.atomicorp.com/wiki/index.php/Using_ASL#Rule_Editor

Option Two

If you do not have access to the ASL web interface then rule modifications can be made directly from the commandline interface. To make modifications please follow the steps below:

Using an editor of your choice access the/etc/asl/rules file

The/etc/asl/rules file is where custom rule modifications are stored. This file has a unique structure and it is as follows.

Field One: V or G -- Modify the rule for a Virtual Host or as a Global configuration

Field Two: waf or hids -- Type of rule that needs modification

Field Three: Alert ID (integer)

Field Four: If field one is set to Vthen the Virtual Host goes in this field

Field Five: yes or no -- Do you want to disable the rule?

Field Six: yes or no -- Do you want to receive email notifications about this alert?

Field Seven: rule level (integer) -- Level of the alert

Field Eight: yes or no -- Is Active Response enabled on this rule?

Field Nine: yes or no -- Is logging enabled on this rule.

Field Ten: NOT USED

Field Eleven: Description

An Example:

V,waf,330215,test.atomicorp.com,no,yes,9,yes,yes,,Atomicorp.com WAF Rules: Sosospider - AbusiveG,hids,5555,,no,yes,10,yes,yes,,Atomicorp.com HID Rules: modification

Atomic Enterprise OSSEC v5.5 Installation

Download and run the Atomic Enterprise OSSEC Beta installer by running the following command as root:

wget -q -O - https://updates.atomicorp.com/installers/aeo-beta|sh

Note: Enter the provided Username and Password after accepting the End User License Agreement.

Upgrading Atomic Enterprise OSSEC to v5.5

Note: Follow the steps below if you already have an EXISTING installation of Atomic Enterprise OSSEC

Run the following command as the root user:

cp /etc/asl/config ~/asl.cfg

Download and run the Atomic Enterprise OSSEC Beta installer by running the following command as root:

wget -q -O - https://updates.atomicorp.com/installers/aeo-beta|sh

Reverting to Non-Beta Installation

Note: Follow the steps below if you have already installed the beta version of AEO

Run the following command as the root user:

yum -y downgrade asl aum asl-waf-module asl-web

This is an internal limit to prevent a special type of DOS attack on the WAF itself.This is not caused by any of the rules.This is caused by the content the rules are inspecting. In certain cases, the content may be so complex that the WAF is stopping itself from doing too much work which could lead to a DOS attack on the system itself. If your system is generating these kinds of errors, it means you need to set the limits higher on your system, while it is beyond the scope of this article, another solution is to reduce the complexity of the content you are inspecting.

It is also possible this is occurring due to an actual DOS attack on your system. If you are certain this is not a DOS attack, simply increase these limits accordingly for your system. we recommend a minimum of 250000 for a modern system.

SecPcreMatchLimit 250000

SecPcreMatchLimitRecursion 250000

You may have to increase these limits for your system if you continue to get PCRE limit errors.

If you're seeing an error similar to the following:

]# yum --disableexcludes=all --enablerepo=tortix-kernel upgrade kernelLoaded plugins: fastestmirrorSetting up Upgrade ProcessLoading mirror speeds from cached hostfileCould not retrieve mirrorlist file:///etc/asl/tortix-kernel-mirrorlist error was14: Could not open/read file:///etc/asl/tortix-kernel-mirrorlistError: Cannot find a valid baseurl for repo: tortix-kernel

The most likely cause is that you have the Kernel Channel disabled, and update type set to exclude kernel. This can be verified with:

cat /etc/asl/config

You'll be looking for "KERNEL_CHANNEL="disabled" andUPDATE_TYPE="exclude-kernel" under the Genera Configuration like so:

# ASL general configuration.NOTIFY="yes"EMAIL="[email protected]"HOSTNAME="youserver.com"ADMIN_USERS=""SYSTEM_TYPE="webserver"AUTOMATIC_UPDATES="daily"UPDATE_TYPE="exclude-kernel"RESTART_APACHE="graceful"ASL_USER="tortix"FEED_TYPE="real-time"FEED_SOURCE=""COMPLIANCE="off"KERNEL_CHANNEL="disabled"ALLOW_NFS="no"DOWNLOADER="internal"REPUTATION_REPORT="yes"REPUTATION_FREQUENCY="daily"PURGE_LOGS="no"

If you see this, all you need to do is simply change "UPDATE_TYPE ="exclude-kernel" to "UPDATE_TYPE="all" andKERNEL_CHANNEL="disabled" to "KERNEL_CHANNEL="tortix-kernel"

There are three methods to change this.

Method 1:1) Log into your AWP GUI at: https://x.x.x.x:30000 (where x.x.x.x is your servers IP).2) Navigate to the configuration page. In the AWP 5x branch, this is a tab at the top. In the AWP6 branch, this is on the menu at the side.3) Click on "General"4) Scroll to "UPDATE_TYPE" and select "all"5) Scroll to "KERNEL_CHANNEL" and select "tortix-kernel"6) Save, then run asl -s -f and aum -uf

Method 2:1) Run the AWP configuration again with the command: asl -c2) For "UPDTE_TYPE" type in "all" and for the kernel updates make sure it says "tortix-kernel"

Method 3:1) Open your AWP config: vi /etc/asl/config2) Go down to "UPDATE_TYPE="exclude-kernel" and replace the "exclude-kernel" entry with "all"3) Go down to "KERNEL_CHANNEL="disabled" and change "disabled" to "tortix-kernel"4) Save your changes and exit the open config file.5) Run asl -s -f followed by aum -uf

If you see rpmdb errors during package management (during yum/dnf/rpm operations) like this:

rpmdb: Thread/process 10605/3765405599488 failed: Thread died in Berkeley DB lib rary error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run d atabase recovery error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm CRITICAL:yum.main:

Error: rpmdb open failed

This means the Operating Systems software database (RPM data) has become corrupted. To fix this issue, run these commands as root:

# mkdir /var/lib/rpm/backup

# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/

# rm -f /var/lib/rpm/__db.[0-9][0-9]*

# rpm --quiet -qa

# rpm --rebuilddb

# yum clean all

There are ways to reduce some of the CPU load from services such as analysisd, syscheckd, mysql and the openscap scan in OSSEC. Analysisd receives the log messages and compares them to the rules. It will create alerts when a log message matches an applicable rule. Syscheckd/rootcheck are the daemons that power the File Integrity Monitoring (FIM) feature and malware scans. OpenSCAP is a compliance and lightweight vulnerability scanner that uses definitions for different security frameworks (PCIDSS, NIST, etc). It runs in conjunction with syscheckd. Below are some measures you can take to help reduce some of the load from these different processes. There will be a trade off between changing some of these configurations and software capabilities/performance.

1. Check the CPU and increase the number of cores for increased performance

2. Check the memory and increase it to enhance performance

[root@demo ~]# free -h

3. Turn OpenSCAP scanning off

In the GUI, navigate to Settings > ASL Configurations > Host Intrusion Detection System >

ossec_modules: openscapHIDS_OPENSCAP_MODULEsets openscap module (compliance scanning) on/off in ossec

and turn this setting off. Save your changes.

4. Run mysqltuner for performance information and tuning suggestions. Note: we do not support mysql. Contact your OS vendor for more assistance on this. High mysql loads can be contributed to the amount of data being processed by the Aria database storage engine.

5. Tune the syscheckd settings

By default the syscheckd is configured to sleep for 1 second after scanning 100 files. This can contribute to high CPU loads depending on how many cores you have provisioned on your server. Consider increasing your CPU or changing the settings. For example, you can set syscheckd to sleep for 2 seconds for every 15 files it reads. Please note that this will cause syscheckd to take longer to finish scanning your file systems that are being watched by OSSEC. The realtime feature works AFTER syscheckd has finished starting. To tune this setting go to Settings > ASL Configuration > Host Intrusion Detection System >

Syscheck: Sleep after checksumHIDS_syscheck_sleepSyscheck checking/usage speed. To avoid large cpu/memory usage, you can specify how much to sleep after generating the checksum of X files.

Syscheck: Sleep after checksum 2HIDS_syscheck_sleep_afterSyscheck checking/usage speed. To avoid large cpu/memory usage, you can specify how much to sleep after generating the checksum of X files.

and change Syscheck: Sleep After Checksum to 2 and Syscheck: Sleep after checksum 2 to 15

Save your changes so they take effect. Below is an example of the full chain to let you know syscheckd has finished starting:

2018/10/23 10:47:46 ossec-syscheckd: INFO: Real time file monitoring engine started.

2018/10/23 10:47:47 ossec-syscheckd: INFO: Finished creating syscheck database (pre-scan completed).

2018/10/23 10:47:52 ossec-syscheckd: INFO: Ending syscheck scan (forwarding database).

2018/10/23 10:49:00 ossec-syscheckd: INFO: Starting syscheck real-time monitoring.

6. Tune Watch Rules for the different Agent Groups and/or server itself.

If you're using the AEO Hub design, navigate to ASL > Agent Manager

Click FIM settings for the group. Look at the files that are currently being monitored. Are these large file systems? Do they currently have dynamically changing files in them? Is whodata, realtime or report changes set to yes? These settings can impact the performance of syscheckd and analysisd. Consider turning some of these settings off or setting ignore rules so syscheckd completely ignores the directory.

If you're using the standalone design (ASL) navigate to ASL > File Integrity > Watch Rules and follow the suggestions above.

This can happen for a number of different reasons. The key is to make sure the server has proper hardware specs along with checking the logs for errors. Sending us data points from the troubleshooting steps below will help tremendously. Below are steps to troubleshoot a GUI that is very slow or not initializing.

Step 1: Check the disk space and memory on the server itself to make sure you are not running out of storage space:

[support@demo ~]# df -hFilesystem Size Used Avail Use% Mounted on

Step 2: Check the memory on your server directly and on any hypervisor you are currently running the server on. Lack of memory will cause performance issues:

[support@demo ~]# free total used free shared buff/cache availableMem: 65695452 4169860 804032 3277112 60721560 57712516Swap: 67104752 15724 67089028

Step 3: Check the mysqld.log in real-time to see what errors you might be getting from the database

[support@demo ~]# tail -f /var/log/mysqld.log

Step 4: Run a web validation and check for any errors. If you see any errors, please email support ( [email protected] ) with this information:

[support@demo ~]# asl --web_validate -d

Step 5: Clear the cache on the browser and try logging back to into the GUI. While doing this, press ctrl + shift + i when logging into the GUI to check Network and Console performance. If you notices any errors, please send a screenshot in a ticket to support.

Step 6: Run the top command to see what processes are potentially bogging down your server:

[support@demo ~]# top

As of November 2016, ASL is officially supported with the following Linux distributions:

Centos 5 (Until March 31, 2017. See extended support )

Centos 6

Centos 7

Redhat Linux 5 (Until March 31, 2017. See extended support )

Redhat Enterprise Linux 6

Redhat Enterprise Linux 7

Redhat Enterprise Linux 8

CloudLinux 6

CloudLinux 7

Amazon Linux 2

Trixbox 2.8

Beta versions are unsupported.

For other platforms, please see our rules only product at the URL below. The rules only product will protection your web applications from attack. More information is available at the URL below:

https://www.atomicorp.com/amember/cart/index/search?q=rules

Note: ASL requires software package management, which all of the supported operating systems provide. If package management has been disabled on your system, you will not be able to install ASL. Older versions of these distributions are not supported.

Please note that when an operating system or distribution is no longer supported by the vendor we also no longer support that operating system unless you have an extended support contract from us, for that platform. Please contact [email protected] if you need an extended support contract.

ASL can block incoming connections by hostname or domain. To enable this feature, set this option to yes:

https://wiki.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_01_DOMAIN_BLOCKS

Once that is enabled, then click on the ASL tab in the ASL web interface, then select Blocking, and then the Domains tab. Add your custom domains or hostnames into the interface one entry at a time. Matching is by string, regular expressions are not supported.

Please note that because matching is by string, users should be careful to use a fully defined hostname or DNS zone entry. For example, if a user wanted to block example.com the correct entry format would be:

.example.com

And not "example.com". example.com will match any entry that contains example.com, including other zones, such as anotherexample.com. If you want to limit a domain you must you DNS zone delimiter ".", as in the example above.

If using a hostname, a hostnames should be defined fully, for example:

www.example.com

This system works by performing a reverse lookup on the incoming hosts IP address. Therefore the system must have a working DNS server, and a local resolver is highly recommended for performance purposes. Remote DNS servers are recommended as they will introduce delays into the resolution process and this will result in degraded performance of the system.

If the DNS lookup returns a hostname or domain name that matches a hostname, or domain that is on the custom domain blocking then the client will be blocked. If the IP address does not have a PTR record, then the IP address will not be blocked.

Note: This feature is currently only available for HTTP and HTTPs protocols that are protected by the ASL embedded WAF, the ASL transparent WAF or the ASL reverse proxy WAF.

This article provides steps on how to remove an agent from the AEO Manager.

Step 1: Use the manage agents service to remove the agent from the Manager. Provide the ID of the agent you want to remove:

[root@atomic-manager ~]# /var/ossec/bin/manage_agents***************************************** OSSEC HIDS v4.0.0 Agent manager. ** The following options are available: ***************************************** (A)dd an agent (A). (E)xtract key for an agent (E). (L)ist already added agents (L). (R)emove an agent (R). (Q)uit.Choose your action: A,E,L,R or Q: RAvailable agents: ID: 001, Name: DEFAULT_LOCAL_AGENT, IP: 127.0.0.1 ID: 002, Name: linux-agent, IP: any ID: 003, Name: windows-agent, IP: anyProvide the ID of the agent to be removed (or '\q' to quit):

Step 2: Remove the line with the agent id in /var/ossec/etc/client.keys:

[root@atomic-manager ~]# vi /var/ossec/etc/client.keys001 DEFAULT_LOCAL_AGENT 127.0.0.1 46760643808e75da0f8208993905458fc36d6297bff9eff475eeb5ea25677033002 linux-agent any dbd752e9b9c9d3511c8fd11734e2b48efba7087e8b0cf1e76daf96b4d6456d5d003 windows-agent any aa87a8e874c8e83e5c4afa993c40607d1bae21e884b1a44b66367e61b4e2d0cc

move the cursor to the line of the agent that was removed. Type: dd to remove the agent. Then hit esc : x

so that it saves the changes and exits the file.

Step 3: Restart OSSEC

service ossec-hids restart

This can mean:

The license manager username and/or password is incorrect and you need to configure ASL to use the correct credentials.

The username and/or the password is incorrect and you need to configure ASL to use the current credentials.

You do not have a license for ASL and/or the license is expired.

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

If you need to reset the network firewall on your system to the defaults, run these commands as root:

service asl-firewall stop

rm -f /etc/asl/firewall/asl_stop.fw

service asl-firewall start

Note: Do not enable or use the iptables or firewalld services. asl-firewall replaces both the iptables and firewalld services. Enabling or starting these services will break your systems firewall and will likely prevent you from accessing the system.

We understand and sympathize that occasionally a subscription might expire. Luckily, there are several options to deal with this issue:

Payflow ("Pay with your credit card" option when you purchased):If you used this option, just follow these simple steps to get it reactivated:

Log in to your license manager at: www.atomicorp.com/amember/member

Click on the "Update Credit Card Info" link.

Once you've supplied your new credit card info, open a ticket or send an email to: [email protected] and provide your username and subscription ID so that we can make sure the subscription reactivated.

Bluesnap:If you paid via Bluesnap (option 2 on the payment list during checkout), you will need to do the following:

Update your credit card information in Bluesnap

Once updated, open a ticket or send an email to: [email protected] with your username and/or subscription ID and we will be able to reactivate your subscription and resume your normal billing.

PayPal:If you used PayPal (last option on the checkout list) unfortunately we're not able to reactivate a subscription once PayPal has canceled it. If this happens, you will need to do the following:

Login to your license manager at: www.atomicorp.com/amember/member

Click on the "Add/Renew Licenses" tab

Select your desired subscription type, and add to your basket.

Proceed to checkout, and follow the steps that it gives you. We recommend the Payflow or Bluesnap options to prevent this from happening in the future.

Step 1: Setup support for custom rules by running these commands as root:

cd /etc/httpd/conf.d

wget https://www.atomicorp.com/examples/01_modsecurity.conf

mkdir /etc/httpd/modsecurity.custom.d

cd /etc/httpd/modsecurity.custom.d

wget https://www.atomicorp.com/examples/99_zzz_custom.conf

Step 2: Choose the URL you want to exclude, in the example below "/administrator" is used.

Add the below to the file /etc/httpd/modsecurity.custom.d/ 99_zzz_custom.conf

<LocationMatch /administrator> SecRuleEngine Off </LocationMatch>

Step 3: check apaches config:service httpd configtestIf you get no errors, restart apache:Step 4: Restart apache

service httpd restart

If you report a false positive we generally release a fix for the issue the same business day. If you aren't sure if something ASL has detected is malicious or may just be a false positive, report it to us. Consider us your Security Gurus - we'll figure it out for you, and let you know.

Please make sure you are running the most up to date version of the real time rules before reporting a false positive. We publish updates several times a day, and its possible your issue may have already been resolved.

If ASL blocks something it shouldn't you can report a False Positive to our support team by simply clicking the "False Positive" button in the GUI. You will find this button on the right side in the event details windows. You can pull up an event details window by clicking on the the specific event you wish to view in the main ASL GUI screen.

This will open up a case in the support portal, and if you have setup a support portal account your False Positive will be added to your account for review. If you have ASL configured to send alerts to one of the email addresses associated with your account then you will see your False Positives show up in real time in the support portal. If not, then a member of our support team will have to manually associate your reports with your account and this can take some time.

If you can not use the GUI to report a false positive or you are a rules only member(and therefore do not have the ASL GUI), you can report false positives from the command line. For example, if you have an event like this in your /var/log/httpd/audit_log file:

[modsecurity] [client 1.2.3.4] [domain yourdomain.com] [403] [/20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa] [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "224"] [id "340026"] [rev "49"] [msg "Atomicorp.com WAF Rules: PHP Injection attempt in URI"] [data ""] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/ " against "MATCHED_VAR" required.

The fourth variable, highlighted above as [/20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa], is the unique token for the event. If you have ASL installed, you can report it with this command:

asl --report-false-positive /20091115/20091115-1635/20091115-163542-rM-wwlKl8i4AACHwQ70AAAAa

This method uses e-mail to send the false positive, so make sure your system can send email out and check your mail logs to ensure that email is being delivered to our servers. ASL does not control or manage email on your system.

[ 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:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#If_you_are_installing_ASL_for_the_first_time

[ 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 yourlicense 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 ]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.

[ 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 gigabitis 134217728

1 gigabyteis 1073741824 (or 8 times a gigabit, which is 134217728)

The default is 1gigabit, 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, butisn'tlogging 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:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#This_version_of_the_ClamAV_engine_is_outdated.

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

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

If you are not using the ASL kernel, then ASL has nothing to do with the segfault in PHP.

Example error messages:

Mar 6 19:25:39 host kernel: grsec: From 1.2.3.4: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/local/cpanel/3rdparty/php/54/zendopt/ZendGuardLoader.so by /usr/local/cpanel/3rdparty/php/54/bin/php-cgi[php-cgi:13019] uid/euid:614/614 gid/egid:615/615, parent /usr/local/cpanel/cpsrvd-ssl[cpsrvd-ssl:13018] uid/euid:614/614 gid/egid:615/615

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 could lead to a full or partial 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 attackers can use to partially or fully 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 your operating system does not manage this software dynamically and ASL can not automatically 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 locally compiled source builds that location may and often is different. For example, cpanel usually locally compiles PHP from source and places it in locations similar to the list below (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 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_error_messages#mprotect.28.29:_13_.28Permission_denied.29

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#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 in 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.

paxctl -mps /path/to/java/bin/java

Where /path/to/java/bin/java is the path to your java vinary, for example:

paxctl -mps /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java

And do the same for tomcat, for example:

paxctl -mps /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:

paxctl -emrspx /usr/bin/gcj-dbtool

gcj-dbtool segfaults

Please see the above FAQ question.

execheap segfaults

See this article:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

execstack segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

execbss segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

execdata segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

shlibbss segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

shlibdata segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

anonmap segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

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:

Apache

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

OSSEC is using a lot of drive space

Discussion

OSSEC can report what changed in a file, and can keep a record of all the changes that have occured with that file. It will keep these "diffs" in this directory:

/var/ossec/queue/diff/local

This can be particularly helpful in determining if a change is authorized or not, and its also an excellent way to maintain a real time record of file or directory to allow for change and revision control as well as a real time back up of these files. For example, OSSEC can tell you that a particular configuration option was removed or changed in a file, and can report those literal changes (as opposed to just an md5sum as with basic file integrity checks). ASL will report what information has been altered and what the original and new information is (for example, with password files). This uses more resources, such as drive space to store all of this change information.

In other cases, with log files for example, this type of diffing can take up a lot of drive space and is not useful. ASL excludes common log files used in standard systems.

Solution

If your system is recording all of the changes on files or directories where you do not wish ASL to record "diffs", log into the ASL gui and check your file integrity configuration for the "Report" option. If a directory is configured to "report", OSSEC will report the details of the change to you (it will generate a "diff"), and will store a record of all changes that occur over time.

Step 1: Log into the ASL web console

Step 2: Click on the ASL tab

Step 3: Click the File Integrity option

Step 4: Click on "Watch Rules"

Select the directory you want to modify. To turn off reporting (or generating diffs), set the "Report" option for the directory to "no". Then click "save changes".

Note: This will not delete the old diffs. You will have to manually remove those diffs. Do not remove the /var/ossec/queue/diff/local/ directory. Only remove subdirectories within that directory. You can also control how many days the system will keep these records with this setting:

https://wiki.atomicorp.com/wiki/index.php/ASL_Configuration#HIDS_CLEAN_DIFF

Reporting can use a significant amount of drive space on your system if you are "report"ing on files or directories that change often, such as logs, temporary or cache directories, or if you are using a product that is changing your operating system a lot (some control panels recompile thousands of software packages nightly, and if you are monitoring these pages ASL will correctly report and log these changes).

You can exclude a subdirectory if you still want to report on changes in a directory, such as /etc. To exclude a subdirectory just log into the ASL GUI, click on the ASL tab, click on File Integrity, then click Options, and scroll the bottom. From there click on the "--add rule--" drop down and select "ignore". This will then give you the option to type in the subdirectory you want to exclude. Type in that directory and then click "update".

Also, ASL will rotate the logs according to your logrotate policy. That policy file is:

/etc/logrotate.d/ossec-hids

You can change the parameters of this file to suit your needs. In general, the logs files themselves are very small. The primary file space usage will be coming from "report"ing events where "diffs" of changed files are stored.

You can also delete these diffs by running this command as root:

rm -rf /var/ossec/queue/diff/local/*

This means you have a third party installation of modsecurity that is attempting load modsecurity twice, and is likely breaking your current modsecurity installation with multiple potentially conflicting configuration settings for modsecurity. Remove and disable any third party modsecurity installations.

If you are seeing errors like this with PHP 7.x:

Dec 21 14:53:18 web kernel: PAX: terminating task: /opt/plesk/php/7.2/sbin/php-fpm(php-fpm):63667, uid/euid: 10000/10000, PC: 00000349116fc010, SP: 000003a221f93d18

This means that PHP is trying to violate the kernels memory protection features. Unfortunately, PHP 7 needs to operate in this insecure manner. To allow PHP to operate this way, follow the steps below:

1) stop your web server and php handlers

For example, on a Plesk system you would shut down apache and the php handlers for the system. If the system only had a php 7.2 handler, then you would run these command:

service httpd stop

service plesk-php72-fpm stop

If you are running additional php handlers, you will need to stop them as well.

2) Configure the system to allow php to run insecurely

Using the example log message above, the php handler is " /opt/plesk/php/7.2/sbin/php-fpm". Run this command as root:

paxctl -m /opt/plesk/php/7.2/sbin/php-fpm

If you get this message when you run that command:

does not have a PT_PAX_FLAGS program header, try conversion

Or something similar, then run this command:

paxctl -c /opt/plesk/php/7.2/sbin/php-fpm

Then run:

paxctl -m /opt/plesk/php/7.2/sbin/php-fpm

3) start apache and your php handler again

service httpd start

service plesk-php72-fpm start

In order to add a hostname or IP to the dynamic whitelist, you must first add the hostname or IP in the file: /etc/asl/dyn-whitelist. This can be done via the command line on your server. You will need to be logged in a root or have the correct permissions.

EXAMPLE:

vim /etc/asl/dyn-whitelist

You must also go into the /etc/asl/config file and search for theFW_DYN_WHITELIST line and make sure to set it to "yes".

vim /etc/asl/config

A cron job is used on the server that will add this hostname or IP. When you are finished with the steps above, please run this command so the updated information is implemented.

asl -s -f

2 302 Core::distributed_update remote fail: E_CONNECT 28 .. www3.atomicorp.com/channels/rules/VERSION

3 301 Core::check_versions ASL Version list could not be retrieved.

If you see errors such as the ones above, it means that the client cannot connect to our servers. It is a common server-related issue caused by the use of an invalid proxy or incorrect proxy set up on behalf of the client. It could also mean that a third party firewall module or rule is blocking access upstream. Please have the client verify that they do not have any firewall rules or modules blocking access upstream and that they are using a VALID and WORKING proxy server.

abrtd errors

abrtd is a product by Redhat.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-abrt.html

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

[ edit ]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.

[ edit ]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

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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 [8]. 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 [9]. The escapeshellcmd function also needs to be available or sending mail will fail without any error messages.

[ edit ]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.

[ edit ]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

[ edit ]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

[ edit ]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

[ edit ]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.

[ edit ]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

[ edit ]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 this command:

paxctl -mps /path/to/java/bin/java

Where /path/to/java/bin/java is the path to your java vinary, for example:

paxctl -mps /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java

[ edit ]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.

[ edit ]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.

[ edit ]up2date issues

[ edit ]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.

[ edit ]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.

[ edit ]yum update errors

[ edit ]Error performing checksum

This usually means that yums cache is out of date, try running this command as root to clear the cache before you run your yum installation or upgrade/update commands:

yum clean all

[ edit ]HTTP Error 401: Authorization Required

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.

[ edit ]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 this command as root:

paxctl -mps /path/to/java/bin/java

Where /path/to/java/bin/java is the path to your java vinary, for example:

paxctl -mps /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java

[ edit ]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 youdon'tknow 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

[ edit ]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.

[ edit ]error: unpacking of archive failed on file /var/asl/etc/httpd/logs: cpio: rename

Context: Updating the tortixd package via aum or yum

Cause: /var/asl/etc/httpd/logs is a directory. This should be a symbolic link to /var/log/tortixd

Step 1) Remove the log directory from /var/asl/etc/httpd/

rm -rf /var/asl/etc/httpd/logs*

Step 2) Update the tortixd package with:

aum -u

[ edit ]Yum Error 401 - Unauthorized on tortix-kernel or tortix-kernel-xen repos

Context: Updating with aum, or yum

Cause: The account is using a VPS subscription, which does not have access to the Kernel channel

Step 1) Log into ASL Web, and select:

Settings->ASL Configuration->General->Kernel Channel

Step 2) Set to "Disabled"

Step 3) Click save changes

[ edit ]Error in PREUN scriptlet in rpm package paxctld-systemd-1.2.1-1.el7.art.x86_64

Context: Updating the paxctld package on EL7, results in duplicate entries

Cause: Package issue with paxctld 1.2.1

Step 1) Log into the system, and become root

Step 2) Run:

rpm -e paxctld-systemd-1.2.1-1.el7.art.x86_64 --justdb

OSSEC directories

[ edit ]/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.

[ edit ]OSSEC messages

[ edit ]Authentication key file '/etc/client.keys' not found.

This messages is normal and harmless, and simply means OSSEC is setup without any remote clients, which is the default. This feature is not currently supported in ASL and will be enabled in a future version.

[ edit ]ERROR: No remote connection configured. Exiting.

This messages is normal and harmless, and simply means OSSEC is setup without any remote clients, which is the default. This feature is not currently supported in ASL and will be enabled in a future version.

[ edit ]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.

[ edit ]MySQL server has gone away

Please see the FAQ below titled "OSSEC-dbd Reports: Lost connection to MySQL server during query".

[ edit ]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

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]Could not establish mysql connection

Please see the FAQ https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Can.27t_connect_to_MySQL_server_on_.27127.0.0.1.27 below.

[ edit ]Starting ossec-hids: [FAILED]

Please see the article below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Command_executed:_.2Fsbin.2Fservice_ossec-hids_restart

[ edit ]2 9901 ASLWCommon::cmd_exec ERROR: '(1) /bin/ps -A | /bin/grep ossec -- '

Please see the article below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Command_executed:_.2Fsbin.2Fservice_ossec-hids_restart

[ edit ]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.

If you just get a single alert, like this:

Command executed: /sbin/service ossec-hids restart Exit value: 0 Signal

number: 0 Dumped core?: 0

Shutting down ossec-hids: [ OK ]

Starting ossec-hids: [ OK ]

And no additional alerts, then everything is fine. ASL just needed to restart OSSEC to apply some software updates to OSSEC.

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.

[ edit ]Solutions

[ edit ]1) ASL not up to date

Upgrade ASL per the upgrade procedure:

Upgrading_ASL

Then run this command:

services ossec-hids restart

If OSSEC starts, your system is working normally. If not, continue with this troubleshooting guide.

[ edit ]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 you have crashed tables, please see this article:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#MYSQL_reports_a_table_is_.22is_marked_as_crashed_and_should_be_repaired.22

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.

[ edit ]3) HIDS rules are not up to date

Run these commands as root:

aum -u

asl -s -f

[ edit ]4) 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.

[ edit ]5) /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. For example a missing or incomplete localhost entry in /etc/hosts (localhost should resolve to 127.0.0.1)

[ edit ]6) 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.

[ edit ]7) 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.

[ edit ]8) 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.

[ edit ]9) 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.

[ edit ]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.

[ edit ]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

[ edit ]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

[ edit ]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

[ edit ]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

[ edit ]psmon

[ edit ]Stopping psmon: [FAILED]

This means that psmon was either not running it an attempt to restart it was issued, or it was not possible to stop psmon. To see if psmon is running, run this command as root:

ps auxwww | grep " /usr/bin/psmon"

If psmon is running, you should see an output similar to this:

root 21851 0.0 0.8 135880 8524? S 17:15 0:00 /usr/bin/perl -w /usr/bin/psmon --daemon --cron

root 21961 0.0 0.0 104744 824 pts/0 S+ 17:21 0:00 grep /usr/bin/psmon

If you are sure psmon is running, try stopping it manually and restarting it manually:

service psmon stop

service psmon start

[ edit ]Checking for psmon installation: not installed [FAILED]

psmon is not supported with cpanel installations with a locally source compiled PERL. If your system is running cpanel, and you have a locally source compiled PERL you will not be able to use the process monitor. cPanel systems that are using package managed PERL are supported.

Note: This error will only occur if you did not have a package managed PERL installation when ASL was installed, or PERL is somehow broken and unable to support PERL packages from rpm. If you have since changed to a package managed PERL, re-run the ASL installer to install PSMON.

[ edit ]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.

[ edit ]If youdon'twant 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

[ edit ]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.

[ edit ]php segfaults

If you are not using the ASL kernel, then ASL has nothing to do with the segfault in PHP.

Example error messages:

Mar 6 19:25:39 host kernel: grsec: From 1.2.3.4: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/local/cpanel/3rdparty/php/54/zendopt/ZendGuardLoader.so by /usr/local/cpanel/3rdparty/php/54/bin/php-cgi[php-cgi:13019] uid/euid:614/614 gid/egid:615/615, parent /usr/local/cpanel/cpsrvd-ssl[cpsrvd-ssl:13018] uid/euid:614/614 gid/egid:615/615

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 could lead to a full or partial 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 attackers can use to partially or fully 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 your operating system does not manage this software dynamically and ASL can not automatically 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 locally compiled source builds that location may and often is different. For example, cpanel usually locally compiles PHP from source and places it in locations similar to the list below (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

[ edit ]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 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_error_messages#mprotect.28.29:_13_.28Permission_denied.29

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#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.

[ edit ]Step 2) Fix the vulnerability in PHP

[ edit ]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.

[ edit ]Option 2) Run ASL in 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

[ edit ]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.

[ edit ]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.

[ edit ]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

[ edit ]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.

paxctl -mps /path/to/java/bin/java

Where /path/to/java/bin/java is the path to your java vinary, for example:

paxctl -mps /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java

And do the same for tomcat, for example:

paxctl -mps /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:

paxctl -emrspx /usr/bin/gcj-dbtool

[ edit ]gcj-dbtool segfaults

Please see the above FAQ question.

[ edit ]execheap segfaults

See this article:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]execstack segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]execbss segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]execdata segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]shlibbss segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]shlibdata segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]anonmap segfaults

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

[ edit ]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:

Apache

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

kernel: xt_lscan: Warning: Pure RST received

[ edit ]If you are using the ASL kernel

This means that the low level portscan detector in ASL has detected a RST packet from a source that does not appear to be associated with an active connection. This can happen for at least two know reasons:

The connection is already torn down and the client is continuing to send RST packets to abort the connection, even though it no longer exists. This can occur with bugging IP stacks on clients.

A system is attempting to port scan the system using RST packets to attempt to get the system to report what ports it has open or closed.

This feature in ASL is not enabled by default, and can be disabled in ASL via this setting:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOWLEVEL_PORTSCAN

ASL does not shun these types of connections. This messages is just informational.

[ edit ]If you are not using the ASL kernel

This means that the low level portscan detector in ASL has detected a RST packet from a source that does not appear to be associated with an active connection. This can happen for at least three known reasons:

This could be a bug in the implementation of of the low level portscan detection kernel module. Please contact your kernel vendor before reporting this issue to us to rule out a kernel level bug.

The connection is already torn down and the client is continuing to send RST packets to abort the connection, even though it no longer exists. This can occur with bugging IP stacks on clients.

A system is attempting to port scan the system using RST packets to attempt to get the system to report what ports it has open or closed.

This feature in ASL is not enabled by default, and can be disabled in ASL via this setting:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOWLEVEL_PORTSCAN

ASL does not shun these types of connections. This messages is just informational.

[ edit ]FATAL: Module ip_set not found.

This means you are either using a third party kernel, or an older kernel that does not include the ip_set kernel module. Please ensure you are using the secure ASL kernel to use this feature, or contact your kernel vendor for assistance with this module.

Note: If you do not have this module your system will use the legacy iptables firewall system for large firewall sets, such as blacklists, geoblocking lists, RBLs and other large firewall lists.

[ edit ]/proc/sys/net/ipv6/conf/all/accept_redirects: No such file or directory

This means you are not using the ASL and your third party kernel is either very old, does not support IPv6, or does not understand how to disable redirects. Please contact your kernel vendor for assistance as this error is only caused by the use of third party kernels.

In general this harmless, it simply means that ASL can not disable redirects on your system.

[ edit ]What do the PAX alerts for software in /usr/libexec/paxtest mean?

These messages are benign, and you can ignore them.

Examples:

Exampleif 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

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

[ edit ]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 youwouldnt 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.

[ edit ]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=0x00RST 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.

[ edit ]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.

[ edit ]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 specialreportingcapability 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 justwon'ttell 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.

[ edit ]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.

[ edit ]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.

[ edit ]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

[ edit ]grsec: denied untrusted exec of /path/to/some/application

See below.

[ edit ]grsec: denied untrusted exec

The application is not being allowed to run because it is insecurely configured and ASL has been configured to prevent insecurely configured applications from running.

Specifically, ASL includes a feature called Trusted Path Execution or TPE for short. When Trusted Path Execution (TPE) is enabled (which is the default), it will only allow system applications owned by root to run on the system and only if they are not modifable by any other user except root. This creates a "trusted" set of software, and protects the system from malicious software, malicious uploads, and local attacks such as via web servers, including those that may change applications on the system or replace them with malicious versions.We do not recommend you disable TPE.

If you get this message, that means that either the application is owned by an untrusted user or its directories are writeable by untrusted users (who could then replace the software in that directory, even though they may not own it). This protection helps to prevent untrusted users from uploading malware, rootkits, shells and other malicious software to the system. This also prevents untrusted users from changing applications, replacing them with a trojan, mobidying systems paths or otherwise tampering with these. 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 TPE 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 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 support and we will put a quote together to perform these services 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 looking at this option in ASL:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration#TPE_UNTRUSTED_USERS

Our by running this command as root:

grep untrusted /etc/group

The standard list of untrusted users currently is:

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

These are system users, that is users that programs run as. These users normally run programs run as root, and not as programs owned by themselves.

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 either change this setting in the ASL gui:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ENABLE_TPE

And reboot the machine, or 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.

[ edit ]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.

[ edit ]execution attempt in: <anonymous mapping>

Log example:

Jan 1 12:00:54 hostname kernel: grsec: From 1.2.3.4: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /opt/cpanel/ea-php70/root/usr/bin/lsphp[lsphp:11604] uid/euid:1001/1001 gid/egid:1000/1000, parent /usr/local/lsws/bin/lshttpd.5.0.18[litespeed:11405] uid/euid:99/99 gid/egid:99/99

Jan 1 12:00:54 hostname kernel: PAX: execution attempt in: <anonymous mapping>, 353513ab000-35351426000 353513ab000

Jan 1 12:00:54 hostname kernel: PAX: terminating task: /opt/cpanel/ea-php70/root/usr/bin/lsphp(lsphp):11605, uid/euid: 1001/1001, PC: 00000353513ab010, SP: 000003c83294db38

Jan 1 12:00:54 hostname kernel: PAX: bytes at PC: 41 54 41 55 41 56 41 57 53 48 8b df 48 83 ec 50 48 8b 43 10

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 being used to compromise your system. This may also occur with malicious applications, applications that are misconfigured such as PHP, or applications that do things in a dangerous way. You can read more about this kernel protection capability in this article:

http://pax.grsecurity.net/docs/mprotect.txt

[ edit ]solutions

1) Most Secure

Report this to your vendor that they need to fix the application so it does not need to open this hole in your system. Modern software shouldnt need to do this.

2) Secure

In some cases it may be possible totell 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/cpanel/ea-php70/root/usr/bin/lsphp

If this does not work, your application may require that this hole be opened in the system. Therefore see Option 3 below.

Note: If you update the application, this option may be removed when the software is updated by your vendor and you may need to remove this insecure configuration again.

3) Very Insecure

Warning: Always confirm with your application vendor if this is actually normal and necessary for your application before you make this change! Some vendors simply open these holes in your system because they do not know better. PHP for example does not need to open this hole in your system.

Note: Turning off this protection for your application will make it vulnerable to attacks which can result in the compromise of the application, and potentially access to your system. Modern applications should not need to open this hole in your system.

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/cpanel/ea-php70/root/usr/bin/lsphp

If you get this message when you run that command:

does not have a PT_PAX_FLAGS program header, try conversion

Please see the FAQ below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#does_not_have_a_PT_PAX_FLAGS_program_header.2C_try_conversion

Then run the command:

paxctl -m /path/to/application_or_library

Note:See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Note_on_vulnerable_libraries for guidance on finding vulnerable libraries that attempt to open this hole in your system.

[ edit ]denied RWX mmap of

Note:Java may require you to open other holes in your system, for other applications keep reading this article. If you are attempting to fix Java, please see this article instead:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Java_is_stopped_by_PAX

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 applications that do things in a dangerous way. You can read more about this kernel protection capability in this article:

http://pax.grsecurity.net/docs/mprotect.txt

[ edit ]solutions

1) Most Secure

Report this to your vendor that they need to fix the application so it does not need to open this hole in your system. Modern software shouldnt need to do this.

2) Secure

In some cases it may be possible totell 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.

If you continue to get this message for that application:

denied RWX mmap of

Option 2 will not work for you, please see Option 3 below.

Note: If you update the application, this option may be removed when the software is updated by your vendor and you may need to remove this insecure option again.

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!

Note: Turning off this protection for your application will make it vulnerable to stack, heap and other types of overflow attacks which can result in the compromise of the application, and potentially access to your system. If this application is running as root, then this can open your system to a full root compromise. Modern applications should not need to open this hole in your system.

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

If you get this message when you run that command:

does not have a PT_PAX_FLAGS program header, try conversion

Please see the FAQ below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#does_not_have_a_PT_PAX_FLAGS_program_header.2C_try_conversion

Then run the command:

paxctl -m /path/to/application_or_library

Note:See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Note_on_vulnerable_libraries for guidance on finding vulnerable libraries that attempt to open this hole in your system.

[ edit ]does not have a PT_PAX_FLAGS program header, try conversion

Run this command to set a PT_PAX_FLAGS header on your application:

/sbin/paxctl -c /path/to/your/application

Then run whatever command you were trying to run with paxctl.

[ edit ]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

[ edit ]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.

[ edit ]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

[ edit ]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 systemyou 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

[ edit ]grsec: denied RWX mprotect

If you see log messages that involve the ASLpaxtestapplication suite, for example:

grsec: denied RWX mprotect of /usr/libexec/paxtest/shlibtest2.so

This is harmless, please see this FAQ:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#What_do_the_PAX_alerts_for_software_in_.2Fusr.2Flibexec.2Fpaxtest_mean.3F

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.

[ edit ]solutions

See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#solutions_2 above.

[ edit ]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

Full System Learning

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.

[ edit ]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.

[ edit ]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.

[ edit ]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.

[ edit ]modprobe: FATAL: Could not load /path/to/module No such file or directory

If you are not using the ASL kernel:

Report this error to your kernel vendor. This error is not caused by ASL. ASL is just alerting you to a problem with your third party kernel. It means your third party kernel is does not have a component your system needs.

If you are using the ASL kernel:

This means someone or something removed parts of the ASL kernel. ASL will not remove the kernel or any of its components.

To fix this, you will want to make sure you reinstall the ASL kernel. Please see the kernel article for additional assistance or contact support if you are unable to reinstall your kernel.

[ edit ]insmod: error inserting /path/to/module -1 Operation not permitted

See the below FAQ below.

[ edit ]modprobe: FATAL: Error inserting somemodule (/path/to/module.ko): Operation not permitted

[ edit ]If you are using the ASL kernel

Discussion

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,isn'tsomething most users need, and its extremely unusual to require on a server. We do not recommend you disable this protection.

Solutions

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.

[ edit ]If you are not using the ASL kernel

If you are using a third party kernel (that is not the ASL kernel), then this information is provided as a courtesy. Please contact your kernel vendor for support with this issue.

Solution 1)

This error generally occurs if the system was not rebooted after ASL was installed or if the third party kernel prevents kernel module loading.

Make sure this setting:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ALLOW_kmod_loading

Is set to yes, then reboot the system.

Solution 2)

Some third party kernels include an option to prevent kernel modules from being loaded. To disable this run this command as root:

echo 0 > /proc/sys/kernel/modules_disabled

If this does not work, this means your kernel makes this option immutable. Try solution 1, if Solution 1 did not work, move on to Solution 3.

Solution 3)

Add this line:

kernel.modules_disabled=0

To this file:

/etc/sysctl.conf

And reboot the system.

If none of these options work, please contact your kernel vendor for assistance.

[ edit ]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.

[ edit ]cannot enable executable stack as shared object requires

Examples:

error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied

grsec: From 1.2.3.4: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/NX/lib/libnxcim.so by /usr/NX/bin/nxserver.bin[nxserver.bin:4626] uid/euid:495/495 gid/egid:10038/10038, parent /usr/sbin/sshd[sshd:4622] uid/euid:495/495 gid/egid:10038/10038

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.

[ edit ]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 (youdon'thave 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.

[ edit ]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

Error creating rule: Could not add entry 1.2.3.45.6.7.8 in line XX of file /etc/asl/whitelist to IP list

This means that there is a bogus entry in your /etc/asl/whitelist file. The format of the file is either one IP address per line, or one CIDR per line. For example:

1.2.3.4

5.6.7.8

10.0.0.0/8

Please remove the bogus line, and either run this command on ASL:

asl -f -

Or if you are not using ASL you will need to manually restart apache.

[ edit ][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.

[ edit ]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.

Tuning mod evasive

Please see the Mod_evasive article.

[ edit ]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.

[ edit ][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.

[ edit ]

Start Rootkit Hunter Update ---------------------

This is just the header line for the rootkit hunter email letting you know its updated itself. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking rkhunter data files...

This means rkhunter is updating its data files. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file mirrors.dat [ No update ]

This means rkhunter check for an update to its mirror files. rkhunter uses "mirror" sites to distribute load for its update files. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file programs_bad.dat [ No update ]

This means rkhunter check for an update to its "bad programs" data file. It uses this data to identify known bad programs. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file backdoorports.dat [ No update ]

This means rkhunter check for an update to its "backdoor ports" data file. It uses this data to identify programs that are using TCP or UDP ports known to be used by malicious programs. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file suspscan.dat [ No update ]

This means rkhunter check for an update to its "suspicious programs" data file. It uses this data to identify programs that may be acting in a suspicious manner. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/cn [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/de [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/en [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/tr [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/tr.utf8 [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/zh [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Checking file i18n/zh.utf8 [ No update ]

This means rkhunter check for an update to one of its language translation files it uses to display events in that language. This means there is no update needed for this data file. You do not need to do anything and this event is normal and means rkhunter is working correctly.

Warning: Found passwordless account in passwd file:

This means that a user account may be setup on the system without a password. This could allow someone to log into the system without a password. Whether this is the case depends on if the system allows password logins, and if the account has been locked out by the operating system.

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 means that rkhunter can not access /proc/modules to see what kernel modules are loaded into the system. This can happen if you are using a virtualization solution, such as VPS technologies, that do not provide you with your own kernel and will not let the virtual private server see what modules are loaded on the system. No action is required and there is no solution to this issue. This is expected behavior for VPS systems.

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. This means that rkhunter can not access /lib/modules because it does not exist. It does this to see what kernel modules are loaded into the system. No action is required and there is no solution to this issue. This is expected behavior for VPS systems.

Warning: Package manager verification has failed:

If rkhunter is reporting:

The File Properties have changed

Example:

Current inode: 401101 Stored inode: 395428

This means that since the last time rkhunter ran the files inode has changed. An inode is a data structure used by your operating system (not rkhunter) to represent a filesystem object, which can be one of various things including a file or a directory. Each inode stores the attributes and disk block location(s) of the filesystem object's data. This can mean that either:

1) The file has been moved or copied on the system, and therefore its inode has changed since the last time rkhunter ran, either through an update or some third party action

2) An unauthorized change has occurred to the system, and someone/something has replaced/moved/copied over the file with a different version of the file 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 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 file found:

Linux has a concept of a "hidden file", where when file listing commands, such as "ls" are run by default the file is "hidden". This is used by legitimate programs to store settings, special directories, "swap" files, temporary files and other information that might "clutter" a file listing. File listing commands, such as "ls", can also display these hidden files when told to list "all" files. For example, the "vim" program creates a swap file when it is editing a file, and makes this file "hidden". Example:

/etc/.password.swp

Attackers may also sometimes use this method to "hide" a file or directory from a user hoping to avoid detection. This alert means that rkhunter has found a "hidden" file in a location where it is unusual to find these files. Rkhunter can not tell if the file is malicious or not, and you will need to investigate the file to determine if it is valid or malicious.

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:

confirm that the file is in fact legitimate

the change was authorized

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:[email protected]/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:[email protected]/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:[email protected]/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

Checking directory: not found [FAILED]

That means you have a blank entry in your admin users setting. Check to make sure youdon'thave a blank entry, for example:

foo,,bar

or

foo,

or

foo,bar,

sh: /proc/sys/fs/inotify/max_user_watches: Permission denied

See below.

cmd_system ERROR: '/bin/echo 16384 > /proc/sys/fs/inotify/max_user_watches >/dev/null 2>&1 (1)'

This means that ASL can not increase the number of inotify "watches" on the system. The Linux inotify system provides a mechanism for monitoring filesystem events. Inotify can be used to monitor individual files, or to monitor directories. When a directory is monitored, inotify will return events for the directory itself, and for files inside the directory. ASL uses Inotify to monitor the file system from changes to software, configuration files and other sensitive parts of the operating system in real time.

This error generally occurs on a VPS system where Inotify limits are set on the host, and can not be changed on the guest. Keep in mind that a watch is require for each file in the directory being watched. By default those directories are:

/etc

/var/ossec/active-response

/var/ossec/etc

/var/ossec/agentless

/bin

/lib

/lib64

/opt

/sbin

/usr/bin

/usr/lib

/usr/lib64

/usr/local/bin

/usr/local/lib

/usr/local/sbin

Solutions

1. Increase Inotify Watches on hardware node

On Virtuzzo/Openvz/[VPS] systems it is possible to change the max_user_watches limit on the hardware node only. This will raise the limit for all containers.

Increase the limit on the hardware node:

[root@vz ~]# sysctl -w fs.inotify.max_user_watches=1000000

To save it across reboots, redirect the output to sysctl configuration file:

[root@vz ~]# sysctl -w fs.inotify.max_user_watches=1000000 >> /etc/sysctl.conf

2. Or remove directories from realtime watches (not recommended)

Please see this article:

https://www.atomicorp.com/wiki/index.php?title=File_Integrity#Watch_Rules

Warning: Removing directories from real time watches means ASL will no longer monitor these files for changes nor will it generate alerts or report anything for these directories in the ASL file integrity monitor.

Error: could not find general_firewall_ftp_mod

This means that ASL could not find any FTP modules loaded into the kernel. If this system is a VPS system, then this is expected behavior. VPS systems do not allow the user (including root) to see what modules are loaded into the kernel. There is no solution to this issue except to check to see if the FTP modules are loaded in the VPS host. Until such time as Virtuzzo/OpenVZ allow VPS systems to see the modules loaded into the kernel, there is no solution to this issue.

Solution:

We highly recommend if you are using FTP that you check the VPS host to ensure the FTP kernel modules are loaded to ensure that FTP and firewall rules will work properly. Please see this article for information on FTP modules to check for in the VPS host:

https://www.atomicorp.com/wiki/index.php?title=ASL_Troubleshooting#FTP_not_working

Discussion

If you need to create your own custom rules, do not change the asl*conf files. These files will be overwritten by updates.

The use of "asl" in the filename is also reserved. Do not name custom files with "asl" in the filename, for example, 99_asl_custom.conf. This file may be overwritten or deleted by the rule management system. Do not create custom rules with "asl" in the filename.

Rule Ids for custom rules

For custom rules,you must create your own rule ids which must be unique. The id: fields contain the rule ids. For custom rules you should use the local (internal) use range (see below for the reserved id ranges).Do not use assigned ranges.

These are the reserved ranges:

* 1-99,999; reserved for local (internal) use. Use as you see fit but do not use this range for rules that are distributed to others.

* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs. (deprecated, all rules require assigned ids in 2.7.x and up)

* 200,000-299,999; reserved for rules published at modsecurity.org.

* 300,000-399,999; reserved for rules published by atomicorp.com

* 400,000-419,999; unused (available for reservation).

* 420,000-429,999; reserved for ScallyWhack.

* 430,000-699,999; unused (available for reservation).

* 700,000-799,999; reserved for Ivan Ristic.

* 900,000-999,999; reserved for the Core Rules project.

* 1,000,000 and above; unused (available for reservation).

You can also change the default action for a rule by using the SecRuleActionById directive.

Changing a rule to be detect only by ID

To change a rule to only detect, but not block attacks, simply change the action for the rule with the above directive. For example, to change the action for rule 12345, simply add this rule directive to your custom rules.

SecRuleUpdateActionById 12345 "pass,status:200"

Note 1: this directive must be added after the rule it is modifying has been loaded.

Note 2: This does not work if you are using the redirect action.

Changing a range of rules ot be detect only by ID

This is similar to the method above, however you can define a range of rule IDs. For example, if you want to disable rules 1000-2000:

SecRuleUpdateActionById 1000-2000 "pass,status:200"

Note 1: this directive must be added after the rule it is modifying has been loaded.

Note 2: This does not work if you are using the redirect action.

If you need to customize a rule do not change the asl*conf files. These files will be overwritten by updates.

The use of "asl" in the filename is also reserved. Do not name custom file with "asl" in the filename, for example, 99_asl_custom.conf. This file may be overwritten or deleted by the rule management system. Do not create custom rules with "asl" in the filename.

If you need to change a rule because it is incorrectly blocking something we recommend you report it to use as a False Postive, using the Reporting_False_Positives procedure. If you simply want to modify a rule to perform different actions, then copy the entire rule into your own rule file, and make sure you tell mod_security not to enable the original ASL rule. You can do that by using the mod_security action SecRuleRemoveById. Here is a simple example:

If you had an original rule like this:

SecRule REQUEST_URI "/foo" "t:normalisePath,id:9000,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"

And you want it to block "bar" instead of "foo", then you would copy the entire rule into your own custom rule file. If you are using our rules we recommend you use the filename 99_zzz_custom.conf and change the id: field to an unused ID. You will need to configure Apache to load this file. You should load this file after the *asl*conf rule files have been loaded.

SecRuleRemoveById 9000000

SecRule REQUEST_URI "/bar" "t:normalisePath,id:9999,rev:1,severity:2,msg:'Atomicorp.com WAF Rules: Block /foo'"

Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.

These are the reserved ranges:

* 1-99,999; reserved for local (internal) use. Use as you see fit but do not use this range for rules that are distributed to others.

* 100,000-199,999; reserved for internal use of the engine, to assign to rules that do not have explicit IDs.

* 200,000-299,999; reserved for rules published at modsecurity.org.

* 300,000-399,999; reserved for rules published at gotroot.com.

* 400,000-419,999; unused (available for reservation).

* 420,000-429,999; reserved for ScallyWhack.

* 430,000-699,999; unused (available for reservation).

* 700,000-799,999; reserved for Ivan Ristic.

* 900,000-999,999; reserved for the Core Rules project.

* 1,000,000 and above; unused (available for reservation).

[ edit ]For a domain

[ edit ]Apache

If you just want to customize the rule, or add a supported configuration setting for a domain you will want to add your modifications within the VirtualHost definition for the domain.

If you have a web application that uses the uncommon ";" argument separator, as opposed to the widely used "&" you will want to change SecArgumentSeparator value for that application. You can do this in one of two ways:

1) Globally

If all your applications use the older delimiter, just change the SecArgumentSeparator in the tortix_waf.conf file. Do not change this if your applications use other delimiters.

SecArgumentSeparator ";"

2) Per Application

You can also configure this per application. For example, if your web applications URL is /foo/bar.php you can create a customer rule like this:

<LocationMatch /foo/bar.php>

SecArgumentSeparator ";"

</LocationMatch>

This will only work if modsecurity is loaded before your virtual host definitions. This is the case with most control panels, but some control panels are known to load modsecurity after vhosts are defined. In which case this will fail because Apache will not know how to process this directive (it will need modsecurity loaded to understand what this means). If you get a syntax error, that means your apache configuration is loaded modsecurity after your vhosts are defined. You will need to change your apache configuration to ensure this loading occurs before vhosts are defined.

ASL will automatically configure modsecurity to load first.

Disabling Rules

Important Notes

Note: ASL users should disable rules from the rule manager. There is no need to create custom rules, apache configuration files or other customizations when using ASL, and ASL supports disabling any rule on both a global and per domain basis.

For non-ASL users, LocationMatch and Location do not work for phase:1 rules. Location and LocationMatch are not available in apache until phase:2. If you need to disable a phase:1 rule, use ASL which can disable phase:1 rules on a per domain and global basis.

If you are not using ASL, and need to disable a phase:1 rule, you will need to create a custom rule to do this. This following is an example of a custom rule to do this for rule 123456.

SecRule REQUEST_HEADERS:Host "example.com$" "phase:1,id:91001,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleRemovebyID=123456"

In the example above, "example.com" is the domain to exclude this rule. This custom rule must be loaded before the rule you want to disable.

If you do not know how to create this kind of custom rule, please contact support and we'll put a quote together to help develop these custom rules for you.

Global

Disabling Mod_Security Globally

If you are using ASL, just change this setting:

https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_ENABLED

If you are not using ASL, you will need to do this manually:

Step 1) Disable config file

mv /etc/httpd/conf.d/00_mod_security.conf /etc/httpd/conf.d/00_mod_security.conf.disabled

Step 2) Restart Apache

service httpd restart

Disable Mod_security on a global URL

Step 1) Create a global exclude file

vim /etc/httpd/modsecurity.d/00_custom_exclude.conf

Step 2) Add the LocationMatch for the url to exclude. Example: /server.php

<LocationMatch /server.php>

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

</LocationMatch>

Step 3) Restart apache

service httpd restart

Step 3) Restart apache

service httpd restart

Set a URL to alert only

Step 1) Create a global exclude file

vim /etc/httpd/modsecurity.d/00000_custom_exclude.conf

Step 2) Add a custom rule

In this example the URL is: /foo/bar

Add this line to the file you created in Step 1:

SecRule REQUEST_URI "/foo/bar" "phase:1,id:1000000,t:none,t:lowercase,pass,nolog,noauditlog,ctl:ruleEngine=DetectionOnly"

Important Note: See the section customizing rules below to pick a unique id for your rule above. Duplicate rule ids will cause the rule to not load.

Step 3) Restart apache

service httpd restart

Per domain

Disabling Mod_security per domain

For Plesk Based Systems

For Plesk and similar systems you can also disable modsecurity in the Apache configuration.

Step 1) Edit the vhost/vhost_ssl.conf for the domain

vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf

Step 2) Add the following

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.

Step 3) Add vhost.conf to domain config

Plesk 9:

/usr/local/psa/admin/bin/websrvmng -a

Plesk 10/11:

/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>

Step 4) Restart Apache

service httpd restart

For Cpanel based systems with EasyApache 4

For full information about include file path expectations, see the official cPanel documentation at Modify Apache Virtual Hosts with Include Files

Step 1) Create the following paths, replacing <user> and <domain> with the correct values for your needs:

mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain>

mkdir -p /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain>

Step 2) In each of the above paths, create a file named 'vhost.conf'

Step 3) Add in the lines below to this file:

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

Step 4) After any addition, modification or removal of userdata files, cPanel requires both of the following scripts to be run:

/usr/local/cpanel/scripts/rebuildhttpdconf

/usr/local/cpanel/scripts/restartsrv_httpd

For Cpanel based systems with EasyApache 3

Step 1) Create the custom modsecurity configuration directory for the domain

For example, if the domain is example.com, you would need to create this directory:

mkdir /usr/local/apache/conf/userdata/std/2/username/example.com

Step 2) Create the file vhost.conf in this directory

cd /usr/local/apache/conf/userdata/std/2/username/example.com

touch vhost.conf

Step 3) Add in the lines below to this file:

<IfModule mod_security2.c>

SecRuleEngine Off

</IfModule>

Step 4) Run the vhost includes script, for example if the domains username is "example":

/scripts/ensure_vhost_includes --user=example

Disabling Mod_security per domain for an IP address

For Plesk based systems

For Plesk and similar systems you can also disable modsecurity in the Apache configuration.

Step 1) Edit the vhost/vhost_ssl.conf for the domain

vim /var/www/vhosts/<DOMAINNAME>/conf/vhost.conf

Step 2) Add the following

<IfModule mod_security2.c>

SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"

</IfModule>

Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.

Then restart apache, if you are using Plesk then you will also need follow steps 3 and 4.

Step 3) Add vhost.conf to domain config

Plesk 9:

/usr/local/psa/admin/bin/websrvmng -a

Plesk 10/11:

/usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>

Step 4) Restart Apache

service httpd restart

For cpanel based systems

Step 1) Create the custom modsecurity configuration directory for the domain

For example, if the domain is example.com, you would need to create this directory:

mkdir /usr/local/apache/conf/userdata/std/2/username/example.com

Step 2) Create the file vhost.conf in this directory

cd /usr/local/apache/conf/userdata/std/2/username/example.com

touch vhost.conf

Step 3) Add in the lines below to this file:

<IfModule mod_security2.c>

SecRule REMOTE_ADDR "^1.2.3.4$" "phase:1,t:none,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off,id:9999"

</IfModule>

Note: You must change id: to a number that you have not used for any other custom rules. Customer generated rules should use the range 1-99999. Numbers about 99999 are reserved and will cause conflicts and are not supported.

Step 4) Run the vhost includes script, for example if the domains username is "example":

/scripts/ensure_vhost_includes user=example

Disable a rule for a single domain

If you have ASL installed:

Method 1:

Log into the ASL GUI, and click on the "ASL" tab. Then click "WAF & HIDS Rules", then click the "Rules" tab, then click the "WAF" tab. Type in the rule ID and the rule manager will pull up the rule. Click on the green down error which will pull up the options for this rule.

Type in the hostname into the Text box on the left side of the options you want to exclude the rule for, then click "add".

Keep in mind this is literal, so if you have a vhost with the name "example.com" that serves content for "ftp.example.com" and "www.example.com" you will need to add those FQDNs as well, or a regular expression *.example.com.

Note: You can use regular expressions in this field, but each end of the expression is anchored.

Method 2: Run this command as root:

In ASL v3.x:

asl -dr RULE_ID --vhost www.example.com

Replace RULE_ID with the ID of the rule you want to disable for the vhost. Keep in mind this is literal, so if you have a vhost with the name "example.com" that serves content for "ftp.example.com" and "www.example.com" you will need to add those as well. For example:

asl -dr RULE_ID --vhost www.example.com

asl -dr RULE_ID --vhost ftp.example.com

asl -dr RULE_ID --vhost example.com

In ASL v4:

asl -drv RULE_ID[,RULE_ID...] VHOST[,VHOST...]

or

asl --disable-rule-vhost RULE_ID[,RULE_ID...] VHOST[,VHOST...]

All supplied rules will be disabled on all supplied vhosts.

asl -drv 111111,222222,333333 www.example.com,ftp.example.com,example.com

If you do not have ASL installedyou will have to do this manually:

Step 1) Edit your domains vhost.conf file (the location of this file will vary based on your control panel, contact your control panel vendor for assistance)

vim vhost.conf

Step 2) Add the LocationMatch for the rule to exclude. Example, ruleid 950005

<LocationMatch .*>

<IfModule mod_security2.c>

SecRuleRemoveById 950005

</IfModule>

</LocationMatch>

If you want to disable multiple rules:

Step 2) Add the LocationMatch for the rule to exclude. Example, ruleids 950005 and 950006

<LocationMatch .*>

<IfModule mod_security2.c>

SecRuleRemoveById 950005

SecRuleRemoveById 950006

</IfModule>

</LocationMatch>

Disable a rule for all domains

Method 1:

Log into the ASL GUI, and click on the "Configuration" tab. Then click "Rule Management", then click the "Rules" tab, then click the "WAF" tab. Type in the rule ID and the rule manager will pull up the rule. Click on the green down error which will pull up the options for this rule.

Set "disabled" to yes and click update.

Method 2:

Use ASL utility to disable rule by ID. Example: 950005

asl --disable-rule 950005

Note: This requires that Atomic Secured Linux be installed. If you do not have Atomic Secured Linux installedyou can disable a rule globally manually by adding a rule to your own custom rules files that contains a line similar to this:

<LocationMatch .*>

<IfModule mod_security2.c>

SecRuleRemoveById 340000

</IfModule>

</LocationMatch>

Custom rules should be loaded after atomicorp rules. A good place to add this, again only if you do not have ASL installed, is in the 999_user_exclude.conf file. If you don't have this file, just create it. Then make sure your modsecurity configuration is setup to load this file.

Per IP or network

Disable Mod_security for an IP address

In ASL, just click the "Whitelist" button.

If you are not using ASL, simply add your IP address to the file:

/etc/asl/whitelist

And restart Apache.

Note: For this rule to work, in ASL you must have the MODSEC_00_WHITELIST ruleset enabled.

If you are not using ASL, then you must have the 00_asl_whitelist.conf ruleset loaded.

Whitelist an IP

See above, "Disable Mod_security for an IP address"

Disable a rule by IP or network

You will need to create a custom rule, loaded after all your other rules. Lets say you wanted to exclude rule id 330039 for the network 1.2.0.0/16. You would construct a custom rule like this:

SecRule REMOTE_HOST "@ipmatch 1.2.0.0/16" \

"id:12345,phase:2,t:none,pass,nolog,noauditlog,ctl:ruleRemovebyID=330039"

Note: ipmatch can also use a list, with a combination of IPs and network for example:

@ipmatch 1.2.0.0/16,5.6.7.8,127.0.0.0/8

Warning: If the CIDR is invalid, this may cause a segfault of the mod_security module. Check to make sure your CIDR is valid before use.

Per application

Disable modsecurity for a specific web application

Note: this is not recommended

Add a custom rule (see the section below on creating custom rules ) after all your rules have been loaded. For example, if you wanted to disable modsecurity for the application /foo/bar.cgi you would add a custom rule like this:

<LocationMatch /foo/bar.cgi>

SecRuleEngine Off

</LocationMatch>

The major OS vendors, Redhat, Suse, Ubuntu and others do an excellent job of building Apache correctly. However, all software has bugs, and you should make sure that you are both running the latest updates from your vendor for a currently supported version of operating system from that vendor, and that you have ruled out an actual bug in apache. modsecurity is a complex piece of software, that relies of an even more complex piece of software, Apache, to work correctly. To improve performance, modsecurity will use apaches built in memory caching capabilities, and if there is a bug in these Apache supplied capabilities memory leaks can occur. We always recommend you discuss Apache memory leaks with your OS vendor first.

Please be especially diligent with source builds and Apache builds form non OS vendors. These builds are generally not as well tested, and so far are the only ones we have seen with memory management problems. If you use an Apache build from a non-OS vendor, you should discuss any memory management issues with them first if you have rules out the previous causes, as they are most likely a byproduct of a build error, or a bug in Apache.

Web applications can and do leak memory. Check to make sure your memory leakisn'tfrom a web application. Or a web applicationisn'tamplifying a memory leak in something else.

Solution 1) Install ASL

ASL will setup a correctly built version of modsecurity.

Solution 2) Install a modsecurity build from our rpm repositories.

You can download modsecurity here.

Solution 3) Install asl-lite

Please see the ASL Lite page for details. ASL Lite is unsupported software.

An incorrectly configured modsecurity setup can cause this to happen. Some vendors that install modsecurity with their control panels do so incorrectly, and configure it in a manner that will lead to memory leaks with advanced security rules. The correct solution is to setup modsecurity correctly. There are two ways to do this:

Solution 1) Install ASL.

This will setup modsecurity correctly, and automatically.

Solution 2) Manually configure and setup modsecurity yourself.

Documentation for setting up modsecurity is available on the Atomic ModSecurity Rules page.

If apache is growing and growing in memory usage, and does not stablize please see the checklist below. If apache is simply using more memory, but has stablized (for example, Apache is using 100MB of memory, as opposed to 40MB of memory without modsecurity) this is normal. modsecurity caches the rules, and certain activities to speed up processing. Memory is infinitely faster than your hard drives, and loading the rules from the hard drive would be terrifyingly slow, too slow to be usable.

If you have installed modsecurity either from source, or via some other third party method remove 2.8.0 and use 2.7.7 or 2.9.0. This bug is not fixed in 2.8.0 or in subversion.

Step 1) Disable buggy modsecurity from the plesk interface under server settings

Note: Run these commands in the steps below as the root user.

Step 2) Remove the buggy modsecurity packages

yum remove plesk-modsecurity*

Step 3) Change the rules path to the correct systemwide path in /etc/asl/config

MODSEC_RULES_PATH="/etc/httpd/modsecurity.d"

Step 4) Make a directory for the rules

mkdir /etc/httpd/modsecurity.d

Step 5) Run the Atomicorp Update Manager

aum -u

cpanel

Step 1) Remove 2.8.0 from your system

Disable modsecurity in cpanel and uninstall it (dont worry, the next step will show you how to install a bug free version)

Step 2) Install aum on your system

aum will install modsecurity and keep both modsecurity and your rules up to date, automatically, with stable bug free versions that will never conflict with our rules. Please see the URL below for installation instructions for aum:

https://www.atomicorp.com/wiki/index.php/Downloading_Rules#Just_a_downloader

Note: If you are using an older modsecurity management tool that does not support the faster concurrent logging method, you need to manually configure modsecurity to use the slower serial method as documented at the URL below:

https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Serial_logging

This error is not caused by the rule. It is caused by a buggy version of modsecurity, specifically 2.8.0.2.8.0 has a known critical bug in its IP matching code. It can not properly use IP addresses with rules, as documented in the github bug report below:

https://github.com/SpiderLabs/ModSecurity/issues/706

Do not use 2.8.0.Users should only use the currently supported version of modsecurity documented at the URL below:

https://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules#Minimum_Version_of_Modsecurity_Required_to_use_the_rules

See below if you are using mod_security 2.8.0.

Introduction

Atomic Secured Linux, or ASL for short, is a powerful security suite that will be analyzing actions of your system in real time. For it to work correctly it will need a properly tuned system with reasonable resources. This document outlines the requirements to install ASL, for ASL to function properly and recommendations for ASL to perform optimally.

Requirements

Client

ASL is accessed and managed through a dedicated web console via your web browser. Please see the following FAQ for a list of browsers that ASL is currently supported:

https://www.atomicorp.com/wiki/index.php/ASL_FAQ#What_browsers_does_the_ASL_GUI_work_with.3F

ASL also includes a limited number of command line features.

Server

Operating system

ASL is tested on up to date versions of the supported operating systems. This means that you will need to have all vendor patches installed for ASL to work correctly.

Supported Operating Systems

A listed of supported operating systems is provided at this url:

http://wiki.atomicorp.com/wiki/index.php?title=ASL_FAQ#What_Linux_distributions_do_you_support.3F

OS Updates and patches

ASL is tested on up to date versions of the supported operating systems. This means that you will need to have all vendor patches installed for ASL to install and work correctly.

ASL will not install on a system that is missing vendors updates, and will generate an alert during installation if vendor updates are missing. You must have you system patched and up to date to install ASL.

Third Party modifications to the OS

Third Party modifications to operating system (OS) files are not supported. For example, third party replacement of glibc would not be supported.

Hardware

Memory

ASL requires at least 2 GB of memory. 4 GB of memory is highly recommend to make use of all of ASLs features.

CPU

ASL does not require a 64bit CPU, however the use of 64Bit CPUs is highly recommended.

File systems

ASL disk space requirements

Minimum free disk space requirements per partition:

Directory

Minimum Free Space Required

/var

Varies (see note below.)

/usr

500 MB

/tmp

10 MB (see note below.)

/etc

100 MB

/boot

30 MB (see note 1 and note 2 below.)

ASL will log and record security events on the system. The amount of space required for this will vary depending on the amount of events that occur on your system. ASL will record all of its events in the /var partition. Therefore, you should have adequate free space available in the /var partition for your system. We recommend at least 5GB of space in this partition, but this is a minimum. You should allocate more space if you intend to keep logs for extended periods of time. You may need to increase this depending on the amount of events that occur on your system and the archive period you have set in your ASL Configuration.

ASL components will be installed in the /boot, /usr, /etc and /var partitions. A minimum of 100MB of free space is required to install ASL, and additional space is required in /var as described above.

Third Party yum repositories

ASL is tested and supported with standard installations of the supported OSes, and not with any third party versions of software.

Database

Supported databases

Centos

ASL is supported with the official versions from Centos for that distribution.

Centos 7

ASL is supported with Mariadb 5 and 10 .

Redhat

ASL is supported on RHEL 5, 6 and 7 with the official versions from Redhat for that distribution.

Cloud Linux

CloudLinux 5 and 6

ASL is supported with the official versions from Centos for that distribution.

CloudLinux 7

ASL is supported with Mariadb 5 and 10 .

Third Party versions

ASL also works with the following versions of CPanels mysql rpms, where CPanel currently supports them for that OS and architecture:

MySQL50

MySQL51

MySQL55

Note: CPanel does not follow package management or MySQL norms or standards. Unlike other MySQL vendors and packagers, CPanel makes non-standard changes to their MySQL rpms as they change both these packages, and what they include. We encourage our customers to contact CPanel regarding any issues with CPanels mysql packages or to use MySQL from one of the vendors above.

ASL is not tested or supported with any other mysq, mariadb or other variants builds or versions not documented above.

MySQL Configuration

old_passwords

This should not be enabled in mysql. If you have this enabled, for example:

old_passwords = 1

Disable or remove this option.

mysql root credentials

You will need your mysql root (superuser) credentials to install ASL. Please note that if your system is setup to only allow logins to your mysql superuser account from a specific IP, or from socket connections only, you will need to change this to allow logins as your mysql superuser account from the source IP address you configure ASL to use. If you use 127.0.0.1 as your mysql address (Recommended), then ASL will use 127.0.0.1 as your source IP. If you use a non-localhost IP, then you will need to configure mysql to use

Note: one Plesk systems the mysql root (superuser) name is changed by Plesk to "admin". Please contact Parallels if you have questions.

skip-name-resolve

Do not enable skip-name-resolve. If you have skip-name-resolve enabled in mysql, then mysql will not resolve localhost and network logins will always fail if you have mysql configured to only allow superuser logins from "localhost". You will find that command line logins work, provided a host IP is not provided (127.0.0.1) as mysql treats localhost as file socket only.

Query caching

When using mysql, querying caching must be enabled. The following setting in mysql must be set for ASL to perform correctly. Failure to set this will result in significant performance impact to ASL, and the system.

query_cache_size=32m

This information is provided as a courtesy, to add this setting to mysql please look for this section:

[mysqld]

in your /etc/my.cnf file.

In this section you will want to add the query_cache configuration setting. For example:

query_cache_size=32m

And then restart mysqld.

If you are not comfortable with configuring mysql, please contact a qualified MySQL administrator for assistance. And in all cases, we recommend you make a backup of any configuration file before you change it.

skip-networking

mysql must not be started with --skip-networking. ASL chroots itself, and will use the localhost network socket to talk to mysql, and not the file system socket. Therefore, networking must be enabled in mysql.

max_connections

Setting this too low will cause unnecessary timeouts of the database and will adversely impact ASL, including but not limited to shunning, the event reporting system, GUI, search engine and other database driven elements of ASL as documented at the URL below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#OSSEC-dbd_Reports:_Lost_connection_to_MySQL_server_during_query

This should be set at a minimum to the number of concurrent mysql connections you would expect your mysql server to handle at its busiest. If you continue to get lost connection errors, you will need to increase this limit. For example:

max_connections = 2048

wait_timeout

Setting this too low will cause unnecessary timeouts of the database and will adversely impact ASL, including but not limited to shunning, the event reporting system, GUI, search engine and other database driven elements of ASL as documented at the URL below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#OSSEC-dbd_Reports:_Lost_connection_to_MySQL_server_during_query

This should be set to 28800 or higher:

wait_timeout=28800

interactive_timeout

Setting this too low will cause unnecessary timeouts of the database and will adversely impact ASL, including but not limited to shunning, the event reporting system, GUI, search engine and other database driven elements of ASL as documented at the URL below:

https://www.atomicorp.com/wiki/index.php/ASL_error_messages#OSSEC-dbd_Reports:_Lost_connection_to_MySQL_server_during_query

This should be set to 28800 or higher:

interactive_timeout = 28800

MySQL tuning

ASL is tested with a standard MySQL configuration with query_caching enabled, as described above. If you have made additional changes to the configuration of MySQL these may be sub-optimal for ASL. Please consult a qualified MySQL expert for assistance with MySQL performance issues if you have made additional changes to the configuration of MySQL and experience performance issues.

Additional

VPS

kernel

VPS systems, that is virtual private servers using Virtuzzo or OpenVZ will not have their own kernel (a VPS shares the hosts kernel). Therefore, there is no free space requirement on a VPS for /boot as the kernel will not be installed.

firewall

Note: Most hosting providers provide fully functional openvz and Virtuzzo containers, however some providers provided limited containers with very limited firewall capabilities. If your firewall does not start, then your container may be on of these limited systems.

Please see this Odin KB article to configure your openvz/Virtuzzo hardware node:

http://kb.odin.com/en/113000

CPanel

If you have CPanel installed, you must have mod_uniqueid installed for mod_security to work correctly. Please contact CPanel for support if you are not sure how to enable this in CPanel.

Support software

shell

ASL does include some shell scripts. These shell scripts are "bash" shell scripts. If the default shell on the system has been changed from bash to some other shell these scripts may not work correctly. Therefore, ASL is only supported on systems where bash is configured as the default shell.

wget

To install ASL you must have a working copy of wget installed on your system, with working HTTPS support (this means your version of wget supports SSL, which ASL uses to download all the software it needs securely). All of the supported OSes above include HTTPS support in wget. However some third party products and hosting companies have been known to replace wget with crippled versions that do not support HTTPS. ASL will not install correctly if your system has been crippled in this manner.

To test if your wget supports HTTPS you can run this command:

wget https://www.atomicorp.com/test-file.html

If your wget supports SSL it will download the file test-file.html, and if you examine the contents of the file you will see this sentence:

If you can read this, your test worked.

If you do not see this sentence, then your wget likely does not support SSL. If you see an error like this:

HTTPS support not compiled in.

Your wget does not support SSL. This means someone has crippled your system and replaced the wget from your OS vendor with a crippled version of wget. They may have also replaced other critical parts of your OS with damaged and crippled software and your system will not be able to install and use ASL.

This means your system can not securely download software, which is a serious vulnerability. You will need to contact the parties that have crippled your system for a solution to replace the crippled version of wget they have installed on your system with a non-crippled version that supports SSL.

If you see an error like this:

Resolving www.atomicorp.com... failed: Name or service not known.

That means your system does not have DNS setup, or otherwise can not resolve our server. Please contact your hosting provider for assistance with DNS on your system.

Third Party Software

OSSEC

Do not install OSSEC from third party sources. ASL will replace and manage OSSEC on your system. ASL is not supported with third party sources for OSSEC.

If you have any third party software of this nature installed, and have issues using or installing ASL, you will need to uninstall this third party software or disable these features in those products.

rkhunter

Do not install rkhunter from third party sources. ASL will manage rkhunter on your system. ASL is not supported with third party sources for rkhunter, and third party or worse parallel installs of rkhunter are known to break rkhunter and its databases.

If you have any third party software of this nature installed, and have issues using rkhunter or installing ASL, you will need to uninstall this third party software.

clamav

ASL will install clamav on your system with the latest version of clamav, and will manage clamav for you. ASL is not supported with third party sources for clamav. Do not install clamav from third party sources.

If you have any third party software of this nature installed, and have issues using or installing ASL, you will need to uninstall this third party software or disable these features in those products.

modsecurity

Do not install modsecurity using any third party tools. If you have done this in the past, remove modsecurity, disable its installation in your control panel (if you are using a control panel), remove any rules and third party add ons, and completely remove your modsecurity configuration from your system.

Note: Do not enable modsecurity in cpanel. This will cause cpanel to overwrite the enhanced modsecurity and will cause duplicate rules to be installed on your system.

ASL is not supported with any third party software that manipulates modsecurity. If you have any third party software of this nature installed, and have issues using or installing ASL, you must uninstall all third party software that installs, configures or manipulates modsecurity before you install ASL.

Note: if you are using Litespeed, you do not have modsecurity installed on your system. You may have a module from Litespeed that acts like modsecurity. You do not need that module, please remove it and follow the instructions in the Litespeed article to setup Litespeed with the T-WAF. Litespeeds must be protected with the T-WAF, as Litespeeds module does not support the full rule language and will leave your system open to attacks their module can not protect you from. The T-WAF will fully protect Litespeed.

firewalls

In Linux you can only safely use one tool to manage your firewall. If you have multiple tools all trying to do the same thing, they absolutely will conflict with each other. For this reason, if you use a third party firewall with ASL, then you can not use ASL to manage your firewall as well. It absolutely will cause conflicts.

Therefore, ASL is not supported with any third party software that manipulates or manages the Linux firewall, iptables or ipset. This includes third party firewall management tools, such as CSF, APF, Parallels Firewall tools, the iptables service (not the iptables command line tools, just the service), firewalld, and any other firewall management tools. ASL includes a powerful firewall and kernel enhancements to the Linux firewall system (netfilter) that these tools do not support. The use of third party firewall tools is unnecessary and redundant.

If you have any third party software of this nature installed you will need to:

uninstall this third party software before you install ASL, or if you can not uninstall it you must disable any firewall features in these products.

remove all firewall rules implemented by these products

You also can not use third party firewall management tools to change the firewall on the system, for example fwbuilder. Only the use of the ASL firewall manager is supported with ASL.

If you installed ASL with any third product firewall you will need to remove it, and any firewall rules it has implemented on your system, and reinstall ASL.

If you want to use a third party firewall with ASL, then you must disable the ASL firewall and active response and any firewall related issues will be unsupported.

iptables daemon

Disable the iptables service.

You will not need to run the iptables daemon service with ASL (the iptables command line tools are fine. Do not remove the iptables command line tools). Running the iptables service will cause conflicts. Please make sure you have disabled the iptables service on your system:

service stop iptables

chkconfig --del iptables

If you had this service enabled when you installed ASL, you will experience problems with your firewall. You will need to disable the service, as described above, and flush any remaining firewall rules. Please follow the process below:

Step 1) Disable iptables

service iptables stop

chkconfig --del iptables

Step 2) Stop the ASL firewall

service asl-firewall stop

Step 3) Flush any remaining firewall rules

rm /etc/asl/firewall/running.fw

Step 4) Restart the ASL firewall

service asl-firewall start

Apache

ASL is fully compatible with Apache 2.0, 2.2, and 2.4. ASL will automatically install the WAF module into Apache for standard supported OS vendor Apache builds, and supported control panel builds.

PHP

The only versions of PHP currently supported by ASL are: Our version, your OS Vendors' version, as well as cPanels' version made through EasyApache.

PERL

The only versions of PERL currently supported by ASL are: Our version and your OS Vendors' official version.

Third part and source installs of PERL are not supported.

ConfigServer

ASL does not support any ConfigServer products. If you have these on your system, they will need to be uninstalled prior to your installation to ensure that ASL installs correctly, and works properly on your system. We have more information on the ConfigServer products located here: https://www.atomicorp.com/wiki/index.php/ASL_FAQ#Is_ASL_compatible_with_ConfigServer

Recommendations

Memory

A minimum of 4 GB of memory is recommended for sites with high volume of events and/or domains. In general, modern Linux systems perform better with more memory, as the Linux kernel will cache file reads speeding up the system and other applications will use memory to further speed up their operations. Memory is a cheap way to speed up a system.

CPU

Multiple 64Bit CPUs are highly recommended for systems with high volume events and/or domains.

Database

bind-address

If you do not need to allow remote access to mysql, then we recommend that you configure mysql to only allow connections from the local host. You can do that by adding this configuration option to /etc/my.cnf:

bind-address=127.0.0.1

And restarting the mysql service.

Query caching

When using mysql, querying caching must be enabled. Larger query caches will result in greater performance, however this must be tuned to the capabilities of the system. Larger query caches also require more memory, so to increase this setting you will need at least 2GB of RAM and preferably 4GB of RAM or more.

For example, on a system with 2GB of RAM the query cache should be set to 128M.

query_cache_size=96m

For systems with 4GB of RAM, or more, a large query cache can be used:

query_cache_size=128m

You can try larger cache sizes, but we find that 128m is generally as high as you need to go. High values may be counter productive.

Dedicated I/O channel

For systems with high volumes of events we recommend you move your mysql databases to their own I/O channel separate from your web sites and/or other file system intensive operations. This will give the database its own dedicated I/O channel to the database files. Databases can be quite large, and the ASL events database will grow over time based on the archive settings you have configured in your ASL Configuration. Therefore, a faster way of reading these databases will improve performance on the system.

mysql tuning

If you are using mysql, we highly recommend you tune it with a professionals help. mysql is a wonderful and powerful database server, but it is not tuned in its default configuration and will perform very poorly as a result. Even if mysql appears to be performing well for you, if you are using the default settings your database server is operating much slower than it needs to be.

You can use the excellent tool mysqltuner to help with this, however this tool will just provide recommendations and an experts assistance should be consulted before making any changes to your mysql configuration, and to make the best use of the recommendations mysqltuner may provide.

To install mysqltuner, please run this command as root:

yum install mysqltuner

And to run it, just run this command:

mysqltuner

More information is available about mysqltuner at this website:

http://www.mysqltuner.com/

Disk Space

/boot

Warning: The 30MB minimum is just that, a minimum.

This the minimum free space necessary to install the ASL kernel (which currently uses approximately 15MB of disk space), and to provide some additional space for a possible upgrade of that kernel. When upgrading kernels ASL will attempt to retain the previous kernels installed on the system, in case there is a need to use older kernels. On systems where a lack of space exists in /boot it may not be possible to either install newer kernels, or keep older kernels. Redhat recommends that /boot be set to a minimum of 250MB to ensure there is adequate space to install and retain kernels.

If your system only has 30MB of space available, you should expect to run into issues in the future with disk space issues on /boot. At best you may only be able to install 2 kernels on your system. We highly recommend you increase the size of /boot to allow for additional kernels to be installed on your system, to provide you with both maximum flexibility as well as a fall back option to earlier kernels should you run into an issue with a different kernel.

/var

ASL follows the Linux standard which is to use /var for any logs. ASL will keep records as long as you desire, therefore the minimum disk space requirements will depend on your data retention requirements. You should monitor your database and /var partitions drive usage and prepare accordingly to add more space based on event volume for your system. If you run out of space in the /var directory, the ASL web console may not work correctly, and other parts of ASL may fail as well.

ASL will also record other events, such as file changes and software updates in a special monitoring system, this data is also stored in /var. Please see the ASL FAQ for further details about tuning this system should you wish to use less drive space for this.

Please see the ASL configuration page for settings to control the amount of days worth of data ASL will keep in the database and in the stored logs in /var/asl:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration

/tmp

Your operating system uses /tmp to process temporary files. For long term use of ASL, and the operating system, /tmp should be as large as necessary for your OS. The actual amount of space needed in your /tmp partition will vary substantially depending on what you are doing with your OS.

ASL needs some amount of free space in /tmp for installation, and may need to use /tmp as part of ongoing activities. However, this partition is primarly used by your OS, not ASL, and a full /tmp partition may result in very adverse effects by your OS. Please contact your OS vendor for assistance with sizing you /tmp partition to meet your OSes needs.

This means that your system is using an out of date version of modsecurity that does not support 2.9.1 and higher rule syntax.

Solutions:

1) Upgrade to ASL. ASL will automatically ensure you have the latest version of modsecurity installed on your system.

2) Use aum, which will automatically ensure you have the latest version of modsecurity installed on your system.

3) use our rpms which are built using 2.9.1, and support remote rules.

4) If you do not wish to upgrade to ASL, use aum, or use our rpms then you will need to manually upgrade modsecurity to at least version 2.9.1, and enable remote rules support when you compile modsecurity.

If you purchase Atomic Secured Linux through Plesk, then you need to install it from your Plesk panel. Navigate to your Plesk Extensions/Addons and you will find it.

If, however you purchased ASL directly from us and not through Plesk you will not be able to install it as an extension inside Plesk and will have to follow our installation instructions.

For example, if you get an error like this:

''ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)''

This means that OSSEC can not connect to mysql. OSSEC, a component in ASL, uses TCP to connect to your mysql server. A number of different things may be the root cause of this error. This checklist provides solutions to the most common causes.

Step 1. If you are running MySQL on the same system as ASL, check to make sure mysql is running, and that its listening on IP address 127.0.0.1.

If you are running MySQL on a remote system, skip this step.

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=mysqlmysql 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 addresses

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 youdon'thave "skip-networking" in your /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 the IP address you configured in ASL

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 ip_address_of_your_mysql_server 3306

For example:

telnet 127.0.0.1 3306

You should see something like this:

Trying 127.0.0.1...Connected to 127.0.0.1.Escape character is '^]'.45.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 addresses

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 your SQL servers IP address, and you still can not connect to it

This is most likely caused by one or more firewalls.

First disable the local firewall to see if you can connect to mysql:

/etc/init.d/iptables stop

If you can connect to mysql, then your local firewall rules need to be adjusted to allow connections to your MySQL server. Please see the ASL_firewall documentation.

If you can not connect to MySQL, then there is another firewall blocking your connection, or a problem with your network that is preventing your system from connecting to that remote system.

The process for upgrading you current subscription type is a very simple process.

Login to your license manager, which is located at: https://atomicorp.com/amember/member

Click the link next to your license that says "upgrade"

That will open up another box that shows you your upgrade options, click the red "Upgrade License" button. That will take you to your chosen payment processor (PayPal or Bluesnap/Plimus) for that license.

Follow the prompts provided by your chosen payment processor to complete payment. Once that's done you will be upgraded to your new license.

Log format

The ASL firewall will log a lot of information about a firewall event. A typical log entry may look like this:

Mar 24 14:11:11 host kernel: DROP_ASL_INPUT IN=eth0 OUT= MAC=00:50:56:bd:76:78:00:a0:c8:26:33:94:08:00 SRC=1.2.3.4 DST=5.6.7.8 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=12197 CE DF MF PROTO=TCP SPT=3619 DPT=110 SEQ=1917628740 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)

Example Element

Explanation

Mar 24 14:11:11

Date/Time Stamp

host

The Hostname of the system where this occurred (your server)

kernel:

Application Name (firewall rules are always kernel:)

DROP_ASL_INPUT

Firewall Rule Name

IN=eth0

Incoming Interface (This is only populated when the packet is coming into the server)

OUT=

Outgoing Interface (This is only populated when the packet is going out of the server)

MAC=00:50:56:bd:76:78:00:a0:c8:26:33:94:08:00

The MAC Address of the last hop upstream hardware that send the packet (usually this will be your upstream router)

SRC=1.2.3.4

Source IP (The IP address for the system that sent this packet)

DST=5.6.7.8

Destination IP (The IP address the source system requested this packet be sent to)

LEN=48

Total length of IP packet in bytes

TOS=0x00

Type Of Service field. This is rarely used, and is replaced on most systems by DS and ECN.

PREC=0x00

The "Precedence" Type of Service field. This is rarely used, and is replaced on most systems by DS and ECN.

TTL=115

Remaining "Time To Live" for this packet in "hops"

ID=12197

Unique ID for this IP datagram. If this is a fragment, all fragments share the same ID.

CE

ECN Flag, Congestion Experienced (optional)

DF

Dont Fragment Flag (optional)

MF

More Fragments to follow (optional)

PROTO=TCP

Protocol (For example, TCP or UDP)

SPT=3619

Source Port (The port the packet came from)

DPT=110

Destination Port (The port the source IP requested the packet go to)

SEQ=1917628740

Receive Sequence number

ACK=0

Same as the Receive Sequence number above, but for the other end of the TCP connection. Normally only seen on the reply packet.

WINDOW=65535

The TCP Receive Window size.

RES=0x00

Reserved bits. This field is used, optionally, for things like ECNE and CWR.

SYN URGP=0

Packet Flags.

OPT (020405B401010402)

TCP Options (optional)

Auditing rules

These rules do not block anything, they just log allowed traffic or special events.

Whitelists

ASL_WHITELIST

This logs when an IP on the firewall whitelist has been allowed to connect to the system. It does not block or shun anything.

ASL only produces these log messages when the following options are enabled:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_WHITELIST

and

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_WHITELIST_LOG

Note: FW_WHITELIST is not enabled by default. This can only occur if you enable this option.

Port Knocking

Advanced Port Knock System

ASL_KNOCK

This logs when a potential knock packet comes in when using the advanced portknocking system. It does not block or shun anything.

ASL_KNOCK_IN

This logs the IP of the source of a client when its connects to a portknock protected port. It does not block or shun anything.

Simple Port Knock System

ASL_SKNOCK

This logs when a potential knock packet comes in when using the simply portknocking system. It does not block or shun anything.

ASL_SKNOCK_IN

This logs the IP of the source of a client when its connects to a portknock protected port. It does not block or shun anything.

Blocking/Dropping rules

Automatic Blocks

ASL_AR_DROP

These rules are labeled in netfilter with "ASL-ACTIVE-RESPONSE" as the label.

ASL has blocked packets from an IP that was shunned by ASL due to a rule violation. By default, these shuns are temporary. You can find out why a shun occurred and remove a shun by following the process in this article:

https://www.atomicorp.com/wiki/index.php/Using_ASL#Why_did_ASL_block_an_IP.3F

You can manually remove a shun by following this process:

https://www.atomicorp.com/wiki/index.php?title=Using_ASL#How_do_you_unblock_an_IP_in_ASL.3F

This capability in ASL is enabled by default, and is controlled by this setting:

https://www.atomicorp.com/wiki/index.php?title=ASL_Configuration#OSSEC_ACTIVE_RESPONSE

Shuns are, by default, automatically removed based on this setting:

https://www.atomicorp.com/wiki/index.php?title=ASL_Configuration#OSSEC_SHUN_ENABLE_TIMEOUT

The timeout to automatically remove shuns is set by this configuration setting:

https://www.atomicorp.com/wiki/index.php?title=ASL_Configuration#OSSEC_SHUN_TIME

Firewall IPS

DROP_ASL: HEARTBEAT

ASL has detected a TLS heartbeat request. This extension to TLS is what caused the HeartBleed vulnerability. This likely means a Heartbleed attack is underway, and ASL has blocked it.

DROP_ASL: DNS_DDOS

ASL has detected an attempt to use your DNS server as a possible DNS DDOS amplifier. This likely means someoneis trying to use your DNS server to launch a DDOS attack against another host, and ASL has blocked this.

DROP_ASL: NTP_DDOS

ASL has detected an attempt to use your NTP server as a possible NTP DDOS amplifier. This likely means someoneis trying to use yourNTP server to launch a DDOS attack against another host, and ASL has blocked this.

User Defined Blocks

DROP_ASL_TORTIX

And IP address has been blocked from connecting the ASL web console based on the IP addresses you have configured to allow access. ASL does not block any IPs by default to the ASL web console.

You can change the IPs you have configured ASL to allow into the ASL web console by editing this file:

/etc/asl/firewall/tortixd-access-list

Then run this command as root:

service asl-firewall restart

ASL_SMTP_OUT

ASL has blocked a user that you have not authorized from sending SMTP traffic outbound. This feature does not prevent users from sending mail out through the systems mail server. It simply prevents them from bypassing the mail server. This feature helps to prevent spam bots from operating on the system.

ASL does not block any users from sending SMTP traffic outbound by default.

Please see this article to change your configuration for this option, if you wish to allow a user to bypass your local mail server:

https://www.atomicorp.com/wiki/index.php?title=ASL_firewall#FW_OUTPUT_MTA

ASL_BLACKLIST_BLOCK

ASL has blocked traffic from an IP that you placed on the ASL blacklist. This blacklist is manually created by the user, and ASL will not add IPs to this blacklist. The blacklist is empty by default.

Blacklists are directional, that is when an IP is blacklisted all traffic to, and from the the IP is blocked. (SRC and DST)

ASL_GEO_BLOCK

ASL has blocked traffic from a country that you have configured ASL to block via ASLs geoblocking. This is manually configured by the user, and ASL will not automatically add countries to the geoblocking lists. No countries are blocked by default.

DROP_ASL_U_RATE

The Ratelimit you configured for this UDP port has been exceeded. ASL does not set any rate limits by default.

DROP_ASL_T_RATE

The Ratelimit you configured for this TCP port has been exceeded. ASL does not set any rate limits by default.

DROP_ASL_INPUT

ASL has dropped an inbound packet because you have configured it to do this. ASL does not block connections to any ports by default.

Please see this setting:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#Inbound.2FOutbound_ports

ASL_OUTPUT

ASL has dropped a packet because you have configured it to do this. ASL does not block outbound connections to any ports by default.

Please see this setting:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_OUTPUT_TCP_SERVICES

RBLS

ASL_TOR_BLOCK

ASL has blocked an IP that is a TOR exit node because you have configured ASL to block tor exit nodes. ASL does not block this by default.

ASL_AUTOSHUN_BLOCK

ASL has blocked an IP that is on the autoshun RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_CIARMY_BLOCK

ASL has blocked an IP that is on the ciarmy RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_DSHIELD_BLOCK

ASL has blocked an IP that is on the dshield RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_ELASSO_BLOCK

ASL has blocked an IP that is on the spamhaus elasso RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_LASSO_BLOCK

ASL has blocked an IP that is on the spamhaus lasso RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_EMERGING_THREATS_BLOCK

ASL has blocked an IP that is on the emerging threats RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_OPENBL_BLOCK

ASL has blocked an IP that is on the openbl RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

ASL_OPENPROXIES_BLOCK

ASL has blocked an IP that is on the openproxies RBL list because you have configured ASL to block IPs from this RBL. ASL does not block this by default.

Bad Packets

ASL_FRAGMENT

ASL has blocked a fragmented packet. ASL, when configured properly, has a stateful firewall that will assemble fragmented packets. If this rule is triggered this means someone has either disabled stateful inspection for user defined rules, or the system is not using the ASL kernel and a third party kernel does not support stateful firewalls.

DROP_ASL_TOOSMALL

ASL has blocked a packet that is too small to be valid.

ASL_INVALID_INPUT

ASL had dropped an incoming invalid packet.

ASL_INVALID_FWD

ASL had dropped an invalid packet in the FORWARD chain.

ASL_INVALID_OUTPUT

ASL had dropped an outgoing invalid packet.

Port scans

DROP_ASL_ADVSCAN

ASL has detected and blocked a portscan using the advanced portscan detector in ASL.

DROP_ASL_PORTSCAN

ASL has detected and blocked a portscan.

DROP_ASL_GSCAN

ASL has detected a potential banner grab portscan.

DROP_ASL_CNSCAN

ASL has detected and blocked a connect() portscan.

DROP_ASL_SSCAN

ASL has detected and blocked a potential SYN portscan.

DROP_ASL_STSCAN

ASL has detected and blocked a stealth portscan.

DROP_ASL_MSS

ASL has detected a packet that is too small to be valid.