Re: [rkhunter] coyote.coyote.den - Daily report
On Tuesday 28 November 2017 05:16:42 Brian wrote:
> On Tue 28 Nov 2017 at 14:04:58 +0500, Alexander V. Makartsev wrote:
> > On 28.11.2017 07:45, Gene Heskett wrote:
> > > On Monday 27 November 2017 17:39:45 Brian wrote:
> > >> On Mon 27 Nov 2017 at 16:56:15 -0500, Gene Heskett wrote:
> > >>> On Monday 27 November 2017 15:57:34 Brian wrote:
> > >>>> On Mon 27 Nov 2017 at 15:46:55 -0500, Gene Heskett wrote:
> > >>>>> On Monday 27 November 2017 14:35:17 root wrote:
> > >>>>>
> > >>>>> Installed new firefox-esr yesterday, from the wheezy repos.
> > >>>>> Today, rkhunter has a cow:
> > >>>>
> > >>>> [rkhunter nonsense snipped]
> > >>
> > >> I'd ignore it. Better still, purge rkhunter from the system. It
> > >> is renowned for giving false positives. There is no
> > >> well-substantiated account of it ever discovering anything of
> > >> consequence.
> > >
> > > Thats another possibility, I get tired of its mewling about stuff
> > > thats normal here. I use amanda, so yes, xinetd is in use, and
> > > other similar crap. I am amazed it doesn't fuss about
> > > ~/gene/bin/mailwatcher, which is my coupling between fetchmail and
> > > kmail.
> > >
> > > Cheers, Gene Heskett
> >
> > IMHO "ignore it and purge" is a terrible advice for anything. It is
> > better to understand the logic behind those triggers, even if they
> > are indeed false positive in this case.
>
> The advice was not intended to be generalised for all software. It was
> given in a particular context for a software which has an extensive
> track record for producing output which is of no consequence. I would
> be very, very surprised if Gene Heskett had obtained firefox-esr from
> an untrusted source. Yet another reason for not giving any credence to
> what it reported.
>
> > "rkhunter" has panicked and rightfully so because it found a working
> > process with suspicious ports in listening state. As it explained
> > these ports were known for usage by malware, ex. 6667 could be used
> > for IRC-bot which is used for remote control of the malware.
> > The name of process was "portsentry" and as stated in its package
> > description is used for portscan detection, so it must have opened
> > ports to "see" if there any portscans of known ports going.
> > Did you installed "portsentry", or should you trust "portsentry" to
> > open ports like this, are another questions.
> >
> > I don't use "rkhunter", but there is probably some mechanism to
> > whitelist, so it won't trigger on the same things (xinetd) every
> > time.
>
There is a specific setup to ignore /etc/xinetd.d stuff, but setting it
up doesn't work.
> I am all in favour of finding causes for software behaviour but make
> an exception for rkhunter. Discovering that xinitrd is running is no
> great achievement. Labelling it as suspicious and the source of a
> possible rootkit comes close to generating FUD and inducing panic
> in less experienced users.
I'll agree. It has never squawked about /etc/xinetd.d/amanda being
enabled before, and adding an pair of ignore that options in its .conf
file has had no effect on its bitching about it.
okaying firefox to use shared memory however did silence that.
I have also used portsentry for many years, and this is the first time
its ever fussed about it. According to its own logs, nothing has
changed, but suddenly its fussing. portsentry has triggered, but always
from my fumble fingers logging in from one of my other machines.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: