I've been struggling to figure this out by myself for a few days now. Stubborn, I guess. clamscan is reporting /etc/httpd/modsecurity.d/50_asl_rootkits.conf: Atomicorp.PHP.MassMailer.20101010161701.UNOFFICIAL FOUND. it's listing the same for that file in /var/asl/rules/modsec then it spits out several errors regarding how it can't read /sys/class/net/lo/uevent or /sys/class/net/eth0/uevent, then it terminates. i'd attach a result file, but it displays the "cannot read errors" to the console. i've run chmod on uevent to grant root permissions to read, but this doesn't stick either. oh, and one other: /usr/share/i18n/locales/hy_AM: Atomicorp.MalwareBlocklist.freenet.am.UNOFFICIAL FOUND

i've run asl -u, yum reports that no packages are marked for update

also, when i run asl -s -f, AllowGSSAPIAuthentication and AllowGSSAPICleanup credentials are marked as fixed every time, so i assume the changes aren't sticking. i saw in another post that this could be caused by an ftp server other than the one Atomicorp provides, so i installed the psa-proftpd. it also reports that no administrative users are defined for ssh. i googled around and couldn't figure out how to create administrative users.

any help would be appreciated.

Thank you for the questions.



Thats correct, thats where those signatures are actually stored, so youre scanning the signatures themselves. You should get a hit there. You can ignore those and you dont need to scan any of the ASL directories.



Correct, those are special system directories in Linux that represent actual hardware. You cant scan then, they aren't files or directories. Dont scan /sys/ or /proc/. If you want to scan your entire system, you should ignore those directories that are special in Linux, a good set to start with is:

--exclude-dir=/proc|/sys|/dev|/var/asl|/etc/httpd/modsecurity.d|/var/clamav



Thats also normal. You cant change the permissions on those device handles because they aren't files, they are device handles.

I guess my question is then, how is it that entries are being added to whitelist.txt in /var/asl/rules/modsec. i delete it, but every few hours, it fills with about 15 entires that shouldn't be there. is there a way to disable the whitelist?

actually, i think i might have just figured out the answer. before i managed to wreck my asl setup, so i reformatted and, long story short, now the whitelist only gets modified when i reboot.

sorry, correction, i apologize. running on no sleep here. i ran asl -u and the rules disappeared for about two seconds. that's when the whitelist was modified.

When you say whitelist, what file do you mean exactly is being modified?

whitelist.txt in the /var/asl/rules/modsec directory. it happens when ever i reboot the server. i clean it but, when i reboot, the server starts up with about 20 entries in it

that isnt a file you should ever touch. The real whitelist lives in /etc/asl/whitelist. If there are any entries that are incorrect, you can remove them from that file and run asl -s -f. Just make sure you don't remove anything local, like localhost/127.0.0.1 or your local IP.

i do remove them. every day. they come back on their own. i'm trying to play around with the sshd_config, passwd, and sudoers file to make sure no one's somehow created a user account and is logging in manually to add them. *sigh* and i locked myself out. i guess that's what you get when you try to learn systems administration from google. i'd appreciate it if you could tell me under what scenarios other than ftp or ssh the whitelist can be modified.

ASL Web would be the other place you can manage the whitelists

Those files can also only be modified by root and the special ASL user tortix. No other user can modify them from the command line.

thanks. it was my fault. the user i upload files with (no ssh permissions) had its password guessed and there were some files there that shouldn't have been. i filled out the wheel group in /etc/group and activated it in /etc/pam.d/su for good measure, i also removed execute permissions for the upload user's directory. i'm sorry for pestering you. i understand that this is my job, not yours. i was just confused as to what was actually happening.

No worries and no need to apologize! We are here to help, and if we were able to do that then its a win-win for everyone.

Exactly, this is how we come up with ways to detect and respond to attacks. Its always OK to ask these kinds of things, or even just publish a new attack you've seen and blocked.

I think I might actually have something for you


109.230.246.169 - - [15/Apr/2011:19:26:27 -0700] "GET http://119.161.9.14/?login=whatboy232&passwd=testing HTTP/1.0" 200 5977 "-" "-"


I went through the access log and i'm pretty sure that's the request that's bringing tomcat down.