Revision as of 12:26, 15 January 2014

Introduction

ASL is configured to a secure set of defaults upon installation. Most users do not need to change these settings.

Installation

ASL Installation settings are documented on the ASL installation page, please see that page for installation configuration options.

Post Installation Configuration

You can access the ASL configuration settings by following this process:

Step 1) Log into the ASL GUI

Step 2) Click on the Configuration tab

Step 3) Select "ASL Configuration"

This will pull up all the ASL Configuration options, which are broken into classes and are documented below or links are provided to the specific documentation pages for those options.

Authentication Information

ASL Web Settings

In addition to the settings below, also, please see the ASL Web Settings page for documentation about configuring the ASL GUI itself.

USERNAME

This is the username ASL will use to download updates. This should be the same username you use to log into the License Manager.

PASSWORD

This is the password ASL will use to download updates. This should be the same password you use to log into the License Manager.

ASL_DB_RETENTION

Period alert data is considered to be live before being moved into an archive table. Once this limit is reached, ASL will move the events into the database archive table.

The format for this field is an integer follow by "days" "weeks" "months" or "years". For example, if you want to archive events after 3 months, you would change this field to:

3 months

The default is 7 days. After 7 days, events do not show up in the security events window or in searches. If you have ASL_DB_ARCHIVE set to "yes" old records are archived in mysql (but do not show up in the security events window or searches)

This value is ignored if ASL_DB_ARCHIVE is set to "no" below.

ASL_DB_ARCHIVE

ASL will store old data in monthly archive table if this is set to 'yes', or simply delete past retention data if it is set to 'no' once the ASL_DB_RETENTION period is reached for the data.

Data Paths

PATH_RSS

URL to the Atomicorp Security Bulletins RSS feed. You shouldnt change this unless told to do so by Atomicorp support personnel.

General Settings

NOTIFY

Determines if ASL will notify by email or not. Set this to yes if you want ASL to email you, and no if you do not.

EMAIL

Default email address used to send alerts to. This is also set during installation.

HOSTNAME

Hostname for the system. This is also set during installation.

ADMIN_USERS

This setting allows you define special administrative users that ASL will check to make sure they can SSH into the system (users other than root). If this is defined, AND the users exist, AND they have valid SSH keys, password auth and root logins will be automatically disabled. This list is not used to restrict what users can ssh into the system, its just a list of special users that should always be allowed to ssh into the system. ASL uses this list to check these accounts to make sure they are working correctly, to ensure that those users can still log into the system is other changes are made to the ssh settings via ASL (for example, disabling password authentication, ASL will check this list of users to make sure they have SSH keys installed). This is an important fail safe feature, and you should list all your administrative users (other than root) in this list to help ensure they will be able to log into the system.

Usernames are separated with spaces. Example:

bob joe karen

Note: This setting has nothing to with the AllowUsers setting in sshd.

Important: If an admin user is not defined, ASL will not allow SSH settings to be modified.

For example, if no admin users are defined, ASL will not allow password authentication to be disabled nor will it allow root logins to be disabled. This is a critical safeguard to prevent users from accidentally locking themselves out of the system.

If an admin user or users are defined, and if password authentication is disabled, ASL will also check to make sure the admin user or users have ssh keys installed in the correct place, and that their permissions are valid. If the keys are not installed, the permissions are wrong, or they are not installed in the right place, ASL will not allow any SSH configuration changes to take place and will ensure the defaults are used. Again, this is a critical safeguard to prevent users from accidentally locking themselves out of the system.

ASL can not test the keys themselves for validity as an authentication credential, as it only has access to the public key. Therefore it is the users responsibility to ensure the SSH key pair works correctly for the account.

SYSTEM_TYPE

Defines a basic services policy for the system, and configures ASL to work with control panels that do not use package management.

Setting the profile to anything other than "custom" will configure ASL to disable the following services:

• portmap
• nfs
• nfslock
• rpcidmapd
• cups
• gpm
• xfs
• pcscd
• mcstrans
• kdump
• isdn
• hplip
• hidd
• messagebus
• haldaemon
• gpm
• bluetooth
• avahi-daemon
• autofs
• apmd

Options

webserver: You should use this setting for all system types except for the three below.

cpanel: setting this to cpanel, will configure the system for cpanel

directadmin: setting this to directadmin, will configure the system for directadmin.

custom: If this is set to custom, no services will be automatically disabled and no special configuration changes are made to the system to work with non-package managed control panels.

AUTOMATIC_UPDATES

Configures the update frequency for ASL to download and install updates, such as new rules and signatures

NOTE: Updates can be run manually from the command line with aum -u.

If a software update is available you should follow your normal patch management procedure. We recommend that all users test upgrades on a test system before deploying to a production system. See "UPDATE_TYPE" below.

UPDATE_TYPE

Configures the behavior of the AUTOMATIC_UPDATE event. There are three options:

All: This will upgrade all ASL software, rule and signatures updates.

Exclude-kernel: This will upgrade all ASL software, rule and signatures updates but not upgrade the kernel.

rules-only: This will exclude all software updates, including updates to ASL. This will prevent ASL from updating any rpm package updates and kernel updates and will only install rule and signature updates.

Important Notice: Some rule and signature updates may not work without ASL updates, so if you set this to "rules only" be sure to regularly check your system for any software updates for ASL to be fully protected.

RESTART_APACHE

Sets the restart policy for actions involving the web server. Updates to the WAF, mod_security, or mod_evasive policies will require a web server restart to go into effect. This setting has three options:

Yes: Restart apache when needed.

Graceful: Use the "graceful" method which tries to wait for all clients to finish being served before restarting Apache. If apache has a stuck thread or worker Graceful may not complete.

No: Do not restart apache.

Note: If you set this to "No", updates that require apache restarts will not be applied, such as new WAF rules. If you set this to "No" you will need to schedule regular restart intervals to install the latest rules. Only the latest rules are supported with the WAF.

ASL_USER

Sets the user to run ASL web activity under. This can be either "tortix" for use with ASL-Web, or "psaadm" for use with the Plesk ASL module. Note: this setting has been deprecated.

FEED_TYPE

This setting allows you to toggle between different WAF feeds. This was only used by ASL Lite, and only supports the Real-Time since the delayed feed was retired. ASL Users should not change this setting.

COMPLIANCE

This a new and UNSUPPORTED feature. If you use this, we welcome your feedback but it is unsupported.

This enables a compliance module based on one of 5 standards (CIS, DISA, DHS, NISPOM, PCI). It is not recommended by Atomicorp that you use any of these. It should only be used if you are required by a 3rd party regulator.

These compliance standards are very generic, and will break things on your system. These are not Atomicorp standards, so if you enable them be prepared to fix things.

Firewall Configuration

Please see the ASL firewall page for documentation on these settings.

Kernel configuration

If you are not using the ASL Kernel these settings in the ASL web console will have no effect.

ALLOW_kmod_loading

The default configuration for ASL is to disable Loadable Kernel Modules (LKM) after the system has booted (S99). This is intended to provide additional protection from attempts to load LKM rootkits by "locking" the kernel and preventing any additional changes to the kernel once it has been configured.

Setting this flag to "yes" and rebooting the system will allow kernel modules to be loaded and unloaded dynamically after a reboot. We do not recommend you set this to "yes", as a properly configured server should not require the kernel to dynamically modified. If you need to load custom modules in your kernel, please see this article which explains how to do this securely, and without needing to open this hole in your system.

https://www.atomicorp.com/wiki/index.php/Using_ASL#Can.27t_install_kernel_modules.

A number of known and in the wild attacks on Linux servers take advantage of kernel module loading being allowed, which can also be triggered by non-root users and have been used to compromise Linux systems.

The secure and recommended setting is "no". Do not allow kernel module loading.

GRKERNSEC_DETER_BRUTEFORCE

