kernel: xt_lscan: Warning: Pure RST received
[edit]If you are using the ASL kernel
This means that the low level portscan detector in ASL has detected a RST packet from a source that does not appear to be associated with an active connection. This can happen for at least two know reasons:
- The connection is already torn down and the client is continuing to send RST packets to abort the connection, even though it no longer exists. This can occur with bugging IP stacks on clients.
- A system is attempting to port scan the system using RST packets to attempt to get the system to report what ports it has open or closed.
This feature in ASL is not enabled by default, and can be disabled in ASL via this setting:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOWLEVEL_PORTSCAN
ASL does not shun these types of connections. This messages is just informational.
[edit]If you are not using the ASL kernel
This means that the low level portscan detector in ASL has detected a RST packet from a source that does not appear to be associated with an active connection. This can happen for at least three known reasons:
- This could be a bug in the implementation of of the low level portscan detection kernel module. Please contact your kernel vendor before reporting this issue to us to rule out a kernel level bug.
- The connection is already torn down and the client is continuing to send RST packets to abort the connection, even though it no longer exists. This can occur with bugging IP stacks on clients.
- A system is attempting to port scan the system using RST packets to attempt to get the system to report what ports it has open or closed.
This feature in ASL is not enabled by default, and can be disabled in ASL via this setting:
https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_LOWLEVEL_PORTSCAN
ASL does not shun these types of connections. This messages is just informational.
[edit]FATAL: Module ip_set not found.
This means you are either using a third party kernel, or an older kernel that does not include the ip_set kernel module. Please ensure you are using the secure ASL kernel to use this feature, or contact your kernel vendor for assistance with this module.
Note: If you do not have this module your system will use the legacy iptables firewall system for large firewall sets, such as blacklists, geoblocking lists, RBLs and other large firewall lists.
[edit]/proc/sys/net/ipv6/conf/all/accept_redirects: No such file or directory
This means you are not using the ASL and your third party kernel is either very old, does not support IPv6, or does not understand how to disable redirects. Please contact your kernel vendor for assistance as this error is only caused by the use of third party kernels.
In general this harmless, it simply means that ASL can not disable redirects on your system.
[edit]What do the PAX alerts for software in /usr/libexec/paxtest mean?
These messages are benign, and you can ignore them.
Examples:
Example if you are running an ASL kernel:
PAX: execution attempt in: <anonymous mapping>, 53181000-53184000 53181000 PAX: terminating task: /usr/libexec/paxtest/anonmap(anonmap):1234, uid/euid: 0/0, PC: 53181000, SP: 23498723984 PAX: bytes at PC: c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PAX: bytes at SP-4: 12345465682347509817324059871340598734
You may also see messages such as this:
kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/libexec/paxtest/execheap[execheap:5854] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/paxtest/execheap[execheap:5853] uid/euid:0/0 gid/egid:0/0
Example if you are not running an ASL kernel:
kernel: anonmap[12345]: segfault at 00002aaaaaaab000 rip 00002aaaaaaab000 rsp 00007fff457153f8 error 15
Discussion
If you see these log messages for any of these programs:
/usr/libexec/paxtest/anonmap /usr/libexec/paxtest/execbss /usr/libexec/paxtest/execdata /usr/libexec/paxtest/execheap /usr/libexec/paxtest/execstack /usr/libexec/paxtest/mprotanon /usr/libexec/paxtest/mprotbss /usr/libexec/paxtest/mprotdata /usr/libexec/paxtest/mprotheap /usr/libexec/paxtest/mprotshbss /usr/libexec/paxtest/mprotshdata /usr/libexec/paxtest/mprotstack /usr/libexec/paxtest/shlibbss /usr/libexec/paxtest/shlibdata
These are caused as part of ASL's built in kernel vulnerability scanner. These messages in syslog are normal and harmless and you can ignore them. They mean the vulnerability scanner is working correctly. These messages do not cause any harm to the system, and are perfectly safe.
If you are running an ASL kernel you are immune to the vulnerabilities the scanner will test for and the "PAX:" messages indicate that ASL is working normally and safely.
If you are not running an ASL kernel you will not see the PAX: messages, which means you are vulnerable to some of these tests. The ASL GUI will report the specific vulnerabilities, you can also get a report from the command line by running this command as root:
asl -s
The solution to kernel level vulnerabilities is to run the ASL kernel. Standard Linux kernels are not immune to all kernel exploits and vulnerabilities.
[edit]Can I suppress these events so they are not logged?
No. These are generated by the kernel itself, and suppressing these events would mean that you wouldnt be notified of an actual attack on your system either. These messages mean that the kernel is working correctly, and this is an important part of the health management system in ASL.
[edit]kernel: ASL_INVALID_INPUT
This message simply means that a packet came in that the kernels firewall has detected as a packet not associated with a valid stateful connection. Most often this happens when a packet comes in "late" and the session is either already torn down, or the session has "moved past" this point and does not need this packet and the packet is out of sequence. These messages can generally be ignored, as they are simply the byproduct of the imperfect nature of IP.
Generally you will see them for cases where a session is shutting down:
Nov 28 19:11:44 host kernel: ASL_INVALID_INPUT IN=eth0 OUT= MAC=<snip> SRC=1.2.3.4 DST=5.6.7.8 LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=51535 DF PROTO=TCP SPT=59190 DPT=30000 WINDOW=0 RES=0x00 RST URGP=0
(this is a "reset" packet, telling the server the client is killing the session, but the session is already gone so the kernel doesnt need this packet)
You may see them for other cases, where a session got our of sync.
ASL can log these packets just in case something more serious is occurring, where an attacker is trying to trick the stateful firewall. You do not need to take any action if you see these messages, these just mean that the stateful firewall is ignoring these packets and if this were an attack, it is being blocked. You can also ignore this for legitimate connections, as ASL will not shun on these types of events. Non-malicious traffic is far too common, and we do not recommend you ever shun on these types of events.
[edit]denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0
The kernel is just reporting that an application tried to core dump, and that you have your system configured to prevent core dumps. When an application core dumps that means it died and its trying to record its state for debugging.
ASL does not configure or enforce this, its just reporting an event. Non-ASL kernels do not have the ability to report core dumps. This information can help you to debug a potential bug in an application, or it may indicate that someone is trying to compromise your system by crashing an application.
Please contact your OS vendor for instructions about how to allow applications to core dump if you want to analyze the core dump to see why the application died. We have also put together a courtesy wiki Apache article which explains how to configure your system to allow core dumps and how to analyze them for your system. Please contact your application vendor with specific questions about why a particular application may have died and generated a core dump.
[edit]denied resource overstep by requesting 12345 for RLIMIT_*
This means that your operating system has a limit configured for something, and your system has exceeded this limit.
ASL does not cause this, the ASL kernel also does not cause this. ASL neither sets nor enforce these limits, it just reports when the operating system has been configured with a limit, when the limit has been exceeded, and if the operating system has prevented an application from exceeding a limit.
Normal Linux kernels do not report when limits are exceeded. This special reporting capability in ASL makes sure you know when your operating system is enforcing one of these limits. With other kernels, you will have no notice that your OS has preventing something working because you have exceeded a limit on your operating system. However, regardless of what kernel you are using your operating system will still enforce whatever limits you have configured it to enforce, regular kernels just wont tell you that you have exceeded some limit configured in your OS.
Please contact your OS vendor for instructions about how to configure your systems limits. You may also need to contact your application vendor with specific questions about why a particular limit is inappropriate for your application, and what they recommend you set the limit to.
[edit]grsec: banning user with uid xx until system restart for suspicious kernel crash
This means a process did something very bad to the kernel and could be an attack on your system.
This message is generated via a special exploit protection feature in the ASL kernel. When a kernel protection alert is triggered due to highly suspicious activity in the kernel (from KERNEXEC/UDEREF/USERCOPY, not just any event) or an OOPs occurs due to bad memory accesses, instead of just terminating the offending process (and potentially allowing a subsequent exploit from the same user), the kernel will take one of two actions:
- If the user was root, this will lock out the system - if this is happening with root, very bad things are happening on the system.
- If the user was non-root, ASL will log the attempt, terminate all processes owned by the user, then prevent them from creating any new processes until the system is restarted.
This deters repeated kernel exploitation/bruteforcing attempts and is useful for later forensics.
[edit]kernel: grsec: chdir to
If you are using the ASL kernel, means that you have enabled this option in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#AUDIT_CHDIR
This option is not enabled by default, and we do not recommend you enable this option if you do not know what you are doing.
If you are using a third party kernel, please contact the vendor of that kernel for assistance. It is possible they have enabled this by default in their kernel. ASL does not enable this by default.
[edit]grsec: From xx.xxx.xxx.xxx: use of CAP_SYS_ADMIN in chroot denied
This means that an application within a chroot tried to use the SYS_ADMIN linux capability. This means the application is trying to do things that would allow the application to escape the chroot. Denying applications in a chroot this capability prevents them from escaping the chroot and prevents them from compromising the system. Allowing them to have this capability means that the chroot essentially does not exist, as the application can just request root level privileges it wants, and can simply move outside the chroot.
Allowing applications within a chroot to have this capability is extremely dangerous and should not be granted.
However, if you need to open this hole in your system please disable this protection in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#CHROOT_CAPS
WARNING: Disabling this protection will make it possible for applications to escape chroots. See this article for more information:
https://forums.grsecurity.net/viewtopic.php?f=7&t=2522
[edit]grsec: denied untrusted exec of /path/to/some/application
See below.
[edit]grsec: denied untrusted exec
The application is not being allowed to run because it is insecurely configured and ASL has been configured to prevent insecurely configured applications from running.
Specifically, ASL includes a feature called Trusted Path Execution or TPE for short. When Trusted Path Execution (TPE) is enabled (which is the default), it will only allow system applications owned by root to run on the system and only if they are not modifable by any other user except root. This creates a "trusted" set of software, and protects the system from malicious software, malicious uploads, and local attacks such as via web servers, including those that may change applications on the system or replace them with malicious versions. We do not recommend you disable TPE.
If you get this message, that means that either the application is owned by an untrusted user or its directories are writeable by untrusted users (who could then replace the software in that directory, even though they may not own it). This protection helps to prevent untrusted users from uploading malware, rootkits, shells and other malicious software to the system. This also prevents untrusted users from changing applications, replacing them with a trojan, mobidying systems paths or otherwise tampering with these. By default the only trusted user on the system is root. If you have an application (or an application in a directory) owned by an untrusted user TPE will not allow it to be executed. You can tune ASL or the application to allow it to run by using one of the four documented methods below. They are in order or most secure to least secure:
Option 1. Change the ownership of the file and its directory, and parent directories to root.root and make sure the file and directory it is in are not writable by other users (including the root group). Here is an example you will need to adapt to your system:
Note: If you do not know what is meant by changing a files ownership to root.root, please contact support and we will put a quote together to perform these services for you. root.root means the user and group must be root. These are example commands to achieve this:
chown root.root /path/to/directory/of/application chown root.root /path/to/application chown root.root /path/to/ chown root.root /path/ chroot root.root / chmod -R og-w /path/to/application
Always make sure the parent directories are also owned by root:root. This is the most common issue, some broken applications are known to change key operating systems directories ownership from root:root to something else. We've even seen cases where someone changed the ownership of / to something other than root. Thats extremely dangerous and something else thankfully will protect the system from.
For example, here is an application that will not run with TPE in the fully secure mode because the directory is not set to root.root nor is the application:
drwxrws--- 2 psaadm swkey-data 4096 May 8 02:32 restart -r-s--x--- 1 root swkey-data 9240 May 4 05:58 plesk-key-handler
In this example, the directory is owned by psaadm and swkey-data. These are not set to the root user, so the kernel in the fully secure TPE mode will will not trust this application to run because those users could modify, replace or otherwise tamper with this application and are not trusted by the kernel. To get these applications to run (and you will need to discuss this with your application vendor if the application can run in such a secure manner) the directory and application would need to be owned by the root user and the root group, and must be writable only by the root user (not the root group).
If you can not set an application to run correct as root.root, then you need to configure ASL into a less secure mode. This also means that you will need to accept the risk of running your application and system in a less secure and protected mode. To do this, simply configure ASL to be less secure using options 2-4. This situation is rare, and only a few vendors seems inclined to run their applications in this less secure manner.
In some cases, you can work around this by moving the application to a trusted directory and making sure the directory it is in is owned by root.root. For example, for a setuid script owned by "testuser":
[testuser2@ac2 ~]$ pwd /home/testuser2 [testuser2@ac2 ~]$ id uid=510(testuser2) gid=510(testuser2) groups=510(testuser2) [testuser2@ac2 ~]$ cat ~testuser/sensitive_file cat: /home/testuser/sensitive_file: Permission denied [testuser2@ac2 ~]$ /usr/local/trusted_apps/special_cat ~testuser/sensitive_file This data can only be read by setuid [testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/special_cat -rwsr-xr-x 1 testuser testuser 23132 Dec 17 19:45 /usr/local/trusted_apps/special_cat
As you can see from this example, there is a setuid program called special_cat (its a copy of /bin/cat in this example) that is setuid to testuser. testuser2 tried to open the file ~testuser/sensitive_file with "cat", but can not because testuser2 must use the setuid program "/usr/local/trusted_apps/special_cat" to read those files.
The key to making this work with the secure ASL kernel is to ensure that the directory in which the application is place must be owned by root.root, and the application itself can still be owned by the untrusted user "testuser":
[testuser2@ac2 ~]$ ls -al /usr/local/trusted_apps/ total 36 drwxr-xr-x 2 root root 4096 Dec 17 19:53 . drwxr-xr-x 12 root root 4096 Dec 17 19:53 .. -rwsr-xr-x 1 testuser testuser 23132 Dec 17 19:45 special_cat
This helps prevent malicious users from uploading programs to the system that you do not want because nothing can be added to that directory except by root. This also helps to prevent users from running programs you don't trust in ways that can compromise the security of your system, such as with spam bots or tools to compromise your system such as malware. The key is to make sure no one can modify the file except the user that owns it, and that the file is in a directory that only root can modify or place new files in. This helps to prevent path poisoning attacks and uploading of malicious software to your system.
Again, if you do understand how to do any of these tasks, please contact a qualified systems administrator to do this for you.
Option 2: Change ASLs behavior so that this restriction only applies to untrusted users. You can do that by turning off this feature, called Trusted PAth Exectuion (TPE) so that it only applies to users in the "untrusted" group:
echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all
Keep in mind that this is considerably less secure than option 1. This means all the users on your system, except users in the "untrusted" group, will be trusted unless you specifically tell ASL not to trust them. You can see a listing of untrusted users by looking at this option in ASL:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#TPE_UNTRUSTED_USERS
Our by running this command as root:
grep untrusted /etc/group
The standard list of untrusted users currently is:
lp,sync,shutdown,halt,mail,news,uucp,operator,games,gopher,ftp,nobody,vcsa,nscd,sshd,rpc,rpcuser,nfsnobody,mailnull,smmsp,pcap,apache,xfs,ntp,mysql,webalizer,named,alias,qmaild,qmaill,qmailp,qmailq,qmailr,qmails,popuser,psaadm,psaftp,mailman
These are system users, that is users that programs run as. These users normally run programs run as root, and not as programs owned by themselves.
NOTE: You can only change this proc setting (/proc/sys/kernel/grsecurity/tpe_restrict_all) on boot if you have configured ASL to lock the kernel (the default setting is to lock the kernel). Once the boot process reaches stage S99 the kernel is locked and you can not change the security settings. So you will need to set this on boot via a custom init script.
If you want to set an ASL kernel setting, such as /proc/sys/kernel/grsecurity/tpe_restrict_all (or any other), you will need to create a custom init script such as:
/etc/init.d/asl-custom
A simple script to do this would look like
#!/bin/bash echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all
Then you will need to link it depending on the runlevel your system is set as. If you do not know what this means, please consult an experienced Linux administrator. Most systems are set to run at run level 3.
ln -s /etc/init.d/asl-custom /etc/rc3.d/S98asl-custom
init is not part of ASL, its part of your operating system, and if you have additional questions about how to configure your operating system or how to write init scripts please contact your operating system vendor. You can read our primer on customizing your kernel in the Installing custom kernel modules with ASL wiki article. This includes a primer on init.
And last but not least, you need to set the script to be executable in Linux. To do that, as root, you need to run this command:
chmod u+x /etc/init.d/asl-custom
Option 3. Remove the user from the untrusted group in /etc/group (we do not recommend you do this).
If your application is running as an untrusted user, you can change the configuration of ASL to trust this user. The default users are system processes such as apache that should NEVER be trusted by the system. This makes it easy for an attacker to upload a trojan to the system. However, if you must run an application in insecure manner as apache then you would remove that user from this group. ASL will not be able to protect the system from uploaded trojan by this user.
Option 4: Turn off all TPE protections (not recommended and very insecure)
This option completely disables the TPE system and makes it possible for any user to upload anything and run it on the system. Although ASL does have real time malware detection and protection this system is not 100% foolproof and disabling TPE is extremely insecure and will make it possible for an attacker to upload malicious code to your system that even ASL may not be able to detect and then run it.
To disable TPE either change this setting in the ASL gui:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ENABLE_TPE
And reboot the machine, or change this proc setting:
/proc/sys/kernel/grsecurity/tpe
To "0"
echo 0 > /proc/sys/kernel/grsecurity/tpe
This also must be done on boot as with option 3.
If you are unsure of how to do any of these custom things on your system please contact us. Our professional services team would be happy to help you configure your custom applications for your system.
[edit]GRsecurity ACL database: not found [INFO]
This simply means you do not have any GRSEC rules set. This is just an information alert and does not mean anything is wrong with your system.
[edit]execution attempt in: <anonymous mapping>
Log example:
Jan 1 12:00:54 hostname kernel: grsec: From 1.2.3.4: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /opt/cpanel/ea-php70/root/usr/bin/lsphp[lsphp:11604] uid/euid:1001/1001 gid/egid:1000/1000, parent /usr/local/lsws/bin/lshttpd.5.0.18[litespeed:11405] uid/euid:99/99 gid/egid:99/99 Jan 1 12:00:54 hostname kernel: PAX: execution attempt in: <anonymous mapping>, 353513ab000-35351426000 353513ab000 Jan 1 12:00:54 hostname kernel: PAX: terminating task: /opt/cpanel/ea-php70/root/usr/bin/lsphp(lsphp):11605, uid/euid: 1001/1001, PC: 00000353513ab010, SP: 000003c83294db38 Jan 1 12:00:54 hostname kernel: PAX: bytes at PC: 41 54 41 55 41 56 41 57 53 48 8b df 48 83 ec 50 48 8b 43 10
This means this program is attempting to either perform a dangerous operation that could cause your system to be compromised, or someone is trying to break into your system and the ASL kernel is preventing this program from being used to compromise your system. This may also occur with malicious applications, applications that are misconfigured such as PHP, or applications that do things in a dangerous way. You can read more about this kernel protection capability in this article:
http://pax.grsecurity.net/docs/mprotect.txt
[edit]solutions
1) Most Secure
Report this to your vendor that they need to fix the application so it does not need to open this hole in your system. Modern software shouldnt need to do this.
2) Secure
In some cases it may be possible to tell the application to not try to open this hole in your system. As root, run this command:
execstack -c /path/to/application_or_library
Example:
execstack -c /opt/cpanel/ea-php70/root/usr/bin/lsphp
If this does not work, your application may require that this hole be opened in the system. Therefore see Option 3 below.
Note: If you update the application, this option may be removed when the software is updated by your vendor and you may need to remove this insecure configuration again.
3) Very Insecure
Warning: Always confirm with your application vendor if this is actually normal and necessary for your application before you make this change! Some vendors simply open these holes in your system because they do not know better. PHP for example does not need to open this hole in your system.
Note: Turning off this protection for your application will make it vulnerable to attacks which can result in the compromise of the application, and potentially access to your system. Modern applications should not need to open this hole in your system.
To allow an application to open this hole in your system, run this command as root:
paxctl -m /path/to/application_or_library
Example:
paxctl -m /opt/cpanel/ea-php70/root/usr/bin/lsphp
If you get this message when you run that command:
does not have a PT_PAX_FLAGS program header, try conversion
Please see the FAQ below:
Then run the command:
paxctl -m /path/to/application_or_library
Note: See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Note_on_vulnerable_libraries for guidance on finding vulnerable libraries that attempt to open this hole in your system.
[edit]denied RWX mmap of
Note: Java may require you to open other holes in your system, for other applications keep reading this article. If you are attempting to fix Java, please see this article instead:
https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Java_is_stopped_by_PAX
This means this program is attempting to either perform a dangerous operation, that could cause your system to be compromised, or someone is trying to break into your system and the ASL kernel is preventing this program from doing this.
This may also occur with malicious applications, or applications that do things in a dangerous way. You can read more about this kernel protection capability in this article:
http://pax.grsecurity.net/docs/mprotect.txt
[edit]solutions
1) Most Secure
Report this to your vendor that they need to fix the application so it does not need to open this hole in your system. Modern software shouldnt need to do this.
2) Secure
In some cases it may be possible to tell the application to not try to open this hole in your system. As root, run this command:
execstack -c /path/to/application_or_library
Example:
execstack -c /opt/dell/srvadmin/sbin/dsm_om_connsvcd
If this does not work, your application may require that this hole be opened in the system. Therefore see Option 3 below.
If you continue to get this message for that application:
denied RWX mmap of
Option 2 will not work for you, please see Option 3 below.
Note: If you update the application, this option may be removed when the software is updated by your vendor and you may need to remove this insecure option again.
3) Very Insecure
Warning: Always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious backdoored copy!
Note: Turning off this protection for your application will make it vulnerable to stack, heap and other types of overflow attacks which can result in the compromise of the application, and potentially access to your system. If this application is running as root, then this can open your system to a full root compromise. Modern applications should not need to open this hole in your system.
To allow an application to open this hole in your system, run this command as root:
paxctl -m /path/to/application_or_library
Example:
paxctl -m /opt/dell/srvadmin/sbin/dsm_om_connsvcd
If you get this message when you run that command:
does not have a PT_PAX_FLAGS program header, try conversion
Please see the FAQ below:
Then run the command:
paxctl -m /path/to/application_or_library
Note: See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#Note_on_vulnerable_libraries for guidance on finding vulnerable libraries that attempt to open this hole in your system.
[edit]does not have a PT_PAX_FLAGS program header, try conversion
Run this command to set a PT_PAX_FLAGS header on your application:
/sbin/paxctl -c /path/to/your/application
Then run whatever command you were trying to run with paxctl.
[edit]mprotect(): 13 (Permission denied)
Examples:
01:01:01 host kernel: grsec: From 1.2.3.4: denied RWX mprotect of /lib64/ld-2.5.so by /usr/local/cpanel/3rdparty/php/53/bin/php-cgi[php-cgi:25915] uid/euid:32003/32003 gid/egid:32003/32003, parent /usr/local/cpanel/cpsrvd-ssl[cpsrvd-ssl:25913] uid/euid:32003/32003 gid/egid:32003/32003
[edit]discussion
This means an application is trying to do something dangerous on your system. Specifically, the ASL kernel protects your system by restricting the mprotect() system call which makes it difficult for an attacker to bypass stack protection systems. This makes it impossible for an attacker to change protection of a specific memory region, for example to mark it as executable if it wasn't originally executable, or to create a new writeable and executable memory mapping using the mmap() call. Without this feature, all the "Stack Protection and "non-executable memory regions" security features used today are more or less useless, as the attacker just change the permissions on your Stack protection to allow them to compromise the system. Unlike other systems, ASL protects you from this vulnerability.
This protection in the ASL kernel is critical to making stack protection meaningful. Therefore, if encounter this message, the application has been stopped from doing something very dangerous to your system. It may not be trying to compromise it, but it is making it much easier for an attacker to compromise your system in the future if it were allowed to do this. Therefore, you should carefully consider if you want to allow an application to do this. If you allow an application to do this you are opening your system to stack and heap based attacks through that application.
It is important then to ensure that your your application absolutely needs this capability, and that if it does and you want to allow it that you can trust the application, and that you are certain that the application is not going to be used by an attacker to compromise your system.
Applications that work with untrusted data, such as scanners and servers shouldn't be allowed to do this unless you know that they have no other vulnerabilities associated with this issue.
[edit]solutions
1) Most Secure
Fix the application so it does not need to open this hole in your system.
2) Secure
Remove the flag from the library that is trying to open this hole in your system. As root, run this command:
execstack -c /path/to/application_or_library
3) Very Insecure
Warning: Always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious copy.
To allow an application to open this hole in your system, run this command as root:
paxctl -m /path/to/application_or_library
[edit]Note on vulnerable libraries
In some cases, such as with PHP, you may need to use strace to find the specific library that is opening this hole in your system as your application may not be trying to open this hole in your system. You can do this by running this command as root:
strace -fF /path/to/app
Example:
strace -fF /usr/local/cpanel/3rdparty/php/53/bin/php-cgi
Will produce a very verbose output as strace tells your what the application is doing. Once the application is prevented from opening this hole in your system it will stop running. Therefore, you want to look at the final output of the strace, which in the case of the example above will look similar to this:
open("/usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\33\3\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1082328, ...}) = 0
mmap(NULL, 2145168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x6ad6faf57000
mprotect(0x6ad6fb042000, 1048576, PROT_NONE) = 0
mmap(0x6ad6fb142000, 118784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xeb000) = 0x6ad6fb142000
mmap(0x6ad6fb15f000, 15248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6ad6fb15f000
mprotect(0x6ad7081c1000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)
Whats important to note is that the library "/usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so" is trying to open a hole in tje system and ASL is stopping it:
mprotect(0x6ad7081c1000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)
In some cases this may be a root level hole which will cause the entire system to be compromised.
To prevent the application from opening this hole in your system, run this command as root:
execstack -c /usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so
To allow it to open this hole in your system you will need to tell ASL to let this application make your system vulnerable to a compromise via this hole for this application or library. We do not recommend you open this hole. Its rare that an application needs to do this, so we recommend you close it, and then test your application to see if it works properly. If it does work properly you do not need this hole opened in your system.
Warning: Before you allow an application to open this hole, always confirm with your application vendor if this is actually normal for your application before you make this change! In many cases its been found that backdoored malicious versions of software will attempt to perform these dangerous operations, and disabling this will allow them to operate. This may be warning you that your software has been replaced by a malicious copy.
paxctl -m /usr/local/cpanel/3rdparty/php/53/zendopt/ZendGuardLoader.so
[edit]grsec: denied RWX mprotect
If you see log messages that involve the ASL paxtest application suite, for example:
grsec: denied RWX mprotect of /usr/libexec/paxtest/shlibtest2.so
This is harmless, please see this FAQ:
For all other applications, please continue reading:
If you see log message like this:
Jan 1 12:00:00 server kernel: grsec: denied RWX mprotect of /lib64/ld-2.12.so by /usr/local/cpanel/3rdparty/php/53/bin/php-cgi[php-cgi:3726] uid/euid:0/0 gid/egid:0/0, parent /usr/local/cpanel/bin/admin/Cpanel/logaholic[logaholic:3715] uid/euid:0/0 gid/egid:0/0
This means an application is trying to do something dangerous on your system, and ASL is preventing it from doing this. This could be an attempt to compromise your system or simply a very vulnerable or poorly constructed application thats operating in a dangerously insecure manner, which would allow users to do bad things to your system including compromising it. You should report this as a vulnerability to the application developer.
If you want to allow this application to do this dangerous thing on your system, you can configure ASL to allow this. Continue reading if you wish to open this hole ASL is alerting you to:
Explanation
Specifically, ASL protects you system by restricting the mprotect() system call which makes it difficult for an attacker to bypass kernel stack protection systems used on Linux systems. Normal Linux kernels do not protect against this, so its trivially easy to beat the stack protection systems they use, and attackers know this.
This protection makes it impossible for an attacker to change protection of a specific memory region, for example to mark it as executable if it wasn't originally executable, or to create a new writeable and executable memory mapping using the mmap() call. Without this feature, all the "Stack Protection and "non-executable memory regions" security features used today are more or less useless, as the attacker can just change the permissions on your Stack protection to allow them to compromise the system. Unlike other systems, ASL protects you from this critical vulnerability.
This protection in the ASL kernel is critical to making stack protection meaningful. Therefore, if you encounter this message, the application has been stopped from doing something very dangerous to your system. It may not be trying to compromise it, but it is making it much easier for an attacker to compromise your system in the future if it were allowed to do this. Therefore, you should carefully consider if you want to allow an application to do this. If you allow an application to do this you are opening your system to stack and heap based attacks through that application and no amount of kernel protection will protect you. It is also not necessary for applications to do this with modern programming techniques, and is rarely seen and never with properly developed applications.
It is important then to ensure that your your application absolutely needs this capability before you open this hole in your system. If it does and you want to allow iit do this, this means that you are completely trusting the application, and you should only do this if you know the application can never be used to compromise your system.
Applications that work with untrusted data, such as log processing tools, data scanners (virus and antispam) and application daemons should never be allowed to do this.
[edit]solutions
See the article https://www.atomicorp.com/wiki/index.php/ASL_error_messages#solutions_2 above.
[edit]kernel: grsec: From x.x.x.x: denied ptrace of
The ASL kernel includes countermeasures to prevent ptrace exploitation. It has always had this capability as part of the RBAC system. In newer versions of ASL a capability has been added to make this protection global so that you do not have enable, or develop policies for the RBAC system. Some rare applications may need to perform ptrace operations that will trigger this protection, exploits can also trigger this so its best to investigate if this behaviour is normal.
Solution:
First ensure that this behaviour is expected and non-malicious for your application. If your application must do this, you will need to disable global ptrace protection. To do this, you will need to set this condition as part of your /etc/sysctl.conf file:
kernel.grsecurity.harden_ptrace = 0
ASL normally locks all grsecurity settings so they can not be reset during runtime, unless you have disabled this safeguard (not recommended, this makes it possible for an attacker to disable all your ASL kernel security settings) you will also need to reboot the system for this change to take effect. sysctl will not change grsecurity kernel settings if the kernel is in its secure and default state.
If you still wish to restrict ptrace capabilities, but wish to only allow it for your application, you will need to enable the RBAC system and configure a policy for your system. this is an advanced task, and will require tuning the policy for your unique system and needs. ASL can auto-generate a complete starter policy for the system, but you must configure it manually to meet your needs as ASL will develop a least privilege policy for the entire system. This means that during the learning period you define only the behavior that occurs during that period will be allowed. This has the added advantage of being very easy to develop a very secure policy for the system, and the disadvantage of creating a very secure policy for the system. In practice, you will want to further tune the policy based on your needs, as the policy generate will be least privilege for every aspect of the system. For further information about the self learning RBAC, please see this article
NOTE: Plesk requires that this protection be disabled. Please contact Parallels for a full explanation for why that product requires this protection to be disabled.
[edit]kernel: grsec: denied ptrace of /usr/bin/sw-engine-cgi
Parallels tries to prevent users from debugging certain Parallels products. It does this by trying to ptrace itself to detect a debugger. The ASL kernel contains protections to prevent ptrace exploits, and controls which users can use this function call. The kernel will block this function, and the Parallels products does not correctly catch this condition, and instead erroneously reports this as the user running a debugger. This is a bug in Parallels products.
If you are using a version of Plesk that has this bug, and there is no fix available from Parallels for this bug, please follow this process to disable this protection on your system.
Note: This workaround is for those users that want to run Parallels products with this bug. This will require you to disable this protection in your kernel. This will be correctly reported as a vulnerability in the system.
To disable ptrace exploitation protection:
When running ASL 3.0 and up simply log into ASL, click on the Configuration tab, and select the "ASL Configuration" menu option.
Then scroll down to Kernel
And change the "HARDEN_PTRACE" entry from "yes" to "no". If you kernel is set to lock itself on boot (this is the default), you will need to reboot your system for this setting to take effect.
If you are not running ASL 3.0, please add this to your/etc/sysctl.conf file:
kernel.grsecurity.harden_ptrace = 0
And reboot the system.
[edit]grsec: process /usr/bin/foo attached to via ptrace by
This is an informational message and can be ignored. ASL will log ptrace activity to help you detect any potentially malicious ptrace actions. To disable this logging run this command as root:
echo 0 > /proc/sys/kernel/grsecurity/audit_ptrace
You will need to set this to occur on boot, or add this to your/etc/sysctl.conf file:
kernel.grsecurity.audit_ptrace = 0
And reboot.
[edit]error: unknown error 22 setting key
When running sysctl -p this error occurs:
error: unknown error 22 setting key 'some.sysctl.setting'
Explanation:
By default the ASL kernel doesn't allow allow certain security parameters in the kernel to be modified. This prevents attackers from disabling kernel protections, such as stack protections and allowing the kernel to be modified on the fly. If you wish to modify these security settings, there are two options:
1) Set these security kernel settings and reboot the system.
2) Configure ASL to allow your kernel to be modified at any time.
This is NOT recommended. Allowing kernel security settings to be changed on a running system makes it possible for an attacker to disable ASL kernel level protections, to install rootkits and to otherwise compromise the security of the system. This is similar to allowing a user to disable antivirus on the system, if a user can disable antivirus so can a virus. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this as occurred. We highly recommend you set any kernel security settings you need, reboot the system and let ASL lock the kernel.
If you wish to use to make your kernel insecure and to allow these security settings to change on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.
[edit]modprobe: FATAL: Could not load /path/to/module No such file or directory
If you are not using the ASL kernel:
Report this error to your kernel vendor. This error is not caused by ASL. ASL is just alerting you to a problem with your third party kernel. It means your third party kernel is does not have a component your system needs.
If you are using the ASL kernel:
This means someone or something removed parts of the ASL kernel. ASL will not remove the kernel or any of its components.
To fix this, you will want to make sure you reinstall the ASL kernel. Please see the kernel article for additional assistance or contact support if you are unable to reinstall your kernel.
[edit]insmod: error inserting /path/to/module -1 Operation not permitted
See the below FAQ below.
[edit]modprobe: FATAL: Error inserting somemodule (/path/to/module.ko): Operation not permitted
[edit]If you are using the ASL kernel
Discussion
By default the ASL kernel will prevent the loading of new kernel modules into the kernel, during runtime, once the system has booted up. It will allow kernel modules to be loaded during boot, but once your system has finished the boot up process, when ASL will allow you to load kernel modules, ASL will then lock the kernel preventing any new kernel modules from being loaded into the kernel. This is to protect the kernel from kernel level rootkits, as it prevents hackers from modifying your kernel and hiding rootkits and malware on your system. Runtime kernel module loading is very dangerous, isnt something most users need, and its extremely unusual to require on a server. We do not recommend you disable this protection.
Solutions
You have two options if you are using this protection. These are listed in order of secure to insecure.
1) (Secure Option) Set the modules to load at boot and reboot your system.
This article: Installing custom kernel modules with ASL provides more information about setting up custom modules to load before ASL locks the kernel down.
2) (Insecure Option) Configure ASL to allow your kernel to be modified at any time.
This is NOT recommended.
Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this has occurred or to remove the rootkit. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if kernel module loading is prevented at runtime.
If you wish to configure your kernel to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.
[edit]If you are not using the ASL kernel
If you are using a third party kernel (that is not the ASL kernel), then this information is provided as a courtesy. Please contact your kernel vendor for support with this issue.
Solution 1)
This error generally occurs if the system was not rebooted after ASL was installed or if the third party kernel prevents kernel module loading.
Make sure this setting:
https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ALLOW_kmod_loading
Is set to yes, then reboot the system.
Solution 2)
Some third party kernels include an option to prevent kernel modules from being loaded. To disable this run this command as root:
echo 0 > /proc/sys/kernel/modules_disabled
If this does not work, this means your kernel makes this option immutable. Try solution 1, if Solution 1 did not work, move on to Solution 3.
Solution 3)
Add this line:
kernel.modules_disabled=0
To this file:
/etc/sysctl.conf
And reboot the system.
If none of these options work, please contact your kernel vendor for assistance.
[edit]Warning: cannot open /proc/net/dev
Question:
Unprivileged users can not open the full proc table, and when I tun top or when I run ifconfig I do not see all the information.
Answer:
ASL contains additional safeguards to prevent non-privileged users from reading the full proc table. If you wish to allow a user to see the full proc table, simply add the user to the "procread" group in your /etc/group file and this safeguard will be disabled for that user.
If you do not know how to add users to a group in Linux, or how to edit your /etc/group file, please contact your OS vendor for assistance.
[edit]
Examples:
error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied
grsec: From 1.2.3.4: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/NX/lib/libnxcim.so by /usr/NX/bin/nxserver.bin[nxserver.bin:4626] uid/euid:495/495 gid/egid:10038/10038, parent /usr/sbin/sshd[sshd:4622] uid/euid:495/495 gid/egid:10038/10038
This means that you have an application installed with a serious vulnerability. The Secure ASL kernel is preventing this application from opening a hole in your system.
Some application developers may configured their applications insecure to use what is referred to as an "executable stack". An executable stack allows an attacker to inject raw code into your system, bypassing your operating systems entire security model. This is a well known and widely used method of compromising systems completely.
Configuring an application in this manner dangerously opens your system to full compromise. Very few, if any applications actually require this insecure state to operate, and often times configuring applications in this manner is done by the application developer in error. You can reconfigure these applications to not do this by following the process below.
The ASL kernel protects you from this dangerous mistake by not allowing these applications to configure your system into this extremely insecure condition.
There are three options for dealing with this critical vulnerability, from most secure to least secure:
Option 1: (Most secure option)
ASL will not allow these applications to punch holes in your system, and running the command below will remove that label from the application so it will run properly and securely.
execstack -c /path/to/application
Sometimes vendors will do this to the libraries the application uses, and not the binary calling it. If you see a log message with a ".so" in it, that indicates a library has been insecurely configured by your vendor. Here is an example:
'error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied'
In which case you may have to remove this vulnerablity from the library itself. You can do this by using the "execstack" comannd and the "-c" switch, which stands for "clear". This command will remove the setting, or clear it, from the application that is causing this critical vulnerability. For example:
execstack -c /opt/splunk/lib/libcrypto.so.0.9.8
If you aren't sure which binary or library has the stack execute bit set, you can run this command to query the file:
execstack -q /opt/splunk/lib/libcrypto.so.0.9.8
If you see this:
- /lib/libcrypto.so.0.9.8e
The "-" means that file is safe, and does not have the stack execute bit set, in which case the binary calling the library is the likely culprit and you would want to query that file and remove the flag from it.
If you see this:
X /opt/splunk/lib/libcrypto.so.0.9.8
The X means stack execution is allowed, which also means X marks the spot for attacking your stack - which ASL will not allow. To close the vulnerability in the above example, remove the stack execute flag from the library by running this command as root:
execstack -c /opt/splunk/lib/libcrypto.so.0.9.8
We also recommend you contact your application vendor and ask them to remove these flags from their applications. They are not necessary with modern Linux kernels, and are bad and unsafe practices which will expose your system to compromise if you are not running ASL. If you are running ASL, you will need to reconfigure these applications per the instructions here.
Option 2:
Some applications require this vulnerable condition during installation. If you are unfortunate enough to have one of those applications, and the application vendor is not willing to fix their application, reboot the system into a non-secure kernel (a non ASL kernel) and install your application. Then reboot the system into the ASL kernel and follow the instructions in Option 1 to fix the vulnerable applications.
Option 3: (Insecure option)
We do not recommend you use this option.
It is possible to disable all stack protection in the ASL kernel so that it will not be enforced by default and only on executables marked explicitly. No executables are marked in this manner by ASL by default, as by default ASL automatically protects all executables. If you wish to use this option you will need to mark the executables you wish to protect.
Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various kernel protection features at runtime via the entries in /proc/sys/kernel/pax.
[edit]iptables: Unknown error 18446744073709551615
Issue:
iptables: Unknown error 18446744073709551615
Solution:
This error is not caused by ASL. There are two causes to this, one is an out of date version of iptables that is not fully compatible with your kernel. Your solution is to upgrade iptables to at least version 1.4.7.
The other cause for this error is that an iptables module is not loaded into the kernel, or that the module is no longer part of netfilter. Netfilter is the actual firewall in Linux and it does change. Older firewall scripts may require modules that no longer exist in Linux. iptables is just the command line tool that interacts with Netfilter. If you get an iptables error such as this one that means iptables tried to do something that netfilter either does allow or does not understand (you dont have that module loaded). On VPSs this can occur if the host kernel does not have the module loaded as VPSs do not control the kernel and therefore can not load any additional iptables modules dynamically.
The solution is to find out what module is missing. Unfortunately iptables won't tell you what module it may need, so we recommend you contact the party that created your firewall script or tool for assistance.
[edit]iptables: Unloading modules: iptable_mangle iptable_nat [FAILED]
When using the secure kernel in the default and secure mode, modifications to the kernel are not allowed. This includes loading and unloading modules.
This error is benign and you can ignore this.
[edit]FATAL: Module xt_lscan not found.
This means you are not using the secure ASL kernel and your third party kernel does not include the lowlevel portscan detection kernel module. Please contact your kernel vendor for assistance, this is not caused by ASL.
Please use the ASL kernel to resolve this issue, or contact your kernel vendor and ask them to include this Linux kernel module.
[edit]FATAL: Module xt_psd not found.
This means you are not using the secure ASL kernel and your third party kernel does not include the portscan detection kernel module. Please contact your kernel vendor for assistance, this is not caused by ASL.
Please use the ASL kernel to resolve this issue, or contact your kernel vendor and ask them to include this Linux kernel module.
[edit]iptables: Unloading modules: iptable_raw iptable_mangle ip[FAILED]
See the above FAQ:
[edit]kernel: ASL Active Response
This is a normal message that ASL will log if an IP addressed has been shunned, or firewalled off by ASL. This will occur if you have configured ASL's Active Response to "yes", and an event is triggered that exceeds the minimum event level threshold you have configured. Once that occurs ASL will log if any additional network traffic comes from that host, and it will limit this to one log message per minute for that IP address to prevent flooding of the systems logs.
[edit]grsec: denied kernel module auto-load of net-pf-10
Thats not an error, that means something on your system is trying to enable IPv6, you have IPv6 disabled on boot and ASL is configured to prevent modifications to the kernel after boot. By default the ASL kernel doesn't allow loading kernel modules at runtime to protect the system from kernel level rootkits. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system.
4 options to resolve this in order of most secure to least secure:
1) Ignore the message - it is harmless and no harm will come to your system from this message
2) If you do not want to enable IPv6, find the application and disable whatever in the application is trying to enable IPv6 dynamically
3) Enable IPv6
4) Configure ASL to allow your kernel to be modified at any time.
Options 2 and 3 you will need to discuss with your OS vendor, those are not part of ASL and are not supported by us.
Option 4, this option is NOT recommended. Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect, remove and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you to even detect that this as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.
If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this as critical vulnerability in the system.
[edit]kernel: grsec: denied resource overstep by requesting
The kernel is reporting that you have configured your system to deny a resource change in an application. The ASL kernel does not cause this, it just reports it. A non-ASL kernel, such as the default kernel used in most versions of Linux, does not have the ability to report when this occurs (the application just silently fails without any log message).
[edit]denied modification of module state
This means that you have configured ASL to protect your kernel from any changes. This is the default setting for ASL, and prevents attackers from inserting malicious code into your kernel. Dynamic modifications to running kernels are dangerous, and many operating system prevent this now (such as 64 bit Windows, and Windows Server.). If you wish to open this hole in your system please see the article #Can't install kernel modules.
[edit]denied use of iopl() by
ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by logging into the ASL GUI, click on the Configuration tab, then select ASL configuration. Scroll down to DISABLE_PRIVILEGED_IO and set this to "no". Then press the update button.
If ASL is configured to prevent changes to the kernel during run time, that is the setting ALLOW_kmod_loading is set to no (this is the default, and recommended setting), then you will need to reboot the system for this change to be applied to the system. We do not recommend you change ALLOW_kmod_loading to yes, that will open your system up to kernel level rootkits.
Or you can appending this to /etc/sysctl.conf
kernel.grsecurity.disable_priv_io = 0
And reboot your system.
[edit]grsec: denied open of /dev/port
ASL protects your system from compromise by disabling certain functions in the kernel that could be used to bypass the normal security protocols in a Linux kernel. If you get this message, it means either someone is trying to compromise your system, or if you know this is normal behavior for a trusted application that it needs privileged I/O access. You can disable this protection by changing the kernel level option "disable_priv_io" from 1 to 0. You can do this by appending this to /etc/sysctl.conf, and rebooting your system:
kernel.grsecurity.disable_priv_io = 0
[edit]mysql errors/messages
[edit]
This means that a third product, that does not use modern software management techniques, such as package or dependency management, has removed key mysql libraries from your system. ASL can not and will not do this, and your operating system will also help to prevent this from occurring. If this has happened to your system, that means you have some software package on your system that has a serious bug or simply does not use modern software management techniques common to all Linux software. We recommend you report this serious bug to the software vendor that caused this to occur to your system. ASL can not, and will not do this to your system.
To fix your operating system you will need to reinstall these libraries. The following command, when run as the root user, may resolve this issue, however this error means that a third product has broken your system and its possible this third party software may have broken other parts of your OS:
RHEL / Centos 5:
yum --disableexcludes=all reinstall mysqlclient15
RHEL / Centos 6:
yum --disableexcludes=all reinstall mysqlclient16
[edit]Failed to connect to database '(2002) Connection timed out
See the article "Can't connect to MySQL server on '127.0.0.1'" below.
[edit]FATAL init Could not establish mysql connection
See the article "Can't connect to MySQL server on '127.0.0.1'" below.
[edit]Can't connect to MySQL server on '127.0.0.1'
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)
This means that OSSEC can not connect to mysql on your system. OSSEC, a component in ASL, uses TCP to connect to your mysql server. A number of different things may be the root cause of this error. This checklist provides solutions to the most common causes.
Step 1. Check to make sure mysql is running, and that its listening on IP address 127.0.0.1.
To check if mysql is running, run this command as root:
ps auxwww | grep mysql
You should see a similar result to this:
root 17813 0.0 0.0 65988 852 ? S Mar19 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql mysql 17930 0.5 6.5 551972 264788 ? Sl Mar19 116:55 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
If you do not see a result similar to this, mysql is not running on your system. Start mysql. If you require assistance with mysql, please contact your Operating System or database vendor. If you have neither, please post in the community support section of our forums.
Also check to make sure mysql is listening on TCP port 3306 and IP address 127.0.0.1:
netstat -anp | grep 3306
A correctly configured mysql will look similar to this:
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5543/mysqld
Or this:
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 5543/mysqld
If you do not see either 0.0.0.0 or 127.0.0.1 in the fourth column then you may have mysql configured to listen on a specific IP address. You have two choices:
Option A) Configure mysql to listen on all addressed
Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:
/etc/init.d/mysqld restart
Option B) Configure ASL to connect to mysql on a different IP address
Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.
Step 2. Make sure you dont have "skip-networking" in you /etc/my.cnf file.
Check for the line "skip-networking" in your /etc/my.cnf file:
grep skip-networking /etc/my.cnf
If you have this line, remove that line from /etc/my.cnf and save the file.
Restart mysql and restart OSSEC. Run these commands as root:
/etc/init.d/mysqld restart
/etc/init.d/ossec-hids restart
Check to make sure mysql is listening:
netstat -anp | grep 3306
A correctly configured mysql will look similar to this:
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5543/mysqld
Or this:
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 5543/mysqld
If you do not see "tcp" in the first column, and LISTEN in the fifth mysql is not configured to listen for TCP connections.
If you only see any entry like this:
unix 2 [ ACC ] STREAM LISTENING 38593710 /var/lib/mysql/mysql.sock
mysql is not configured to listen on a TCP port.
Step 3: check to make sure mysql is listening on port 3306 and IP address 127.0.0.1:
A final test to see if mysql is listening on loopback is to telnet, from the system that mysql is running on (not from a remote system), to the loopback interface:
telnet localhost 3306
You should see something like this:
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 4 5.0.77>
If you can not connect to mysql, check to make sure that you do not have any lines in /etc/my.cnf that contain "bind-address". If you do:
Option A) Configure mysql to listen on all addressed
Remove any line in /etc/my.cnf that contains "bind-address", and restart mysql:
/etc/init.d/mysqld restart
Option B) Configure ASL to connect to mysql on a different IP address
Log into ASL, click on ASL Configuration, scroll down to "OSSEC_DATABASE_SERVER" and change "127.0.0.1" or "localhost" to the IP address of your mysql server.
Step 4. If mysql is listening on port 3306 and on 127.0.0.1, and you still can not connect to it on loopback (127.0.0.1)
This is most likely caused by local firewall rules. Disable your firewall to see if you can connect to mysql:
/etc/init.d/iptables stop
If you can connect to mysql, then your firewall rules need to be adjusted to allow connections to mysql on localhost. Please see the ASL_firewall documentation.
Step 5: Your mysql credentials may be invalid.
Please see the FAQ, Access denied for user 'tortix'@'localhost' (using password: YES), below to reset your mysql credentials.
[edit]The server requested authentication method unknown to the client
See the ASL 3.2 release notes:
https://www.atomicorp.com/wiki/index.php/Atomic_Secured_Linux#MySQL
[edit]mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication.
See the ASL 3.2 release notes:
https://www.atomicorp.com/wiki/index.php/Atomic_Secured_Linux#MySQL
[edit]MariaDB reports a table is "is marked as crashed and should be repaired"
This error is not caused by ASL. That means MariaDB was not shut down cleanly or that it crashed. You may have other crashed databases. See the article below for MySQL for instructions to repair crashed databases.
[edit]MYSQL reports a table is "is marked as crashed and should be repaired"
This error is not caused by ASL. That means mysql was not shut down cleanly or that it crashed. You may have other crashed databases.
[edit]Option 1
If this involves one of ASLs tables, we have added in logic to the database rotation system to try to fix crashed tables. This method is not fool proof.
As root, not via sudo, run this command:
/var/asl/bin/asl_db_rotate
That will trigger the message from MySQL that the table is crashed:
ASL DB Rotate: Locking failed - Table './tortix/data' is marked as crashed and should be repaired
That will then trigger a self healing event in ASL to fix the table, if possible. Keep in mind that if MySQL was shut down incorrectly or crashed, MySQL tables can be severly corrupted and this Self Healing method may not work. If it does work, you will see an event "60912" in your /var/ossec/logs/self-healing.log log file. You can search for this event with this command:
grep "tortix.data repair" /var/ossec/logs/self-healing.log
If the Self Healing event worked, your output will look similar to this:
Table Op Msg_type Msg_text tortix.data repair note
If you do not see any events, or if the table is still marked as crashed, then the Self Healing method was not successful because the MySQL table is severely corrupted. See Option 2 below for other methods to repair a corrupt MySQL database.
[edit]Option 2
Sometimes a mysql database may be too corrupt to repair, in which case you will need to re-install the database. To that, run this command as root:
/var/asl/bin/database-setup
And answer "y" when the application asks the question "Would you like to re-install the ASL database?"
Then restart the HIDS to ensure it is able to connect to the new database:
service ossec-hids restart
[edit]Option 3
If Option 1 does not work or if you do not want to re-install the database, please follow the process documented by mysql to conduct more advanced repairs of a crashed database.
Please follow the process documented by mysql to repair a crashed database.
The follow are some links to get you started:
For mysql 5.0:
http://dev.mysql.com/doc/refman/5.0/en/myisam-repair.html
For mysql 5.1:
http://dev.mysql.com/doc/refman/5.1/en/myisam-repair.html
For mysql 5.5: