ASL FAQ

Atomic Secured Linux Frequently Asked Questions

General Support Questions

How can I buy an Atomic Secured Linux (ASL) license?

To purchase a license for ASL, just visit the Atomic Secured Linux product page and click the Buy Now icon, or click on this link.

Can I try Atomic Secured Linux (ASL) before I purchase it?

Absolutely! We offer a free, no risk 30 day trial. Just click here to get your trial license now!

What is the benefit of Subscribing to ASL?

A: Peace of mind knowing that a team of security experts will work tirelessly to ensure that you have a security solution that will protect your system, and rapid support for all your security needs.

Access to the best Linux security product available, that includes a full SIM with a stand alone web gui, a fully integrated web application firewall, event correlation, intelligent log reduction and alerting, a built in vulnerability scanner with automatic vulnerability repair, virtual patching, compliance monitoring, self healing, anti-spam protection, anti-malware protection, upload malware protection (Web and FTP), realtime malware protection, automatic redation, a secure and hardened kernel, Stack Protection, Heap Protection, a Role Based Access Control system and many many more features!

And most importantly, full support. If we distribute any component, be it a kernel, rules, modules, etc., we will support issues you may have with your integration, with drivers, etc. We focus on building software such as ASL that works on the widest range of hardware, with the most advanced and modern security features that will work on all platforms. This includes firewall extensions for STEALTH and MATCH support, the strongest stack protection in the world, special defenses against kernel module rootkits, cutting edge countermeasures against the latest threats and more!

With ASL, you wont have to do it all yourself, we're here to help you.

What is the SLA for critical security or support issues in ASL?

If there is a security issue with ASL, we will release a fix within 24 hours of the issue being reported to us.

What is included with the support , what is your approx response time?

Email based support for Atomic Secured Linux the same day during normal business hours which are monday-friday from 9am - 5pm EST except on US Federal Holidays.

For extended support customers, the response time is dictated in the support contract and includes after hours support, and may include 24/7 support depending on the support contract.

What are your normal support hours?

Support is available in two forms:

Standard Support

Standard support is included with all our products.

Standard Support is available from 07:00 AM to 07:00 PM, Monday through Friday, US Eastern Time, excluding company holidays.

Support requests received after hours or on holidays will be addressed during the next business day.

Extended support contract holders are still covered during the holidays.

Our holiday schedule is published here: Atomicorp Holiday Schedule.

Extended Support

Extended support is available with an extended support contract.

Extended support is available 24 hours a day, 7 days a week. Extended support contract holders are also covered during company holidays.

If you need extended support please contact us! Just send an email to sales@atomicorp.com.

Do you offer support outside of your normal support coverage?

Yes, for customers with extended support contracts. Please contact sales@atomicorp.com for more information.

Do you offer phone support?

Yes, for customers with existing extended support contracts. Please contact sales@atomicorp.com for more information about extended support contracts.

Phone support is not available without an existing extended support contract.

Help! I need help!

See the ASL Support page for instructions on contacting support, opening a case and other tools you can use to get assistance.

I have a false positive, how do report it?

Solution:

Send the false positive to “support@atomicorp.com” or press the “Report False Positive” button in the ASL GUI. Fps are usually resolved and an update is released the same day they are reported, and during normal business hours usually within a few hours.

You can also follow the Reporting False Positives procedure. That provides detailed instructions about how to report a false positive if you can not use the GUI, or if you choose to report it from the command line.

How can I give atomicorp support access to my system?

Answer:

Please run this command as root to give us access to the system (please do not send us passwords, this tool will set us up access using our SSH keys):

wget -q -O - https://www.atomicorp.com/installers/key |sh

Note: To become root you must run the command "su -".

If you use ASLs admin user feature, or use sshds AllowUsers feature make sure you add the "atomic" user to the allowed users. If our tool does not add the user "atomic" that is because you allow root logins, and the tool will simply add our credentials to the root account.

If you need to open firewall access, we will be logging in from these addresses:

support1.atomicorp.com (70.184.242.83)

support2.atomicorp.com (71.246.237.50)

If this is for an installation, please make sure you also provide us with your mysql administrator credentials in the email.

And finally, remember to send and email to support AT atomicorp DOT com with the IP address(es) of the system(s) you want us to log into, and if you run SSH on a non-standard port please include that information as well.

If you have sent this information to us in the past, please make sure you send it with any new request. We get a lot of requests and its not possible for our support ninjas, as awesome as they are, to always remember everyones details.

How can I remove atomicorp access to my system?

If you followed the process above, just remove the "atomic" user when you are finished, or if you allow root ssh login access then you will need to remove our ssh keys from the /root/.ssh directory. The script above will not provide us with any passwords to your system, it will simply install our keys as the "atomic" user (or if you allow root access, as the "root" user). Removal of those keys will also remove our access to the system.

General ASL Questions

My system has experienced a kernel panic.

Solution:

We have documented several issues that may cause kernel panics on the wiki along with solutions in the Kernel_Panic article.

What should I do if I believe a system has been compromised?

Answer:

First, stop and ask yourself what you want to do. Do you want to prosecute or do you want to just find the problem and fix it? This is a critical question you have to ask yourself because if you want to prosecute you must preserve evidence, and the actions you take to fix the intrusion may destroy or make that evidence inadmissable. If you want to prosecute, contact us to discuss your situation as you may need professional help to build a case. Also, if you choose to prosecute, you should know that in some jurisdictions the personnel working on your case may need special licenses to do this, otherwise they may be committing a felony (Michigan for example requires a Private Investigator license to perform computer forensics that will be used in court, failure to have this license is a felony.)

If you want to find out what happened and just clean up, please continue with this checklist.

First, start with the simple case - the compromise may have occurred by the attacker simply stealing a users password and logging into the system. We have put together a wiki article that provides guidance here for those cases:

Compromised System: FTP

If you know that an attacker did not simply log into the system with stolen credentials please read this Wiki article:

Compromised System

In most cases we have seen, attackers are stealing users passwords and keys via keyloggers and trojans and just logging in. In those cases, there is no technical vulnerability in your system, the issue lies with your users and their computers. So, check you logs first to see if someone simply logged into your account or your users accounts. You'd be surprised at how often we see that happen.

If you find yourself in this situation we recommend you explore two factor authentication options such as SecureID, OTP generators on your cell phone (not on your computer, if the computer has been compromised so has the OTP!) and other hardware tokens.

You can also use an operating system that is more secure for your desktop such as Linux, Solaris, BSD or MacOS.

Do you have pre-defined access policies , or do we have to configure these policies?

A: Yes, currently we use Trusted Path Execution (TPE), and the untrusted users group by default. Members of the untrusted users group can only execute commands owned by root. In addition non-root users can only see processes owned by them. Grsec has an additional RBAC and Process ACL system available.

License questions

How can I upgrade a trial?

Just log into the license manager using the same credentials you used to setup your trial and purchase a license. You don't need to do anything else. The system will automatically convert your system from a trial to a full license, and you won't have to reinstall or install anything.

You can access the license manager at the URL below:

https://www.atomicorp.com/amember/member.php

VPS licenses

1. Do the VPS licenses need to be used on one physical machine or can the VPS boxes be located on different physical machines in different locations?

They can be located on diferent physical machines in different locations, or on the same machine.

2. If we use more than 5 licenses, do we have to add additional licenses 5 at a time, or can we add just 1 at a time after we purchase the initial 5?

Once you have a 5 license pack, you can add single licenses through the license manager.

Reverse Proxying

Can I use ASL as a reverse proxy for my other servers?

No. ASL is not supported or licensed for use as a reverse proxy for other servers. It is only supported for the server it is deployed on.

If you wish to use ASL as a reverse proxy for other servers, please contact us for support. This configuration requires additional modifications depending on the protocols and platforms that will be proxied and we would be happy to help you put together a solution to meet your needs.

Atomic Secured Linux Compatibility Questions

Linux Distributions

What Linux distributions do you support?

As of March 2012, we officially support:

Centos 5 and 6.

Redhat Linux 5 and 6.

Scientific Linux 5 and 6

CloudLinux

Trixbox

Amazon EC2

Support is also available, with an extended support contract, for these platforms:

Centos 4

RHEL 4

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

Also, 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.

Do you support custom builds of apache, or other custom non-standard Linux distributions or hybrids?

Yes, only through extended support contracts. If you do not have an extended support contract there is no support. Please contact sales@atomicorp.com and we can put together a proposal for your project and price out ongoing support for your custom configuration.

What browsers does the ASL GUI work with?

Officially we support:

• Firefox 2.x, 3.x, 4.x and 5.x
• Internet Explorer 6, 7, 8 and 9
• Safari 5.x
• Opera 11.5+

We have unofficial reports that the GUI should work with Opera and Safari and are working to officially test and support these as well.

ASL does not support my version of my operating system

We support versions of operating systems per the list above. Specifically, we only support operating systems which are still supported by the vendor.

We do this because of the serious security issues associated with running an operating system that is no longer supported, as well as the problems associated with lack of bug fixes for platforms that have been abandoned by their Vendors. For example, if a serious vulnerability were to be discovered in openssh and there was no patch for your system, ASL may not be able to protect your system adequately. Some vulnerabilities are beyond even our capabilities to defend against. We are always looking out for your security - and unsupported OSes are a serious risk to operate

For newer versions of operating systems we work as fast as possible to support these new distributions.

Databases

ASL optionally can use a database to store event information (this configuration is highly recommended). ASL uses mysql to do this, and is built to support the version of mysql provided by the vendors of the OSes as described above. It is tested with the software provided by the OS vendor, and therefore, ASL is fully supported with the current version of mysql provided and supported by the OS vendor on the platform. ASL is not tested or supported with non-standard mysql builds or versions.

For example, the current vendor supported version of mysql on Redhat 5 is 5.0. ASL is supported with the current release of mysql provided by the OS vendor.

mysql 5.5 on Redhat 5 would not be supported.

Please contact your OS vendor for details about what versions of MySQL they support.

Control Panels

Does ASL require a control panel?

No, ASL does not require any control panel product (Plesk, Cpanel, etc.). You can use ASL with, or without a control panel. If you do use a control panel, ASL works with all major control panels, and the specific list of supported configurations is provided below.

Plesk

Does ASL work with Plesk?

Absolutely! Atomicorp was founded by two Plesk founders. You won't find a security company that knows more about Plesk, or cares more about making security products that work with Control Panels like Plesk. ASL works with all Plesk versions from 8 to 10, including the latest version of Plesk 10.2.

Can you use ASL without plesk?

Answer:

Yes, ASL uses its own GUI and does not require any control panel to work.

Will I lose any functionality in Plesk if I use ASL?

No. ASL will only add new functionality to your system.

If predefined will your policy fit into a PLESK system? Since Plesk uses its own chroot enforcements on some deamons?

Atomicorp was founded by Plesk founders. ASL is designed to integrate in that environment and with other control panels too.

Directadmin

Yes. ASL works with and is supported with Directadmin.

Note: If you are not using the systems RPMs, and are using a custom built Apache, then you will need to use the currently beta version of ASL for custom Apache environments. You can read more about it here:

https://www.atomicorp.com/forums/viewtopic.php?f=21&t=4828

When you have a custom non-rpm managed Apache install use the installer in the link above.

Virtualmin

ASL works with Virtualmin and is a supported configuration. Please see the Virtualmin page for any notes on using ASL with this product.

CPanel

ASL works with CPanel and is a supported configuration. Please see the Cpanel page for any notes on using ASL with this product.

Interworx

ASL works with Interworx and is a supported configuration. Please see the Interworx page for any notes on using ASL with this product.

Virtualization Technology

Whats supported

Please see this article for the up to date chart of supported Virtualization technologies: ASL 3.0 Virtualization Notes

Web Servers

Apache

ASL is fully compatible with Apache 2.x

LiteSpeed

ASL will work with LiteSpeed, however Litespeed does not support the full modsecurity language, and using the built in modsecurity like capability in litespeed will leave your system open to web attacks. Because of this, the Litespeed modsecurity implementation is not supported.

If you use this web server you must install a WAF before this product, such as apache, otherwise your system will be vulnerable to web attacks.

Please see the Litespeed wiki article for detailed information on LiteSpeed support.

nginx

ASL will work with nginx, however nginx does not support modsecurity nor does it have any Web Application Firewall capability built in. If you use nginx as your web server you must install a web server, such as apache, that supports modsecurity or install a WAF in front of nginx. Otherwise your system will be vulnerable to web attacks.

Web Applications

ASL works with any web application.

General Compatibility questions

Does ASL work with X11/Xorg?

Yes, ASL works with X. To configure ASL with X, please see the X with ASL article.

Installation Questions

General Installation Questions

Is ASL easy to install?

Very! You just run one command and the ASL installer will walk you through a few questions to configure itself for your needs. Just follow the instructions on the ASL installation page.

Is ASL safe to install?

Yes. ASL was designed for high SLA environments and comes with robust support for a company that understands the needs of high SLA environments. ASL has numerous fail safes built into it to make it both easy to install and safe to use. For example, if ASL detects that your kernel has an error on boot, it will reboot the system into the last known working kernel. This a feature no Linux distribution includes, so installing ASL will actually make sure your system more stable and more reliable.

ASL is also easy to uninstall, and is designed to work with your existing operating system and not replace any core components.

Will ASL replace core components of my system?

No. ASL will install additional software on your system, and will not replace anything, including the kernel.

Does ASL need to be installed on a system before Plesk/Cpanel/etc. is installed?

No, ASL can be installed on a system that already has Plesk, Cpanel or any other control panel installed. ASL does not require a bare system, and is designed to be installed into already operating systems that have been configured for use, and have third party software already installed. ASL is an enhancement and can be installed on any supported Linux system.

Does installing ASL require any downtime?

No, ASL does not require you to take your system down. It is designed to be installed on running systems. You will want to reboot the system into the secure kernel, but you can do that any time. ASL will operate normally without the secure kernel, and does not require it to function, however without the secure kernel you will still be vulnerable to the same kernel level weaknesses and vulnerabilities that exist in all non-ASL kernels. Therefore, we recommend that you run the secure kernel, which will require a reboot.

CS4 and ASL

It is OK to install CS4 with ASL?

Answer: Just say "no" when it asks if you want to download and install clamd when you run the installation script. ASL already provides clamd.

Does ASL works with php sites running under fast_cgi ?

Yes, ASL works with systems using fcgi, mod_ruid2, and itk. It also works just fine with systems that use none of these. ASL integrates fully and safely into Apache.

How easy is it with ASL to debug and use modsecurity?

Very easy. ASL includes an easy to use web based graphical interface that allows you to view alerts, modify rules, and report false positives all with one click. We typically can resolve a false positive in less than one hour when reported through the ASL Web interface.

If I face problems with the installation/setup of ASL do you provide support?

Absolutely! We fully support all our products. ASL licenses come with email and web based support, using an easy to use case and bug management system that is associated with your account. You can log in through our support portal directly from the atomicorp website, or via email. Phone support is also available with an extended support contract.

What are the minimum system requirement for ASL?

If all of the ASL security features are turned on, we recommend that your system have a minimum of 1GB of RAM. ASL includes advanced web application and antispam security features that do best with this minimum requirement.

Our servers run without issue with 2GB of RAM on Dual Core P4s or single core AMD 64bit CPUs.

I also had previously installed rkhunter and chkrootkit, should I have uninstalled those prior to installing ASL?

If you installed these via the package management system in your OS no. If you installed these via source, you should remove them.

What is the performance impact of using ASL on a system with 700-1000 domains per server?

A: PaX operates with around a 3-5% of additional overhead on Intel processors. AMD processors implement this in hardware, so there is no additional overhead.

What are testing channels for?

Answer:

For the ASL channels:

Beta releases.

Please keep in mind that testing channels are not supported.

For the Free Atomic Channels:

This is for software that may be of beta quality, but has not be evaluated for security or stability issues. It may also contain rpms that are experimental or buggy and are parked here to allow other researchers to experiment with this software.

Please keep in mind that the atomic channels are not supported. The Atomic repository provides free software.

What are bleeding channels for?

Answer:

Alpha and less releases. You shouldn't use bleeding code unless you are prepared to roll up your sleeves and debug the builds. They are also not supported.

"How to" installation questions

How do I install ASL?

Just follow the instructions on the ASL installation page.

How can I disable ASL?

Step 1) Disable mod_security

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

Step 2) Disable mod_evasive

