Using ASL
General Usage Questions
ASL web console
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)
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 configure ASL?
Please see the ASL_Configuration page.
How can I change the reporting level in the ASL GUI?
Step 1) Log into the ASL GUI.
Step 2) In the security events window, click on the Filter By: drop down and select the new level you wish to filter by. Lower numbers are less important or common events, higher numbers are more critical events.
Step 3) Click the refresh button
How do I add users to the web console?
Step 1) Log into the ASL web console
Step 2) Click on the "Settings" tab
Step 3) Select the "ASL Web User Manager"
Step 4) Click "+ Add New User"
Step 5) Type in the username and password of the user
Step 6) Make sure "Enabled" is selected in the "Status" drop down menu.
Step 7) Put the users email address in the email field.
Step 8) Select the users group, if you have defined any additional groups. The "default" group has access to all areas of the ASL web console. If you want to define groups will less privileges, select the "Groups" tab at the top of tyhe "ASL Web User Manager" window, and define new groups to meet your needs.
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
ASL 4
Just log into the ASL web console, click on "Scan" and open the malware protection control panel. From there you can run scans from the web console.
Configuring
Step 1)
Add in the directory/ies that you want to scan by clicking on the window above the Include Path button. Put your path in this window. For example, /home.
Continue adding in directories.
Step 2)
Then click scan.
DO NOT INCLUDE DIRECTORIES such as these:
Signature directories:
/var/clamav /var/lib/clamav /etc/httpd/modsecurity.d/
Log directories:
/home/user/apache/log /var/log /var/www/vhosts/example.com/statistics/log/ /var/www/vhosts/example.com/logs/
Build directories:
/home/cpeasyapache /home/.cpan /home/.cpanm /home/.cpanan
Your should also never include system directories, such as /proc, /selinux, /sys and /dev if you configure realtime malware protection.
ASL 3
To scan the system again for malicious software, just run this command as root:
nice -n 20 clamscan --exclude-dir=^/etc/httpd/modsecurity.d/ --exclude-dir=^/var/ossec/ --exclude-dir=^/var/clamav --exclude-dir=^/var/lib/clamav --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 --exclude-dir=^/home/.*/mail/ --exclude-dir=^/home/.*/tmp/awstats --exclude-dir=^/home/.*/tmp/webalizer --exclude-dir=^/home/.*/logs -i -r /
Important Note: There are some directories you should not scan. For example, directories that contain signatures, and raw logs should not be scanned. They contain actual attack patterns that will trigger signatures, this is expected behavior. Other tools will process your logs looking for attacks and malicious code, and clamscan should not be used to scan log files.
Quarantine
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=^/etc/httpd/modsecurity.d/ --exclude-dir=^/var/ossec/ --exclude-dir=^/var/clamav --exclude-dir=^/var/lib/clamav --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 --exclude-dir=^/home/.*/mail/ --exclude-dir=^/home/.*/tmp/awstats --exclude-dir=^/home/.*/tmp/webalizer --move=/root -i -r /
Restricting I/O
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=^/etc/httpd/modsecurity.d/ --exclude-dir=^/var/ossec/ --exclude-dir=^/var/clamav --exclude-dir=^/var/lib/clamav --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 --exclude-dir=^/home/.*/mail/ --exclude-dir=^/home/.*/tmp/awstats --exclude-dir=^/home/.*/tmp/webalizer -i -r /
Note: ionice is supported with the ASL kernel. Not all kernels support ionice.
Scheduling scans
Step 1)
Become root on the system:
su -
Step 2)
Add a cronjob to schedule the scan.
Run the crontab editing tool:
crontab -e
Step 3)
Add in the cron tab:
0 0 * * * clamscan --exclude-dir=^/var/ossec/ --exclude-dir=^/var/clamav --exclude-dir=^/var/lib/clamav --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 --exclude-dir=^/home/.*/mail/ --exclude-dir=^/home/.*/tmp/awstats --exclude-dir=^/home/.*/tmp/webalizer -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, set the level to "1", 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.
If you are unable to log into the ASL web console, you can also check the ASL active response log. All shuns are logged by ASL. Please see this FAQ for further information:
https://www.atomicorp.com/wiki/index.php/Using_ASL#Does_ASL_log_all_shuns.3F
Can I search for a domain to see if its been blocked?
Yes, please see this article, just use the domain name instead of the IP:
https://www.atomicorp.com/wiki/index.php/Using_ASL#How_can_I_tell_if_ASL_is_blocking_an_IP.3F
Why did ASL block an IP?
If ASL blocks anything, it will log that action. Just log into the ASL GUI, set the level to "1", 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 currently 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.
If you are unable to log into the ASL web console, you can also check the ASL active response log. All shuns are logged by ASL. Please see this FAQ for further information:
https://www.atomicorp.com/wiki/index.php/Using_ASL#Does_ASL_log_all_shuns.3F
How can I tell if ASL blocked something in the past?
If ASL is no longer blocking an IP, but you want to find out if it blocked it in the past you can check the logs to see if an IP was blocked with this command as root:
grep <IP> /var/ossec/logs/active-responses.log
Example:
grep 1.2.3.4 /var/ossec/logs/active-responses.log
Where 1.2.3.4 is the IP address you want to check. Keep in mind that if you have log rotation enabled, you may need to check the archived logs as well.
If you have compression enabled for your logs, you can do that with this command:
zgrep 1.2.3.4 /var/ossec/logs/active-responses.log*gz
If you do not have compression enabled for your logs, you can do that with this command:
grep 1.2.3.4 /var/ossec/logs/active-responses.log.*
You can also check your systems firewall at the system level if you are concerned that the shunning system may be corrupted or broken on your system by running this command:
iptables -L -n | grep 1.2.3.4
Where 1.2.3.4 is the IP address you want to check.
Note: If you have whitelisted an IP address, ASL will not shun the IP.
How can I tell if ASL is blocking something?
If ASL blocks anything, it will log that action. Just log into the ASL GUI, trigger the event, or type in the IP address into the Event: box in the Security Events window. If ASL has anything to do with this event it will report it in the Security Events window. If you do not see any reports related to this event try setting the filter by level to 1, then trigger the event again or if you are looking for an IP, domain name or specific event type in the search words you wish to use in the Event: window.
If you do not see ASL reporting anything related to your event, then ASL is not causing this event to occur.
How can I tell why ASL has blocked an IP?
If ASL blocks anything, it will log that action. Just log into the ASL GUI, set the level to 1, and type in the IP address into the Event: box in the Security Events window. This will tell you if ASL has alerted on anything, it may not have shunned it. If you do not see the IP listed at all, then ASL is not involved, if you do the IP continue reading.
If you want to find out if ASL is currently' blocking, shunning, or firewalling off an IP address, just click on the ASL tab, then then select Blocking. Any IP address that ASL is currently blocking will be listed in that window. If ASL is no longer blocking the IP, it will not show up in that window.
If you want to find if ASL blocked an IP in the past, you will find that information in this log file:
/var/ossec/logs/active-responses.log
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 long is an IP address blocked?
This depends on how you have configured ASL. By default an IP is blocked for 600 seconds. If you want to block attackers for longer, even permanently, simply adjust these two settings in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_SHUN_TIME
And if you want blocks to be permanent just disable this setting:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_SHUN_ENABLE_TIMEOUT
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
asl -wl 1.2.3.4 1.2.3.5 1.2.3.6
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.
Note: If you want the firewall to completely whitelist an IP, please enabled this option:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_WHITELIST
Note: The WAF in ASL will still block the attack if it can detect it, but it will not shun the IP.
Important Note: If you want the WAF to also ignore all attacks from your whitelisted IPs, enable this option:
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_WHITELIST
Important Note: If you also want to allow all traffic from hosts on the whitelist, enable this option:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_WHITELIST
Why are whitelisted IPs still blocked by the WAF?
If you want the WAF to also ignore all attacks from your whitelisted IPs, you must enable this option:
https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_WHITELIST
This is disabled by default because most users will still want to detect and block attacks from whitelisted IP, although they may not want to shun them. You should only put hosts on the whitelist that you know will never be compromised.
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.
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.
Unsupported method:
You can also do this from the command line, however this feature has been deprecated and is no longer supported. It may also be removed in the future. Run 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
Note: Networks must be in CIDR format.
What does "system" mean in the blacklist window?
This means that a legacy blacklist entry existed before ASL supported the "Listed by" logging capability, or the IP was added from the command line.
ASL 4 can log the logged in ASL console users name that added the IP to blacklist, however if the IP was added either manually from the command line, or existed before ASL 4 then this information will not exist, and the entry will say "system". This does not mean ASL added the IP to the blacklist. ASL can not add IPs to the blacklist. The blacklist is user defined, and is not controlled by ASL.
How do you remove an IP from the user defined blacklist?
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, then just click the "minus" button next to the IP you want to blacklist.
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 aum -u?
Answer:
aum -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 aum -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
When a rule is triggered will ASL redirect the user to a webpage?
Not by default. By default ASL just provides an error code to apache, and apache does whatever you have configured apache to do with that code. In some cases this means apache will provide a different error code, and may redirect your user to a webpage you have configured apache to redirect them to. If you have specicially configured ASL to redirect your users, then ASL has no effect on any redirects apache may be generating.
If you wish ASL to control redirects, you will need to setup a redirect page and configure the option below based on your needs.
https://www.atomicorp.com/wiki/index.php/ASL_WAF#WAF_REDIRECT_URL
ASL will then redirect WAF events to the URL of your choosing.
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 format for this log file is:
(Day of Week) (Month) (Day on Month) (Time of Day) (Time Zone) (Year) (Tool) (Action) - (IP) (Time Stamp) (Rule ID)
Example:
Sun May 20 20:13:30 EDT 2012 asl-shun.pl add - 1.2.3.4 1337559210.7251129 12345
In the example above, the IP address 1.2.3.4 was shunned on Sunday, May 20th, 2012 at 20:13:30 EDT for triggering rule ID 12345. You can search for rule ids, and what that rule means and what can cause it to trigger by putting the rule ID number into the search window on this page.
The same is true if ASL unshuns, or unblocks an IP address. That will also be logged. Adding a shun will log the action as "add", removing a shun will log the action as "delete".
You can also log the ASL GUI and click on the ASL tab, then click on Blocking. If ASL is currently blocking an IP, it will also show up there.
You can check the logs to see if an IP was blocked with this command as root:
grep <IP> /var/ossec/logs/active-responses.log
Example:
grep 1.2.3.4 /var/ossec/logs/active-responses.log
You can also check your systems firewall at the system level if you are concerned that the shunning system may be corrupted or broken on your system by running this command:
iptables -L -n | grep 1.2.3.4
Where 1.2.3.4 is the IP address you want to check.
Does ASL log all unshuns?
Yes. If ASL unshuns, or unblocks a source IP with the systems firewall, it will log that action in this file:
/var/ossec/logs/active-responses.log
The format for this log file is:
(Day of Week) (Month) (Day on Month) (Time of Day) (Time Zone) (Year) (Tool) (Action) - (IP) (Time Stamp) (Rule ID)
Example:
Sun May 20 20:13:30 EDT 2012 asl-shun.pl delete - 1.2.3.4 1337559210.7251129 12345
In the example above, the IP address 1.2.3.4 was unshunned on Sunday, May 20th, 2012 at 20:13:30 EDT for originally triggering rule ID 12345.
You can also log the ASL GUI and click on the ASL tab, then click on Blocking. If ASL is currently blocking an IP, it will also show up there, if its not in that tab, ASL is not blocking that IP.
You can check the logs to see if an IP was blocked with this command as root:
grep <IP> /var/ossec/logs/active-responses.log
Example:
grep 1.2.3.4 /var/ossec/logs/active-responses.log
You can also check your systems firewall at the system level if you are concerned that the shunning system may be corrupted or broken on your system by running this command:
iptables -L -n | grep 1.2.3.4
Where 1.2.3.4 is the IP address you want to check.
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.
Please see the URL below for documentation on this setting:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#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.
Please see the URL below for documentation on this setting:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#HIDS_SHUN_MULTIPLIER
Rule Editor
How can I modify a rule?
Step 1) Log into the ASL web console
Step 2) Click on the ASL tab
Step 3) Click on WAF & HIDS Rules
Step 4) Type in the rule ID or name into the search field. For example, if you are looking for rule 12150, put that into the search field and click the Search button
Step 5) Click on the rule ID number, for example, click on 12150, this will open the rule editing window for that rule.
When you finish making changes to the rule, make sure you click the "Update" button to save your changes. Until you do this, no changes will be made to the rule.
How can I disable active response on a rule?
See the steps above to pull up the rules editing screen. Once you have that screen open, just change the "active response" dropdown from "yes" to "no", then click the "Update" button.
ASL Vulnerability Scanner
Runtime module loading fixed
Please see this article Vuln kernel loadable modules
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 a package managed system and a properly configred non-package managed system, like cpanel, this is automatic, but with source built systems and inproperly configure non-package managed system (i.e if cpanel was told to remove modsecurity, or to install modsecurity) this may need to be done manually.
If you are using cpanel, this means that the easyapache system is broken or someone has configured cpanel to install or remove modsecurity. Do not configure cpanel to remove or install modsecurity. Do not use cpanel to manage modsecurity. ASL will configure easyapache to install a special optimized version of mod_security. The version that comes with cpanel is not optimized, and should never be used. If you get this error, and you did not configure cpanel to install or remove modsecurity, it means easyapache has been broken on the system, which can happen for many reasons that have nothing to do with modsecurity. For example, a broken apache configuration file can cause the easyapache process to fail to complete. 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
SAFE MODE Restriction in effect. The script whose uid is XXX is not allowed to access /some/thing owned by uid YYYY
PHPs safe mode, when enabled, will prevent PHP from executing any PHP script that is owned by a different user. This prevents PHP from running code that is not 100% owned and controlled by the user running it.
When using safe mode in PHP, all PHP scripts must be owned by the same user that is running PHP. This includes the root user. If you must use code owned by different users, you can not use safe mode.
ASL keeps changing my php.ini
If you configure ASL to configure and enforce your PHP settings, then ASL will change your php.ini file. In that case, you must use the ASL options to change your PHP settings. For example, if you manually change a setting in php.ini and the option in ASL does not match this change, ASL will by design change this setting to whatever you have configured ASL to enforce. Please see these options in ASL to configure ASL to enforce your PHP settings, and what those settings should be:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#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.
How can I prevent ASL from changing php.ini?
By default ASL will not change php.ini. It will only do this if you have configured ASL to do so. If you have not enabled this capability in ASL, then ASL can not php.ini.
To disable this capability in ASL follow this process:
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_CHECKS" to "No" then select "Update".
ASL will only scan for PHP vulnerabilities when it is managing php.ini. If you set this to "No" and manually change php.ini, ASL will not scan php.ini.
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.
Administrative users are: not defined
Please see the product documentation and set this option in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ADMIN_USERS
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.
Network Firewall Questions
How can I disable the ASL firewall during boot?
You can configure the ASL firewall to not be enabled on boot with this command, run as root:
chkconfig --del asl-firewall
Note: When you upgrade ASL the firewall will be re-enabled by default, so you must do this again if you wish to disable the firewall.
Important Note: This will also prevent Active Response from working correctly in ASL.
How can I disable the ASL firewall during runtime?
You can temporarily disable the ASL firewall with this command, run as root:
service asl-firewall stop
Important Notes:
- This will not disable Active Response in ASL, to disable Active Response you must set this option to "No": https://www.atomicorp.com/wiki/index.php/ASL_Configuration#OSSEC_ACTIVE_RESPONSE
- When you reboot the system the ASL firewall will be re-enabled by default, so you must do this again if you wish to disable the firewall.
- Disabling the ASL firewall may also prevent Active Response from working correctly in ASL.
- ASL is not supported with third party firewalls. If you use a third party firewall ASL may not work correctly. Please see the ASL pre-requisities: https://www.atomicorp.com/wiki/index.php/ASL_prerequisites
Does the network firewall block any ports by default?
No, the network firewall is not configured to block any ports by default. Please see the firewall documentation to configure the network firewall in ASL for your specific needs:
https://www.atomicorp.com/wiki/index.php/ASL_firewall
ASL_SMTP_OUT
This means that ASL is blocking outbound connections, based on your configuration, to SMTP ports on other systems. ASL does not block these connections by default, and will only do this if you enable this feature and configure this function according to the documentation at the URL below:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_OUTPUT_MTA
Two types of log messages will be generated:
1) Actual unauthorized user activity
If an actual user that is not authorized to connect to an external SMTP server tries to connect to one, you will see a log entry similar to this:
Sep 11 12:27:57 asl-modsec-test kernel: ASL_SMTP_OUT IN= OUT=eth0 SRC=192.168.1.249 DST=74.208.113.198 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=274 DF PROTO=TCP SPT=56585 DPT=25 SEQ=1409302022 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030306) UID=502 GID=502
The UID and GID fields tell you the userid and groupid that tried to make the connection, and was denied. If you do not see a UID or GID field, see #2 below.
2) Noisy TCP stack events
TCP stacks can be "noisy", that means they may generate packets they dont need to generate that become orphaned. These packets are harmless, but get dropped by the firewall because they no longer belong to an existing stateful connection. If you see events similar to this:
Sep 11 11:54:56 secure03 kernel: ASL_SMTP_OUT IN= OUT=eth0 SRC=10.10.10.100 DST=10.10.10.200 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=54313 DPT=25 SEQ=1459875425 ACK=0 WINDOW=0 RES=0x00 RST URGP=0
These are orphaned packets, and you can safely ignore these events. The key to telling the different is that the log message will not have a uid or gid value, as in the example above.
Note: These events do not generate shuns. Because the firewall rule already blocks the user action, there is no need for a shun, and doing so would cause the server to shun itself, which ASL will not do by default.
DROP_ASL_TORTIX
This means that ASL is blocking connections to the ASL web console, based on your configuration. ASL does not block any connections to the web console for default. If an IP is being blocked it is because the IP or network is not included in your configuration. Review your configuration in this file:
/etc/asl/firewall/tortixd-access-list
The format is one IP or network per line. For example:
1.2.3.4 5.6.7.8
ASL does not create this file, and does not block connections to the web console by default. Blocks can only occur due to user configuration.
ASL_BLACKLIST_BLOCK
This log message means that you have manually added an IP address or network to the user defined blacklist in ASL. ASL can not add IP addresses to your user defined blacklist, and there are no IP addresses included in the user defined blacklist by default. These events can only occur if someone has manually blacklisted an IP address on your system. ASL can not blacklist an IP address, only a person can do this, and this requires them to manually add the address or network to the blacklist on your system.
If you have incorrectly added an IP or network to the user defined blacklist in ASL, simply log into ASL, click on the Blocking menu option, then select the Blacklist tab. Then just select the IP or network you want to remove from your user defined blacklist and click the "Remove selected IPs" button.
Can I prevent ASL from logging these drops?
Yes. See this configuration option:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOG_BLACKLIST_DROP
ASL_GEO_BLOCK
This log message means that ASL has blocked a connection to a TCP or UDP port based on how you have configured ASL. Specifically, these events only occur if you have configured ASL to block a country using the GeoBlock feature.
Can I prevent ASL from logging these drops?
Yes. See this configuration option:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOG_GEOBLOCK_DROP
DROP_ASL_INPUT
This log message means that ASL has blocked a connection to a TCP or UDP port based on how you have configured ASL. Specifically, any ports not listed in the FW_INBOUND_TCP_SERVICES and FW_INBOUND_UDP_SERVICES lists will be blocked.
If ASL is blocking packets on ports that are configured to be open, and you have confirmed that you do not have any third party or custom firewall rules that may be interfering with the ASL firewall rules, check to ensure that you have this option enabled:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_DROP_INVALID
If Invalid is enabled, and you have confirmed that your rules should be allowing traffic to this port, on this protocol, and that ASL is logging this block as as a DROP_ASL_INPUT rule (and not any other message or rule is being triggered) this can mean:
- The system is not running the ASL kernel, and the kernel that is being used is unable to perform stateful inspection on the packets.
- The client is sending broken sessions, either because a broken desktop firewall or some other firewall is breaking the session and generating invalid packets
Can I prevent ASL from logging these drops?
No. As a general rule if ASL blocks something ASL will log it. We do this to ensure that you know what ASL is doing to your system, and also because ASL will use this information to take other actions against an IP address, and to also learn if a larger or long term attack is in progress. If this event was not logged, ASL would not be able to determine if port scan or other attack was occurring on the system.\
VPS errors
/proc/sys/net/ipv4/tcp_ecn: Permission denied
VPS based virtualization technologies do not allow operators of VPS systems to change this setting on the VPS. This error is harmless, the ASL firewall is working fine, however you can not change the ECN settings for your VPS.
/proc/sys/net/ipv4/tcp_timestamps: Permission denied
VPS based virtualization technologies do not allow operators of VPS systems to change this setting on the VPS. This error is harmless, the ASL firewall is working fine, however you can not change the TCP timestamps settings for your VPS.
/proc/sys/net/ipv4/tcp_window_scaling: Permission denied
VPS based virtualization technologies do not allow operators of VPS systems to change this setting on the VPS. This error is harmless, the ASL firewall is working fine, however you can not change the TCP window scaling settings for your VPS.
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?
Please see the Proxy article.
Why is modsecurity logging 4xx and 5xx events?
If modsecurity is configured with this directive:
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
It will log all 4xx and 5xx events for apache (except 404 events, as in the example above). We recommend you do this, as apache will natively block some attacks and modsecurity rules are both not necessary for these attacks, and would never be triggered (because Apache will block itself). For example, an invalid URI would be blocked natively by apache, and this may indicate certain types of attacks are in progress. 401 errors, authentication failed errors, are also logged by modsecurity which can be used to determine if a brute force attack is in progress. 5xx errors may indicate that an application has failed, which could indicate that an attack is under way, or simply that an application or component is broken or failed to perform correctly.
These events will not include any information about a rule being triggered, because a rule will not have been triggered. Here is one example:
--40deca15-A-- [19/Nov/2012:02:11:22 +0000] UKmVSQoAAGQAAEz2C2sAAAAB 1.2.3.4 58000 5.6.7.8 443 --40deca15-B-- GET / HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Netcraft SSL Server Survey - contact info@netcraft.com) --40deca15-F-- HTTP/1.0 400 Bad Request Vary: Accept-Encoding Content-Length: 287 Connection: close Content-Type: text/html; charset=iso-8859-1 --40deca15-H-- Stopwatch: 1353291081928397 183549 (- - -) Stopwatch2: 1353291081928397 183549; combined=620, p1=0, p2=0, p3=359, p4=240, p5=21, sr=0, sw=0, l=0, gc=0 Producer: ModSecurity for Apache/2.6.6 ( http://www.modsecurity.org/); 201211011322. Server: Apache/2.2.16 (Debian) --40deca15-Z--
In the example above you will notice that no rule is listed in the H second. That is because no rule has been triggered. This event was logged only because of the SecAuditLogRelevantStatus configuration setting. Again, we recommend you log these events, as they can be indicators of other types of attacks that modsecurity will not be able to respond to, because Apache will natively respond to these events itself.
If you do not care about these events, simply remove that configuration directive. Please keep in mind that you will miss some attacks if you do this.
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 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_LASSO_BLOCK
This log message means that you have configured ASL to block sources on SpamHaus' Lasso list. This option is disabled by default, and can only be enabled by the user. Documentation on this feature is provided at the URL below:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LASSO
This list if run by SpamHaus and not by Atomicorp, if there are IPs or networks on this list that are incorrect report this issue to SpamHaus.
Disabling the firewall
To temporarily disable the network firewall, simply run this command as root:
service asl-firewall stop
Geoblocking
To disable geoblocking, log into the ASL web console and:
1) click on the ASL tab
2) Select the "Geoblock" tab
3) In the blocked column on the left select the sountries you wish to unblock
4) At the bottom of that window click the "Unblock Selected" button
If you are unable to access the web console and need to disable geoblocking you can also remove the geoblocking database and reset the firewall. Run these command as root:
rm /etc/asl/geo-blacklist
service asl-firewall restart
ASL Kernel Usage Questions
User can not see all processes
This is a special protection only available on ASL kernels. This prevents non-root users from attempting to access the processes of other users on the system, which also prevents non-root users from seeing any process except their own.
If you want a user to be able to see all processes on the system simply add them to the "procread" group.
We do not recommend you add a user to this group unless you trust this user. Most users will never need this capability, as it has no effect on normal user operations and it would be extremely rare for a non-root user to need to be able to access the state of other users processes.
User can not see some /proc entries
This is a special protection only available on ASL kernels. This prevents non-root users from attempting to access the processes of other users on the system, which also prevents non-root users from seeing any process except their own.
If you want a user to be able to see all /proc entries on the system simply add them to the "procread" group.
We do not recommend you add a user to this group unless you trust this user. Most users will never need this capability, as it has no effect on normal user operations and it would be extremely rare for a non-root user to need to be able to access the state of other users processes.
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 (Virtuzzo or OpenVZ), you will not be able to install a kernel (VPS' dont have kernels, they share the hosts kernel). VPS' are not the same as virtual machines (VMs, such as VMWare, KVM, Xen, etc.), VMs do have their own kernel and you can install a kernel in a VM.
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.
/proc/sys/kernel/modules_disabled: Permission denied
If you are using a VPS technology, you do not have a kernel you can control. Your system shares the servers kernel, however you can not control, replace, modify or configure the kernel. Therefore you can not change any kernel settings. This message simply means you can not change this setting.
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.
WARNING: No module ohci-hcd found for kernel
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. Please contact your OS vendor for assistance if your OS has configured this in a different location. This error is not caused by ASL.
WARNING: No module uhci-hcd found for kernel
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. Please contact your OS vendor for assistance if your OS has configured this in a different location. This error is not caused by ASL.
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. For non-Xen systems run this command as root:
yum--enablerepo=tortix-kernel install kernel-devel
For Xen systems run this command:
yum--enablerepo=tortix-kernel-xen install kernel-headers
Custom compiled kernels are not supported.
Where are the kernel headers?
If you wish to install the kernel source it is included in the "kernel-devel" package. For non-Xen systems run this command as root:
yum--enablerepo=tortix-kernel install kernel-devel
For Xen systems run this command:
yum--enablerepo=tortix-kernel-xen install kernel-headers
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.
SSH
ASL manages the SSH daemons configuration and enforces that configuration based on your settings in ASL. If you want to change the SSH daemons configuration, you will have to change the corresponding setting in ASL, otherwise ASL will reset it to whatever you have configured in ASL. Please see the SSH configuration options documentation at the URL below:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#SSH_daemon_configuration
OSSEC
Integrity checksum changed
These alerts mean that ASL has detected that a file has changed. We recommend that you investigate this file change to determine if it was authorized on your system, and if it was not this may indicate that a compromise has occurred.
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, please see the article ASL file integrity manager.
Specifically, 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
Discussion
OSSEC can report what changed in a file, and can keep a record of all the changes that have occured with that file. It will keep these "diffs" in this directory:
/var/ossec/queue/diff/local
This can be particularly helpful in determining if a change is authorized or not, and its also an excellent way to maintain a real time record of file or directory to allow for change and revision control as well as a real time back up of these files. For example, OSSEC can tell you that a particular configuration option was removed or changed in a file, and can report those literal changes (as opposed to just an md5sum as with basic file integrity checks). ASL will report what information has been altered and what the original and new information is (for example, with password files). This uses more resources, such as drive space to store all of this change information.
In other cases, with log files for example, this type of diffing can take up a lot of drive space and is not useful. ASL excludes common log files used in standard systems.
Solution
If your system is recording all of the changes on files or directories where you do not wish ASL to record "diffs", log into the ASL gui and check your file integrity configuration for the "Report" option. If a directory is configured to "report", OSSEC will report the details of the change to you (it will generate a "diff"), and will store a record of all changes that occur over time.
Step 1: Log into the ASL web console
Step 2: Click on the ASL tab
Step 3: Click the File Integrity option
Step 4: Click on "Watch Rules"
Select the directory you want to modify. To turn off reporting (or generating diffs), set the "Report" option for the directory to "no". Then click "save changes".
Note: This will not delete the old diffs. You will have to manually remove those diffs. Do not remove the /var/ossec/queue/diff/local/ directory. Only remove subdirectories within that directory.
Reporting can use a significant amount of drive space on your system if you are "report"ing on files or directories that change often, such as logs, temporary or cache directories, or if you are using a product that is changing your operating system a lot (some control panels recompile thousands of software packages nightly, and if you are monitoring these pages ASL will correctly report and log these changes).
You can exclude a subdirectory if you still want to report on changes in a directory, such as /etc. To exclude a subdirectory just log into the ASL GUI, click on the ASL tab, click on File Integrity, then click Options, and scroll the bottom. From there click on the "--add rule--" drop down and select "ignore". This will then give you the option to type in the subdirectory you want to exclude. Type in that directory and then click "update".
Also, ASL will rotate the logs according to your logrotate policy. That policy file is:
/etc/logrotate.d/ossec-hids
You can change the parameters of this file to suit your needs. In general, the logs files themselves are very small. The primary file space usage will be coming from "report"ing events where "diffs" of changed files are stored.
You can also delete these diffs by running this command as root:
rm -rf /var/ossec/queue/diff/local/*
ossec-remoted
ASL 3.x does not use this component. Its OK if this daemon does not start.
ossec-execd: INFO: Adding offenders timeout:
This messages means that ossec is configuring the timeout for firewall blocks, known as the "offenders timeout". Offenders are blocked for a period of time, and when that period expires they are unblocked. The system has a repeat offenders system, that will increase the amount of time an offender is shunned and you should see a series of messages like this when ossec starts:
Starting ossec-hids: 2012/06/13 09:55:18 ossec-execd: INFO: Adding offenders timeout: 20 (for #1) 2010/02/13 04:15:08 ossec-execd: INFO: Adding offenders timeout: 40 (for #2) 2010/02/13 04:15:08 ossec-execd: INFO: Adding offenders timeout: 80 (for #3) [ OK ]
This means OSSEC has started up correctly.
