Atomic Secured Linux
Contents |
About ASL
Atomic Secured Linux(tm) is an easy to use out-of-the-box Unified Security Suite add-on for Linux(tm) systems designed to protect your servers against both known and unknown zero day threats. Unlike other security solutions, ASL is designed for beginners and experts alike. You just install ASL and it does the work for you.
ASL works by combining security at all layers, from the Kernel all the way up to the application layer to provide the most complete protection available for Linux servers and helps to ensure that your system is compliant with commercial and government security standards. ASL includes the most hardened kernel on the market, automated system hardening techniques, userspace and host Intrusion Prevention Systems (IPS), malware/rootkit detection and elimination, blacklisting technologies, an autolearning Role Based Access Control System and web application firewalling to protect multiuser and web application hosting environments like no other solution. ASL is uniquely effective at addressing emerging threats posed by vulnerabilities in today's complex systems and applications, such as web hosting environments, multiuser systems, CRM's, ERPs, forums, shopping carts, Content Management systems and custom applications.
The design of ASL approaches securing the server and its applications, by combining different layers of security technologies and application layer firewalls to filter out malicious content before it reaches your system and its applications. Our hardened kernel further enhances the overall security model by enforcing anti-rootkit, file, network and process level security policies on the system.
The ASL approach also includes our "Just In Time Patching" system, which allows you to address security threats posed by applications where either it is not possible to fix the application due to lack of source code, availability of resources, or the number of applications that make repairing all vulnerabilities economically infeasible. You can known that your systems are protected, even when you can't patch them.
You can read more about ASL on the ASL product page.
Purchasing
To purchase a license for ASL, please visit the Atomic Secured Linux product page.
Installation
Upgrading ASL
ASL Features
See the ASL Features article.
Adding more Licenses
To add more licenses simply log into your ASL License Manager account. You can also reset your ASL License Manager password on this page.
To reset a Support Portal password please send an e-mail to support@atomicorp.com with your request.
Documentation
ASL Documentation
Release Schedule
Frequently Asked Questions
Troubleshooting
Get support
Release Notes
ASL 5.0 Notes
Hurray, no notes at the time.
ASL 4.0 Notes
ASL 3.2 to 4.0 upgrade requirements:
These must be done via the ASL installer. Upgrading to ASL 4.0 requires re-running the ASL installer. There is no need to uninstall, just re-run the installer. Upgrades via yum are absolutely not supported and will break.
And during the process of upgrading, when asked if you want to reinstall the ASL database, answer yes. ASL4 has a new database schema that is faster, and reinstallation of the database is required.
ASL 3.2 Notes
ASL 3.2 Release Notes
CPanel
Tortixd in this release changes its default logging path from /var/log/httpd to /var/log/tortixd to separate logging from the standard httpd daemon. For all environments except for cpanel, this is a transparent change. Cpanel users are recommended to update their security policies immediately after upgrading to this release with: asl -s -f. Otherwise this will run automatically 1 hour after the ASL update is completed. Failure to run this immediately afterwords could result in a brief outage of Active responses from WAF events.
MySQL
If you have "old_passwords=1" enabled, or previously had this enabled in MySQL your passwords are saved in the older less secure MySQL 4 format. ASL now requires that passwords be saved in MySQL in the more secure format as of ASL version 3.2.7. This method was introduced into MySQL as of MySQL 5.0 and is the default method. However, if you had mysql configured to use the older method, you may get an error when you try to log into the ASL gui.
If you already have ASL installed, and you used this configuration option in MySQL, you will have to follow the process below to update the hashes ASL uses to log into MySQL using the newer secure format. If this is a new install, disable old_passwords in my.cnf during the ASL install. ASL will no longer support the older MySQL 4 password format as it is insecure and it fails to meet basic security requirements.
Step 1) Determine what your OSSEC database users name is.
Run this command as the root user:
grep OSSEC_DATABASE_USERNAME /etc/asl/config
Step 2) Determine what your OSSEC database password is.
Run this command as the root user:
grep OSSEC_DATABASE_PASSWORD /etc/asl/config
Step 3) Log into mysql as your priviliged user.
On most systems, this is usually "root". On Plesk systems this is usually "admin".
Type this command as root, and enter the priviliged user password for mysql. If you do not know this, please contact the parties that configured mysql on your system. This password is not set or configured by ASL.
mysql -u root -p
Change "root" to the admin user for your platform. On Plesk, this is "admin".
Step 4) Set mysql to not use the old MysqL 4 format
mysql> SET SESSION old_passwords=0;
Step 5) Load the mysql users database
mysql> use mysql;
Step 6) Reset the OSSEC_DATABASE_USERNAMEs password to use the new MySQL format
SET PASSWORD FOR 'tortix'@'localhost' = PASSWORD('yourpassword');
Make sure you change "tortix" to whatever OSSEC_DATABASE_USERNAME is set to on your system, and change "yourpassword" to whatever OSSEC_DATABASE_PASSWORD is set to on your system.
If you complete all of these steps and ASL-Web still displays the MySQL "old_passwords" error message, you may need to change 'localhost' to '127.0.0.1'
Step 7) Flush MySQLs privilige table so it will use the newer password format
mysql> flush PRIVILEGES;
Self Healing System
This release adds a new self-healing component to detect and repair corrupt tortix databases. In order to activate the new self-healing rules, the HIDS component will need to be restarted (not reloaded). If you are experiencing corrupt database conditions now, or otherwise have issues with the event viewer not showing any events you can force this to occur manually by upgrading to 3.2.4, restarting ossec hids and then manually running /var/asl/bin/asl_db_rotate. This will trigger the self-healing function and repair the database (note: this could take several minutes).
Firewall
This release series includes our new Advanced Firewall capabilities, including a vast new array of firewall Target & Condition flags for ASL kernel environments through the xtables-addons package. This package will be automatically installed once ASL has been upgraded to 3.2. The ASL updater is the recommended method to ensure the system is in sync with the recommended ASL release. It can be run directly with:
aum -u
Minimum OS version
For customers using Redhat 6, CloudLinux 6, and CentOS 6, those platforms will need to be on a minimum of Release 6.3 to access necessary dependencies to upgrade to ASL 3.2.
WAF
Updating the WAF to 2.7.1 will require an update of existing rules to a 2.7.1 compatible format. ASL generated exceptions will automatically be updated to this format when the policy is updated by:
/var/asl/bin/asl -s -f
If you have custom rules you have created yourself, you will need to make sure they each have an id: and that the id: is unique. modsecurity 2.7.x requires an id for each rule, and it must be unique. Be careful to not use rule id:s that are reserved. The current reserved ranges are 100000-3000000. 1-99999 should be used for custom internal local rules. If you share your rules with others, dont use the 1-99999 range, instead use rule ids in the non-reserved range (3000000 and up)
Non-Hardware accelerated 32bit virtualization environments
If you are forced to use a non-hardware accelerated 32bit virtualization environment, you may want to disable CONFIG_PAX_MEMORY_UDEREF. These environments may experience some performance degradation. The most secure solution is to use a hardware accelerated virtualization solution.
However, if you can not do this, and you experience a performance degradation, you may want to disable this protection. To do this add this line to your grub.conf bootline:
pax_nouderef
Example:
kernel /vmlinuz-2.6.32.59-17.art.x86_64 ro root=/dev/md0 console=tty0 console=ttyS0,57600n8 panic=5 pax_nouderef
Xen
Xen users will need to use the xen kernel branch in tortix-kernel-xen channel. Please see the ASL 3.2 Virtualization Notes for details. Please see the kernel page for instructions on installing, and configuring the ASL kernel.
VPS technologies
Note: A VPS is not a virtual machine. VPS in this article refers to virtualization technologies such as Virtuzzo or OpenVZ that abstract a single kernel running on the host system and share it with all the VPS'.
All of the features of ASL work inside a VPS. VPS technologies,do not provide the VPS with a kernel of its own (unlike a virtual machine, which does have its own kernel). A VPS uses the host systems kernel. If you are using a VPS on a server that is not running ASL you will see several important kernel vulnerabilities reported in your system. These vulnerabilities are real, and they can not be fixed from inside a VPS.
The ASL kernel, when used with VPS technologies, can only be installed on the host machine, this is because the VPS' themselves do not have their own kernel. This is not to be confused with Virtual Machine technologies such as VMWare, KVM, Xen and others. Those virtual machines do have their own kernel, and therefore the ASL kernel can be installed inside those virtual machines. VPS', however, do not have their own kernel, they share the single host machines kernel. To eliminate these vulnerabilities in a VPS the host server must be running ASL as well.
VPS's will also see "hidden processes" reported by ASL. This is also expected as the rootkit detection capabilities of ASL are seeing hidden processes from other VPS' running on the system. Therefore VPS customers that do not wish to get these alerts will need to turn off rootkit checks inside their VPS's. To do this modify this file:
just modify this file:
/var/ossec/etc/ossec.conf
Search for this:
<rootcheck>
you should see something like this:
<rootcheck> <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files> <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans> </rootcheck>
Check that to this:
<rootcheck> <disabled>yes</disabled> </rootcheck>
You will also want to disable the hidden process checks in the VPS that are performed by rkhunter:
You want to edit this file:
/etc/rkhunter.conf
Look for this line:
ENABLE_TESTS="all"
Change it to:
#ENABLE_TESTS="all"
Then look for this line:
#DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps"
And change it to:
DISABLE_TESTS="hidden_procs os_specific"
Do not disable these checks on the host server.
If you are not on a VPS, then reports of hidden process means you do in fact have hidden processes. That means you are running some root level process that is hiding a process, or your system was compromised at some point in the past, and ASL has detected that a rootkit is installed.
ASL 3.0 Notes
ASL 3.0 Release Notes
GUI issues
Make sure that you clean your browsers cache when logging into 3.0 if you have been using 2.2. This will clear out any old cached AJAX elements from the 2.2 GUI. You only need to do this once.
Authentication
The Authentication system in ASL Web has changed. Your ASL Username & Password is now the default login. This can be changed from the User manager interface, or from the command line using: /var/asl/bin/asl-web-setup or /var/asl/bin/asl-web-passwd <username>
PHP
ASL 3.0 added five new high risk PHP functions:
- pfsockopen
- fsockopen
- curl_exec
- curl_multi_exec
- ftp_exec
These are disabled in ASL by default, if you configure ASL to harden PHP. If you have a web application that uses these functions, please ensure that you re-enable them.
For example, to re-enable fpsockopen and fsockopen, just change these settings in ASL:
ALLOW_pfsockopen and ALLOW_fsockopen
to "yes"
Disabled Rules and Signatures
/etc/asl/disabled_signatures has been replaced by /etc/asl/rules. Disabled rules are not imported from 2.2 to 3.0 configurations, they will need to be re-added through ASL Web's Rule Manager, or from the command line using:
/var/asl/bin/asl -dr <rule id>
End of Life Operating systems
Redhat and the Centos project both announced that RHEL 4 and CentOS 4 are End of Life as of February 29th, and are no longer supported by them. Accordingly, those platforms are also no longer supported by Atomicorp.
Xen
If you are using Xen, you will want to use the Xen kernel.
Non-Hardware accelerated 32bit virtualization environments
If you are forced to use a non-hardware accelerated 32bit virtualization environment, you will want to disable CONFIG_PAX_MEMORY_UDEREF. To do this add this line to your grub.conf bootline:
pax_nouderef
Example:
kernel /vmlinuz-2.6.32.59-17.art.x86_64 ro root=/dev/md0 console=tty0 console=ttyS0,57600n8 panic=5 pax_nouderef
ASL 3.0 Known Issues
1. Centos and Redhat 4 do not include an up to date SSL certificate file, which will result in bogus errors such as these:
Redhat and the Centos project have both announced that RHEL 4 and CentOS 4 are End of Life as of February 29th, and are no longer supported by them. Accordingly, those platforms are also no longer supported by Atomicorp.
aum -u
Checking for updates..
ASL version is current: 3.0 [OK]
APPINV rules are current: 201008021738 [OK]
Update failed for some reason, retrying with full debug information...
--17:25:04-- https://username:*password*@www.atomicorp.com/channels/asl-2.0/rules//clamav-201107191237.tar.gz
=> `/var/asl/updates/clamav-201107191237.tar.gz'
Resolving www.atomicorp.com... 74.208.155.133
Connecting to www.atomicorp.com|74.208.155.133|:443... connected.
ERROR: Certificate verification error for www.atomicorp.com: self signed certificate in certificate chain
To connect to www.atomicorp.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
exiting...
The certificate used is not self signed, however older Centos and Redhat distributions do not include up to date certificate authority information. One solution is to use a newer certificate authority file from Red Hat and Centos versions 5 and 6. We have included the certificate file from Centos 5 at the URL below:
https://www.atomicorp.com/installers/cert.pem
On RHEL and Centos 4 systems, the default certificate authority file is stored in:
/usr/share/ssl/cert.pem
Simply download the cert.pem file from the URL above, and overwrite the file at /usr/share/ssl/cert.pem. We highly recommend you make a backup of your current file, and that you download this file from us only over an SSL connection and not in the clear. For example, use a browser that does have up to date CA certificates to download this file to ensure that it is not tampered with during transit, or simply get a copy of a RHEL or Centos 5 or 6 distribution and get a copy from there.
2. There is a known bug in early versions of 3.0 that can occur if you have the malware protection rules turned off, and the malware output rules turned on (which are new and on by default in 3.0).
There are three solutions:
Option 1) Upgrade ASL to the current release
Option 2) Disable the MODSEC_99_MALWARE_OUTPUT rules, set them to "no". (Least secure method)
Option 3) Enable the malware protection rules, change MODSEC_10_ANTIMALWARE to "yes". (Most secure method)
We will be putting out a point release shortly to resolve this so you can enable the malware output protection rules with the malware rules disabled. For now, you have to either enable both, or disable both.
ASL 2.2 Release Notes
New Web GUI to manage everything, plus everything in 1.0 and tons of new features and security:
- Vulnerability scanner
- Hardening tools to secure your system
- Stack overflow protection from the PaX project, that addresses exploits in services on the system, such as apache, bind, secure shell, mysql, postgres, etc.
- Virtual Patching of web applications, which makes its possible to use software which have vulnerabilities when a patch is not available or it is not possible to install one
- Web Application Firewall through mod_security, and the industry leading rules created by Atomicorp at gotroot.com, optimized for Plesk Server Administrator environments.
- Realtime malware scanning of web, email and local filesystems
- Domain based control of antispam and antimalware features (for control panels like Plesk)
- Automatic process monitoring, alerting and actions, such as restarting critical processes that have died, have hung or are consuming too many resources
- An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration, from the Grsecurity project.
- Trusted Path Execution, which only allows untrusted users such as apache to execute commands owned by root, thus simply preventing a whole class of exploit techniques used by attackers, or internet worms
- Users are restricted to only view their processes
- Denial of Service protection through mod_evasive
- Realtime attack shunning and blocking, and policy based unshunning after user defined period of time
ASL Kernel (grsecurity, firewall additions like match, and stealth), mod_security and, mod_evasive for input validation, and DoS protection, userspace HIDS with ossec, application inventory module, compliance and vulnerability scanner, and PSA integration.
ASL 1.0 Release Notes
Atomic Secured Linux(tm) version 1.0 is a linux security solution, distributed through a subscription yum channel. It works by combining both Kernel hardening techniques, as well as userspace Intrusion Prevention Systems (IPS) to your web application hosting environment. ASL is specifically targeted at addressing the threats posed by vulnerabilities in applications, such as CRM's, forums, shopping carts, or other custom applications.
The design of ASL approaches securing the server, and its applications, by using an application layer firewall to filter out malicious content, before it reaches the application. The hardened kernel subsystems further enhance the overall security model by enforcing file and process level security policies on the system.
The advantages of the ASL approach to security, is that it addresses the security threats posed by web based applications where either it is not possible to fix the application due to lack of source code, or availability of resources, or the number of applications make repairing all vulnerabilities economically unfeasible.
It offers among many other features:
- Stack overflow protection from the PaX project, that addresses exploits in services on the system, such as apache, bind, or secure shell
- An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration, from the Grsecurity project.
- Trusted Path Execution, which only allows untrusted users such as apache to execute commands owned by root, thus simply preventing a whole class of exploit techniques used by attackers, or internet worms
- Users are restricted to only view their processes
- Application layer firewalling through mod_security, and the industry leading rules created by Atomicorp at gotroot.com, optimized for Plesk Server Administrator environments.
- Denial of Service protection through mod_evasive