If you say Y here, attempts to bruteforce exploits against forking daemons such as apache or sshd, as well as against suid/sgid binaries will be deterred. When a child of a forking daemon is killed by PaX or crashed due to an illegal instruction or other suspicious signal, the parent process will be delayed 30 seconds upon every subsequent fork until the administrator is able to assess the situation and restart the daemon. In the suid/sgid case, the attempt is logged, the user has all their processes terminated, and they are prevented from executing any further processes for 15 minutes. It is recommended that you also enable signal logging in the auditing section so that logs are generated when a process triggers a suspicious signal.

[Default: no]

Note: This option is available in ASL 4.0 and up.

ENABLE_TPE

Trusted Path Execution(TPE) will allow you to choose a gid to add to the supplementary groups of users you want to mark as "untrusted" or "trusted". These users will not be able to execute any files that are not in root-owned directories writable only by root.

TPE_GROUP_POLICY

The TPE group policy indicates the mode to enforce on the system. These are "trusted", which is an Unless Allow, Deny configuration where only users in the "trusted" group can execute commands that are not owned by the root user. It is the more aggressive and constricted mode. The default "untrusted" mode is an Unless Deny, Allow policy where the TPE security controls only apply to users in the "untrusted" group.

TPE_UNTRUSTED_USERS

Users in this group will have the TPE policy applied if the system is configured to operate in "untrusted" mode. The root user is automatically trusted.

Untrusted users can only run applications owned by root. This prevents untrusted users from uploading code to the system, such as malware and spam tools, and will prevent them from running regardless of where they are located on the system.

TPE_TRUSTED_USERS

Users in this group will NOT have the TPE policy applied if the system is configured to operate in the "trusted" mode. Setting the policy to "trusted" means that only users in this list are trusted, all other users are considered untrusted. The root user is automatically trusted.

DISABLE_PRIVILEGED_IO

If you say yes here, all ioperm and iopl calls will return an error. Ioperm and iopl can be used to modify the running kernel. This is generally safe to set to "yes". Very few applications require that this be set to "no".

Some programs may need this access to operate properly, the most notable of which are XFree86 and hwclock.

hwclock is remedied by having RTC support in the the ASL kernel, so real-time clock support is enabled if this option is enabled, to ensure that hwclock operates correctly.

XFree86 still will not operate correctly with this option enabled, so DO NOT CHOOSE YES IF YOU USE XFree86.

AUDIT_MOUNT

Log all mount() and umount() actions.

AUDIT_CHDIR

Log all chdir() calls, or every time an application or user changes their directory. This is a high volume setting, and is disabled by default.

AUDIT_PTRACE

Log all attempts to attach to a process via ptrace().

AUDIT_TEXTREL

Log text relocations with the filename of the offending library or binary. This is a high volume setting, and is disabled by default.

CHROOT_CAPS

When enabled, the capabilities on all root processes within a chroot jail will be lowered to stop module insertion, raw i/o, system and net admin tasks, rebooting the system, modifying immutable, files, modifying IPC owned by another, changing the system time and elevating capabilities via the SYS_ADMIN capability.

Note: EL6 boots the system into a chroot. Enabling this protection will cause the first tty on the system to "echo" all input that should not be "echoed". For example, the password field will echo from the console on tty1. This may also cause problems with serial consoles that use the first tty (which is normally the default case).

The solution is to either disable this protection, or to use a different tty.

WARNING: Disabling this protection will make it possible for applications to escape chroots.

See these posts for a more detailed explanation of the technical and security issues with disabling this protection.

https://forums.grsecurity.net/viewtopic.php?f=7&t=2522

https://www.atomicorp.com/forums/viewtopic.php?f=3&t=6292&p=36069&hilit=chroot#p36069

CHROOT_DENY_CHMOD

When enabled, processes inside a chroot will not be able to chmod or fchmod files to make them have suid or sgid bits.

CHROOT_DENY_CHROOT

When enabled, processes inside a chroot will not be able to chroot again outside the chroot.

CHROOT_DENY_FCHDIR

When enabled, a well-known method of breaking chroots by fchdir'ing to a file descriptor of the chrooting process that points to a directory outside the filesystem will be stopped.

CHROOT_DENY_MKNOD

When enabled, processes inside a chroot will not be allowed to mknod.

CHROOT_DENY_MOUNT

When enabled, processes inside a chroot will not be able to mount or remount.

CHROOT_DENY_PIVOT

When enabled, processes inside root will not be able to use pivot_root().

CHROOT_DENY_SHMAT

When enabled, processes inside a chroot will not be able to attach to shared memory segments that were created outside of the chroot jail.

CHROOT_DENY_SYSCTL

When enabled, an attacker in a chroot will not be able to write to sysctl entries, either by sysctl(2) or through a /proc interface.

CHROOT_DENY_UNIX

When enabled, processes inside a chroot will not be able to connect to abstract (meaning not belonging to a filesystem) Unix domain sockets that were bound outside of a chroot.

CHROOT_ENFORCE_CHDIR

When enabled, current working directory of all newly-chrooted applications will be set to the the root directory of the chroot.

CHROOT_ENFORCE_CHDIR

When enabled, current working directory of all newly-chrooted applications will be set to the the root directory of the chroot.

CHROOT_EXECLOG

When enabled, all executions inside a chroot jail will be logged to syslog. This is a high volume setting and is disabled by default.

CHROOT_FINDTASK

When enabled, processes inside a chroot will not be able to kill, send signals with fcntl, ptrace, capget, getpgid, setpgid, getsid, or view any process outside of the chroot.

CHROOT_RESTRICT_NICE

When enabled, processes inside a chroot will not be able to raise the priority of processes in the chroot, or alter the priority of processes outside the chroot.

EXEC_LOGGING

When enabled, all execve() calls for users in the group execlog (1007) will be logged (since the other exec*() calls are frontends to execve(), all execution will be logged). This is a high volume setting and is disabled by default.

EXEC_LOG_USERS

Users in the group execlog will have all execve() actions logged to syslog if EXEC_LOGGING is enabled. This is a high volume setting, and is disabled by default.

DMESG

When enabled, non-root users will not be able to use dmesg(8) to view up to the last 4kb of messages in the kernel's log buffer.

EXECVE_LIMITING

When enabled, users with a resource limit on processes will have the value checked during execve() calls.

FIFO_RESTRICTIONS

When enabled, users will not be able to write to FIFOs they don't own in world-writable +t directories (i.e. /tmp), unless the owner of the FIFO is the same owner of the directory it's held in.

FORKFAIL_LOGGING

When enabled, all failed fork() attempts will be logged.

HARDEN_PTRACE

When enabled, TTY sniffers and other malicious monitoring programs implemented through ptrace will be defeated.

Certain Parallels products have a bug that requires that this protection be disabled. These products have a bug that incorrectly reports that users are running a debugger, when they are not if this protection is enabled. This is a bug in Plesk, and not in ASL. Please report this bug to Parallels if you wish to use these feature.

You can read more about this bug in Plesk at the forum post below:

https://atomicorp.com/forums/viewtopic.php?f=3&t=4636&p=26867#p26867

IP_BLACKHOLE

When enabled, neither TCP resets nor ICMP destination-unreachable packets will be sent in response to packets sent to ports for which no associated listening process exists.

Default: y

This feature supports both IPv4 and IPv6 and exempts the loopback interface from blackholing. Enabling this feature makes a host more resilient to DoS attacks and reduces network visibility against scanners. The blackhole feature prevents RST responses to all packets, not just SYNs.

Note: Under most application behavior this causes no problems, but applications (like haproxy) may not close certain connections in a way that cleanly terminates them on the remote end, leaving the remote host in LAST_ACK state. Because of this side-effect and to prevent intentional LAST_ACK DoSes, this feature also adds automatic mitigation against such attacks. The mitigation drastically reduces the amount of time a socket can spend in LAST_ACK state. If you're using haproxy and not all servers it connects to have this option enabled, consider disabling this feature on the haproxy host.

