I rebooted my server today after some changes.
When i returned to ASL i got a bunch on Critical and Other warnings.

Any suggestions?

cat /etc/grub.conf
#
default=0
timeout 5

title CentOS (2.6.32.43-6.1.art.x86_64)
root (hd0,1)
kernel /vmlinuz-2.6.32.43-6.1.art.x86_64 ro root=/dev/md2 selinux=0 panic=5
initrd /initrd-2.6.32.43-6.1.art.x86_64.img

title CentOS (2.6.32.43-6.art.x86_64)
root (hd0,1)
kernel /vmlinuz-2.6.32.43-6.art.x86_64 ro root=/dev/md2 selinux=0 panic=5
initrd /initrd-2.6.32.43-6.art.x86_64.img

title CentOS Linux (2.6.18-238.9.1.el5)
root (hd0,1)
kernel /boot/vmlinuz-2.6.18-238.9.1.el5 ro root=/dev/md2
initrd /boot/initrd-2.6.18-238.9.1.el5.img

uname -r
2.6.32.43-6.1.art.x86_64

# asl -s -f
Starting Atomic Secured Linux scan, please be patient...

Checking Kernel security settings
ASL kernel: not detected [CRITICAL]
Runtime module loading: disabled [OK]
GRsecurity administrative password: not set [INFO]
GRsecurity ACL database: not found [INFO]
Executable anonymous mapping: no [OK]
Executable bss: no [OK]
Executable data: no [OK]
Executable heap: no [OK]
Executable stack: no [OK]
Executable anonymous mapping (mprotect): yes [HIGH]
Executable bss (mprotect): yes [HIGH]
Executable data (mprotect): yes [HIGH]
Executable heap (mprotect): yes [HIGH]
Executable shared library bss (mprotect): yes [HIGH]
Executable shared library data (mprotect): yes [HIGH]
Executable stack (mprotect): yes [HIGH]

Vulnerability Detail

Critical Risk: Stack is executable. The system is vulnerable to buffer overrun class attacks. Read More...
Critical Risk: Trusted Path Execution(TPE) capabilities are not available/disabled. Read More...
Critical Risk: Privileged Kernel I/O is allowed. Read More...
High Risk: Kernel check, anonymous mapping (mprotect) is vulnerable. Read More...
High Risk: Kernel check, Executable bss (mprotect) detected. Read More...
High Risk: Kernel check Executable data (mprotect), detected. Read More...
High Risk: Kernel check, Executable heap (mprotect) detected. Read More...
High Risk: Kernel check, Executable shared library bss (mprotect) detected. Read More...
High Risk: Kernel check, Executable shared library data (mprotect) detected. Read More...
High Risk: Kernel check, Executable stack (mprotect) detected. Read More...
High Risk: Kernel check, Shared library randomisation test. Shared libraries can be located at random addresses too, which is what this test tries to find out. Read More...
High Risk: Kernel check, Executable shared library data condition detected. Read More...
High Risk: Root processes within a chroot jail are not restricted. Module insertion, raw i/o, system and net admin tasks, rebooting the system, modifying immutable, files, modifying IPC owned by another, and changing the system time are permitted. Read More...
High Risk: PHP Function fsockopen() allows an attacker to open sockets, useful for spamming, remote inclusion, etc. Read More...
Moderate Risk: Processes inside a chroot are able to chmod or fchmod files to make them have suid or sgid bits. Read More...
Moderate Risk: Processes inside a chroot are able to chroot again outside the chroot. Read More...
Moderate Risk: Processes inside a chroot are able to invoke fchdir. 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 when this policy is enforced. Read More...
Moderate Risk: Processes inside a chroot are able to invoke mknod(). This can be used to escape from the chroot() jail. Read More...
Moderate Risk: Processes inside a chroot are able to invoke mount(). This can be used to break out of the chroot() jail. Read More...
Moderate Risk: Processes inside a chroot are able to use pivot_root(). This can be used to escape from a chroot jail. Read More...
Moderate Risk: Processes inside a chroot are able to attach to shared memory segments that were created outside of the chroot jail. Read More...
Moderate Risk: Processes inside a chroot are able to write to sysctl entries, either by sysctl(2) or through a /proc interface. Read More...
Moderate Risk: Processes inside a chroot are able to chroot again to connect to abstract (meaning not belonging to a filesystem) Unix domain sockets that were bound outside of a chroot. Read More...
Moderate Risk: Chroot chdir policy is not enforced. When active the current working directory of all newly-chrooted applications will be set to the the root directory of the chroot. Read More...
Moderate Risk: Processes inside a chroot are able to kill, send signals with fcntl, ptrace, capget, getpgid, setpgid, getsid, or view any process outside of the chroot. Read More...
Moderate Risk: Kernel dmesg restrictions are not in effect. Read More...
Moderate Risk: Kernel execev() limits are not enforced. Read More...
Moderate Risk: Kernel ptrace() restrictions are not enforced. Read More...
Moderate Risk: Weak SMTP_AUTH passwords detected. A full report is available in /var/asl/reports/password.report. Read More...
Low Risk: Users will be able to write to FIFOs they don't own in world-writable +t directories (i.e. /tmp). Read More...
Low Risk: Kernel fork failure logging is not enabled. Read More...
Low Risk: IP Blackhole policy disabled. When enabled TCP resets and ICMP destination-unreachable packets will not be sent in response to packets sent to ports for which no associated listening process exists. This is used for DoS protection. Read More...
Low Risk: Linking restriction policy is not enforced. 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. Read More...

Ive seen those tests fail when NX is disabled in the BIOS

Hello Scott - this was all working two days ago & I certainly did not change any BIOS settings.
I did read another post on this topic and did the following.

egrep '^flags' /proc/cpuinfo | uniq

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid

As far as I can see NX is not dissabled.

Only way to really verify that is to look at the bios itself, cpuinfo will report that its supported but it cant tell if its active. The kernel checks that test for it in ASL on the other hand would fail if it was supported, but disabled in the bios.

Still don't understand how this would have changed over the past few days.
Everything was working perfectly.

Surely I would had had to make the change to the BIOS?

I decicded to roll back the kernel one version to test.

Latest Kernel
2.6.32.43-6.1.art.x86_64

Active Kernel

uname -r
2.6.32.43-6.art.x86_64

After reboot All modules are now active:

ASL Active
Anti-Virus Active
IPS/IDS Active
Kernel Protection Active
WAF Active
DoS Protection Active

Suggestions?

Oh gotcha, yeah you were one of those 4PSA users. That -6.1 release was a test build to see if it was related to ASL. It actually is just a vanilla kernel without anything in it so we could determine if the 4PSA products worked with newer kernels, its not even available. We installed it on your system to confirm the 4PSA bug.

Hi My name is Mark & I am a 4PSA user



2.6.32.43-6.art.x86_64 is running fine with ASL Version 3.0.3: CentOS 5 (SUPPORTED)

I still have to run

ln -sf /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock

to get 4PSA Cleanserver to run without errors

apart from that, all is well.

Clean Server has (or had) a bug that made it mangle email on newer Linux kernels. If you arent using CS, then this may not apply to you. If you are, then you may want to check with 4PSA.

Yip that has been fixed - but I still have to run ln -sf /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock

The guys at 4PSA did say there was an update coming... (but they have been saying that for months)

Anyways, it's all running now.

Not sure what that has to do with ASL.

With that said, whos mysql are you using?

I was just mentioning it - maybe a solution pops up



mysql-5.1.58-2.el5.art

Thats a configuration issue in your /etc/my.cnf file, the standard location for the socket it:

/var/lib/mysql/mysql.sock

And your my.cnf file should have an entry like this:

socket=/var/lib/mysql/mysql.sock

If you want the socket in a different place, just change that line.

Thank you --

The guys from 4PSA have been on the server a number of times and have never suggested that!