similar to: Problem rkhunter v. 1.2.8 - CENTOS 4

Hi list, after a bit of struggling I found out how to cleanly install rkhunter ... maybe this is useful for you: * Download rkhunter (I downloaded v 1.2.8) * mv /etc/rpm/platform /root/etc_rpm_platform * setarch i386 rpmbuild -ta --target=i386 rkhunter-1.2.8.tar.gz * mv /root/etc_rpm_platform /etc/rpm/platform * rpm -ivh /usr/src/redhat/RPMS/noarch/rkhunter-1.2.8-1.noarch.rpm * wget

in my prior message, that should be in rkhunter.conf On Wed, Aug 30, 2017 at 11:43 AM, Tony Schreiner <anthony.schreiner at bc.edu> wrote: > This has come up for me on the most recent upgrade, add the line > > HASH_CMD=sha1sum > > On Wed, Aug 30, 2017 at 11:15 AM, <m.roth at 5-cent.us> wrote: > >> Can't remember if I posted this before... We're getting

Can't remember if I posted this before... We're getting warnings from rkhunterWarning: Checking for prerequisites [ Warning ] All file hash checks will be skipped because: This system uses prelinking, but the hash function command does not look like SHA1 or MD5. Now, googling, I find people saying to rm /etc/prelink.cache, then run rkhunter --propupd. Works. And then,

On Wed, August 30, 2017 10:43 am, Tony Schreiner wrote: > This has come up for me on the most recent upgrade, add the line > > HASH_CMD=sha1sum > > On Wed, Aug 30, 2017 at 11:15 AM, <m.roth at 5-cent.us> wrote: > >> Can't remember if I posted this before... We're getting warnings from >> rkhunterWarning: Checking for prerequisites [ Warning

Hi, folks, rkhunter is reporting a broken link on one of our servers. This is quite reasonable, since it's on a drive whose controller card I have declared dead the other day. I've been googling, searching in the manpage, and I've done an rkhunter --propupd, but it still finds the broken link. Anyone know how to remove the link from the rkhunter d/b? mark

I updated java-1.7.0-openjdk a few hours ago - it *was* listed as a critical security update, and I don't want yelling from rkhunter. The man page tells me I can tell it rkhunter --propupd <package name>... but it doesn't know the name above as a package. Been googling a bit, and cannot find a good example of a package (other than the manpage's coreutil). Anyone got an example,

On Wed, 2017-08-30 at 11:03 -0500, Valeri Galtsev wrote: > On Wed, August 30, 2017 10:43 am, Tony Schreiner wrote: > > This has come up for me on the most recent upgrade, add the line > > > > HASH_CMD=sha1sum > > > > On Wed, Aug 30, 2017 at 11:15 AM, <m.roth at 5-cent.us> wrote: > > > > > Can't remember if I posted this before...

I rebuilt rkhunter-1.2.8-1.noarch.rpm by using the spec and tgz from the rkhunter site (www.rootkit.nl). (I rebuilt it using his instructions.) However rkhunter does not do an md5 check. The box used to have fedora and each time there were updates it would complain that the some of the md5's don't match. I contacted the author using his contact feature on Wednesday but he hasn't

This has come up for me on the most recent upgrade, add the line HASH_CMD=sha1sum On Wed, Aug 30, 2017 at 11:15 AM, <m.roth at 5-cent.us> wrote: > Can't remember if I posted this before... We're getting warnings from > rkhunterWarning: Checking for prerequisites [ Warning ] > All file hash checks will be skipped because: > This system uses

The latest version of rkhunter is complaining about "suspicious file types" in /dev/shm. Thing is, they're being created on the fly by R, and then seem to be a random name (5d1f...), and I have zero expectation that R will only create shm files beginning with those characters. For those running rkhunter, if you've run into something like this, how have you handled it - told

Hi. On one of my servers aide just reported inode changes to a large bunch of files in a variety of directories, e.g. /usr/bin, /usr/sbin etc. This machine sits behind a couple of firewalls and it would be hard to get to. The day before I updated "clam*" and updated the aide database right after that: -rw------- 1 root root 7407412 Sep 26 10:58 aide.db.gz The problem was that the

---------- Forwarded message ---------- From: <m.roth at 5-cent.us> Date: Thu, May 15, 2014 at 3:40 PM Subject: For the CentOS list: rkhunter and NFS To: lesmikesell at gmail.com Hi, Les, Could you forward this to the CentOS list? That damn nixspam is blocking my hosting provider's mailhost *again*; it was on and off yesterday, and today it won't even let me remove it, and

Anyone seeing this? /etc/cron.daily/rkhunter: /usr/bin/rkhunter: regel 13967: [: eenzijdige operator werd verwacht, -ne gevonden Translating: line 13967 unary operator expected -ne found Line 13967 is: if [ `${IPCS_CMD} -u 2>/dev/null | awk -F' ' '/segments allocated/ {print $3}'` -ne 0 ]; then rkhunter 1.4.2 release 1.el6 from epel on a CentOS 6.5 Thanks Patrick

On Fri, 2015-08-07 at 09:45 -0400, m.roth at 5-cent.us wrote: > Hi, folks, > > rkhunter is reporting a broken link on one of our servers. This is > quite reasonable, since it's on a drive whose controller card I have > declared dead the other day. I've been googling, searching in the > manpage, and I've done an rkhunter --propupd, but it still finds the >

Another alternative is to use a FIMS/HIDS such as Aide (Advanced Intrusion Detection Environment), OSSEC or Samhain. Be prepared to learn a lot about what your OS normally does behind the scenes (and thus a fair amount of initial fine tuning to exclude those things). Aide seems to work well (I've seen only one odd result) and is quite granular. However, it is local system based rather than

Alle, I know this is off-topic, so I apologize in advance, but we have installed rkhunter from EPEL (because it has the current version, 1.3.6 vice the 1.3.4 rpmforge version) on our CentOS machine and find that it does not remove the files in /dev/shm it uses for the SUSPSCAN test, this triggering a warning for said test. This was a known bug that was supposed to be have been fixed in V1.3.1.

Hi all, Debian Lenny, dovecot 1.0.15 My rkhunter script has picked up dovecot using port 1984 temporarily. When I run it now however, it is gone. Warning: Network TCP port 1984 is being used by /usr/lib/dovecot/imap. Possible rootkit: Fuckit Rootkit Use the 'lsof -i' or 'netstat -an' command to check this. Does dovecot use this port for any reason? anyone seen this before?

Ok, one more issue to resolve. The old server was still using the postfix/virtual for delivery, but the new one is using the dovecot LDA. Now, when an email generated locally by a cron job is delivered, this shows in the log: 2013-12-22T10:29:55-05:00 host postfix/pickup[31400]: C67FD90F676B2: uid=0 from=<newsrv+rkhunter at example.com> 2013-12-22T10:29:55-05:00 host

I have an old version of rkhunter installed on my CentOS 5 machine, one I got from rpmforge. In my most recent attempts to update this, I get the following errors in yum: Resolving Dependencies --> Running transaction check ---> Package perl-AnyEvent.noarch 0:5.240-1.el5.rf set to be updated --> Processing Dependency: perl(JSON::XS) >= 2.2 for package: perl-AnyEvent --> Processing

Is there a step by step approach to securing CentOS 4X (or even RHEL 4X)? I don't mean the stuff in the docs/security guide but a working step by step guide? There used to be packages like rkhunter and tripwire but I don't know if the ones in rpmforge/kbs repo are up to date. Thanks, Josh.