When this option is enabled, two sysctl options with names ip_blackhole and lastack_retries will be created. While ip_blackhole takes the standard zero/non-zero on/off toggle, lastack_retries uses the same kinds of values as tcp_retries1 and tcp_retries2. The default value of 4 prevents a socket from lasting more than 45 seconds in LAST_ACK state.

LASTACK_RETRIES

When enabled, prevents a socket from lasting more than 45 seconds in LAST_ACK state. The default value of 4 prevents a socket from lasting more than 45 seconds in LAST_ACK state.

The default is 4.

LINKING_RESTRICTIONS

When enabled, /tmp race exploits will be prevented, since users will no longer be able to follow symlinks owned by other users in world-writable +t directories (i.e. /tmp), unless the owner of the symlink is the owner of the directory. users will also not be able to hardlink to files they do not own.

RESOURCE_LOGGING

When enabled, all attempts to overstep resource limits will be logged with the resource name, the requested size, and the current limit. Due to high volume alerts you can consider disabling this option. RESOURCE_LOGGING is disabled by default.

ROMOUNT_PROTECT

By setting this option to 1 at runtime, filesystems will be protected in the following ways: No new writable mounts will be allowed, Existing read-only mounts won't be able to be remounted read/write, Write operations will be denied on all block devices. This is best used in embedded or appliance type environments, and is disabled by default.

RWXMAP_LOGGING

When enabled, calls to mmap() and mprotect() with explicit usage of PROT_WRITE and PROT_EXEC together will be logged when denied by the PAX_MPROTECT feature.

SIGNAL_LOGGING

When enabled, certain important signals will be logged, such as SIGSEGV, which will as a result inform you of when a error in a program occurred, which in some cases could mean a possible exploit attempt. This is enabled by default.

SOCKET_ALL

When enabled, you will be able to choose which users will be unable to connect to other hosts from your machine or run server applications from your machine.

SOCKET_USERS

Users in the socket group be unable to connect to other hosts from your machine or run server applications from your machine.

SOCKET_CLIENT

When enabled, users in the client group will only be able to create outbound connections, and will be prevented from creating servers on the system (clients can not listen for incoming connections).

SOCKET_CLIENT_USERS

Users in the client group will be unable to run server applications from your machine. This is in a comma delimited format.

SOCKET_SERVER

When enabled, the server-only policy group will be enabled on the system. Users in the servers group will be able to run servers on the system, but be unable to connect to other hosts from the machine.

SOCKET_SERVER_USERS

Users in the server group will be able to run services on the system, but be unable to connect to other hosts from the system as a client. This is in a comma delimited format.

Non GUI options

There are a few options that are not currently configurable via the web console. These will be added in a future release of ASL.

Restrict symlinks to owner

This is a kernel-based race-free implementation of Apache's SymlinksIfOwnerMatch option. This is enabled by placing users into a special group. When users are made part of this group, ASL restricts the following of symlinks to the owner of the file. This means that if a user is part of this special group, and creates a symlink to a file or directory they do not own, the kernel will prevent the symlink from being followed. This feature ensures that a compromised user on a shared hosting server can't cause Apache to follow a symlink to a sensitive file in another user's webroot in order to read its contents.

Note: This requires kernel 2.6.32.59-28 and up, and gradm 2.9.1 and up.

To add a user

To restrict a user, simply add their user ID to the symlinkown_gid. By default, that group is "1008". So if you add a user ID to group ID 1008, that user will not be able to follow symlinks to files and directories they do not own. For example:

If user "bob" has the uid "123", and symlinkown_gid is set to 1006, you can add bob to the symlinkown_gid with this command:

usermod -a -G 1008 bob

