Atomic Protector Usage Guide

Introduction

This guide contains usage questions for Atomic Protector.

Atomic Protector Web Console

Where is the Atomic Protector Web Console?

  • You can access the Web Console on your system at the following URL (change www.example.com to either your system’s name or IP address):

    https://www.example.com:30001

Note

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

Can’t connect to the Atomic Protector Web Console?

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

Web Console running slow?

How can I change the reporting level in the AP GUI?

Step 1) Log into the AP GUI

Step 2) In the Dashboard > 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 AP GUI

Step 2) Click on the Atomic Protector

Step 3) Select the User Management

Step 4) click ‘Create new user’

Step 5) Complete the requested fields

Step 6) Select ‘Is Admin’ if the user will need admin priviledges

Step 7) Select the users group, if you have defined any additional groups. The “default” group has access to all areas of the AP web console. If you want to define groups with less privileges, select the “Groups” tab at the top of the “AP Web Users” window, and define new groups to meet your needs.

Need more info?

Scanning for Malware

Qurantine

  • 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 --follow-dir-symlinks=0 --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 --follow-dir-symlinks=0 --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 AP kernel. Not all kernels support ionice.

Scheduling Scans

Step 1) Become root of the system by running the following command

su -

Step 2) Add a cronjob to schedule the scan by running the following command

crontab -e

Step 3) Add in the cron tab, like the following

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 AP is blocking an IP?

  • If AP blocks anything, it will log that action. Just log into the AP 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 AP has shunned, or firewalled off an IP address previously, just click on the AP tab, then then select Blocking. Any IP address that AP is blocking will be listed in that window.

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

  • If you are using the geoblocking features, check the Geoblocking window for the list of countries you have configured AP to block.

  • If you are unable to log into the AP Web Console, you can also check the AP Active Response log.

Can I search for a domain to see if its been blocked?

  • Yes, just yes the domain name instead of the IP address.

How can I tell if AP has blocked something in the past?

  • If AP is no longer blocking an IP, but you want to find out if it blocked it in the past you can check either the AP GUI as explained in the article above, or you can also check the logs to see if an IP was blocked. To check the logs, run this command as root:

    grep <IP> /var/ossec/logs/active-responses.log*

  • If you have compression enabled for your logs, you can do that with this command:

    zgrep <IP> /var/ossec/logs/active-responses.log*gz

  • 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 <IP>

Note

If you have whitelisted an IP address, AP will not shun the IP.

How can I tell if AP is blocking something?

  • If AP blocks anything, it will log that action. Just log into the AP GUI, trigger the event, or type in the IP address into the Event: box in the Security Events window. If AP 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 AP reporting anything related to your event, then AP is not causing this event to occur.

How long is an IP address blocked?

  • This depends on how you have configured AP. 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 AP:

    1. OSSEC_SHUN_TIME

    2. OSSEC_SHUN_ENABLE_TIMEOUT

How do you whitelist an IP in AP?

  • Log into the AP GUI, click on the AP tab and select the Blocking menu option. This will open the window of any IPs AP 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>

    Keep in mind that whitelisting an IP means that it will never be shunned by AP, 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: FW_WHITELIST

  • If you want the WAF to also ignore all attacks from your whitelisted IPs, enable this option: MODSEC_00_WHITELiST

  • If you also want the WAF to allow all traffic from hosts on the whitelist, enable this option: FW_WHITELIST

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

Step 1) Become root on the system by running the following command

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) Update the AP Security Policy by running the following command

asl -s -f

How do you unblock an IP in AP?

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

Alternative Method:

  • You can also do this from the command line, however we do recommend using the Atomic Protector Web Console for ease of use. To accomplish this from the command line, run this command as root:

    asl -ub <IP to unblock>
asl -ub <Network to unblock>

How do you blacklist an IP in AP?

  • Log into the AP GUI, click on the AP tab and select the Blocking menu option. This will open the window of any IPs AP 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.

Alternative Method:

  • You can also do this from the command line, however we do recommend using the Atomic Protector Web Console for ease of use. To accomplish this from the command line, run this command as root:

    asl -bl <IP to blacklist>
asl -bl <network to blacklist>

What does “system” mean in the blacklist window?

  • This means that a legacy blacklist entry existed before AP supported the “Listed by” logging capability, or the IP was added from the command line.

How do you remove an IP from the user defined blacklist?

  • Log into the AP GUI, click on the AP tab and select the Blocking menu option. This will open the window of any IPs AP 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?

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

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.

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

Debugging Usage

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

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

AP X11 Usage

How can I use the Linux X11 GUI with AP?

  • Please see the X with AP article for further instructions.

Enabling/Disabling Usage

Disabling AP

  • From AP Web, Settings->AED Configuration make the following changes:

    Step 1) Disable the WAF, Set MODSEC_ENABLED to no

    Step 2) Disable the HID, Set OSSEC_ENABLED to no

    Step 3) Disable Psmon, Set PSMON_ENABLED to no

    Step 4) Disable the Firewall, Set FW_ENABLE to no

    Step 5) Disable clamav, Set CLAMAV_ENABLED to no

    Step 6) Disable mod_evasive, Set MODEV_ENABLED to no

    Step 7) Disable mod_qos, set MOD_QOS_ENABLED to no

    Step 8) Click Save Changes

  • From the command line as root, run the following commands:

    service ossec-hids stop
service psmon stop
service clamd stop
service asl-firewall stop

Renabling AED

  • From AED Web, Settings->AED Configuration make the following changes:

    Step 1) Enable the WAF, Set MODSEC_ENABLED to yes

    Step 2) Enable the HID, Set OSSEC_ENABLED to yes

    Step 3) Enable Psmon, Set PSMON_ENABLED to yes

    Step 4) Enable the Firewall, Set FW_ENABLE to yes

    Step 5) Enable clamav, Set CLAMAV_ENABLED to yes

    Step 6) Enable mod_evasive, Set MODEV_ENABLED to yes

    Step 7) Enable mod_qos, set MOD_QOS_ENABLED to yes

    Step 8) Click Save Changes

  • From the command line as root, run these commands:

    service ossec-hids start
service psmon start
service clamd start
service asl-firewall start
asl -s -f

Note

psmon not used on el7 systems, you can ignore any errors from starting psmon on those platforms.

Active Response Usage

When a rule is triggered will AED redirect the user to a webpage?

  • Not by default. By default AED 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 AED to redirect your users, then AED has no effect on any redirects apache may be generating.

    If you wish AED to control redirects, you will need to setup a redirect page and configure this option: WAF_REDIRECT_URL

    AED will then redirect WAF events to the URL of your choosing.

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

  • Log into the AED GUI, click on Configuration, then select AED 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 AED 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 AED kernel protections stop kernel level attacks, then reboot the system into a non-AED kernel.

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

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

Does AED log all shuns?

  • Yes. If AED 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)

  • For 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 AED 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 AED GUI and click on the AED tab, then click on Blocking. If AED 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

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

Does AED log all unshuns?

  • Yes. If AED 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)

  • For 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 AED 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 AED GUI and click on the AED tab, then click on Blocking. If AED 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

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

How long will AED 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 AED GUI, click on the Configuration tab, then select AED Configuration, and scroll down to OSSEC_SHUN_TIME.

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

Editing Rules

How can I modify a rule?

Step 1) Log into the AED web console

Step 2) Click on the AED 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.

How can I disable logging of a rule in the AED GUI?

Step 1) Log into the AED web console

Step 2) Click on the AED 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.

Step 6) click on the “log” dropdown and change the dropdown from “yes” to “no”.

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.

AED Vulnerability Scanner Usage

Runtime module loading fixed

  • Please see this page for more information.

Whitelisted IP’s exceed 256: [CRITICAL]

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

    AED 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 AED 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. AED 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. AED 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. AED 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 AED to resolve this.

I’m getting High Risk Vulnerability errors for my kernel

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

  • If you are running AED 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

Managing PHP by using AED

SAFE MODE Restriction in effect:

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

AED keeps changing my php.ini

  • If you configure AED to configure and enforce your PHP settings, then AED will change your php.ini file. In that case, you must use the AED options to change your PHP settings. For example, if you manually change a setting in php.ini and the option in AED does not match this change, AED will by design change this setting to whatever you have configured AED to enforce. Please see these options in AED to configure AED to enforce your PHP settings, and what those settings should be here .

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

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

Note

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

How can I prevent AED from changing php.ini?

  • By default AED will not change php.ini. It will only do this if you have configured AED to do so. If you have not enabled this capability in AED, then AED can not php.ini.

  • To disable this capability in AED follow this process:

    Step 1) Log into the AED Web Console

    Step 2) Click on the ‘Configuration’ tab

    Step 3) Select ‘AED Configuration’

    Step 4) Scroll down to the ‘PHP Configuration’ section and change the ‘PHP_CHECKS’ to ‘NO’.

    Step 5) Select ‘Update’

  • AED will only scan for PHP vulnerabilities when it is managing php.ini. If you set this to “No” and manually change php.ini, AED will not scan php.ini.

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

  • By default AED will only report PHP vulnerabilities.

  • If you want AED to fix these vulnerabilities follow the process below:

    Step 1) Log into the AED Web Console

    Step 2) Click on the ‘Configuration’ tab

    Step 3) Select ‘AED Configuration’

    Step 4) Scroll down to the ‘PHP Configuration’ section and set ‘PHP_CHECKS’ to ‘YES’

    Step 5) Select ‘Update’

Manage SSH by using AED

How to re-enable an SSH setting AED is managing?

Step 1) Log into the AED Web Console

Step 2) Select the ‘Configuration’ tab

Step 3) Select the ‘AED Configuration’ tab

Step 4) Scroll down to the ‘SSH Daemon Configuration’ section and change the SSH settings you have configured AED to enforce.

Step 5) Select ‘Update’

How can I disable my SSH banner?

  • If you are using the AED Web Console, please follow the steps below:

    Step 1) Log into the AED Web Console

    Step 2) Click on the ‘Configuration’ tab

    Step 3) Select the ‘AED Configuration’ tab

    Step 4) Scroll down to SSH_BANNER and set it to ‘off’

    Step 5) Click ‘Update’

  • If you manually want to change this setting in /etc/asl/config you must run the following command as root:

    asl -s -f

  • On some systems, you may need to reload the SSH daemon to make the configuration take effect. Run the following command:

/etc/init.d/sshd reload

Note

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

Network Firewall Usage

How can I disable the AED firewall during boot?

  • You can configure the AED firewall to not be enabled on boot with this command, run as root:

    chkconfig --del asl-firewall

Note

When you upgrade AED the firewall will be re-enabled by default, so you must do this again if you wish to disable the firewall. This will also prevent Active Response from working correctly in AED.

How can I disable the AED firewall during runtime?

  • You can temporarily disable the AED firewall with this command, run as root:

    service asl-firewall stop

  • This will not disable Active Response in AED, to disable Active Response you must set this option to “No”

  • When you reboot the system the AED firewall will be re-enabled by default, so you must do this again if you wish to disable the firewall.

  • Disabling the AED firewall may also prevent Active Response from working correctly in AED.

  • AED is not supported with third party firewalls. If you use a third party firewall AED may not work correctly.

Does the network firewall block any ports by default?

  • No, the network firewall is not configured to block any ports by default.

AED_SMTP_OUT

  • This means that AED is blocking outbound connections, based on your configuration, to SMTP ports on other systems. AED does not block these connections by default, and will only do this if you enable this feature and configure this function. Modify this AED setting FW_OUTPUT_MTA.

  • Two types of log messages will be generated:

    1. 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: AED_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

    2. 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: AED_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 AED will not do by default.

DROP_AED_TORTIX

  • This means that AED is blocking connections to the AED web console, based on your configuration. AED 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:

    /ect/asl/firewall/tortixd-access-list

AED_BLACKLIST_BLOCK

  • This log message means that you have manually added an IP address or network to the user defined blacklist in AED. AED 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. AED 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 AED follow the process below to remove it:

    Step 1) Log into the AED Web Console

    Step 2) Click on the ‘Blocking’ menu

    Step 3) Select the ‘Blacklist’ tab

    Step 4) Select the IPs/Networks to remove and click ‘Remove selected Ips’ button

  • Can I prevent AED from logging these drops?

    • Yes, see this configuration setting in the AED Web Console: FW_LOG_BLACKLIST_DROP

AED_GEO_BLOCK

  • This log message means that AED has blocked a connection to a TCP or UDP port based on how you have configured AED. Specifically, these events only occur if you have configured AED to block a country using the GeoBlock feature.

  • Can I prevent AED from logging these drops?

    • Yes, see this configuration setting in the AED Web Console: FW_LOG_GEOBLOCK_DROP

DROP_AED_INPUT

  • This log message means that AED has blocked a connection to a TCP or UDP port based on how you have configured AED. Specifically ports not listed in FW_INBOUND_TCP_SERVICES and FW_INBOUND_UDP_SERVICES

  • If AED 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 AED firewall rules, check to ensure that you have this option enabled: 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 AED is logging this block as as a DROP_AED_INPUT rule (and not any other message or rule is being triggered) this can mean:

      1. The system is not running the AED kernel, and the kernel that is being used is unable to perform stateful inspection on the packets.

      2. 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 AED from logging these drops?

    • No. As a general rule if AED blocks something AED will log it. We do this to ensure that you know what AED is doing to your system, and also because AED 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, AED 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 AED 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 AED 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 AED firewall is working fine, however you can not change the TCP window scaling settings for your VPS.

Web Application Firewall Usage

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

How to disable a single rule?

  • Run the following command:

    asl --dr <rule_number>

How do you exclude a domain from the modsecurity rules?

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?

  • See the Proxy article for more information.

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). Modsecurity and AED do not cause these error messages, and disabling modsecurity or AED would not cause them to go away.

    For example:

    [Wed Nov 1 11:11:11 2014] [error] [client 1.2.3.4] client denied by server configuration: /wp-admin/admin-ajax.php, referer: http://example.com/wp-admin/tools.php?page=foo

    These are Apache errors that ModSecurity is logging, not causing.

  • 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 before modsecurity even “sees” the attack). 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)

    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, this is not caused by modsecurity, modsecurity is just logging these events. 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, or may indicate a more sophisticated attack may be in progress of that something is wrong with the machine.

    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.

AED Data Retention Usage

Configuring the AED database retention policy

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

Configuring modsecurity audit log retention

  • By default, AED 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 AED 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.

Can I reduce database usage?

  • Yes you can. Just follow the steps below:

    Command Line:

    Step 1) In the AED configuration file, set ‘AED_DB_ARCHIVE’ to ‘no’

    Step 2) Update the AED Security Policy by running the following command:

    asl -s -f

    AED Web Console:

    Step 1) Log into the AED Web Console

    Step 2) Select the ‘AED Configuration’ tab

    Step 3) Select ‘AED Web Settings’

    Step 4) Uncheck ‘Database Rotation’

    Step 5) Click ‘Save’

AED Firewall Usage

Using the AED Firewall Manager

AED-ACTIVE-RESPONSE

  • This iptables chain is used by AED for temporary shuns.

AED_LASSO_BLOCK

  • This log message means that you have configured AED to block sources on SpamHaus’ Lasso list. This option is disabled by default, and can only be enabled by the user. Modify this AED setting: FW_LASSO

Note

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

Disabling GeoBlocking

  • To disable geoblocking, follow the process below:

    Step 1) Log into the AED Web Console

    Step 2) Click the ‘AED’ tab

    Step 3) Select the ‘Geoblock’ tab

    Step 4) In the blocked column on the left select the countries you wish to unblock

    Step 5) At the bottom of that windo 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

AED Kernel Usage

User can not see all processes

  • This is a special protection only available on AED 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 AED 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 not showing as disabled

  • This means that either:

    1. DOS protection is disabled in AED. Please log into the AED GUI, click on the Configuration Tab and select the “AED Configuration” menu option. When the AED 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. AED 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 AED secure kernel. To resolve this follow these steps:

    Step 1) Check to see if you are running the AED kernel by referring to this section

    Step 2) If you are not, then check to see if its installed, and if not install it by following this process

    Step 3) If the kernel is installed, just reboot your system into the AED kernel. By default, AED should set itself up to boot into the AED secure kernel, but if you are not sure follow our process outlined in the Kernel Wiki.

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 AED 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 is 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 AED 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 the following:

      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 the application from doing something dangerous to your kernel. The path to the application in the example above is:

    /usr/foo/bar

    If you wanted to allow the application to modify your kernel’s running stack, and to disable all security protections in the kernel for this application you would run the following 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.

Cannot install kernel modules

  • By default the AED 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 AED 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 AED:

    1. Set the modules to load at boot and reboot your system. Please see installing custom kernel modules which provides more information about setting up custom modules to laod before AED locks the kernel down.

    1. Configure AED 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 AED lock the kernel. Remember, AED 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 AED GUI, click on AED Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. AED will report this, correctly, as a critical vulnerability in the system.

WARNING: No module ohci-hcd found for kernel

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

WARNING: No module uhci-hcd found for kernel

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

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

  • 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 the AED Kernel?

  • Indeed you can, PAE kernels are fully suported in asl. Just check yum and install the PAE kernel by running the following command:

    yum install kernel-PAE

Where are the kernel headers?

Centos 5 and 6:

  • 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

Centos 7:

  • If you wish to install the kernel source it is included in the “kernel-asl-devel” package. For non-Xen systems run this command as root:

    yum--enablerepo=tortix-kernel install kernel-asl-devel

  • For Xen Systems run this command:

    yum--enablerepo=tortix-kernel-xen install kernel-asl-headers

AED Kernel with Xen

  • AED is fully support inside a Xen guest. If you can not get the AED kernel to run inside a Xen virtualized machine make sure your Xen system is up to date. AED 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 AED 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 the following line:

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

    To:

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

    Once this change has been made, reboot the system by running the following command:

    reboot

Types of Virtualization Technologies

Full Hypervisor

  • QEMU, KVM, Vmware, Virtualbox, Parallels, etc (no custom OS required - AED 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. AED 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. AED 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 AED 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 AED does). This means that you boot the master off of one kernel, and then the guests boot again in their special xen guest kernels.

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

OSSEC Usage

Integrity checksum changed

  • These alerts mean that AED 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.

AED is changing my OSSec Configuration

  • AED 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 AED templates that AED uses to manage those files. The templates are stored here:

    /var/asl/data/templates/

  • The OSSec master template is stored here:

    /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 the following command:

    asl -s -f

  • AED 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-AED managed directory. Currently AED 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 does Syscheckd do?

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

  • Specifically, log into AED, click on the AED 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 AED 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 AED 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 AED GUI, click on the AED 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 the following directory:

    /var/ossec/etc/

    And to change the 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

OSSec is using a lot of disk space

  • 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). AED 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. AED excludes common log files used in standard systems.

  • Here’s the solution:

    • If your system is recording all of the changes on files or directories where you do not wish AED to record “diffs”, log into the AED 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 AED Web Console

      Step 2) Click on the ‘AED’ tab

      Step 3) Click on the ‘File Integrity’ option

      Step 4) Click on ‘Watch Rules’

      Step 5) Select the directory you want to modify. Select the ‘Report’ option for the directory to ‘no’.

      Step 6) 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 AED 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 AED GUI, click on the AED 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”.

  • Additionally, AED will rotate the logs according to your logrotate policy. The policy file is located here:

    /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 ‘reporting’ events where “diffs” of changed files are stored.

  • You can also delete these diffs by running the following command as root:

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

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.