Some possible issues on my mind, regarding my moribund Debian oldstable desktop, mostly relating to smarter interpretation of tripwire, chkrootkit, rkhunter output:

• Is chkrookit being updated to include latest linux rootkits?
• @unspawn (rkhunter developer): is rkhunter being updated to include the latest linux rootkits? And any linux-applicable zero-day exploits included in the HBGary leakfest? (I hear that inside the NSA, Aaron Barr is regarded as the biggest boob since Col. Bonner Fellers and Mr. Robert Murphy, whose maladroit cryptographic blunders while serving in Cairo c. 1940-2 provided the Germans with reams of operational intelligence on British capabilities, plans, and operations, thus greatly prolonging the North Africa campaign. Whatever you think about HBGary's missteps, it makes sense to look over their zero-day exploits, I think, to make sure rkhunter protects against anything which might be cross-platform.)
• I have some empty files, names beginning with period, which chkrootkit considers "suspicious":
  
  Code:

  /usr/lib/iceweasel/.autoreg
  /usr/lib/icedove/.autoreg 
  /usr/lib/xulrunner-1.9/.autoreg 
  /lib/init/rw/.ramfs

  I believe that the first three are just the way iceweasel does things, and that the last is due to fact I installed from live-CD, too long ago to recall details. If I delete them, I think they are regenerated upon reboot. Even so, I guess that the only reason chkrookit is suspicious is that the names begin with a period. Is that correct?
• In my ordinary user's home directory I have a directory ~/.mozilla/extensions which contains an empty directory with a long name. Is this some kind of undeletable cookie?
• When running
  
  Code:

  tripwire --check --interactive

  I always see listed many files in /var/run, /var/log, /proc, and /dev which I think should change, but by default tripwire looks in these directories because rootkit authors like to try to hide their logs and malware there. Is that right? So that we would be wise to look over these results daily to see if anything looks obviously wrong? And what is obviously wrong, anyway. I think I'd recognize that a file newly added to /var/run with a name like ".pwnd_u" doesn't belong, but can anyone offer some further rules of thumb?
• Every time I reboot, when I run Tripwire I see files like
  
  Code:

  Added:
  [x] "/dev/.udev/failed/\\x2fdevices\\x2fplatform\\x2fvesafb.0"
  [x] "/dev/.udev/failed/\\x2fdevices\\x2fplatform\\x2ffloppy.0"
  [x] "/dev/.udev/failed/\\x2fdevices\\x2fpci0000:00\\x2f0000:00:0b.0"
  [x]
  "/dev/.udev/failed/\\x2fdevices\\x2fLNXSYSTM:00\\x2fdevice:00\\x2fPNP0A03:00\\x2fPNP0F13:00"
  [x] "/dev/.udev/failed/\\x2fdevices\\x2fLNXSYSTM:00\\x2fdevice:00\\x2fPNP0A03:00\\x2fPNP0C04:00"
  [x] "/dev/.udev/failed/\\x2fdevices\\x2fLNXSYSTM:00

  These files are broken symbolic links to nonexistent devices such as
  
  Code:

  /devices/LNXSYSTM:00/device:00/PNP0A03:00/PNP0C04:00

  I have been assuming this is due to some kind of misconfiguration, or some aspect of DHCP, avahi, dirmngr I have broken by setting up a possibly overly restrictive firewall, or something to do with the despicably insecure dsl modem/router my telecome forces customers to buy in order to get on the internet, but now I am starting to wonder. I guess some of the above might be related to doing something slightly tricky in past few days involving a live CD and floppy disks which might have confused my system.
• Since I install patches as soon as they become available from the Debian repos, I often see many modified binaries. Usually I can recognize most of them as changes expected due to upgrading avahi, cups, sambda, or other packages with many dependencies. But sometimes I see some which are not obviously related, like /etc/logrotate.d (what does that have to do with yesterday's security patches?) What do experienced sysadmins do to check what libraries and binaries should be modified when they upgrade, for example, cups? Isn't there a command I can run as root which will tell me what all the dependencies are?
• When I boot, the messages which rapidly scroll by mention some kind of code for Tor which looks like a unique identifier. I can't reproduce it here because it goes by too quickly. Anyone know more?

Use your favorite search engine to locate the developers website (and CVS repo and user mailing list if any). Check its release date and those of currently known rootkits.


No. There will be modified rootkits and new rootkits I don't have access to. Regardless of that the amount of rootkit infestations has been dwindling since the turn of the millennium: unpatched vulnerabilities and misconfigured machines are easy to find on which to use way easier methods. BTW there's rarely any need to ask for me specifically: most regulars here know as much as I do if not more.


And which ones would that be exactly?


Either you have information from somebody inside the NSA which is highly unlikely or you should re-evaluate how much an opinion based solely on hearsay is worth.


In ye aulden days filenames starting with a dot where thought useful for hiding names because you need to use the "-a" switch to list them so most of the time there'll be false positives. For non-empty files the file name and location may hold clues as would examining them using the package manager as would using common tools like 'ls -al', 'stat' and 'strings' as would feeding names into LQ search or your favorite search engine.


As you haven't provided any information (stat, ls) the only think comes to mind is it might be an uninstalled extension. And it's not a security-related question BTW.


Tripwire has no concept of "rootkits" or "malware". It simply records changes because items appear or disappear, have ownership, access rights, inode or content changed. In the case of these standard directories you should reference the FSSTND/LFS docs to know which directory holds what volatile or growing files. Also see the tools under the previous dot files reply.



Paraphrasing one of the standard mantra's: "do not attribute to malice what can be attributed to standard system activity". I suggest you get to know your system better.


0) My distributions package management allows me to peek into packages, list dependencies and examine any scripts run before or after a package is installed, 1) I keep a backup scheme that allows me to compare and restore files at will, 2) all /etc configuration is loaded in CVS, again allowing me to compare changes and restore at will, 3) Samhain tracks changes and so does 4) the audit service and 5) all sudo sessions are wrapped in 'rootsh' as extra audit layer. Once you have a fix on MAC times it's just a question of grepping back logs.