mv /etc/httpd/conf.d/mod_evasive.conf /etc/httpd/conf.d/mod_evasive.conf.disabled

Step 3) Disable mod_sed

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

Step 4) Disable OSSEC

/etc/init.d/ossec stop

Step 5) Disable clamd

/etc/init.d/clamd stop

Step 6) Restart apache

(Use your method of choice, this is just an example)

/etc/init.d/httpd restart

Step 7) Remove the hardened proftp

 yum remove psa-proftpd-1.3.2a-1.el5.art

Step 8) Boot into a non-ASL Kernel

Configure your system to boot into a non-ASL kernel.

Step 9) Reboot

 reboot

Also, its important to recognize that ASL is a threat manager that repairs vulnerabilities on your system. Disabling ASL will not undo any vulnerability repairs you have instructed ASL to fix. If you want to undo a vulnerability repair in ASL, do not uninstall ASL. Simply change the action in the ASL GUI and run ASL in Fix mode to undo the repair.

How do I remove or uninstall ASL?

Answer for ASL 3.0:

Just run this command as root:

 /var/asl/lib/uninstall

Answer for ASL 2.2:

 yum remove mod_security asl mod_evasive ossec-hids psmon rkhunter skdet unhide paxtest clamd asl-web gradm

Make sure you remove the asl.repo file from the /etc/yum.repos.d/ directory.

You will have to manually configure you system to not boot into the ASL kernel. If you do not know how to do this, please consult a qualified Linux engineer for assistance.

If your license has expired, you may have to tell yum to exclude the asl-2.0 repository. For example:

 yum   --disablerepo=asl-2.0 remove mod_security asl mod_evasive ossec-hids psmon rkhunter skdet unhide paxtest clamd asl-web-gui gradm

Answer for ASL 2.0:

 yum remove mod_security asl mod_evasive ossec-hids psmon rkhunter skdet unhide paxtest clamd asl-web-gui gradm

Make sure you remove the asl.repo file from the /etc/yum.repos.d/ directory.

You will have to manually configure you system to not boot into the ASL kernel. If you do not know how to do this, please consult a qualified Linux engineer for assistance.

How can I migrate ASL to a new server?

Regarding your ASL license you don't need to do anything special. Each ASL license allows you to run ASL on one production system, one QA system and one development system. The licensing manager is also very generous and will allow you a certain amount of overlap, so from a licensing point of you - you don't need to do anything special.

Regarding migration, we recommend you install ASL on the new system and run through the entire configuration process. If you want the ASL configuration to use your other systems configuration then just copy over the /etc/asl/config file to your new system to migrate your settings. Doublecheck them manually to make sure you have everything setup for your needs, if you copy over your config your basically telling the new server to be completely identical to the old one and that may not be exactly right for you.

Once you copy over the config and have everything setup as you want then run this command as root:

asl -s -f

Updates and Upgrading ASL

Signatures & Modules window

The Signatures & Modules window lists the state of all ASL components, such as if they are active, inactive or have updates waiting.

Green: Component is active and up to date.

Yellow: Component is active, but updates are available such as rule, signature or software updates. To force an update just click the "Updates Available" link, or you can wait for ASL to install the updates automatically based on your configuration. (Please see the FAQ below on configuring automatic updates, ASL is configured by default to automatically update all its components).

Red: Component is inactive, either because it has been disabled, or is not installed. For example, if the system is not using the ASL kernel the "Kernel Protection" will show as red. Or if a component has been uninstalled or otherwise removed, such as if mod_security was removed from the system WAF will show as red. ASL looks at the actual condition of the system and is reporting its state in this window. This is a "fail safe" to ensure that the actual state of the system is reported to the user, even if the configuration may be set to one state ASL will independently check the system to see if it really is in this state.

Will ASL automatically update the rules and signatures

Yes, by default it will do this daily. ASL will update all the rules and signatures available automatically. Occasionally you may see ASL report that updates are available. ASL will install these updates for you at the next scheduled interval you have configured for your system. Or you can manually update these by clicking the "Updates Available" link.

Will ASL automatically update itself?

By default, ASL will also automatically keep itself up to date (the core components and the rules). To check this setting, log into the ASL GUI, click on the Configuration Tab and then Click on "ASL Configuration". Scroll down to UPDATE_TYPE and check to make sure it is set to "all".

How can I set the update interval?

Log into the ASL GUI, click on the Configuration Tab and then Click on "ASL Configuration". Scroll down to AUTOMATIC_UPDATES. You can set updates to "none", "hourly" and "daily". The default is "daily".

How can I set ASL to only update the rules and not ASL itself?

If you only want ASL to keep its rules and signatures up to date, but not to automatically upgrade ASL, log into the ASL GUI, click on the Configuration Tab and then Click on "ASL Configuration". Scroll down to UPDATE_TYPE. Then set UPDATE_TYPE to "rules only".

Process to upgrade ASL

Please see the Upgrading_ASL article.

Firewalls and Upgrades/Updates

To allow ASL to download updates, please ensure that any firewall you use allows connections to www.atomicorp.com and updates.atomicorp.com on TCP port 443.

Password Reset Questions

How can I reset my license manager password?

To reset your password, to log into the license manager, please visit this page:

License Manager

How can I reset my support portal account password?

To reset your password, to log into the license manager, please visit this page:

Support Portal Reset

How can I reset my ASL GUI password(s)?

Just run this command as root:

/var/asl/bin/asl-web-password <your user name>

For example, if your username was "jdoe", run this command as root:

/var/asl/bin/asl-web-password jdoe

Note: Your ASL GUI username and password are only used to log into your ASL installation. These are not to be confused with your internal ASL update credentials, which are used by ASL itself to log into the Atomicorp servers to securely download updates for your system. This procedure does not change your internal ASL update credentials.

If you need to change your internal ASL update credentials password, please see the #How_can_I_change_my_ASL_password section.

How can I change my ASL password?

Your ASL username and password are used to log into the Atomicorp servers to download updates. These are not to be confused with your ASL GUI username and password, which is used to log into your ASL GUI. Your ASL username and password credentials are only used by ASL itself to log into the Atomicorp servers to securely download updates for your system.

If you need to change your GUI password, do not follow this procedure. If you need to change your ASL GUI credentials please see the #How_can_I_reset_my_ASL_GUI_password section.

This process is only to change the internal credentials used by ASL to log into the Atomicorp servers.

Step 1) Log into the ASL GUI

Step 2) Click on Configuration

Step 3) Check to make sure the USERNAME and PASSWORD variables are set to your ASL credentials. Those are the credentials you use to log into the license manager:

https://atomicorp.com/support/license-manager.html

If you do not know what those credentials are, you can reset them at the URL above.

Step 4) Then click the "Update" button to update your configuration.

What is the default username and password for ASL Web?

The default username and password are your ASL credentials, that you created when you signed up for a license.

You can also generate usernames and passwords by running this command as root:

 /var/asl/bin/asl-web-setup

And you can also create user accounts from the ASL GUI.

Using ASL

General Usage Questions

Where is the ASL Web GUI?

You can access it on your system at this URL (change www.example.com to either your systems name or IP address)

https://www.example.com:30000

Make sure your firewall is configured to allow access to the TCP port 30000.

Can't connect to ASL Web GUI

Please see the ASL Troubleshooting page which contains a comprehensive list of steps to take to determine the root cause. Often this is caused by not configuring your firewall to allow access to port 30000.

How can I scan for malware?

ASL will ask to perform an initial malware scan when it is installed. If you tell it to perform this scan the results of that scan, once complete, will be available in this file:

/root/asl-malware-scan.log

To scan the system again for malicious software, just run this command as root:

nice -n 20 clamscan --exclude-dir=^/var/ossec/ --exclude-dir=^/usr/share/doc/clamav --exclude-dir=^/var/www/vhosts/.*/statistics/logs/ --exclude-dir=^/sys --exclude-dir=^/dev --exclude-dir=^/proc --exclude-dir=^/var/lib/spamassassin --exclude-dir=^/var/asl --exclude-dir=^/usr/share/w3af --exclude-dir=^/var/lib/openvas/plugins -i -r /

If you wish to quarantine any files that may be found, just add the "--move=" switch. For example, if you want to move quarantined files to the directory /root you would use this command:

nice -n 20 clamscan --exclude-dir=^/var/ossec/ --exclude-dir=^/usr/share/doc/clamav --exclude-dir=^/var/www/vhosts/.*/statistics/logs/ --exclude-dir=^/sys --exclude-dir=^/dev --exclude-dir=^/proc --exclude-dir=^/var/lib/spamassassin --exclude-dir=^/var/asl --exclude-dir=^/usr/share/w3af --exclude-dir=^/var/lib/openvas/plugins --move=/root -i -r /

You can also restrict the amount of I/O the scanner uses by using the ionice command:

nice -n 20 ionice -c 3 clamscan --exclude-dir=^/var/ossec/ --exclude-dir=^/usr/share/doc/clamav --exclude-dir=^/var/www/vhosts/.*/statistics/logs/ --exclude-dir=^/sys --exclude-dir=^/dev --exclude-dir=^/proc --exclude-dir=^/var/lib/spamassassin --exclude-dir=^/var/asl --exclude-dir=^/usr/share/w3af --exclude-dir=^/var/lib/openvas/plugins -i -r /

Blocking/Unblocking an IP/network(s)

How can I tell if ASL is blocking an IP?

If ASL blocks anything, it will log that action. Just log into the ASL GUI, and type in the IP address into the Event: box in the Security Events window.

If you want to find out if ASL has shunned, or firewalled off an IP address previously, just click on the ASL tab, then then select Blocking. Any IP address that ASL is blocking will be listed in that window.

If you have blacklisted an IP, then check the Blacklist window.

And if you are using the geoblocking features, check the Geoblocking window for the list of countries you have configured ASL to block.

How do you whitelist an IP in ASL?

Log into the ASL GUI, click on the ASL tab and select the Blocking menu option. This will open the window of any IPs ASL is blocking. Select the Whitelist tab, and at the bottom of the window type in the IP address or network you wish to whitelist. Then click the "Add to Whitelist" button.

You can also do this from the command by running this command as root:

asl -wl <IP to whitelist>

asl -wl <network to whitelist>

Examples:

asl -wl 111.222.333.444

asl -wl 111.222.333.0/24

Keep in mind that whitelisting an IP means that it will never be shunned by ASL, even if an actual malicious action is launched from the IP. The WAF in ASL will still block the attack if it can detect it, but it will not shun the IP.

How do you bulk add IPs to the whitelist in ASL?

Step 1) Become root on the system:

su -

Step 2) edit the file /etc/asl/whitelist with the editor of your choice, the example below uses vi

vi /etc/asl/whitelist

Step 3) Save the file

Step 4) Step the security policy on the system

asl -s -f

How do you unblock an IP in ASL?

Log into the ASL GUI, click on the ASL tab and select the Blocking menu option. This will open the window of any IPs ASL is blocking. Just check the "unblock" box next to the IP address(es) you wish to unblock and then click the "update" button.

You can also do this from the command, but running this command as root:

asl -ub <IP to whitelist>

Example:

asl -ub 111.222.333.444

How do you blacklist an IP in ASL?

Log into the ASL GUI, click on the ASL tab and select the Blocking menu option. This will open the window of any IPs ASL is blocking. Select the Blacklist tab, and at the bottom of the window type in the IP address or network you wish to blacklist. Then click the "update" button.

You can also do this from the command, but running this command as root:

asl -bl <IP to blacklist>

asl -bl <network to blacklist>

Examples:

asl -bl 111.222.333.444

asl -bl 111.222.333.0/24

How can you whitelist an IP address with denyhosts?

Answer:

denyhosts is deprecated in ASL and is no longer supported or used. If you still use denyhosts we recommend you remove it from the system.

If you wish to use it in parallel, please contact the denyhosts authors for support. This information is provided as a courtesy:

denyhosts uses a different file for whitelisting (we will be symlinking this in a future update to reduce confusion):

/var/lib/denyhosts/allowed-hosts

What is the difference between whitelisting and disabling a signature?

Whitelisting keeps an IP address from being shunned. Attacks from the IP may still be blocked.

Disabled a Signature turns off a signature for the entire system.

If you are experiencing a false positive and wish to disable it, we recommend you report the false positive to us and we will put put an update rapidly that will resolve the issue for you.

How can I debug a problem with updating asl -u?

Answer:

asl -u calls a number of programs, if you get a FAILED error on update try running this command as root:

yum update

Most problems with asl -u involves problems with yum or the rpm database. If you run yum update alone you will be able to collect more detailed debug data about problems with those subsystems.

How can I use the Linux X11 GUI with ASL

Please see the X with ASL article for instructions.

Active Response

How can I configure ASL to only log but not block events?

Log into the ASL GUI, click on Configuration, then select ASL Configuration from the menu.

To disable all firewall type blocks (also known as shuns), set OSSEC_ACTIVE_RESPONSE to "No".

To disable all Web Application firewall blocks, set WAF_ENGINE to "DetectionOnly".

This will disable all blocking capabilities. The ASL kernel will still prevent malicious kernel level actions, there is no mechanism to disable these built in protections. If you do not wish to have the ASL kernel protections stop kernel level attacks, then reboot the system into a non-ASL kernel.

How can I find out what IPs are being blocked by ASL?

Just log into the ASL GUI, click on "ASL" and then Blocking. All blocked IPs along with links to the events that caused the block are provided there.

Does ASL log all shuns?

Yes. If ASL shuns, or blocks a source IP with the systems firewall, it will log that action in this file:

/var/ossec/logs/active-responses.log

The same is true if it unshuns, or unblocks an IP address. That will also be logged.

You can also log the ASL GUI and click on the ASL tab, then click on Blocking. If ASL is blocking an IP, it will also show up there.

How long will ASL shun an address

That depends on your configuration. The default is 600 seconds. Please check your configuration for your systems limit. You can do this by logging into the ASL GUI, click on the Configuration tab, then select ASL Configuration, and scroll down to OSSEC_SHUN_TIME.

ASL can also intelligently increase the shun time for repeat attackers. This is set by the HIDS_SHUN_MULTIPLIER configuration setting, which will multiple the shun time by this number for each successive attack. If you set HIDS_SHUN_MULTIPLIER to 0 this will disable the multiple, and IPs will only be shunned for the static period set by the OSSEC_SHUN_TIME variable.

ASL Vulnerability Scanner

Whitelisted IP's exceed 256: [CRITICAL]

ASL will report when a large number of IP addresses has been whitelisted. A whitelisted IP is absolutely implicity trusted. That means the IP address can do anything to the system, and ASL will do nothing to stop it. This can be very dangerous, as a large number of trusted IPs is very difficult to manage and to ensure that those system can not be compromised themselves.

ASL has a very sophisticated algorithm that will analyze the number of trusted IPs, and once they exceed a certain limit it will report that the amount of implicitly trusted systems is very risky. This alert means that ASL is concerned that you may be trusting too many systems to manage.

Cannot load /usr/local/apache/modules/mod_security2.so into server

This means that someone or some application has removed mod_security from your system. ASL does not have the capability to remove mod_security. If this has occurred on your system, first check to make sure it was authorized. A malicious party may have removed this without your permission.

If this was authorized, then you will need to reinstall mod_security. With package managed system and cpanel this is automatic, but with source built systems this may need to be done manually.

If you are using cpanel, this means that the easyapache system is broken. ASL uses easyapache to install mod_security, and somehow easyapache has been broken on the system. ASL can not cause this condition, so you should open a case with cpanel to discuss why easyapache is no longer honoring the request to install mod_security.

You can manually attempt to force easyapache to run its "post" procedure with this command, run as root:

/scripts/posteasyapache 

However, this happens automatically so if mod_security is missing easyapache is either broken, or someone has replaced it with a version that does not contain the directive to install mod_security. If easyapache is working correctly, then this is mostly the case (easyapache was overwritten and lost all its settings). You will need to reinstall ASL to resolve this.

I'm getting High Risk Vulnerability errors for my kernel

This can only happen if you are not running the ASL kernel. Please see the link below to ensure that you are running the secure ASL kernel:

Kernel#What_to_do_if_the_kernel_is_not_installed

If you are running ASL on a VPS system, such as a virtual system using Virtuzzo or other similar technologies you will not have your own kernel (not to be confused with VMWare, Xen, KVM and others, those are VM technologies, not VPS so this does not apply to them). VPS virtualization technologies share the host systems kernel. You will need to replace the kernel on the host. Please see the ASL#ASL_inside_a_VPS article for additional information.

WAF disabled warning

ASL has a fail safe check to make sure the WAF is still active. ASL uses mod_security as the WAF engine, which is a module that is loaded by Apache. If ASL is reporting the WAF is disabled, and you did not disable the WAF, this means that someone or something has removed the module from the system. ASL does not have the capability to do this, and can not cause this condition, so something other than ASL has caused this condition.

This can either be an indication of a malicious compromise of the system, a user has removed the WAF, or some application has removed it.

If ASL is reporting the WAF is disabled, the WAF is disabled. Check your system and software logs to ensure that someone or some application has not uninstalled mod_security, or if you are using a source built apache, such as with cpanel, its possible apache may have been recompiled without mod_security.

We highly recommend you always use package managed software, and not source built software as these accidental removal issues are very common with unmanaged software.

If mod_security has been uninstalled from your system, we recommend you first confirm that this was not done maliciously, and then rerun the ASL installer. This is a serious condition and other important parts of ASL and your operating system may also be missing.

Using ASL to manage your PHP configuration

How can re-enable a PHP setting ASL is managing?

Log into ASL, and click on the "Configuration Tab", then select the "ASL Configuration" menu item. That will open the "ASL Configuration" window. Scroll down to the "PHP Configuration" section and change the PHP settings you have configured ASL to enforce. Then click the "update" button at the bottom of the "ASL Configuration" window.

Important Note: If "PHP_CHECKS" is set to "No" then ASL is not managing any of these settings, and changing these settings will have no effect on your PHP configuration. ASL will only warn if you have PHP configured in an insecure manner.

I'm getting High Risk Vulnerability errors for many of my PHP settings

By default ASL will only report PHP vulnerabilities. If you want ASL to fix these vulnerabilities log into the ASL GUI and select ASL Configuration. Scroll down to "PHP configuration" and set the PHP_CHECKS to "Yes". Then select which PHP functions you want ASL to fix. For example, if you want to disable the "exec" function, change the ALLOW_exec setting to "No".

Then select "Update". ASL will then disable the PHP functions you have configured it to disable, and will report any remaining as vulnerabilities.

Using ASL to manage your SSH configuration

How can re-enable an SSH setting ASL is managing?

Log into ASL, and click on the "Configuration Tab", then select the "ASL Configuration" menu item. That will open the "ASL Configuration" window. Scroll down to the "SSH daemon configuration" section and change the SSH settings you have configured ASL to enforce. Then click the "update" button at the bottom of the "ASL Configuration" window.

How can I disable my SSH banner?

Just log into ASL, click on Configuration, scroll down to SSH_BANNER and set it to "off". Then click "Update" and the SSH banner will be disabled.

If you manually change this setting in /etc/asl/config you must run this command as root to set the security policy:

 asl -s -f

On some systems, you may need to reload sshd to make the configuration changes take effect:

 /etc/init.d/sshd reload

If your system does not support reload you will need to restart sshd.

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

Example if you are running an ASL kernel:

PAX: execution attempt in: <anonymous mapping>, 53181000-53184000 53181000
PAX: terminating task: /usr/libexec/paxtest/anonmap(anonmap):1234, uid/euid: 0/0, PC: 53181000, SP: 23498723984
PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PAX: bytes at SP-4: 12345465682347509817324059871340598734

Example if you are not running an ASL kernel:

 kernel: anonmap[12345]: segfault at 00002aaaaaaab000 rip 00002aaaaaaab000 rsp 00007fff457153f8 error 15

Answer:

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

Are part of ASL's built in vulnerability scanner. These messages in syslog are normal and you can ignore them.

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.

Audit mount() events: not enforced [INFO]

This message means that this logging capability is disabled. ASL has the log mount events. This is disabled by default, but if you want the kernel to log these events just enable this option.

Audit chdir() events: not enforced [INFO]

This message means that this logging capability is disabled. ASL has the ability to log all chdir events, or "change directory" events. Unless you need this high level of auditing, we recommend you leave this disabled.

Audit text relocation events: not enforced [INFO]

This message means that this logging capability is disabled. ASL has the ability to log special events in legacy applications called "text relocation" events. Unless you are a developer working with legacy applications, you do not need to enable this.

RWX map Logging: not enforced [INFO]

This message means that this logging capability is disabled. ASL can log if an application tries to carry out a restrict mmap operation. You may want to enable this, this could either be an attack on the system or a buggy application.

RBL Ruleset: off [LOW]

This message means that this ruleset if disabled. This is the real time blacklist ruleset. You can read more about it at the URL below:

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

Strict Multiform Ruleset: off [MODERATE]

This message means that this ruleset if disabled. The ruleset enforces strict adherence RFCs for multiform messages. This prevents advanced attacks that may try to bypass the WAF. Note: Broken applications and clients that do not adhere to RFCs will not be able to send multiform to the system if you enable this. This not a false positive, these clients and applications are broken. If you are unfortunately stuck with these, you will have to disable this.

Anti-Spam URI RBL Ruleset: off [LOW]

This message means that this ruleset if disabled. This is a new ruleset much like the RBL rules. It will perform domain name, as opposed to IP based, lookups of known spam domains.

Web Application Firewall Questions

How can I modify or disable mod_security rules for a domain, rule, or globally?

A: See the Mod_security page for more information.

How to disable a single rule?

Solution:

asl --dr rule_number

How do you exclude a domain from the modsecurity rules?

Solution:

See the mod_security page for details.

Note: This is very dangerous, it is not recommended as it leaves the entire domain open to all web based attacks which could also potentially cause the entire server to become compromised. If you find that you are experiencing any false positives please report them to support@atomicorp.com - we will fix the false positives for you rapidly. We generally release a fix the same day the issue is reported - its all part of the service and its included for free. We're here to help, just ask.

How can I use a proxy in front of the WAF?

A proxy will pass traffic to the WAF, in most cases this will be comprised of a proxy in front of apache. When the proxy passes traffic to apache, it will make the requests to apache using the proxies IP address. The WAF will then detect and report attacks as having come from the proxy, and not from the actual source of the attack. This is because the attack is in fact coming from the proxy, as far as apache is concerned. Most proxies will pass on the actual source of the connection sent to the proxy server. These proxy servers use what is referred to as the X-Forwarded-For header to pass on this information.

WARNING: This header can be forged, and should never be blindly trusted. All proxy headers can in fact be forged, so the key to using this header is to only trust specific sources and to restrict its use otherwise. For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server.

You will want to use a module with apache that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. You will also want to use a module that will automatically restrict the use of the X-Forwarded-For header to a trusted set of sources. Using a module like this restores apache to its "normal" behavior, where apache will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es).

The mod_rpaf module can be used to achieve this automatically. This module is neither provided by or supported by Atomicorp. You can get the module from the URL below:

http://stderr.net/apache/rpaf/

Instructions for its installation are available at the URL above.

ASL Data Retention Questions

Configuring the ASL database retention policy

By default, ASL will keep 7 days of records in the database. You can change this by changing the variable ASL_DB_RETENTION in the ASL configuration to the number of days you wish to keep records.

Configuring modsecurity audit log retention

By default, ASL will keep 30 days of audit logs for attacks logged by modsecurity. You can change this by changing the variable MODSEC_CLEAN_ALERT in the ASL configuration to the number of days you wish to keep records.

Can the tortix database be moved?

Yes. Follow the standard procedure for configuring and using mysql as provided by your database vendor.

Can the modsecurity audit logs be moved?

Yes. You can move them by either symlinking the directories, or changing the MODSEC_AUDITDIR variable to a directory of your choosing.

Can the ossec logs be moved?

Yes. You can move them by symlinking the directories.

Firewall

Using the ASL Firewall Manager

Please see the ASL firewall page.

ASL-ACTIVE-RESPONSE

This iptables chain is used by ASL for temporary shuns.

ASL Kernel Usage Questions

DOS Protection is now showing as disabled

This means that either:

1) DOS protection is disabled in ASL. Please log into the ASL GUI, click on the Configuration Tab and select the "ASL Configuration" menu option. When the ASL Configuration window is displayed, scroll down to the "MODEV_ENABLED" option and set it to "yes" then click the update button.

2) The denial of service module is not installed on the system. ASL installs this module automatically on all package managed systems. If you have a non-package managed system, such as CPanel, you will not be able to install this module as it is not supported on non-package managed systems.

If you have a package managed system, and the module is not installed, run this command as root to install the module:

yum install mod_evasive

Kernel Protection is now showing as disabled

This occurs only if you are not running the ASL secure kernel. To resolve this follow these steps:

Step 1) Check to see if you are running the ASL kernel:

Kernel#How_to_tell_if_you_are_running_the_ASL_kernel

Step 2) If you are not, then check to see if its installed, and if not install it:

Kernel#Checking_to_see_if_the_ASL_kernel_is_installed

Note: If you are on a VPS, you will not be able to install a kernel (VPS' dont have kernels, they share the hosts kernel).

Step 3) If the kernel is installed, just reboot your system into the ASL kernel. Bu default, ASL should set itself up to boot into the ASL secure kernel, but if you are not sure follow the link below for instructions about to check and configure which kernel your system boots into.

Kernel#Setting_which_kernel_to_boot

PAX is preventing an application from running

Please see the rest of this FAQ to make sure specific guidance on your application is not explained in detail in this FAQ. If your application is not documented in this FAQ, and you are sure the behavior of your application is safe then follow these instructions. Please understand that the ASL kernel is designed to pre-emptively prevent applications from either compromising your system, or putting themselves in a dangerous state that will allow your system to be compromised. The vast majority of application do not need to be configured as described below, and this condition is so rare we recommend you report this issue to us as we can work with you to ensure that this is not either a clever attack on your system, or if the application could be configured to not operate in such a dangerous state.

Option 1: Assume this an attack

Do not change any configuration settings. PAX messages are very rare (see the rest of this FAQ for PAX events you can ignore, some PAX events are generated by ASL when it tests itself) and mean that the kernel is protecting your system from something either malicious or dangerous, which could cause your server to crash. We recommend you investigate the event first to rule out that an attack has occurred before implementing option 3.

Option 2: Configure the application to operate more securely

Some applications may be configured by the vendor to operate in a less than secure manner, or may simply be configured in to request certain kernel privileges they do not need. Contact your vendor to ask why they need to manipulate your kernel and stack in this manner, and see if they can do this in a secure manner before you disable any kernel level security measures.

Option 3: Disable all kernel protections for this application

A typical PAX event will look like this:

If the PAX subsystem of the kernel blocks something it will give you that path. For example:

 PAX: execution attempt in: <anonymous mapping>, 53181000-53184000 53181000
 PAX: terminating task: /usr/foo/bar(bar):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

That entry means the system stopped that application from doing something dangerous to your kernel. The path to the application in the example above is bolded:

/usr/foo/bar

If you wanted to allow the application to modify your kernels running stack, and to disable all the security protections in the kernel for this application you would run this command:

 paxctl -pemrxs  /usr/foo/bar

This is a dangerous thing to do as it disables all the kernel level protections for this applications and makes it possible for this application to be used to compromise your entire system. It is extremely rare that an application needs to be run in this manner, and you should always assume that this is either a real attack, or that the application is doing something dangerous and further analysis is required to determine a safer means of running the application that does not require disabling your kernel level protections.

Can't install kernel modules.

Solution:

By default the ASL kernel doesn't allow loading (or unloading) of kernel modules during runtime to protect the system from kernel level rootkits and other malicious kernel level code. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system. When attempting to load modules dynamically, this may result in error messages such as this:

modprobe: WARNING: Error inserting sunrpc (/lib/modules/2.6.32.43-6.art.i686.PAE/kernel/net/sunrpc/sunrpc.ko): Unknown symbol in module, or unknown parameter (see dmesg) modprobe: WARNING: Error inserting auth_rpcgss (/lib/modules/2.6.32.43-6.art.i686.PAE/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko): Unknown symbol in module, or unknown parameter (see dmesg)

You have two options with ASL:

1) 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) Configure ASL to allow your kernel to be modified at any time.

This is NOT recommended and is highly insecure. 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 as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.

If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.

Kernel is reporting: No module ehci-hcd/ohci-hcd/ehci-hcd found for kernel during an upgrade

A: These modules have been deprecated from newer kernels. The error message can be safely ignored, if you want to remove this message from future updates remove those entries from /etc/modprobe.conf

is there a way to enable PAE with ASL KERNEL?

Solution:

Indeed you can, PAE kernels are fully suported in asl. Just check yum and install the PAE kernel.

The normal command is:

 yum install kernel-PAE

If you have an issue with a PAE kernel please report it to support@atomicorp.com.

Where is the kernel source?

If you wish to install the kernel source it is included in the "kernel-devel" package. If you use yum, this is the standard command to install that package:

 yum install kernel-devel

Custom compiled kernels are not supported.

ASL kernel with Xen

ASL is fully support inside a Xen guest. If you can not get the ASL kernel to run inside a Xen virtualized machine make sure your Xen system is up to date. ASL works with the latest Xen implementation. This is because Xen is in the middle ground of virtualization, it requires a customized xen-aware operating system for both the master, and the slave OS's. Therefore versions are critical with Zen implementations.

When using the ASL kernel inside a Xen guest, paths to the console device may change from "xvc" to "hvc". If you use the console, then you will want to make the following changes to /etc/inittab:

Change this line

co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

To:

co:2345:respawn:/sbin/agetty hvc0 9600 vt100-nav

Once this change is made you can reload this on the fly with the follow command run as root:

init q

or reboot the system.

Types of Virtualization technologies

• Full Hypervisor- QEMU, KVM, Vmware, Virtualbox, Parallels, etc (no custom OS required - ASL runs in these environments)

• Para-Virtualization - Xen (Xen aware kernel required and up to date Xen implementation)

• Container - Vserver, Virtuozzo/Openvz, etc. (Virtual servers do not have their own kernel, they share the systems kernel. Therefore, no kernel can be installed into these containers. ASL will run just fine, but because you can NOT run a custom kernel inside these types of virtual machines, and they do not have their own kernels you will inherit any vulnerabilities in the host kernel. ASL will detect these, if they exist. They are not false positives and if you have these vulnerabilities we encourage you to contact your hosting company and ask them to install ASL on the host system as well as the guests)

What that means is that you can basically install any x86 based OS into a full-hypervisor virtualization system. If the master is linux, you can run freebsd, windows, linux, osx, etc under it. No changes to the guest OS's are required.

Paravirtualization means you can run any Xen-aware OS under it, so if you're running Linux, you can run Xen-Windows, or Xen-Linux as a slave OS. Mainly this means that the slave OS's have unique, xen kernels (such as ASL does). This means that you boot the master off of one kernel, and then the guests boot again in their special xen guest kernels.

Container virtualization is limited to the OS of the master, if the master is linux, then the slaves are linux, since everything is running under the same kernel. The main advantage of a container type system is that it scales farther than the other two.

OSSEC

ASL is changing my ossec configuration

ASL manages OSSEC and all its files, dyamically updating and changing them based on conditions on the system. If you want to change any of OSSEC configuration files, you will have to change the ASL templates that ASL uses to manage those files. The templates are stored here:

/var/asl/data/templates/

And the ossec master template is:

/var/asl/data/templates/template-ossec-server.conf

Once you change a template, you will need to implement the changes into the security policy by running this command as root:

asl -s -f

ASL also manages all the rules in OSSEC, and will not allow its rules or rule directories to be manually changed. If you want to change a rule, use the rule manager.

If you want to add additional rules, please modify your ossec configuration per the above guidance to point to a file in a non-ASL managed directory. Currently ASL manages all rules in the "etc/rules.d" and "/etc/rules" directories. Do not use these directories for custom rules, your modifications will be overwritten and deleted.

Also, please know that custom rules are not supported by Atomicorp. If you have a special need for a custom rule, please let us know and we will see what we can do to add it and support it for you. So far, we've added every custom rule our customers have asked for, so please don't hesitate to ask us!

ossec-syscheck is using a lot of CPU

What ossec-syscheckd does:

syscheck is daemon that runs on your system continuously, much like apache, bind, sshd and other daemons. It periodically checks your system for evidence of compromise, such as files being modified. On systems that support real time analysis (such as when using the ASL kernel), it will monitor files in real time that it has been configured to watch, and will detect when those file change in real time. It can also report this change and then check that file for additionally evidence of a compromise or other unauthorized changes. On start up, it will determine what files it should monitor, based on how you configure it. And will then periodically recheck the the system to see if any new files or directories have been created on the system in those areas.

CPU usage:

The first factor in CPU usage for this daemon is the amount of work if has been configured to do. Specifically, you configure it to monitor files and directories for evidence of change and potentially unauthorized activity. The first thing to check then is what you have configured it monitor. By default, it is configured to monitor the systems core binaries, optional software directories (/opt) and configuration directories. These are the directories it will monitor by default:

 /etc
 /usr/bin
 /usr/sbin
 /bin
 /sbin
 /usr/lib64
 /usr/lib
 /lib64
 /lib
 /usr/local/bin
 /usr/local/sbin
 /usr/local/lib64
 /usr/local/lib
 /opt

By default, these directories compromise the core operating system and its configuration, along with any custom software installed on the system.

The second thing to remember is that ossec-syscheckd detects changes based on the methods you have configured it to use. By default ossec-syscheckd will determine a file has changes by generating an md5 and sha1 hash of the file. Then when either the kernel reports the file has changed, or on systems that do not support real time notifications it will hash the file again to confirm if it has changed. This all uses CPU cycles. It can also use less reliable methods, such as simply looking at time stamps on the file or the size of the file. However, these methods are less reliable and are very easy for an attacker to forge, so we do not recommend you use these insecure methods as the only means of detecting changes. The default hashing method is very secure and reliable.

If you have an unusually large number of files in these directories syscheckd will have a lot more work to do. For example, Splunk can be configured to put all of its logs into the /opt directory, which will create a massive amount of files to watch (that change all the time and can be rather large), lots of virtual servers are configured in /var/www/vhosts which can create a lot of work if /var is monitored, some other applications place their logs in /etc, etc. The bottom line is that syscheckd will only do the work you have configured it to do. By default the monitored directories are both a good compromise between performance and security, however not all systems are configured the same nor do they all have the same software installed. So its up to you to look into your system and the software thats installed to determine whats going on in the directories you are monitoring.

The amount of work syscheckd has to do is completely controlled by your configuration, so the great news is you can tell it to do as little or as much work as you want! Remember when configuring it that the purpose of syscheckd is to watch programs, applications (including web), the operating system itself, and its configuration for malicious or unauthorized changes. It should not be used to watch non-program/application files, such as logs, temporary files and really large files (like media files) and other items you do not want to be monitored for changes and malicious activity, or that you can not afford the CPU power to monitor. It can monitor these, so if your security needs require you to monitor more than just applications ASL is certainly capable of doing this.

Troubleshooting

The first thing to check if CPU usage is high are the contents of those directories on your system. If you do find some application using those system directories for non-application files, such as logs and temporary files, we recommend you move the applications logs and temporary files. You can also configure ASL to ignore just those sub directories that contain the logs (/etc/logs for example can be ignored, while the rest of /etc can still be monitored). The least secure, and not recommended option would be to disable inspection of the folders where these applications reside.

Configuring

If you want syscheckd to do less work, then just configure it to watch less files and directories. To do this, log into ASL, click on the ASL tab, then click the "File Integrity" menu option. A window will open for the File Integrity manager. Click the "Options" button, then click the "Directories" button. This will list all the directories you have configured for ASL to watch, and any special things to ignore or monitor. To remove a directory, just click the green check mark next to the directories name and it will turn into an exclamation point. Remove any directories you do not want to monitor and click the Update button, and you are finished. You can also configure ASL to ignore subdirectories. Within the same window, click on the "-- ad new rule --" drop down, select "ignore" and type in the subdirectories you wish to ignore. For example, if you had log files in the /etc/logs directory and still wish to monitor the /etc directory, just type in /etc/logs, hit eneter, and then press the "update" button.

syscheckd can also report what changed in certain files, which can be particularly helpful in determining if a change is authorized or not. For example, syscheckd can tell you that a particular configuration option was removed or changed in a file, or that information has been altered and what the original and new information is. This also uses more resources, so check your configuration for the "Report" option. If a directory is configured to report, syscheckd will report the details of the change to you, and will store a record of all changes that occur over time. This will also use more drive space on your system.

The syscheckdaemon will also perform other actions such as looking for malicious software on a regular schedule. On systems with slower I/O buses, lots of I/O activity (such as systems that share a single I/O channel for databases and websites and typically virtual machines, where multiple virtual machines will share the same drives or buses) or systems that are simply very busy the frequency at which this occurs may be too often for those slower systems. If you wish to reduce the frequency at which these checks run (except for real time checks, more on that in a moment), log into the ASL GUI, click on the ASL tab, then select the "File Integrity" menu option. Then press the Options button and change the "Scan Timing" options to meet your needs. The default is every 24 hours.

If you see significant CPU utilization when checks are running, this means your system has a slower I/O bus, or the I/O channels in use at the time are simply heavily used. If you have confirmed that the daemon is not looking at large numbers of files, then you will need to configure syscheck to check a smaller set of files over a longer period of time to lower CPU utilization. If you do have an unusually high number of files, ensure that the daemon is only looking at programs and their configuration, and not at files that should not be monitored (such as logs, temp files, etc.). There is no need for the daemon to inspection and monitor log and temporary files.

To reduce the speed at which the daemon scans in new files to generate their hashes for monitoring, go to this directory:

/var/ossec/etc/

And change the file internal_options.conf increasing the value of syscheck.sleep and reducing the value of syscheck.sleep_after.

# Syscheck checking/usage speed. To avoid large cpu/memory
# usage, you can specify how much to sleep after generating
# the checksum of X files. The default is to sleep 2 seconds
# after reading 15 files.
syscheck.sleep=4
syscheck.sleep_after=10

syscheck.sleep tells the syscheck daemon to wait for, in the above example, 4 seconds before reading in new files.

syscheck.sleep_after tells the daemon to stop working after it reads in 10 files. For a slower system, start by increasing syscheck.sleep to 8, and syscheck.sleep_after to 5.

OSSEC is using a lot of drive space

OSSEC can report what changed in a file, and can keep a record of all the changes that have occured with that file. 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). O that 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.

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

This 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 and temporary or cache directories.

You can also 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 and compress them 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 coming from "report"ing events where "diffs" of changed files are stored.

proftp errors

Fatal: unknown configuration directive 'ClamAV' on line 1 of '/etc/proftp-asl.conf'

Explanation:

This means that you are not using the Atomicorp version of Pro FTP. You are using some other parties version of proftp that does not include malware upload support.

Some products (such as PSA miroupdates), will install a different version of proftp over the Atomicorp version. These vendors will also not update your rpm repository, so checking your installed packages will also not show this change and will appear to report that the atomicorp version of proftp is install, it is not.

This error is conclusive proof the system is not running the Atomicorp version of psa-proftp.

Solution:

Reinstall the Atomicorp version of Proftp:

 yum reinstall psa-proftpd psa-proftpd-xinetd

If you attempt to resinstall our version of proftp, and you get an error from yum similar to this:

yum reinstall psa-proftpd psa-proftpd-xinetd
Loaded plugins: fastestmirror
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
 * addons: centos.kiewel-online.ch
 * atomic: www7.atomicorp.com
 * base: centos.kiewel-online.ch
 * extras: centos.kiewel-online.ch
 * rpmforge: ftp-stud.fht-esslingen.de
 * updates: centos.kiewel-online.ch
Installed package psa-proftpd-1.3.3c-3.el5.art.x86_64 not available.
Installed package psa-proftpd-xinetd-1.3.3c-3.el5.art.x86_64 not available.
Nothing to do

This means that you have either configured yum to either exclude you from installing proftp, you have yum priorities setup, you have disabled the asl repository or you have third party repositories also configured on the system that is throwing off yum and not allowing it to install the software it needs.

Steps to troubleshoot your yum configuration:

Step 1)

Disable all third party repositories.

Step 2)

Remove yum priorities if its installed:

yum remove yum-priorities

Step 3)

Check your yum configuration to make sure you do not have anything excluded. Exclude entries are sometimes added to /etc/yum.conf or in your /etc/yum.repos.d/ directory, and will look similar to this example:

 exclude=psa-proftp*

Remove these entries.

Step 4)

Check to make sure the asl respository is enabled. The ASL respository is stored in the /etc/yum.repos.d directory in a file titled "asl.repo". In that file are three asl "channels", there are:

• asl-2.0
• asl-2.0-testing
• asl-2.0-bleeding

Ensure that under the asl-2.0 heading that you see a line like this:

enabled=1

That means the channel is enabled. You do not need to enable the asl-2.0-testing or asl-2.0-bleeding channels. Those channels are for beta and test software, and are not supported.

A working configuration will look like similar to this:

[asl-2.0]
name=Atomicorp -  - Atomic Secured Linux 2.0
baseurl=http://username:password@atomicorp.com/channels/asl-2.0/centos/5/x86_64
enabled=1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt
gpgcheck=1

[asl-2.0-testing]
name=Atomicorp -  - Atomic Secured Linux 2.0 (TESTING)
baseurl=http://username:password@atomicorp.com/channels/asl-2.0-testing/centos/5/x86_64
enabled=0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt
gpgcheck=1

[asl-2.0-bleeding]
name=Atomicorp -  - Atomic Secured Linux 2.0 (BLEEDING)
baseurl=http://username:password@atomicorp.com/channels/asl-2.0-bleeding/centos/5/x86_64
enabled=0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY.art.txt
gpgcheck=1

Do not change any other settings in this file.

Step 4) Attempt to reinstall again

 yum reinstall psa-proftpd psa-proftpd-xinetd

If this still fails, it may because your system had a very old version of psaproftp, and you need to upgrade. In which case, run this command as root:

 yum upgrade psa-proftpd psa-proftpd-xinetd

mod_evasive

Tuning mod evasive

Please see the Mod_evasive article.

cpanel and mod_evasive

Currently mod_evasive does not work with cpanel. You may be able to install it manually, but ASL will not be able to manage it and this is not a supported configuration. We are working with cpanel to support mod_evasive.

mod_evasive works with and is supported with all other platforms.

[file "mod_evasive20.c"] [line 246] [level 3] client denied by server configuration:

Please see the Mod_evasive article for detailed information about this message, and how to tune or disable this component for your needs.

Apache files

I'm seeing files owned by apache in /tmp

If you see files with names like this:

tmp/dos-218.254.50.104

That are very small, and only contain an integer for example the contents of the file tmp/dos-218.254.50.104 are "2671" or some other number, then you can ignore these files. These are locking files used by the web DOS protection system in ASL.

If you see files with names like this:

tmp/20120314-104701--CliB38AAAEAAEehOeMAAAAA-file-Y6rewB

These are temporary files generated by apache as a user uploads a file, via apache, to the system. Generally apache will clean up these files with a few seconds once the file is scanned by the WAF, but if you see them accumulating on your system you may have MODSEC_KEEPFILES set to "on". This means that the ASL WAF will keep any files it has been asked to scan, regardless if the files are allowed to be uploaded to the system or not.

Apache errors messages

[warn] module security2_module is already loaded, skipping

This error means that apache has tried to load mod_security twice, and is refusing to do so. This is worth investigating because ASL will never try to do this, and this error means that someone or something else has configured apache to do this twice. This could mean that there are two (or more) modsecurity configurations on the system, which will in fact be loaded by apache. Although the module is not loaded, the configuration options will be which could cause all sorts of problems with the system.

Again, ASL will never configure the system to do this, so if you see this error it means someone or something else has added another modsecurity configuration to the system which could cause severe performance problems, could disable key settings, or enable other settings that may conflict with the configuration of modsecurity.

If the module is just configured to load twice, and there are no configuration options then this error may be harmless.

Address already in use: make_sock: could not bind to address [::]:80

This is a generic error generated by Apache.  This message occurs if apache (or some other process) is bound to port 80.  This error is not caused by ASL. 

In some cases, such as when apache is restarted, the apache init script may not actually shut apache down before starting it. In some other cases, such as if the system is running a processor manager, or a process watchdog, they may restart apache during the restart cycle if Apache takes a long time to stop (the apache "graceful" option may take a long time to shut down all child processes, and this can occur). The process manager may incorrectly (or depending on how you look at the situation, correctly) detect that Apache is "down" and restart it automatically, before the Apache init script can start Apache. This will result in this error which is technically incorrectly.

This can also occur if some other process is listening on port 80. In all cases, when this error message is generated by apache, it means that apache tried to start and tried to bind to port 80 only to find something else (possibly apache) already listening on port 80.

Check to see if apache is already running, by running this command as root:

ps auxwww | grep httpd

If apache is running, you will see an output similar to this:

root     30070  0.0 11.2 572444 227872 ?       Ss   16:01   0:01 /usr/sbin/httpd
apache   30338  0.0 10.6 445936 215880 ?       S    16:01   0:00 /usr/sbin/httpd
apache   30339  0.2 13.1 652036 266176 ?       S    16:01   0:09 /usr/sbin/httpd
apache   30340  0.1 12.7 633744 256844 ?       S    16:01   0:09 /usr/sbin/httpd
apache   30341  0.2 12.7 641456 257528 ?       S    16:01   0:09 /usr/sbin/httpd
apache   30342  0.2 12.7 641852 257364 ?       S    16:01   0:10 /usr/sbin/httpd
apache   30343  0.2 12.7 635864 256688 ?       S    16:01   0:09 /usr/sbin/httpd
apache   30344  0.2 12.9 644080 261692 ?       S    16:01   0:10 /usr/sbin/httpd
apache   30345  0.2 12.9 644012 261632 ?       S    16:01   0:10 /usr/sbin/httpd
apache   30346  0.2 12.4 634564 251056 ?       S    16:01   0:12 /usr/sbin/httpd
apache   32012  0.1 12.8 644100 259272 ?       S    16:31   0:04 /usr/sbin/httpd
apache   32013  0.1 12.7 643804 256628 ?       S    16:31   0:04 /usr/sbin/httpd
apache   32014  0.1 12.6 641456 255712 ?       S    16:31   0:04 /usr/sbin/httpd
apache   32015  0.1 12.9 645856 262424 ?       S    16:31   0:05 /usr/sbin/httpd
apache   32016  0.1 11.5 631772 233776 ?       S    16:31   0:04 /usr/sbin/httpd
apache   32017  0.1 12.7 641424 258196 ?       S    16:31   0:04 /usr/sbin/httpd

If you see apache running, you can ignore this error. However, you may want to restart apache again just to make sure whatever changes were applied to apache, to cause it need to be restarted, were applied.

If you do not see apache running, try starting it again. If you continue to get this error, then something else is running on port. You can find out what is listening on port 80 with this command:

netstat -anp | grep :80 | grep LISTEN

The output will look like this:

tcp 0 0 :::80  :::* LISTEN 30070/httpd

The last field "300070/httpd" lists the process ID and process name that is listening on port 80.

Kernel Messages/Errors

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.

grsec: denied untrusted exec of /path/to/some/application

The application is not being allowed to run because ASL is configured to prevent it from running.

Specifically, ASL includes a feature called Trusted Path Execution. When Trusted Path Execution (TPE) is fully enabled (which is the default), it will only allow applications owned by root to run on the system that are not modifable by any other user except root. This protects the system from malicious software that may try to change these applications or to replace them with malicious versions. We do not recommend you disable TPE.

If you get this message, that means the application is owned by an untrusted user. This helps to prevent untrusted users from uploading software to the system, which could include trojans, malware and rootkits. This also prevents untrusted users from changing applications, replacing them with a trojan or otherwise tampering with them. By default the only trusted user on the system is root. If you have an application (or an application in a directory) owned by an untrusted user ASL will not allow it to be executed. You can tune ASL or the application to allow it to run by using one of the four documented methods below. They are in order or most secure to least secure:

Option 1. Change the ownership of the file and its directory, and parent directories to root.root and make sure the file and ensure directory it is in are not writable by other users (including the root group). Here is an example you will need to adapt to your system:

Note: If you do not know what is meant by changing a files ownership to root.root, please contact a qualified system engineer to do this for you. root.root means the user and group must be root. These are example commands to achieve this:

 chown root.root /path/to/directory/of/application
 chown root.root /path/to/application
 chown root.root /path/to/
 chown root.root /path/
 chroot root.root /
 chmod -R og-w /path/to/application

Always make sure the parent directories are also owned by root:root. This is the most common issue, some broken applications are known to change key operating systems directories ownership from root:root to something else. We've even seen cases where someone changed the ownership of / to something other than root. Thats extremely dangerous and something else thankfully will protect the system from.

For example, here is an application that will not run with TPE in the fully secure mode because the directory is not set to root.root nor is the application:

 drwxrws--- 2 psaadm swkey-data 4096 May 8 02:32 restart
 -r-s--x--- 1 root swkey-data 9240 May 4 05:58 plesk-key-handler

In this example, the directory is owned by psaadm and swkey-data. These are not set to the root user, so the kernel in the fully secure TPE mode will will not trust this application to run because those users could modify, replace or otherwise tamper with this application and are not trusted by the kernel. To get these applications to run (and you will need to discuss this with your application vendor if the application can run in such a secure manner) the directory and application would need to be owned by the root user and the root group, and must be writable only by the root user (not the root group).

If you can not set an application to run correct as root.root, then you need to configure ASL into a less secure mode. This also means that you will need to accept the risk of running your application and system in a less secure and protected mode. To do this, simply configure ASL to be less secure using options 2-4. This situation is rare, and only a few vendors seems inclined to run their applications in this less secure manner.

In some cases, you can work around this by moving the application to a trusted directory and making sure the directory it is in is owned by root.root. For example, for a setuid script owned by "testuser":

 [testuser2@ac2 ~]$ pwd
 /home/testuser2
 [testuser2@ac2 ~]$ id
 uid=510(testuser2) gid=510(testuser2) groups=510(testuser2)
 [testuser2@ac2 ~]$ cat ~testuser/sensitive_file
 cat: /home/testuser/sensitive_file: Permission denied
 [testuser2@ac2 ~]$ /usr/local/trusted_apps/special_cat ~testuser/sensitive_file
 This data can only be read by setuid
 [testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/special_cat
 -rwsr-xr-x 1 testuser testuser 23132 Dec 17 19:45 /usr/local/trusted_apps/special_cat

As you can see from this example, there is a setuid program called special_cat (its a copy of /bin/cat in this example) that is setuid to testuser. testuser2 tried to open the file ~testuser/sensitive_file with "cat", but can not because testuser2 must use the setuid program "/usr/local/trusted_apps/special_cat" to read those files.

The key to making this work with the secure ASL kernel is to ensure that the directory in which the application is place must be owned by root.root, and the application itself can still be owned by the untrusted user "testuser":

 [testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/
 total 36
 drwxr-xr-x  2 root     root      4096 Dec 17 19:53 .
 drwxr-xr-x 12 root     root      4096 Dec 17 19:53 ..
 -rwsr-xr-x  1 testuser testuser 23132 Dec 17 19:45 special_cat

This helps prevent malicious users from uploading programs to the system that you do not want because nothing can be added to that directory except by root. This also helps to prevent users from running programs you don't trust in ways that can compromise the security of your system, such as with spam bots or tools to compromise your system such as malware. The key is to make sure no one can modify the file except the user that owns it, and that the file is in a directory that only root can modify or place new files in. This helps to prevent path poisoning attacks and uploading of malicious software to your system.

Again, if you do understand how to do any of these tasks, please contact a qualified systems administrator to do this for you.

Option 2: Change ASLs behavior so that this restriction only applies to untrusted users. You can do that by turning off this feature, called Trusted PAth Exectuion (TPE) so that it only applies to users in the "untrusted" group:

 echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all

Keep in mind that this is considerably less secure than option 1. This means all the users on your system, except users in the "untrusted" group, will be trusted unless you specifically tell ASL not to trust them. You can see a listing of untrusted users by running this command as root:

 grep untrusted /etc/group

The standard list of untrusted users currently is:

untrusted:x:1005:lp,sync,shutdown,halt,mail,news,uucp,operator,games,gopher,ftp,nobody,vcsa,nscd,sshd,rpc,rpcuser,nfsnobody,mailnull,smmsp,pcap,apache,xfs,ntp,mysql,webalizer,named,alias,qmaild,qmaill,qmailp,qmailq,qmailr,qmails,popuser,psaadm,psaftp,mailman

There are system users, that is users that programs run as. We do not recommend you change these users.

NOTE: You can only change this proc setting (/proc/sys/kernel/grsecurity/tpe_restrict_all) on boot if you have configured ASL to lock the kernel (the default setting is to lock the kernel). Once the boot process reaches stage S99 the kernel is locked and you can not change the security settings. So you will need to set this on boot via a custom init script.

If you want to set an ASL kernel setting, such as /proc/sys/kernel/grsecurity/tpe_restrict_all (or any other), you will need to create a custom init script such as:

 /etc/init.d/asl-custom

A simple script to do this would look like

 #!/bin/bash
 echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all

Then you will need to link it depending on the runlevel your system is set as. If you do not know what this means, please consult an experienced Linux administrator. Most systems are set to run at run level 3.

 ln -s /etc/init.d/asl-custom /etc/rc3.d/S98asl-custom

init is not part of ASL, its part of your operating system, and if you have additional questions about how to configure your operating system or how to write init scripts please contact your operating system vendor. You can read our primer on customizing your kernel in the Installing custom kernel modules with ASL wiki article. This includes a primer on init.

And last but not least, you need to set the script to be executable in Linux. To do that, as root, you need to run this command:

 chmod u+x /etc/init.d/asl-custom

Option 3. Remove the user from the untrusted group in /etc/group (we do not recommend you do this).

If your application is running as an untrusted user, you can change the configuration of ASL to trust this user. The default users are system processes such as apache that should NEVER be trusted by the system. This makes it easy for an attacker to upload a trojan to the system. However, if you must run an application in insecure manner as apache then you would remove that user from this group. ASL will not be able to protect the system from uploaded trojan by this user.

Option 4: Turn off all TPE protections (not recommended and very insecure)

This option completely disables the TPE system and makes it possible for any user to upload anything and run it on the system. Although ASL does have real time malware detection and protection this system is not 100% foolproof and disabling TPE is extremely insecure and will make it possible for an attacker to upload malicious code to your system that even ASL may not be able to detect and then run it.

To disable TPE you will need to change this proc setting:

 /proc/sys/kernel/grsecurity/tpe

To "0"

 echo 0 > /proc/sys/kernel/grsecurity/tpe

This also must be done on boot as with option 3.

If you are unsure of how to do any of these custom things on your system please contact us. Our professional services team would be happy to help you configure your custom applications for your system.

GRsecurity ACL database: not found [INFO]

This simply means you do not have any GRSEC rules set. This is just an information alert and does not mean anything is wrong with your system.

denied RWX mmap of

This means your program needs to perform a potentially dangerous operation and the ASL kernel is preventing it from doing this. If you wish to allow your application to do this, configure the system to allow the application to open the mprotect hole in your system:

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

mprotect(): 13 (Permission denied)

Solution:

This means an application is trying to do something dangerous on your system. Specifically, ASL protects you 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 have no stack vulnerabilities.

To allow an application to open this hole in your system, run this command as root:

chpax -m /path/to/application

grsec: denied RWX mprotect

Solution:

This means an application is trying to do something dangerous on your system. Specifically, ASL protects you 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 have no stack vulnerabilities.

To allow an application to open this hole in your system, run this command as root:

chpax -m /path/to/application

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

kernel: grsec: denied ptrace of /usr/bin/sw-engine-cgi

Parallels tries to prevent users from debugging certain Parallels products. It does this by trying to ptrace itself to detect a debugger. The ASL kernel contains protections to prevent ptrace exploits, and controls which users can use this function call. The kernel will block this function, and the Parallels products does not correctly catch this condition, and instead erroneously reports this as the user running a debugger. This is a bug in Parallels products.

If you are using a version of Plesk that has this bug, and there is no fix available from Parallels for this bug, please follow this process to disable this protection on your system.

Note: This workaround is for those users that want to run Parallels products with this bug. This will require you to disable this protection in your kernel. This will be correctly reported as a vulnerability in the system.

To disable ptrace exploitation protection:

When running ASL 3.0 and up simply log into ASL, click on the Configuration tab, and select the "ASL Configuration" menu option.

Then scroll down to Kernel

And change the "HARDEN_PTRACE" entry from "yes" to "no". If you kernel is set to lock itself on boot (this is the default), you will need to reboot your system for this setting to take effect.

If you are not running ASL 3.0, please add this to your/etc/sysctl.conf file:

kernel.grsecurity.harden_ptrace = 0

And reboot the system.

grsec: process /usr/bin/foo attached to via ptrace by

This is an informational message and can be ignored. ASL will log ptrace activity to help you detect any potentially malicious ptrace actions. To disable this logging run this command as root:

echo 0 > /proc/sys/kernel/grsecurity/audit_ptrace

You will need to set this to occur on boot, or add this to your/etc/sysctl.conf file:

kernel.grsecurity.audit_ptrace = 0

And reboot.

error: unknown error 22 setting key

When running sysctl -p this error occurs:

error: unknown error 22 setting key 'some.sysctl.setting'

Explanation:

By default the ASL kernel doesn't allow allow certain security parameters in the kernel to be modified. This prevents attackers from disabling kernel protections, such as stack protections and allowing the kernel to be modified on the fly. If you wish to modify these security settings, there are two options:

1) Set these security kernel settings and reboot the system.

2) Configure ASL to allow your kernel to be modified at any time.

This is NOT recommended. Allowing kernel security settings to be changed on a running system makes it possible for an attacker to disable ASL kernel level protections, to install rootkits and to otherwise compromise the security of the system. This is similar to allowing a user to disable antivirus on the system, if a user can disable antivirus so can a virus. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this as occurred. We highly recommend you set any kernel security settings you need, reboot the system and let ASL lock the kernel.

If you wish to use to make your kernel insecure and to allow these security settings to change on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.

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

Solution:

By default the ASL kernel doesn't allow loading kernel modules during runtime to protect the system from kernel level rootkits. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system.

You have two options with ASL:

1) 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) 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 as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.

If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.

Warning: cannot open /proc/net/dev

Question:

Unprivileged users can not open the full proc table, and when I tun top or when I run ifconfig I do not see all the information.

Answer:

ASL contains additional safeguards to prevent non-privileged users from reading the full proc table. If you wish to allow a user to see the full proc table, simply add the user to the "procread" group in your /etc/group file and this safeguard will be disabled for that user.

If you do not know how to add users to a group in Linux, or how to edit your /etc/group file, please contact your OS vendor for assistance.

cannot enable executable stack as shared object requires

Example

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

Some application developers label their applications as needing an executable stack. This opens your system to attack. Very few, if any applications require this insecure state to operate, and often times this labeling is done by the application developer in error. The ASL kernel protects you from this mistake by not allowing these applications to request this extremely insecure condition.

There are three options for dealing with this 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 library itself, and not the binary calling it, in which case you may have to remove the execute bit from the library itself:

 execstack -c  /opt/splunk/lib/libcrypto.so.0.9.8

If you aren't sure which binary or library has the stack execute bit set, you can run this command to query the file:

 execstack -q /opt/splunk/lib/libcrypto.so.0.9.8

If you see this:

 - /lib/libcrypto.so.0.9.8e

The "-" means that file is safe, and does not have the stack execute bit set, in which case the binary calling the library is the likely culprit and you would want to query that file and remove the flag from it.

If you see this:

 X /opt/splunk/lib/libcrypto.so.0.9.8

The X means stack execution is allowed, which also means X marks the spot for attacking your stack - which ASL will not allow. To close the vulnerability in the above example, remove the stack execute flag from the library by running this command as root:

 execstack -c /opt/splunk/lib/libcrypto.so.0.9.8

We also recommend you contact your application vendor and ask them to remove these flags from their applications. They are not necessary with modern Linux kernels, and are bad and unsafe practices which will expose your system to compromise if you are not running ASL. If you are running ASL, you will need to reconfigure these applications per the instructions here.

Option 2:

Some applications require this vulnerable condition during installation. If you are unfortunate enough to have one of those applications, and the application vendor is not willing to fix their application, reboot the system into a non-secure kernel (a non ASL kernel) and install your application. Then reboot the system into the ASL kernel and follow the instructions in Option 1 to fix the vulnerable applications.

Option 3: (Insecure option)

We do not recommend you use this option.

It is possible to disable all stack protection in the ASL kernel so that it will not be enforced by default and only on executables marked explicitly. No executables are marked in this manner by ASL by default, as by default ASL automatically protects all executables. If you wish to use this option you will need to mark the executables you wish to protect.

Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various kernel protection features at runtime via the entries in /proc/sys/kernel/pax.

iptables: Unknown error 18446744073709551615

Issue:

iptables: Unknown error 18446744073709551615

Solution:

This error is not caused by ASL. There are two causes to this, one is an out of date version of iptables that is not fully compatible with your kernel. Your solution is to upgrade iptables to at least version 1.4.7.

The other cause for this error is that an iptables module is not loaded into the kernel, or that the module is no longer part of netfilter. Netfilter is the actual firewall in Linux and it does change. Older firewall scripts may require modules that no longer exist in Linux. iptables is just the command line tool that interacts with Netfilter. If you get an iptables error such as this one that means iptables tried to do something that netfilter either does allow or does not understand (you dont have that module loaded). On VPSs this can occur if the host kernel does not have the module loaded as VPSs do not control the kernel and therefore can not load any additional iptables modules dynamically.

The solution is to find out what module is missing. Unfortunately iptables won't tell you what module it may need, so we recommend you contact the party that created your firewall script or tool for assistance.

iptables: Unloading modules: iptable_mangle iptable_nat [FAILED]

When using the secure kernel in the default and secure mode, modifications to the kernel are not allowed. This includes loading and unloading modules.

This error is benign and you can ignore this.

kernel: ASL Active Response

This is a normal message that ASL will log if an IP addressed has been shunned, or firewalled off by ASL. This will occur if you have configured ASL's Active Response to "yes", and an event is triggered that exceeds the minimum event level threshold you have configured. Once that occurs ASL will log if any additional network traffic comes from that host, and it will limit this to one log message per minute for that IP address to prevent flooding of the systems logs.

grsec: denied kernel module auto-load of net-pf-10

Thats not an error, that means something on your system is trying to enable IPv6, you have IPv6 disabled on boot and ASL is configured to prevent modifications to the kernel after boot. By default the ASL kernel doesn't allow loading kernel modules at runtime to protect the system from kernel level rootkits. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system.

4 options to resolve this in order of most secure to least secure:

1) Ignore the message - it is harmless and no harm will come to your system from this message 2) If you do not want to enable IPv6, find the application and disable whatever in the application is trying to enable IPv6 dynamically 3) Enable IPv6 4) Configure ASL to allow your kernel to be modified at any time.

Options 2 and 3 you will need to discuss with your OS vendor, those are not part of ASL and are not supported by us.

Option 4, this option is NOT recommended. Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect, remove and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you to even detect that this as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.

If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this as critical vulnerability in the system.

kernel: grsec: denied resource overstep by requesting

The kernel is reporting that you have configured your system to deny a resource change in an application. The ASL kernel does not cause this, it just reports it. A non-ASL kernel, such as the default kernel used in most versions of Linux, does not have the ability to report when this occurs (the application just silently fails without any log message).

denied modification of module state

This means that you have configured ASL to protect your kernel from any changes. This is the default setting for ASL, and prevents attackers from inserting malicious code into your kernel. Dynamic modifications to running kernels are dangerous, and many operating system prevent this now (such as 64 bit Windows, and Windows Server.). If you wish to open this hole in your system please see the article #Can't install kernel modules.

denied use of iopl() by

ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by logging into the ASL GUI, click on the Configuration tab, then select ASL configuration. Scroll down to DISABLE_PRIVILEGED_IO and set this to "no". Then press the update button.

If ASL is configured to prevent changes to the kernel during run time, that is the setting ALLOW_kmod_loading is set to no (this is the default, and recommended setting), then you will need to reboot the system for this change to be applied to the system. We do not recommend you change ALLOW_kmod_loading to yes, that will open your system up to kernel level rootkits.

Or you can appending this to /etc/sysctl.conf

kernel.grsecurity.disable_priv_io = 0

And reboot your system.

grsec: denied open of /dev/port

ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by appending this to /etc/sysctl.conf, and rebooting your system:

kernel.grsecurity.disable_priv_io = 0

mysql errors/messages

MYSQL reports a table is "is marked as crashed and should be repaired"

This error is not caused by ASL. That means mysql was not shut down cleanly or that it crashed. You may have other crashed databases. Please follow the process documented by mysql to repair a crashed database.

The follow are some links to get you started:

For mysql 5.0:

http://dev.mysql.com/doc/refman/5.0/en/myisam-repair.html

For mysql 5.1:

http://dev.mysql.com/doc/refman/5.1/en/myisam-repair.html

For mysql 5.5:

http://dev.mysql.com/doc/refman/5.5/en/myisam-repair.html

OSSEC Messages

ERROR: Error executing query 'SELECT id FROM location WHERE name = 'host->/var/log/mysqld.log' AND server_id = '1' LIMIT 1'. Error: 'MySQL server has gone away'.

This generally means that mysql is either misconfigured or under heavy load. The most likely scenario is that the maximum number of connections that mysql will allow has been exceeded. Please increase the maximum on your system. You can do that by increasing "max-connections" in your mysql configuration, which is normally stored in /etc/my.cnf.

Other misconfigurations of mysql can also cause it "go away", which means that mysql has killed the connection. Check your mysql error logs and contact your OS or database vendor for additional support. A misconfigured database will have other effects on your system, and if ASL is unable to communicate successfully with your database your system has serious problems with the database.

Also, check your mysql logs to make sure you don't have any errors, a corrupt database can also cause this to occur.

ERROR: Error connecting to database 'localhost'(ossec): ERROR: Unknown MySQL server host 'localhost' (3).

This means that your system does not know what the IP address for "localhost" is. This is a default special server name that all systems use to refer to themselves, and the IP address for localhost is 127.0.0.1. Check your systems /etc/hosts file and ensure you have an entry for localhost. Below is an example of a localhost entry:

 127.0.0.1	localhost.localdomain	localhost	

Also check the permissions on your /etc/hosts file to ensure that it is world readable. A correct configured systems /etc/hosts file will have the following permissions:

 -rw-r--r--. 2 root root 866 Mar 31 18:26 /etc/hosts

Could not establish mysql connection

Please see the FAQ "Can't connect to MySQL server on '127.0.0.1'" below.

Command executed: /sbin/service ossec-hids restart

This message means that the process monitor has restarted the OSSEC host intrusion detection system. This generally means that the HIDS has either been shut down manually, and is being automatically restarted, or that the HIDS or a part of the HIDS is not running correctly and has been restarted.

Generally this occurs if there is a problem communicating with the systems database server. 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.

First, check your mysql logs first to determine if you have any corrupt databases that require repair. The HIDS will not start correctly to log events to the database if the tables it is using are corrupt.

If there are no mysql errors, check the log below for any error messages:

/var/ossec/logs/ossec.log

Then check this FAQ for guidance on those 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.

The following is a list of common problems:

1. HIDS rules are not up to date. Run these commands as root:

asl -u

asl -s -f

2. Firewall rules do not allow connection to the database.

3. Incorrectly configured /etc/hosts file (for example, using a hostname for the database that is not resolving or is not in the /etc/hosts file. "localhost" is the most common missing record, see #3 below)

4. Missing or incomplete localhost entry in /etc/hosts (localhost should resolve to 127.0.0.1)

5. A non-optimally tuned database that is rejecting connections

6. An overloaded database that is dropping, closing or rejecting connections sporadically

7. A database that is not listening on a TCP port or the same port that you have configured ASL to use.

8. A database server that is listening on a different IP address from the one configured for OSSEC.

ossec-syscheckd: ERROR: Unable to add directory to real time monitoring:

This error means that the system either:

1) Has run out file descriptors.

This is known to occur on VPS systems, where a limit has been set. Increase the limits on your VPS. Please contact your VPS vendor to determine how to do this with your VPS solution.

2) Does not support inotify

Non ASL kernels may not support the modern inotify capability in Linux. This allows files to monitored in real time. Please ensure that your system is running the ASL kernel.

3) You have reached the limit for watches on your system

The kernel sets a limit, which can be changed, on the number of real time files that can be monitored. This setting is:

/proc/sys/fs/inotify/max_user_watches

In most cases, the default is 8192. Which means the system can watch 8192 files in real time for changes. In practice, that is a lot of files, and should be adequate for the systems key software and configuration files. If you are watching additional directories, in real time, such /home, /var/www and so on, where the system may have tens of thousands of files you will want to increase this number. You can do that either temporarily by changing that value with a command such as this (run as root of course):

echo 16384 > /proc/sys/fs/inotify/max_user_watches

Or, you can set this permanently by modifying your systems /etc/sysctl.conf file by adding an entry such as the one below, which increases the limit to 16384:

fs.inotify.max_user_watches = 16384

If you do not have a /proc directory or an /etc/sysctl.conf, then this means you are using a virtualization technology that does not allow you to tune the kernel. Please contact your virtualization vendor for assistance with this.

4) The final option is to reduce the number of directories, and therefore files you have ASL configured to monitor. Please log into the ASL GUI, click on the "ASL" tab, then click on "File Integrity", then select the "Options" button. This will pull up the configuration screen to set which directories or files to monitor. Select the "Directories" button, and configure according to your needs.

ossec-analysisd: INFO: Reading decoder file etc/decoders.d/01-asl-decoder.xml

This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:

asl -u

asl -s -f

ERROR: Duplicated decoder with prematch: 'smtpauth-failed'.

This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:

asl -u

asl -s -f

ERROR: Error loading decoder options.

This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:

asl -u

asl -s -f

ERROR: Configuration error at 'etc/decoders.d/01-asl-decoder.xml'. Exiting.

This means that your OSSEC rules are out of date. Please run these commands as root to download the latest rules:

asl -u

asl -s -f

segfaults

Examples:

Jun 8 09:14:16 system kernel: php[5963]: segfault at a801cecc ip a800809b sp bff43d70 error 7 in ld-2.5.so[a8001000+1b000]

23:00:43 system 12 30104 [notice] child pid 26148 exit signal Segmentation fault (11)

exit signal bus error

ASL gives you more visibility into your systems errors, so in the case of segfaults ASL is not actually causing them its just reporting them (which the system didnt actually do very well before). 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, thats a very generic error, however to help you we have provided this courtesy section to explain these 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 the subsections below for solutions to commonly known segfaults.

If you are not using our kernel

Your problem is a little more complex, as your system will not log what caused the segfault. Unfortunately, you may have to do some detective work to find out what application is causing the segfault. Please review the final subsection, "apache segfaults" which links to an article that provides generic guidance for tracking down the source of segfaults through core dump analysis.

php segfaults

Example error messages:

Jun 8 09:14:16 system kernel: php[5963]: segfault at a801cecc ip a800809b sp bff43d70 error 7 in ld-2.5.so[a8001000+1b000]

Jun 8 09:14:11 system kernel: grsec: From 207.46.13.89: Segmentation fault occurred at a622eecc in /usr/bin/php[php:5952] uid/euid:590/590 gid/egid:590/590, parent /usr/local/apache/bin/httpd[httpd:5684] uid/euid:99/99 gid/egid:99/99

$ /usr/bin/php -v Segmentation fault

Discussion:

Some third party PHP modules, such as ioncube and Zend Optimizer may have their libraries set to allow the stack to be executable (a very huge security vulnerability the kernel will prevent, and a setting that is not necessary for these libraries to work). When php tries to load these libraries the kernel will prevent these libraries from calling a special function, mprotect, in an insecure manner. This will cause php to segfault. The solution (described below) is to just set the libraries to load securely.

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 a customized php install or have installed php from source (as happens with cpanel), then ASL can not manage this software dynamically and fix these broken libraries. You will need to find the insecure third party library that PHP is loading. In most cases this will be the ioncube and zend optimizer libraries, and in a package managed system (Such as Centos and Redhat) they are normally stored in locations such as (this is not a complete list):

/usr/lib64/php/ioncube/
/usr/lib/php/ioncube/

On non-package managed systems, such as cpanel systems, where the the package managed versions of PHP have been replaced with source compiled builds that location may be different. For example, cpanel usually compiles PHP and places it in locations similar to this (these may change, please contact cpanel or the party that build PHP from source for more information):

 /usr/local/IonCube/
 /usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/
 /usr/local/Zend/
 /usr/local/Zend/lib/Guard-5.5.0/php-5.3.x/
 (This is not a complete list, you will need to check what external libraries your source built PHP has installed).

One trick to find these libraries is to use your systems "locate" command. For example, you can use this command to find the ioncube libraries:

locate -i ioncube | egrep ".so$" | grep lib

And this one to find the zend libraries:

locate -i zend | egrep ".so$" | grep lib

Solutions:

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.

Option 2) Run ASL is scan and fix mode

ASL 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 almost always the case) 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, you can use these command that are included with your operating system to find them:

locate -i ioncube | egrep ".so$" | grep lib

locate -i zend | egrep ".so$" | grep lib

locate -i zend | grep -i optimizer | egrep ".so$"

Option 3) Use an insecure kernel

The least secure and not recommended option would be use an insecure kernel, such as the one 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.

Tomcat segfaults

Solution: Tomcat uses Java, and Java performs certain actions that violate stack protection security models. To allow Tomcat to run in this manner, you simply need to run chpax to configure tomcat and Java to be allowed to do anything they want on your system, and to turn off all security protections for Java. This vulnerability exists on all platforms, with or without ASL, if you want to run Java.

/sbin/chpax -ps /path/to/java/bin/java

/sbin/chpax -ps /path/to/tomcat/

You may also need to configure certain tomcat support tools to run without protection as well, gcj-dbtool is one such case:

chpax -emrspx /usr/bin/gcj-dbtool

gcj-dbtool segfaults

Please see the above FAQ question.

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

cpanel errors

Error from ssl wrapper: Unable to produce a valid Apache configuration file

Additionally, these errors may be found in the cpanel error log:

/usr/local/cpanel/logs/error_log:

[2012-04-05 19:18:33 +1000] warn [ssladmin] Unable to produce a valid Apache configuration file. at bin/ssladmin line 201
[2012-04-05 19:18:33 +1000] warn [cpanel] Cpanel::AdminBin::adminrun(ssl) set error in context ssl
[2012-04-05 19:18:33 +1000] warn [ssl::install] Encountered error in ssl::install: Error from ssl wrapper: Unable to produce a valid Apache
configuration file.

This is caused by an insufficient amount of memory being allocated to the cpanel process. The allocated amount of memory can be changed from within WHM as follows:

1) In the menu on the left, click on "Tweak Settings".

2) In the main frame, click on the "System" tab.

3) Increase the value for "Max cPanel process memory".

An increase of 64MB should generally be enough, but this may vary depending on your system, the amount of domains you have on the system, etc. If an increase of 64MB is inadequate, keep increasing the limit by 32MB increments.

Generic Errors/Issues

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.

Checking for psmon installation: not installed [FAILED]

psmon is not supported with cpanel installations. If your system is running cpanel you will not be able to use the process monitor.

No events in the ASL GUI

Step 1)

First check to make sure the GUI is not working. Set the GUI level to 1 so you can see all events. By default the ASL GUI is set to a higher level to filter out lower importance events and to only display attacks and highly supicious events by default. If the ASL GUI is showing lower level events, you may either not have any attacks or suspicious events to report, or you may have disabled or not installed all of ASL protection components.

In that case, send a simple test from the local system, or another system that should be both blocked and logged. This article provides a test example:

Atomic_ModSecurity_Rules#Testing_to_see_if_the_rules_are_loaded

Step 2) Check mysql to ensure you do not have a corrupt database

If you have tested to make sure the system is actually blocking the test attack, and are sure that the ASL GUI should be displaying events, and it is not displaying any, check that your database is not corrupt. Mysql is normally configured to log errors to /var/log/mysqld.log. A corrupt database will result in an error in the mysql logs. A typical entry will look like this (this is just an example, please check your logs for any mysql errors and not just the example below):

Table './tortix/alert' is marked as crashed and should be repaired

If you see errors such as these, please see the faq article above for links to mysqls procedures for fixing databases.

Some products, such as cpanel, configure mysql to not save logs. Please contact your database vendor if this is your case for advice on how to configure your database server to log errors as you will need to confirm the database is working correctly before moving on to the next step.

Step 3) Check to make sure OSSEC is working correctly

If you have determined that your database does not have any errors, check to make sure your OSSEC rules are up to date. Run these commands as root:

asl -u

asl -s -f

If OSSEC is still not starting, please see this article for additional system checks to perform:

#Command_executed:_.2Fsbin.2Fservice_ossec-hids_restart

cannot open database /var/lib/rpm and db3-error from dbenv_open

This a serious error with your operating systems software management system. This is not caused by ASL and is not something ASL can fix.

This either means that you do not have permission to access the software management system, or if you do have permission it means your operating systems software management database is corrupt or missing. Please contact your OS vendor for assistance with this issue.

Yum was not detected. Attempting to resolve..

This means that yum, the package management system built into modern Linux rpm based Linux systems, such as Redhat, Fedora and Centos is missing. This is a key and vital part of the system that makes it not only possible to install software, but also to make sure the system is up to date and properly patched. ASL will try to install yum if its missing, but if it can not you will need to discuss this issue with your OS vendor.

yum is an internal part of the OS, and if its missing something is seriously wrong with the system and should be resolved before trying to install any software.

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.

Can't connect to MySQL server on '127.0.0.1'

This means that OSSEC can not connect to mysql on your system. OSSEC, a component in ASL, uses TCP to connect to your mysql server. Configure mysql to listen on port 3306 on 127.0.0.1 on your system.

Step 1. Check to make sure mysql is running, and that its listening on IP address 127.0.0.1.

To check if mysql is running, run this command as root:

 ps auxwww | grep mysql

You should see a similar result to this:

root     17813  0.0  0.0  65988   852 ?        S    Mar19   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock 
--pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql    17930  0.5  6.5 551972 264788 ?       Sl   Mar19 116:55 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql 
--log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock

If you do not see a result similar to this, mysql is not running on your system. Start mysql. If you require assistance with mysql, please contact your Operating System or database vendor. If you have neither, please post in the community support section of our forums.

Also check to make sure mysql is listening on TCP port 3306 and IP address 127.0.0.1:

 netstat -anp | grep 3306

A correctly configured mysql will look similar to this:

 tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      5543/mysqld         

Or this:

 tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN     5543/mysqld      

If you do not see either 0.0.0.0 or 127.0.0.1 in the fourth column then you may have mysql configured to listen on a specific IP address. You have two choices:

Option A) Configure mysql to listen on all addressed

Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:

 /etc/init.d/mysqld restart

Option B) Configure ASL to connect to mysql on a different IP address

Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.

Step 2. Make sure you dont have "skip-networking" in you /etc/my.cnf file.

Check for the line "skip-networking" in your /etc/my.cnf file:

 grep skip-networking /etc/my.cnf

If you have this line, remove that line from /etc/my.cnf and save the file.

Restart mysql and restart OSSEC. Run these commands as root:

 /etc/init.d/mysqld restart

 /etc/init.d/ossec-hids restart

Check to make sure mysql is listening:

 netstat -anp | grep 3306

A correctly configured mysql will look similar to this:

 tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      5543/mysqld         

Or this:

 tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN     5543/mysqld      

If you do not see "tcp" in the first column, and LISTEN in the fifth mysql is not configured to listen for TCP connections.

If you only see any entry like this:

 unix  2      [ ACC ]     STREAM     LISTENING     38593710 /var/lib/mysql/mysql.sock

mysql is not configured to listen on a TCP port.

Step 3: check to make sure mysql is listening on port 3306 and IP address 127.0.0.1:

A final test to see if mysql is listening on loopback is to telnet, from the system that mysql is running on (not from a remote system), to the loopback interface:

 telnet localhost 3306

You should see something like this:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
4
5.0.77>

If you can not connect to mysql, check to make sure that you do not have any lines in /etc/my.cnf that contain "bind-address". If you do:

Option A) Configure mysql to listen on all addressed

Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:

 /etc/init.d/mysqld restart

Option B) Configure ASL to connect to mysql on a different IP address

Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.

Step 3. If mysql is listening on port 3306 and on 127.0.0.1, and you still can not connect to it on loopback

This is most likely caused by local firewall rules. Disable your firewall to see if you can connect to mysql:

/etc/init.d/iptables stop

If you can connect to mysql, then your firewall rules need to be adjusted to allow connections to mysql on localhost. It is beyond the scope of this article to explain how to do that, please contact your firewall or OS vendor for support.

ModSecurity: Request body (Content-Length) is larger than the configured limit

Change this setting in the ASL GUI to the maximum value you wish to set.

MODSEC_REQUESTBODYLIMIT

Note: This is set in bits. Therefore, if you want to set the limit by bytes you will need to compute for bits.

For example:

1 gigabit is 134217728

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

The default is 1 gigabit, or 134217728

32 bit systems note: There is a hard limit in apache itself of 2Gb on 32 bit platforms. Apache supports file sizes greater than 2 Gb on 64 bit platforms where Apache is built with large file support. Versions of Apache that are not compiled with 64 bit offsets (large file support), or are operated on 32 bit platforms will have a 2GB maximum limit. This 2GB hard limit is not enforced by modsecurity nor is it something ASL establishes, this is an internal limit in apache. Keep in mind this is also request body limit, not a response body limit.

Error: Another instance of ASL appears to be running, exiting...

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" | 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

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

Error: Missing Dependency: httpd-mmn = 20051115 is needed by package

This means that the system is running a non-package managed version of Apache, such as with cpanel or directadmin and your system has been configured to not allow package management or dependency resolution via a package manager. ASL will generally attempt to work around this, but in some cases this may not be possible. Please report this as a bug to your control panel vendor as disabling package management is a very bad software engineering practice.

Access denied for user 'tortix'@'localhost' (using password: YES)

This means that the credentials you are 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, just run this command as root:

/var/asl/bin/database-setup

HTTP Error 401: Authorization Required Trying other mirror.

Explanation:

This can mean:

• your ASL username and/or password is incorrect, 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 check to make sure you credentials are correct and that your licenses are valid first.

Solutions:

If you have not installed ASL, or have not installed ASL completely installed, and are getting this error:

This means you have entered your credentials incorrectly, or you are attempting to install ASL on more systems that you have a license for.

Step 1

Check the License Manager to ensure your license(s) is/are up to date. You can access the license manager here:

https://www.atomicorp.com/support/license-manager.html

Step 2

Run the ASL installer. When asked to enter your "Enter subscription Username" and "Enter Subscription Password", enter the same credentials you used in step 1 to log into the license manager.

If you do not know what those credentials are, or you need to reset them, please visit this URL to reset your subscription credentials:

https://www.atomicorp.com/support/license-manager.html

Step 3

If you are still getting this error, remove the asl.repo file from this directory:

/etc/yum.d/

Then run the installer again.

If you do have ASL installed:

Step 1)

Check the License Manager to ensure your license(s) is/are up to date. You can access the license manager here:

https://www.atomicorp.com/support/license-manager.html

Step 2)

If your licenses are up to date, check to make sure you have ASL configured to use your current ASL username and password.

Sub Step 1) Log into the ASL GUI

Sub Step 2) Click on Configuration

Sub Step 3) Check to make sure the USERNAME and PASSWORD variables are set to your ASL credentials (that is the same username and password you use to log into the license manager.

Sub Step 4) Then click the "Update" button to update your configuration.

Sub Step 5) Run the update process.

Alternatively, you can manually edit the file /etc/asl/config, and change the USERNAME and PASSWORD calues. Then run the command "asl -s -f" as root to set your configuration, and "asl -u" to update.

Error: Your Username/Password is incorrect, or your account has Expired.

See the #HTTP Error 401: Authorization Required Trying other mirror. FAQ above.

ossec-dbd(5202): ERROR: Error connecting to database 'localhost'(tortix): ERROR: Unknown MySQL server host 'localhost' (0).

Check to ensure you are not using "skip-networking" in /etc/my.cnf, OSSEC chroots and because it does so, cannot use the regular mysql socket to communicate to the database. It requires a TCP connection over the loopback IP address. Likely mysql has been configured to not listen on the loopback IP (skip-networking) or firewall rules are blocking connections to it.

ERROR: Invalid SMTP Server: localhost

This means your system is missing an entry for localhost and the operating system can not determine what the IP address for localhost is. This is a serious error on the system and will have adverse impact on other systems.

Recommended solution

1) Determine how the localhost entry was removed, this may be indicative of other serious problems with your system

2) Add a localhost entry to /etc/hosts

127.0.0.1 localhost.localdomain localhost

If this does not solve your problem with missing localhost entries you may more serious problems with your system that are beyond the scope of ASL. localhost is a standard name used on all operating systems, and all operating systems are configured with a localhost entry. If yours is missing your system has been modified from the OS vendors standard working configuration.

Horde webmail is reporting: "There was an error sending your message: Failed to open sendmail [/var/qmail/bin/sendmail] for execution."

Option 1) The host secure choice and frankly the easiest option is to configure horde to use SMTP and not to call the sendmail binary. This post in the support forum details how to configure horde to use SMTP[1]. 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 [2]. The escapeshellcmd function also needs to be available or sending mail will fail without any error messages.

Cant get or send mail with webmail application

This can happen if a webmail application is written in PHP and requires a PHP function that has been disabled based on either your ASL configuration, or was manually disabled in your PHP configuration file (php.ini). Most webmail clients require these functions to be enabled in PHP at a minimum:

• exec
• popen

Some webmail clients will also require these functions:

• pfsockopen
• fsockopen

If you are using horde, please see the FAQ above for an additional more secure option, which uses SMTP instead of the exec and popen functions.

What does the following alert mean and what should be done?

Message: [file "/etc/httpd/modsecurity.d/05_asl_scanner.conf"] [line "37"] [id "351000"] [rev "1"] [msg "Malicious File upload attempt"] [severity "CRITICAL"] Access denied with code 403 (phase 2). File "/tmp/12345" rejected by the approver script "/usr/bin/modsec-clamscan.pl": 0 Unable to parse clamscan output [WARNING: Can't connect to clamd.] Action: Intercepted (phase 2) Stopwatch: 12345 12345 (12345* 12345 -) Producer: 200811121208. Server: Apache/2.0.63 (CentOS)

This means that clamd is not running on the system. Please check to make sure that clamd is running. You can do that by executing the following command as root:

ps auxwww | grep clamd

If you do not get a result like this:

[root@www3 clamav]# ps auxwww | grep clamd clamav 21142 0.0 8.5 203064 173996 ? Ss 04:21 0:04 clamd

clamd is not running. To start clamd simply run this command:

/etc/init.d/clamd start

Error: Cannot retrieve repository metadata (repomd.xml) for repository: plesk. Please verify its path and try again

Solution:

http://www.atomicorp.com/channels/plesk/README

The plesk third party RPM archive has moved! Running the installer again will reconfigure your system to use the new channel.

wget -q -O - http://www.atomicorp.com/installers/atomic |sh

Metadata file does not match checksum

This is not an ASL error, that error is generated by your Operating Systems package management system. Please contact your OS vendor for assistance. The information that follows is provided as a courtesy. This tool is not part of ASL, is not used by ASL and is not supported by Atomicorp.

This generally means your yum cache has corrupt or old data in it, you need to clear your yum cache.

Method 1)

Run this command as root:

 yum clean metadata

Method 2)

 yum clean all

Method 3)

If the previous two methods do not work, and you have fastestmirror installed you may need to rebuild your cache:

 yum makecache --disableplugin=fastestmirror

Method 4)

If you still can not get yums cache cleared you may need to disable fastestmirror:

 vi /etc/yum/pluginconf.d/fastestmirror.conf

And set "enable=0"

Method 5)

If your package management database seems corrupt, you can try to rebuild it with this command run as root:

 rpm --rebuilddb

This is generally not required unless you have killed an rpm operation or had a crash during an rpm operation.

Method 6)

Remove fastestmirror (if you have it installed):

 yum remove yum-fastestmirror

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

If you want to install this tool, please follow the instructions generated by yum. Specifically, this message is stating that the tool yum-complete-transaction is part of the "yum-utils" package:

The program yum-complete-transaction is found in the yum-utils package. To install that package you need to run this command as root:

yum -y install yum-utils

You need to install that package to use that tool. This tool is part of the overall system that allows you to (among other things) pause & resume upgrades.

If you dont know where a component comes from you can use "yum provides /path/to/file" (wildcards accepted) to search.

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.

/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

Rule: 30104 fired (level 12) -> Apache segmentation fault

Solution:

This means that apache is experiencing a recoverable memory error. We have found that mod_memcache seems to cause this. Turning it off has worked for many users.

Also, see this wiki article for more information on apache debugging:

http://www.atomicorp.com/wiki/index.php/Apache

Java is stopped by PAX

Solution: Java performs certain actions that violate stack protection security models. To allow JAVA to run in this manner, you simply need to run chpax this way:

/sbin/chpax -ps /path/to/java/bin/java

DEBUGGER DETECTED... Bye!

This message is generated by Parallels programs that attempt to detect if the user is running the Parallels program through a debugger. If you are not running a debugger, and you are running the ASL kernel this is most like caused by the a bug in the Parallels program that incorrectly detects this condition. The FAQ article above provides a solution to workaround this bug in Parallels products.

You can also read more about the kernels ptrace exploitation protections.

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

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.

ASL reports that grsecurity is not installed

Solution:

You must reboot your system to use the ASL kernel, which includes grsecurity. Default OS kernels do not include any stack protection, grsecurity or PAX features.

To tell which kernel you are running, as root execute this command:

uname -a

ASL kernel Critical not detected

See above.

Kernel GRsecurity support High not found

Solution:

You must reboot your system to use the ASL kernel, which includes grsecurity. Default OS kernels do not include any stack protection, grsecurity or PAX features.

To tell which kernel you are running, as root execute this command:

uname -a

If you are a VPS customer you can use a separate kernel from the host machine, which means you will not be able to use the ASL kernel. This is a security risk for your VPS and you are encouraged to contact your hosting provider for information about how they will protect your virtual server from attacks through the host server. If your hosting provider is unwilling to meet your security needs we encourage you to contact some of the fine hosting companies that use ASL and who post regularly to these forums.

If you are running a PAE system you will need to install one of our testing PAE kernels. PAE allows a 32 bit system to access memory beyond the limits of a 32 bit architecture, its sort of a hack to get around the system not being 64 bit. As a result, these kernels require more work for our kernel development team. If you are in a rush, we recommend you use a 64 bit architecture to access memory beyond 4 GB. Normal 32 bit and 64 bit kernels are fully supported.

We are working hard to finish testing of PAE kernels and will keep you informed of its progress.

Checking service for authorized_keys: not found [FAILED]

Answer:

This means that when you installed ASL you did not configured your system to use keys for SSH logins, but is instead configured to only use passwords. Passwords are less secure than keys as keys are a simple for of a two factor authentication system, something you have and something you know.

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.

WARNING: SSH will not be reconfigured at this time.

Answer:

This means that you did not configure SSH when you installed ASL, so ASL will not reconfigure SSH per your instructions.

FAILED: Remote root logins are still permitted: [HIGH]

Answer:

This means that when you installed ASL you did not configured your system to use non-privileged accounts for logins. This means that you allow root logins to your system which is very dangerous and should be disabled. All users, including admins, should always log into a unique account for each person so that you will know logged into your system, and then those non-privileged users can su to root, or can use sudo to run privileged commands.

FAILED: Password authentication is enabled: [HIGH]

Answer:

This means that you did not configured SSH when you installed ASL to disallow password based logins. ASL will ask you to configure SSH to use key based authentication as it is more secure. If you tell ASL not to configure this ASL will report this as a high risk vulnerability.

up2date issues

When running yum update or yum upgrade this error occurs:

Loading "installonlyn" plugin

Loading "rhnplugin" plugin

There was an error communicating with RHN.

RHN support will be disabled.

Error communicating with server. The message was:

Error Message:

Please run rhn_register (or up2date --register on Red Hat Enterprise Linux 3 or later)

as root on this client

Error Class Code: 9

Error Class Info: Invalid System Credentials.

Explanation:

An error has occurred while processing your request. If this problem

persists please enter a bug report at bugzilla.redhat.com.

If you choose to submit the bug report, please be sure to include

details of what you were trying to do when this error occurred and

details on how to reproduce this problem.

Solution:

This is not an ASL error. This means that your system is configured to use Redhat Update Network and you do not have valid credentials to use their server. Contact Redhat support for assistance.

yum update errors

When running yum update or yum upgrade this error occurs:

Setting up Upgrade Process

Setting up repositories

http://atomicorp.com/channels/asl-2.0/c ... repomd.xml: [Errno 14] HTTP Error 401: Authorization Required

Trying other mirror.

Error: Cannot open/read repomd.xml file for repository: asl-2.0

Solution:

This means that your system is not configured with a valid ASL subscription account. Please check your username and password in your asl configuration and check to make sure your subscription is up to date.

Wheres the ASL Web GUI?

You can access it on your system at this URL (change www.example.com to either your systems name or IP address)

https://www.example.com:30000

Make sure your firewall is configured to allow access to the TCP port 30000.

Security Bulletins Blank

Issue:

Security bulletins window is blank, or in the Security bulletins window you see "loading", but nothing loads.

Answer:

If the security bulletins are not loading this generally means that the system running ASL can not connect to www.atomicorp.com on port 80. Please check to make sure that you can connect to www.atomicorp.com from the system running ASL (not your desktop). If you can not, then check to make sure you do not have a local firewall rule (an OUTPUT rule for example) or an upstream firewall preventing connections to www.atomicorp.com.

Does ASL have any PHP dependencies?

No. ASL uses its own PHP libraries which are installed in /var/asl and have nothing to do with the systems PHP libraries.

The ASL PHP libraries rpm packages will have the name "art" in them. Do not change the ASL PHP rpms, they are only used by ASL.

Table 'tortix.asl_user' doesn't exist

This means that you did not setup your ASL database. To manually setup the database simply run this command as root:

/var/asl/bin/ossec_database_setup.sh

It is safe to run this script multiple times.

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.

Tomcat is stopped by PAX

Solution: Java performs certain actions that violate stack protection security models. To allow JAVA to run in this manner, you simply need to run chpax this way:

/sbin/chpax -ps /path/to/java/bin/java

There are unfinished transactions remaining.

The error continues:

You might consider running yum-complete-transaction first to finish them. The program yum-complete-transaction is found in the yum-utils package.

This is not an ASL error, that error is generated by your Operating Systems package management system. 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.

If you want to install this tool, please follow the instructions generated by yum. Specifically, this message is stating that the tool yum-complete-transaction is part of the "yum-utils" package:

The program yum-complete-transaction is found in the yum-utils package. To install that package you need to run this command as root:

yum -y install yum-utils

You need to install that package to use that tool. This tool is part of the overall system that allows you to (among other things) pause & resume upgrades.

If you dont know where a component comes from you can use "yum provides /path/to/file" (wildcards accepted) to search.

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) then you will not able to install ASL. ASL is only supported on Linux systems that use package management.

clamav messages/errors/issues

This version of the ClamAV engine is outdated.

First, don't panic, this is not a serious error. 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:

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 from the asl-2.0-testing yum repository.

/usr/bin/modsec-clamscan.pl (The timeout specified has expired)

This means that the clamd daemon is either not running, or a response from the daemon has timed out. The later can occur if the system is heavily overloaded to such an extent that the clamd daemon is unable to process the request quickly enough.

Troubleshooting:

1) Check that the clamd service is running:

Run this command as root:

ps auxwww | grep clamd

If clamd is running, you should see something similar to this:

root 29859 0.0 6.8 471680 419364 ? Ssl 12:28 0:00 clamd

If clamd is running and the event happened in the past its possible clamd was not running at the time and was started by the system process watchdog. In that case, monitor to the system to see if the clamd service was stopped.

If clamd is not running, start clamd with this command as root:

/etc/init.d/clamd start

2) Check the load, CPU usage and memory available on the system at the time the event occurred. If the system was overloaded, add additional resources to compensate for system load.

LibClamAV Warning: Detected duplicate databases /var/clamav/main.cvd and /var/clamav/main.cld, please manually remove one of them

This can occur if an update is interrupted and clamav does not have a chance to clean up after itself.

Solution:

Remove either the /var/clamav/main.cvd or /var/clamav/main.cld file.

You can also remove both, if you do that run the command "freshclam" as root after you do that.

Other Questions

I want to have greylisting.

Those are all freely available from the atomic repository. They are not part of ASL and not supported through an ASL license. If you need support for these packages contact sales@atomicorp.com and we can put together a custom support package for you.

Install ClamAV and SpamAssassin:

yum install clamd spamassassin

Edit required_hits in /etc/mail/spamassassin/local.cf if you want to change the default tagging threshold (default is 5).

Install qmail-scanner (integrates virus and spam filters with Plesk's qmail):

yum install qmail-scanner

Edit SA_DELETE in /etc/qmail-scanner.ini if you want to delete mail (at SpamAssassin's required_hits + qmail-scanner's SA_DELETE).

I also recommend adding Pyzor, Razor and DCC to SpamAssassin:

yum install pyzor razor-agents dcc

If you want to add greylisting:

yum install qgreylist

Start clamd and spamassassin:

service clamd start

service spamassassin start

Reconfigure qmail-scanner to make sure it uses all your custom settings:

qmail-scanner-reconfigure

Make sure clamd and spamassassin are started at boot time (maybe they are enabled by default, I'm not sure):

chkconfig --level 345 clamd on

chkconfig --level 345 spamassassin on

Atomic Scanner

How do you view/find/install the extra modules/areas for statistics reporting? I only seem to have Dashboard/Inventory/Block List/Configuration/Support views in the Plesk (8.6.0) options. e.g. Atomic Scanner.

Solution:

Atomic Scanner is a separate project which is not available in the stable repository yet and is not currently supported. You can install the atomic-scanner package from the testing repository.

vmware-tools will not compile

On older Linux distributions, such as EL5 and Centos 5, VMWare(TM) has compiled its product using older compilers used to build the older kernel used by default in those distributions. ASL uses the most modern and up to date Linux kernel, and must be compiled using modern compilers. When VMWares module compiler script tries to compile their modules against a more modern kernel it may fail if VMWare has used an older compiler for their product. Their script expects the system to have the same version of compiler installed as was used to compile the kernel. This is not possible with modern kernels.

Solutions (in order of ease and least impact to system):

Option 1) We provide the open source open-vm-tools (VMWares official open source vmware tools package) in the ASL repository that provides the same functionality as vmware-tools. You can install that with:

yum install open-vm-tools

Option 2) If you wish to install vmware-tools, then you must upgrade your system to the same version of the compiler used to compile the kernel. This requires heavy modification to your system, and is beyond the scope of support Atomicorp can provide for VMWares product. Contact VMWare for assistance or uses vmwares open-vm-tools (option 1) which provides the same functionality.

You can read more about VMWares open machine tools at the URL below:

http://open-vm-tools.sourceforge.net/

/usr/bin/vmware-config-tools.pl

Please see the article above if VMWare's tools will not compile on an older system.

If VMWare tools will compile, but you get an error from VMWares tools that it can not find kernel headers, you simply need to install them. Run this command as root to install the kernel source and headers:

yum -y install kernel-headers kernel-devel

If you have previously installed both, and VMWare is complaining that it can not find the source for the kernel, you simply need to upgrade the kernel-devel package. Run this command as root to do this:

yum -y upgrade kernel-headers kernel-devel

If your system does not install anything with either of these commands, check to make sure a third party has not excluded kernel updates from being installed on your system. You can read more about this in the kernel wiki article.

What is included in the open-vm-tools?

Please see the projects official FAQ:

http://open-vm-tools.sourceforge.net/faq.php

Why does Linux report that all memory is in use?

Note: This FAQ article is not about ASL, it is about all Linux based systems. This characteristic of Linux based systems is universal to all Linux systems, not just systems running ASL.

Memory is almost infinitely faster than reading from a hard disk, so modern high performance operating systems, such as Linux, will cache things into memory if they are read from disk. Over time, you should see a Linux system (via some tools) report an almost 100% "memory utilization" regardless of much memory is actually needed by a process or how much memory is installed in the system. This can be a little strange to users that are new to Linux and come from operating systems that do not cache (such as Windows), however this is normal and is good for the system as actually makes it much faster. This does not mean your processes are using up all the memory the system has, this is simply modern caching which all modern Linux kernels will do.

Why Linux does this

Hard drives are slow. Even the fastest hard drive is never even close to the speed of RAM. If hard drives were fast, we wouldnt need RAM. So we load programs into memory. As memory has gotten cheaper, and performance demands have increased, operating system vendors have increased the use of RAM over reading from hard drives to improve performance. One way they do this is by caching "reads" from the hard drive (they cache other things too). In the case of caches reads, the operating system will store, temporarily, information it has been asked to read from the hard drive into memory. This makes it much faster the next time the operating system wants to "read" that information, it doesnt have to go back to the hard drive to get it, it can get it from memory. Which results in a huge performance increase.

Caching is different from process utilization. Actual memory in use by processes, or process utilization, which will be discussed more below is different from caching. Modern operating systems will use memory for processes (actual use), and also to "cache" things that they have accessed from disk. Most users are familiar with process utilization, which is what may cause them to think that Linux is "using up all their memory". When in reality the amount of memory in use by the processed by be considerably less than the memory in use.

It is the later use of memory, caching, that typically "uses" up the memory on the system and creates this illusion that all memory is in use. This memory is actually not "in use", or prevented from being used by other processes on the system. Its really "free memory", for the moment a process needs this memory the cached information is dropped and made available to the application. So in reality, the system is "using" considerably less memory that it may appear to be using because its making use of memory, temporarily, thats not actually in use. Its really a very clever enhancement, and something all operating system vendors are implementing. As memory has continued to get cheaper, some products don't even have hard drives anymore, and just use RAM. Smart Phones for example, and even some modern tablets just use memory.

So, to determine how much memory is actually being used by your processes (as opposed to all memory being used by processes and the cache), you will need to use a tool that can tell you how much memory is cached, and how much is actually being used by your programs. Once such tool is "free". The application "top" which is popular for looking at memory usage is not a good tool for this as it will incorrectly report that more memory is in use than is actually being used by processes.

Here is an example for how to use the "free" tool:

free -m

             total       used       free     shared    buffers     cached
Mem:         12002      10199       1803          0        573       8185
-/+ buffers/cache:       1440      10562
Swap:        14015          0      14015

In this example the total amount of memory in use is 10GB, however 8GB of that is cached. So the system isn't using 10GB of memory. Of the 12GB of memory on the system, just slightly under 10GB is actually free (1.8 GB isnt used at all, and 8GB is cached).

This is very typical of a Linux based system, in that its really using much less memory that some tools report, because of this use of cached reads.

Remember that cached memory is always available to any program that needs it. So the memory is not "used", its just being temporarily taken advantage of because nothing else is using it to make the system faster. Linux will just make use of the memory available on the system to cache information until any program requests it, at which time that cached data is dropped and the memory is made available to the application.

How can I find out what process is using swap?

Swapping in Linux is handled by the kernel, all Linux kernels will pull things out of memory and write them to the disk swap based on need depending on how much memory you have, swappiness setting on the system, and so on. Therefore, its not possible to find out which process is using swap, processes dont use swap, the kernel will write memory pages as needed to swap, processes dont control this (although a process could request memory that is not "swapped" out to disk). Linux will also use swap and memory to cache file reads, over time all Linux kernels will use 100% of memory to cache as much as possible. Memory is infinitely faster than RAM, so this is how modern high performance operating systems work. You should see near 100% memory utilization on all modern Linux kernels over time, regardless of much memory is actually needed by a process. This does not mean your processes are using up all the memory the system has, this is simply modern caching which all modern Linux kernels will do.

If you have additional questions about Linux swap you may want to ask your Operating System vendor.

How are malware domains aged out?

The actual algorithm is sensitive information and we can't go into the specifics as that would give the bad guys an advantage to game the system. The short answer is infected domains are aged out depending on the extent to which the domain is still serving malware (more on this in a moment, this is actually pretty difficult to prove that a domain is not serving malware), if its been seen in other malware, past experience with the domain, IP range, or network and the sophistication of the malware. Some sites are long term sources of malware, and act as "clearing houses" for attackers, others may simply be victims of a compromise that clean up their systems the same day, and others may be negligent operators that don't care. For this reason the process varies depending on a number of characteristics.

Its important to remember that all Internet based malware scans are incomplete, regardless of the technology used, the system itself is not being scanned, merely publicly discoverable resources. Attackers can hide malware in orhpaned URLs, they may use authentication to hide the malware from all crawlers, they may encrypt or obfuscate it and they may simply take the malware or domain down for a few days or weeks in hopes of being delisted by simple scanners.

For this reason we do not use a naive algorithm that simply removes malicious domains based on simplistic criteria. Our first priority is to help our customers protect their systems, if a domain has been serving malware its a good idea to treat it with kid gloves. If you know the domain is safe, you can always whitelist that domain.

The best way to delist a domain is to contact us. If we can get in contact with the domain owner we can determine more clearly if the domain is no longer infected, otherwise domains are aged out based on the criteria described above.

How are malware domains added?

They are collected from our honeypots.

Do you use third party malware domain lists?

No, but we do share our information with other projects.

You can use the google safebrowsing lists with clamav which is an excellent third party malware list. ASL enables this by default in clamav. False positives on the google lists should be reported to google.

How are spam domains added?

They are collected from our honeypots.

How are spam domains aged out?

The actual algorithm is sensitive information and we can't go into the specifics as that would give the bad guys an advantage to game the system. The short answer is spam domains are aged out depending on the extent to which the domain is still serving spam and the nature of the spam thats served, past experience with the domain, IP range, or network and the sophistication of the spamming attack captured on the honeyports. Some sites, networks and IPs are long term sources and hosts of spam, others may simply be victims of a compromise or some form of multi-system spamming attack that clean up their systems the same day, and others may be negligent operators that don't care. For this reason the process varies depending on a number of characteristics.

For this reason we do not use a naive algorithm that simply removes spam domains based on simplistic criteria. Therefore, our first priority is to help our customers protect their systems, if a domain has been used as part of a spamming attack, and is actually serving up spam (we don't block so called "joe job" spams) its a good idea to treat the domain a a spam source.

The best way to delist a domain is to contact us. If we can get in contact with the domain we can determine more clearly if the domain is no longer part of a spamming operation, otherwise domains are aged out based on the criteria described above.

Do you use third party spam domain lists?

No, but we do share our information with other projects.

Both atomic and asl yum channels are enabled, is this normal?

That depends, ASL does not need the atomic channel and will not install nor enable this channel. If you have the atomic channel enabled on your system then someone enabled this yum channel. You do not need it for ASL. In general its perfectly safety to run both channels (we do).

The atomic yum channel is our open source yum repository. All the software in the atomic yum repository is not supported and provided as is, with no warranty. If you have issues with software in the open source atomic channel please post your questions in the General Help forums:

https://www.atomicorp.com/forums/viewforum.php?f=1&sid=56518c30b96faf5235e2f4ef5e902d11

Software in asl channels is fully supported. If you require assistance with ASL software please send a support request to support@atomicorp.com.

What are the IPs ASL will use to update itself?

You will want to allow access to www0 thru www6.atomicorp.com. The IPs for these hosts may change in the future.

I can't upload files via web

Check and make sure you haven't run out of drivespace. This may seem like an obvious and simple problem that one wouldn't easily overlook, but we've had a number of cases where users setup /tmp partitions and filled them up. If you fill up your /tmp partition apache won't let you upload anything! Thats not an ASL issue, thats Apache and its right - theres no place to put the file.

ASL will log this event, but since ASL isn't designed to report when you run out of drive space it will detect this as a pretty major error and a broken connection with your HTTP session. Which will look like this:

[Fri Oct 01 17:33:21 2010] [error] [client xxx.xxx.xxx.xxx] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "38"] [id "340152"] [msg "Request Body Parsing Failed. Multipart parsing error: Multipart: writing to "/tmp/20101001-173321-8ZuEbMzo8r8AABWjEW8AAAAe-file-NvPOwz" failed: check your application or client for errors, this is not a false positive."] [severity "NOTICE"] Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_PROCESSOR_ERROR" required. [hostname "www.example.com"] [uri "/horde/imp/compose.php"] [unique_id "8ZuEbMzo8r8AABWjEW8AAAAe"]

This would means that you ran out of drive space in /tmp.

Solution:

Free up some drive space.

Do you have pre-defined access policies , or do we have to configure these policies?

Answer:

Yes, currently we use Trusted Path Execution (TPE), and the untrusted users group by default. Members of the untrusted users group can only execute commands owned by root. In addition non-root users can only see processes owned by them. Grsec has an additional RBAC and Process ACL system available.

Does ASL include SELinux?

Yes. SELinux is available in the ASL kernel.

ASL also includes a powerful self-learning Role Based Access Control (RBAC) System designed by the grsecurity project that is superior to SELinux. This RBAC was designed, and our company provides funding to the grsecurity project to account for weaknesses in SELinux, so we recommend you use the RBAC system in ASL if you need the same capabilities as SELinux.

However, if you wish to use just SELinux ASL will work with SELinux just fine.

If predefined can you give us a sample policy that mitigates the critical server file access when mod_perl is called via a client, or in other words how hard is your tuning. (intrusion log..etc)?

A: TPE would automatically prevent an untrusted user, such as apache, from executing commands owned by apache. It would log to syslog, an example entry follows:
Nov 11 14:53:10 server4 kernel: grsec: From 10.249.64.1: denied untrusted exec of /tmp/w00t by apache [uid/eid: 48/48] /home/httpd/vhosts/testhost.atomicorp.com/httpdocs/modules/phpBB/index.php

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

Installation Errors

kernel-PAE.2.6.32-1.art.i686 is allowed multiple installs, skipping

This is a fairly serious error, it means someone has manually attempted to remove your kernel and has broken the package management record for the kernel. We do not recommend you ever uninstall a kernel. Linux has a boot loader that allows you to pick which kernel (or even operating system) you want to boot into. If you wish to switch kernels, dont uninstall a kernel or even replace it, just install another kernel and configure your system to log into it.

If your system has been broken in this manner, you will need to try and correct your package management record and to try to reinstall your kernel. The follow is a set of steps that may work, however if someone has manually removed your kernel its likely the system may be in a very abnormal state and these commands many not work. This type of error is not caused by ASL.

Step 1) Attempt to remove the kernel record from the package manager:

 rpm -e kernel-PAE

or

yum remove kernel-PAE

Step 2) Attempt to manually reinstall the kernel

 yum install kernel-PAE

Note: If your system requires that you do this, your system is in a very adverse state as the package management built into the OS will not allow this condition to occur. It can only occur if someone attempts to manually remove a kernel and does so in a manner that breaks package management. Your system may be in an abnormal condition, and we highly recommend you consider investigating whether other adverse conditions many exist on the system.

CREATE DATABASE failed; error: 'Can't create database 'tortix'; database exists'

This can only happen if the ASL database already exists, such as if ASL is being reinstalled on a system and the ASL data was not completely removed. If this occurs, you will need to manually remove the ASL database. To do that, log into mysql as your administrative user (root for example, but check with your OS vendor if you are not sure).

Step 1)

Drop the database by running this command in mysql:

drop database tortix;

Step 2)

Drop the "tortix" user by running this command in mysql:

drop user tortix;

Step 3)

Then run this command inside mysql:

flush privileges; 

Step 4)

Then run the ASL installer again.

asl-firstboot reboots system

asl-firstboot has a simple network failsafe that will try to detect if the network on the system has been initialized correctly on the first boot of an ASL kernel. Its does this by comparing the exact network configuration that system had when ASL was installed, and if anything has changed it will attempt to reboot into the last known working kernel. If you change the network deliberately, after installing ASL but before rebooting the system for the first time the failsafe will incorrectly detect that the network has not been initialized correctly.

If this happens to you, just disable the failsafe by removing the init file:

rm /etc/init.d/asl-firstboot

If you did not change the network, then ASL is detecting that something is wrong with the network and it is not initialized as it did when ASL was first installed. You will need to either disable the failsafe, or investigate why the network is starting up correctly.

Error: Missing Dependency: libmysqlclient

This error means that your system has been incorrectly setup to exclude the installation of any package with "mysql" in the name. This library provides applications with the ability to speak SQL to a mysql database. These libraries are not actually part of mysql, are not used by mysql, and their installation will have no effect on mysql.

Therefore, if you are using some third party product that has excluded any package with "mysql" in its name from being installed on your system you will need to:

1) run this command to temporarily bypass the broken and incorrect excludes configured for your system:

yum --disableexcludes=all upgrade asl asl-web mod_security ossec-hids

2) Report this as a bug to the makers of the product(s) that have configured this incorrectly on your system. These libraries have nothing to do with mysql and some software companies incorrectly configure the operating systems software management system to not allow the installation or upgrade of any package with "mysql" in the name. This configuration is incorrect if they simply wish to prevent MySQL from being installed or upgraded on your machine. They need to fix the changes they are making to your operating systems software management system which is incorrectly breaking software updates so this will not to occur in the future.

Copyright 2005-2012, Atomicorp