Note: For web applications, if you wish to enforce this restriction, its important to make sure that the effective uid for the web application is included in this group. For example, if your web applications run as the user "apache", then apache must be added to this group.

To change the group ID

If you wish to change the GID for the symlinkown group, you will need to set this condition as part of your /etc/sysctl.conf file:

kernel.grsecurity.symlinkown_gid = 12345

Change 12345 to the GID you wish to use.

One trick with this option, is to set the GID to the default GID for your users. This is a quick way to cause this restriction to be automatically inherited by your users.

Note: If your kernel is locked, this may require a reboot of your system.

TIMECHANGE_LOGGING

ClamAV configuration

Also, see the anti virus page for important documentation about configuring the Real Time Antimalware system in ASL.

CLAMAV_ENABLED

Enable or Disable the ClamAV malware detection engine for the system.

CLAMAV_ENABLE_DAZUKO

Enable or Disable the the kernel realtime antimalware detect module. Note this requires the ASL kernel, and the dazuko module.

To configure, please see the Anti virus page.

CLAMAV_TCPADDRESS

Set the IP address for clamd to listen on. Default: localhost

This is an unsupported option, and will not work with the CLAMAV_ENABLE_DAZUKO option, which when enabled, requires a local instance of clamd.

CLAMAV_SCANONACCESS

Scan with clamav when a file is accessed. This requires CLAMAV_ENABLE_DAZUKO be set to use, and the ASL kernel is used. Default: no

CLAMAV_SCANONOPEN

Scan with clamav when a file is opened. This requires CLAMAV_ENABLE_DAZUKO be set to use, and the ASL kernel is used. Default: no

CLAMAV_SCANONEXEC

Scan with clamav when a file is executed. This requires CLAMAV_ENABLE_DAZUKO be set to use, and the ASL kernel is used. Default: no

CLAMAV_SCANONCLOSE

Scan with clamav when a file is closed. This requires CLAMAV_ENABLE_DAZUKO be set to use, and the ASL kernel is used. Default: no

CLAMAV_CLAMUKO_MAXFILESIZE

Maximum size of a file dazuko will scan in megs. This requires dazuko. Default: 10m

CLAMAV_SAFEBROWSING

Set to "yes" to enable the Google Safe Browsing database. Set to "no" to disable the Google Safe Browsing database.

Note: This will increase memory usage in clamd significantly.

Default: no

The Safebrowsing database is designed by the clamav project to detect URLs from compromised sites in email messages, its not designed to find these in other file types. Therefore, this database is only useful for screening incoming email messages, and not as a general antimalware signature set.

Heres a simple test you can run to see if an URL is on the google safebrowsing list:

URL=<URL on blocklist>; echo -e "From test\n\n<a href=http://$URL>test</a>" | clamdscan -

And provided your signatures are up to date, if the URL is on the list you'll see this:

stream: Heuristics.Safebrowsing.Suspected-phishing_safebrowsing.clamav.net FOUND

PSMON configuration

PSMON_ENABLED

Allows the Process monitoring daemon to be enabled/disabled.

Note: not supported on systems that do not use package managed PERL installations.

PSMON_NOTIFY =

Enable/Disable email notification for PSMON. The default is to use the $NOTIFY setting.

PSMON_EMAIL

Email address notifications of restart events will be sent to. The default is to use the value set for EMAIL

PSMON_FROM

From: line used for notifications of restart events. The default is to use psmon@hostname of the system

OSSEC configuration

OSSEC_ENABLED

Enable or Disable OSSEC HIDS

OSSEC_NOTIFY

Configure OSSEC to send alert notifications over email or not. Default is yes.

OSSEC_MODE

Operating mode for OSSEC, can be configured as either 'server' or 'client'. When in client mode you will need to set up the OSSEC key from the command line.

OSSEC_USE_MYSQL

Configure OSSEC to store events in mysql

OSSEC_DATABASE_SERVER

IP or hostname of OSSEC database server. Note OSSEC only uses tcp sockets. Network access is required

