RkHunter Output - Opinion Please
 

Hello...

Early this morning I received 2 emails from BFD. The first said that there was 300+ attacks against an ftp account and the 2nd email said there was 70+.

I ran RkHunter and got this:

Performing trojan specific checks
Checking for enabled xinetd services [ Warning ]
Checking for Apache backdoor [ Not found ]

Performing Linux specific checks
Checking kernel module commands [ Warning ]
Checking kernel module names [ Warning ]

But the final log summary was:
System checks summary
=====================

File properties checks...
Required commands check failed
Files checked: 124
Suspect files: 5

Rootkit checks...
Rootkits checked : 110
Possible rootkits: 0

Applications checks...
Applications checked: 9
Suspect applications: 0

The system checks took: 6 minutes and 4 seconds

Have you had a look through /var/log/rkhunter.log to see what the warnings were and which required commands were missing? Also, does your FTP log contain any information about whether they were able to log in successfully?

Well... Here is BFD Log file:
/var/log/secure shows a LOT of attempts:
A bunch of lines like this -
Some like this:
And then a bunch with some other usernames (one existed) but no passwords/logins were valid (I don't think).

In /var/log/messages:
And a bunch of (I think) failed attempts - different username attempts to:
And then a this:

Please check what you replied. Gilead asked three questions (warnings in rkhunter.log, missing commands in rkhunter.log and successful logins in system logs), of which only *one* you partially replied to. If you don't know exactly what's asked for there's nothing wrong with asking for clarification because providing complete information is crucial.


The init: Trying to re-exec init line looks interesting, because re-executing init will only be done in a few circumstances like installing Glibc updates and after prelinking. If it was an authorised move then 'last' should show action between 02:20 and 02:40. Or did you leave out surrounding log lines you thought wouldn't be interesting? Wrt FTP: unless you left out lines or unless there's something wrong with logging, a "session opened" line should be followed by a "proftpd pam_unix session opened for user " to show a login.


I too would be interested to see what rkhunter.log says about this. Kernel module names + init sounds like a recipe for something Knark-ish to me, let's hope it's not. If you can't



Unassorted remarks:
- It's good to know which version of Rootkit Hunter you run (I guess 1.2.9). Versions below 1.2.9 are deprecated and must not be used while version 1.2.9 is considered outdated. Support for it will drop RSN. We're at version 1.3.0 now which is a major rewrite.
- While we know BFD executed a ban for 210.173.249.105 on Jan 10 01:50:01 we don't know the duration of the ban (check your BFD config) but since he connected again at 02:20 it sure is too low. Also look into configuring your FTP daemon with additional access restrictions (see the config and docs).
- The /var/log/secure "set_loginuid failed opening loginuid" lines have nothing to do with FTP, BFD or Rootkit Hunter. The fifth field denotes the sending process (argv[0][$PID]) which is crond. It means you run a kernel that was configured without CONFIG_AUDIT and CONFIG_AUDITSYSCALL. Commenting out the loginuid.so lines in your /etc/pam.d/ stacks will remove the message. This is a minor issue.
- If you're going to post log lines or configs please use BB code tags and make sure you don't arbitrarily leave out lines. If the logs are too large U/L them on sone free hoster and post the D/L URI.

Please excuse my ignorance. I'm trying hard but this (Linux) is a lot to grasp when using Windows practically my whole life.

There were entries that I cut out due to the size of the file. It's really big!

I think I have the right log files, and I read them to show that this particular attacker (Jan 10 @ 2:18am +/-) didn't get access, but I'm not sure. The RkHunter is 1.3.0 and the errors that I'm getting from that could very will be a configuration error.

/var/log/apf_log
/var/log/bfd_log
/var/log/messages
/var/log/rkhunter

At about 1pm on Jan 10, you will notice that there was a successful login, but I think that was me. I finally got near a computer that I could login and I thought it would be a good idea to install clamAV to scan the system with that too (but that didn't go to smoothly).

I do appreciate the help!!!

No problem. We're here to help and that is what we'll do. Thanks for the logs. The logs show no information about a breach of security. That does not mean there wasn't any, there just isn't enough info. What I'd suggest is that, before doing anything else, you familiarise yourself with the Intruder Detection Checklist (CERT): http://www.cert.org/tech_tips/intrud...checklist.html. Next to performing checks from the checklist use your package manager (if so capable) to verify all package contents. Please report back any findings, preferably using BB code tags for readability.

By package manager, I assume you mean yum? If so, I can install with this, but would you be willing to give me the commands to verify the contents please?

Okay... I've already been looking at the log files so I skipped right to step 2. Unfortunately, I really don't know what the output should be but here is what I got:

and:
Is that okay?

I just ran # last, and there is no entries (on the 10th) from 'admin', which was the user that was being attacked. The only successful login with admin was me from my IP at home.

Does that mean I have nothing to worry about?

I ran rkhunter again with --report-warnings-only. Here's what I got:

Sorry, one more post tonight and then I'll wait for my next instruction. I just installed CHKRootkit 0.47 (installed by yum). It's output was:

It says that there is a possible LKM trojan installed! Is this a false positive?

Wrt post #7 about package managers it would be good to update your LQ profile with your distro info or post it here.

Wrt post #8, the filenames of setuid and setgid files look OK, checking their hashes against what the package database (or remote copies of packages) provides should give proof. The "No such file or directory" error may be caused by 'find' looking inside its own process information in /proc and is no cause for alarm.

Wrt post #9, if 'last' doesn't show logins for that date and time then that is OK, except if the wtmp database was tampered with. Unless there's suspicions there is no immediate need to check that. Remember though that for some forms of compromise, like for instance those exploited through (usually) available PHP-based applications, no root account compromise or login is necessary as they will run OK within webserver processes.

Wrt post #10, running RKH has changed between versions. The installation doc tells you you must run 'rkhunter --propupd' before scanning. The assumption there is that you install any auditing apps right after you install your O.S., especially if you specify RKH to use your package managers database to verify hashes. Also check rkhunter.conf for helper apps you might want to install.

Wrt post #11, for "/usr/lib/perl5/5.8.8/i386-linux-thread-multi/.packlist" see the Chkrootkit FAQ about dot-files, the chkproc "process hidden for readdir command" is in the FAQ as well, it's about short-lived processes.


I'm missing info about you running CERT checks five through eight. Some of those checks can be covered by running Tiger version 3.2.2 (http://freshmeat.net/projects/tiger-audit/) and if you run Debian, Gentoo or Red Hat or derivatives, you can complement it with LSAT version 0.9.6 (http://freshmeat.net/projects/lsat/).


In short we haven't seen any signs of compromise sofar and I doubt it any will turn up. If you want to find out if your system needs additional configuration and if you want to learn how to audit your system (which should be done regularly anyway) and if you want to be prepared in case of emergency I'd invite you to finish the rest of the checks.

I didn't know what to do for steps 5 through 8, well, except for step 7. I did that one.

I didn't hear from you in a while, and my provider suggested that I reinstall my OS. So I did.

I didn't really think that there was an intrusion after all that stuff that you had me doing. However, I figured that it couldn't hurt.

Uh. It's not like this is 24/7 paid support or an IRC session you know. Consider a reply within 24hrs quite good actually.


Mitigating risks by reinstalling is laudable but in case of a real breach of security should have been preceded by making a bit copy of the disks. Wiping possible "evidence" means by reinstalling there's nothing to learn from and if the box was not reconfigured it could happen all over again.


If that's your conclusion that's good.
At least now you have rudimentary knowledge of what to look for.

Please accept my sincerest apologies. Sometimes what you think doesn't come across properly when posting.

I appreciate ALL of the help you gave me! I only opted for the re-install because I figured that I would get a lot of practice re-installing.

Thanks!