Check your system and or daemon logs?

1 members found this post helpful.

hanks, unspawn, for your quick response. Some of what you wrote was helpful:

That's good to know, but is it possible that with growing sophistication, modern rootkits are simply better at hiding from view?

And thanks for all your work on Rkhunter--- I and many others use it because we find it useful!

Exactly what I am trying to do in this thread.

Computers are complicated. Mine has something like

• 250000 files (3000 open during normal operations)
• 2300 binaries in the usual four directories
• 2000 .ko files
• 1200 packages installed from debs
• 100 running user space processes
• 70 kernel modules
• ...

Not even to mention the hardware. That's a lot to understand, and the challenge is all the greater for those who lack the neccessary background in computing. But as we both know, it is essential to try, so we all have to do the best we can with what we have.

I think you would be amazed at (or scornful of?) the lengths to which I have gone to try to systematically benchmark "normal behavior" on my system. But that's exhausting work, and I've found that over time, as more software is installed and user behavior evolves, the benchmark can become quite outdated. So trying to understand a system, and to distinguish normal or otherwise innocuous behavior from things which should raise an alarm, is an ongoing process, and from time to time, I seek help and advice here.

Perhaps I did not express myself clearly. Of course I checked all the logs before asking. The problem is that there is no log (at least, not in /var/log) which contains all the notices I see scrolling past at boot time. I probably should have said that this is something I have been trying to chase down by poking around in my system, looking around on the internet, etc., for almost a year.

I was hoping that someone here would have seen a similar notice at boot time on their own system, and would know what the identifier means. It seems too long to simply identify the version of tor which I have.

So, back to the point. Can anyone offer some answers, educated guesses, or links to relevant information? For example, about the /dev files I don't understand?

That could be possible albeit remotely (or should I say infinitesimal?). The most simple explanation I think is that the "threatscape", to borrow large security vendors marketoid speek, has changed: longterm stealth isn't as much an issue as working fast and providing "services" in the right volume is what certain "markets" want.


Thanks, but the last years you shoul mainly thank John. He's the one who improved RKH greatly, I try to add rootkit details and such.


IMHO it isn't as much hiatus in computing as it is grokking concepts: once you dig the framework then details follow naturally from that.


The kernel maintains a buffer storing messages at boot time. Once userland (r)syslog(-ng) is up those and every other message, apart from what you could call "vanity status messages", end up in whatever /etc/(r)syslog(-ng).conf is configuring (r)syslog(-ng) to log to.


TOR by default logs as little as possible. Starting TOR logging more verbosely could yield clues.

Thank you, John!

Agreed. (Not to imply that I think I know more than you do about the current threatscape, of course.)

We probably also agree that one constant is the principle that users are the single biggest threat to themselves.

Agreed: once you (somehow) acquire sufficient background knowledge, you can teach yourself efficiently. What some people call a steep learning curve: hard to get out of the weeds, but once you do, you can easily climb high under your own power.

If you will indulge me by answering a stupid question: in /etc/rsyslog.conf, what does a hyphen mean? For example:
And you are right, I found the Tor notice I was asking about in one of the obvious log files. I don't know why I didn't find it when I grepped weeks ago, but anyway, it goes something like this:
Question: what is that string in parentheses?

The iceweasel engine: I am curious to learn more about what exactly is stored in place like ~/.mozilla/firefox/xxx.default. For example: I can tell from viewing the file that
extensions.rdf
appears to store information about add-ons which iceweasel uses to check for updates. But I'd like to know for sure. I know that
XPC.mfasl
is something XUL does to "speedload" pages. But what exactly? I suspect that if I knew, I'd want to disable it since my connection is too slow and flaky to benefit. The file
xpti.dat
seems to contain lots of things which might be hidden cookies. More mysterious to me are the files in database formats I can't even read. I do know that sqlite and db files should be readable if I knew how to not only fire up those database engines but to actually read the files. Of course, for security reasons, iceweasel probably doesn't want to make that too easy for curious persons.

I disagree but we're getting OT here. Studying a subject will always start with "just accepting" the ground rules, how things are done, and in some cases un-learning how one did things in the Other OS.


Not a security question: 'man 5 syslog.conf' (omit sync after every log action).


Not a security question. I don't know. Might be some version-related hash. You have to check the application source for that.


Not security questions or related to the problem in your OP either AFAIK but you got that by now.
Best create new threads per topic in the most relevant forum.
For everything Mozilla see http://kb.mozillazine.org/.
For SQLite see 'sqlitebrowser' or 'sqlite' CLI commands.

Back to the OP, then. I was asking for help interpreting output of Tripwire, and of course my goal in asking that arises from my goal of improving my system security. No-one has yet said anything about this possible issue:
So is that highly unusual, and if so, it is innocuous or suspicious?

You can determine yourself if something is innocous or not: read for instance this (old: 2006) thread to gain understanding the reason why Udev device probes may end up in /dev/.udev/failed/ and how you could try and mitigate that.

Thanks, unspawn, this information is helpful:
Returning to interpreting output of tripwire --check --interactive, I frequently reboot my PC and thus (?) always see many changes in /proc, dev/, /var/log/, /var/run which should be accepted as innocuous. It is possible to configure tripwire to ignore /proc, /dev but I understand that is a bad idea since many old-style rootkits like to try to "hide" files in these places. Thus, as I understand it, one should let tripwire flag any changes in /dev et cetera and simply look for obviously suspicious entries like "added: /proc/.aufero". Is that correct?

One thing to mention about /proc - it doesn't exist anywhere but memory. As such, you can't just decide to create a file in /proc/. In order to do so, you will need to invoke a kernel specific function (create_proc_entry). If a rootkit is at the point where it's adding entries to /proc, you've already lost and are unlikely to detect it (unless it is poorly written), since it has control over the kernel, and thus your OS as a whole. I think it's probably safe to just ignore /proc for the average user, but you'll have to judge for yourself how much paranoia you have.

You make a good point.

My views are rapidly evolving, but my current "common sense summary" is:

• "state of the art" rootkits are becoming far more sophisticated,
• it is no longer sensible to assume that state-sponsored or otherwise well-funded and capable attackers will not attack your "small fry" network, "politically inoffensive" bulletin board, or "innocent citizen" PC,
• nevertheless, old (and sometimes badly written) rootkits remain a threat, and tools like Tripwire and Rkhunter which can be (apparently) easily evaded by some modern rootkits are probably worth using for that reason,
• complaints about computer intrusions to "the authorities", which have never been of much use, are even more pointless at a time when it appears to have become common practice for "law enforcement agencies" to break the law to engage in the same activities as the criminals, targeting "small fry" networks et cetera,
• these days, there are no "small fry", anything can be "politically offensive" (to someone somewhere), and governments presume all citizens are guilty of something,
• the only one looking out for your network is yourself, so we all need to pay more attention to doing that.