Remote mysql servers are not currently supported (but they may work).

OSSEC_DATABASE

Name of OSSEC database

OSSEC_DATABASE_USERNAME

Name of OSSEC database user

OSSEC_DATABASE_PASSWORD

Password for OSSEC database user

OSSEC_SERVER

IP address of OSSEC server, when this node is configured to be an OSSEC client. Leave this blank if OSSEC_MODE is set to server.

OSSEC_EMAIL

Email address to send all OSSEC alert notifications

OSSEC_SMTP_SERVER

SMTP server to send OSSEC alert notifications.

OSSEC_FROM

From: line used for OSSEC alert notifications

OSSEC_MAX_MSG

Maximum number of email messages OSSEC will send per hour. Multiple alerts will be sent in digest mode (a single email). Setting this to 0 will disable digest mode

OSSEC_ACTIVE_RESPONSE

Enable/Disable Active response mode. Setting this to yes will enable active firewall blocks when ASL detects an attack. Setting this to no will prevent ASL from enabling any firewall blocks due to an attack.

OSSEC_SHUN_ENABLE_TIMEOUT

Enable/Disable expiration of active response firewall blocks. Setting this to yes will expire blocks after a fixed interval defined in OSSEC_SHUN_TIME. Setting this to no will make all blocks permanent (not recommended).

OSSEC_SHUN_TIME

Number of seconds to maintain an active response block. Default is 600 seconds (10 minutes).

HIDS_SHUN_MULTIPLIER

Enable a block time exponential multiplier for repeat offenders based on the Shun Time setting.

To disable this functionality, set the value to "0".

This feature will multiple the shun time by the HIDS_SHUN_MULTIPLE value for any successive attacks from the same IP. For the first attack from an IP, the shun period will always be the setting OSSEC_SHUN_TIME. For the second, and successive attacks from an IP the Shun Time for that IP will be multipled by the HIDS_SHUN_MULTIPLER number for each successive attack from that IP. That value will then be multipled for the next attack and so on. This causes repeat attackers to be blocked for longer and longer periods based on this setting.

Note: This is exponential, not linear. The shun time for an attack is calculated by multiplying the previous shun time by the multipler. This means the value will not increase linearly to the base Shun Time, but rather the shun time will increase exponentially with each attack.

For example:

If the shun time is configured to 600 seconds, and HIDS_SHUN_MULTIPLE is set to "3". The shun times would be:

• First attack: 600 seconds
• Second attack: 1800 seconds
• Third attack: 5400 seconds
• Forth and any following attacks: 16200 seconds

The current system does not increase the shun time past the forth attack.

This period is valid for as long as the OSSEC Daemon is running, once OSSEC is restarted, all of this data will be lost/reset and the counter returns to the lowest value (in this example 600 seconds) and the process starts over.

HIDS_EMAIL_ALERT_LEVEL

This controls the minimum level an alert will need to be in order to activate an email event. Some events will be sent that are lower levels than this, for example 1002 which is the suspicious event alert. You can disable specific over rides in the rule manager.

Mod_security configuration

Please see the ASL WAF page for documentation on these settings.

PHP configuration

Note: If you want ASL to manage these settings do not change them manually in php.ini, and do not use third party tools to manage these settings.

Important Note: When php functions are disabled, and an application tries to use them, Apache will log that in the domains error_log file. Therefore, if you have a PHP application that does not work correctly after changing these settings, please check the effected domains error_log file. This is the only place that errors involving disabling functions will be logged or reported.

PHP_CHECKS

Enable/Disable PHP check enforcement mode. Default: No.

If this is set to "no", ASL will not be configured to manage any PHP settings, and rest of the PHP settings will have no effect. To enable, or disable PHP functions, this must be set to "yes".

Note: Setting this to no will still test for vulnerabilities, but will neither fix them, nor make any changes to your PHP configuration.

PHP_SAFE_MODE

Enable/Disable PHP Safe_Mode

Note: PHP 5.3 and later has deprecated this feature.

PHP_REGISTER_GLOBALS

Enable/Disable register_globals.

PHP_URL_FOPEN

Enable/Disable url_fopen

Please see this page for information on this function and a serious vulnerability that can be created by allowing this function in PHP:

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

PHP_URL_INCLUDE

Enable/Disable URL includes

ALLOW_curl_exec

Enable/Disable the curl_exec() function

ALLOW_curl_multi_exec

Enable/Disable the curl_multi_exec() function

ALLOW_dl

Enable/Disable the dl() function

ALLOW_phpinfo

Enable/Disable the phpinfo() function.

Default: yes (allow phpinfo)

SSH daemon configuration

Also, see the SSH debugging page in case you can't log into your ASL server via SSH.

SSH_PROTOCOL

Note: Do not change this setting unless you know what you are doing.

SSH supports several legacy protocols (1 and 1.5), along with the current SSH protocol, 2. 1 and 1.5 have fundamental weakenesses that can cause SSH sessions with those protocols to be compromised, therefore we recommend you leave the protocol setting of "2".

Default: 2

SSH_PORT

This will tell SSH to change its default port of 22 to a different port. If you set this to "no", that will tell SSH to use the default port of 22. For example, if you wanted to change SSHs port to "2222" you would enter "2222" in this field.

Default: no

SSH_STRICTMODE

This tells SSH to check the ownership and permissions on ssh public key files. This prevents a user from accidentally setting the permissions on the file so that other users can add their keys to another users key file. We highly recommend you enable strict modes.

Default: yes

SSH_IGNORE_RHOSTS

This tells SSH to ignore rhosts file. rhosts files tell SSH to trust another host completely, which means a user logging in from that host will not asked for a password. Allowing rhosts files is very insecure, and we recommend you leave this enabled.

Default: yes

SSH_PUBKEY

This setting tells SSH to allow the use of public keys, instead of passwords, for authentication. Public keys are more secure than passwords, provided that the public key itself has a strong password. Keys can provide a cheap two factor authentication system (what you have, and what you know).

Default: yes

SSH_ROOTLOGINS

This setting tells SSH to allow root logins. If you set this to yes, root will be allowed to ssh in, if you set this to no, root will not be allowed to ssh in. We recommend you set this to "no".

Default: yes

Note: You can only disable root logins if you have defined a valid ADMIN_USER. Please see this option:

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

SSH_PASSWORD_AUTH

This enables/disables password authentication via SSH. See also the ADMIN_USERS option.

Default: yes

Options:

Yes - Allows password authentication

No - Does not allow password authentication, but will check to make sure at least one valid ADMIN_USER exists with keys installed. This is a fail safe to prevent accidental lockout from the system.

Override - Does not allow password authentication, but will NOT check to make sure at least one valid ADMIN_USER exists with keys installed. Warning: This will lock you out of your system if you do not have valid key based authentication configured for the system.

SSH_PRIV_SEPARATION

This ensures that SSH runs with privilege separation.

Default: Yes.

SSH_GSSAPI_AUTH

Default: No.

SSH_GSSAPI_CLEANUP

Default: No.

SSH_BANNER

ASL can configure SSH to display a banner to users when they log in. This tells SSH what file to use for the banner. ASL comes with a standard banner you can use that is provided in the /etc/asl/banner file.

Default: /etc/asl/banner

SSH_USEDNS

Default: yes

Rkhunter settings

RKHUNTER_ENABLED

Enable/Disable nightly rkhunter scanning

RKHUNTER_EMAIL

Email address to send rkhunter alerts

Mod_evasive

Also, see the Mod evasive page for important documentation about configuring the DOS protection system for Apache.

Web App Inventory

APPINV_CRON

Interval to run the web application inventory engine. Default is daily.

Plesk Security Settings

PSA_DISABLE_CRONTAB

This setting will disable the ability to manage cron jobs in Plesk.

Default: No. Which means that you can manage cron jobs in Plesk.