Re: [rkhunter] coyote.coyote.den - Daily report

[Dejan Jocic]

On 28-11-17, Michael Stone wrote:
> On Tue, Nov 28, 2017 at 01:20:52PM +0100, Dejan Jocic wrote:
> > If you do not understand it, purge it and
> > warnings will be gone. That rkhunter is approved, tested and well used
> > and recommended tool by some security experts is of no value at all.
> 
> I think you'd find more security experts who roll their eyes at it.
> 
> Mike Stone
> 

Well, I would love to see sources where you've found that. Any links
perhaps, or is it more based on personal opinion and/or conversations
you had with some security experts?

Re: [rkhunter] coyote.coyote.den - Daily report

[Michael Stone]

On Tue, Nov 28, 2017 at 01:20:52PM +0100, Dejan Jocic wrote:

If you do not understand it, purge it and
warnings will be gone. That rkhunter is approved, tested and well used
and recommended tool by some security experts is of no value at all.


I think you'd find more security experts who roll their eyes at it.

Mike Stone

Re: [rkhunter] coyote.coyote.den - Daily report

[Gene Heskett]

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 

Re: [rkhunter] coyote.coyote.den - Daily report

[Brian]

On Tue 28 Nov 2017 at 16:38:24 +0500, Alexander V. Makartsev wrote:

> On 28.11.2017 15:16, Brian wrote:
> > On Tue 28 Nov 2017 at 14:04:58 +0500, Alexander V. Makartsev wrote:
> >
> >> 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.
> That could be nothing to do with firefox-esr. Just because some package
> was installed last doesn't always means it will be the source of the
> problem.
> Anyway, creating software that will reliably detect something meant to
> be undetectable like rootkit, while evading rootkit's protection
> measures against well-known anti-rootkit software is impossible.
> When I read that log Gene posted and seen "6667 port" I was like "Holy
> shit this is serious", but then I looked up for "portsentry" and
> realized it is FP.
> "rkhunter" had every right to panic and it's user's fault to not know
> about how "portsentry" works. (IF this is legit "portsentry" not
> something that just has its name)
> >> "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.
> > 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.
> >
> That said, it is better to know at least something and investigate, than
> just saying "meh its another FP" and uninstall the software.
> "rkhunter" has served it's purpose at least to urge "less experienced
> users" to do a research and learn.

Two decent arguments. All it needs now is for somene to come forward and
recount how rkhunter's objective (Rootkit Hunter scans systems for known
and unknown rootkits, backdoors, sniffers and exploits) has resulted in
a positve outcome of benefit to the security of the machine. 

-- 
Brian.

Re: [rkhunter] coyote.coyote.den - Daily report

[Dejan Jocic]

On 27-11-17, 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]
> > > >
> > > > > How should I restore?
> > > >
> > > > Restore what?
> > >
> > > An obviously contaminated firefox-esr. Or whatever in this list is
> > > contaminated: Its to complete list from the last wheezy update.
> > >
> > > Turns out that rkhunter looked over firefox-esr on its previous run
> > > and apparently gave it a passing grade. So I have to assume its
> > > something in yesterdays list:
> >
> > [Long list 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.
> 
That is terrible advice. If you do not understand it, purge it and
warnings will be gone. That rkhunter is approved, tested and well used
and recommended tool by some security experts is of no value at all.

> 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
> -- 
> "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 
> 

If you are tired of its "mewling about stuff thats normal here" then do
something about it. Rkhunter has conf file where you can whitelist that
stuff.

All that rkhunter did was its job. He issued you warnings about some
stuff that according to its conf file is suspicious. Now, it is on you
to investigate that and see if those warnings  are serious, or not.

Re: [rkhunter] coyote.coyote.den - Daily report

[Alexander V. Makartsev]

On 28.11.2017 15:16, Brian wrote:
> On Tue 28 Nov 2017 at 14:04:58 +0500, Alexander V. Makartsev wrote:
>
>> 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.
That could be nothing to do with firefox-esr. Just because some package
was installed last doesn't always means it will be the source of the
problem.
Anyway, creating software that will reliably detect something meant to
be undetectable like rootkit, while evading rootkit's protection
measures against well-known anti-rootkit software is impossible.
When I read that log Gene posted and seen "6667 port" I was like "Holy
shit this is serious", but then I looked up for "portsentry" and
realized it is FP.
"rkhunter" had every right to panic and it's user's fault to not know
about how "portsentry" works. (IF this is legit "portsentry" not
something that just has its name)
>> "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.
> 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.
>
That said, it is better to know at least something and investigate, than
just saying "meh its another FP" and uninstall the software.
"rkhunter" has served it's purpose at least to urge "less experienced
users" to do a research and learn.


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: [rkhunter] coyote.coyote.den - Daily report

[Brian]

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.

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.

-- 
Brian.

Re: [rkhunter] coyote.coyote.den - Daily report

[Alexander V. Makartsev]

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.
"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.

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: [rkhunter] coyote.coyote.den - Daily report

[Alexander V. Makartsev]

On 28.11.2017 12:09, deloptes wrote:
> Gene Heskett wrote:
>
>> [21:15:19]          Process: /usr/lib/firefox-esr/firefox-esr    PID:
>> 16994    Owner: gene
>> [21:15:19]          Process: /usr/lib/firefox-esr/firefox-esr    PID:
>> 16994    Owner: gene
> the only reason for using esr is flash - do you have it enabled active or
> running - might be worth looking in firefox what is causing the problem.
>
> otherwise I would ignore it - just a warning.
>
> regards
>
FYI, Adobe Flash Plugin is working normally with latest Mozilla Firefox
57.0 64-bit. FF57 is great performance wise too.


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: [rkhunter] coyote.coyote.den - Daily report

[deloptes]

Gene Heskett wrote:

> [21:15:19]          Process: /usr/lib/firefox-esr/firefox-esr    PID:
> 16994    Owner: gene
> [21:15:19]          Process: /usr/lib/firefox-esr/firefox-esr    PID:
> 16994    Owner: gene

the only reason for using esr is flash - do you have it enabled active or
running - might be worth looking in firefox what is causing the problem.

otherwise I would ignore it - just a warning.

regards

Re: [rkhunter] coyote.coyote.den - Daily report

[Gene Heskett]

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]
> > >
> > > > How should I restore?
> > >
> > > Restore what?
> >
> > An obviously contaminated firefox-esr. Or whatever in this list is
> > contaminated: Its to complete list from the last wheezy update.
> >
> > Turns out that rkhunter looked over firefox-esr on its previous run
> > and apparently gave it a passing grade. So I have to assume its
> > something in yesterdays list:
>
> [Long list 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
-- 
"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 

Re: [rkhunter] coyote.coyote.den - Daily report

[Gene Heskett]

On Monday 27 November 2017 17:32:44 deloptes wrote:

> Gene Heskett wrote:
> > Warning: The following suspicious shared
> >
> >> memory segments have been found: Process:
> >> /usr/lib/firefox-esr/firefox-esr    PID: 16994    Owner: gene
> >> Process: /usr/lib/firefox-esr/firefox-esr    PID: 16994    Owner:
> >> gene Warning:
>
> do you have this same today?
>
That is todays. I have it set to scan at nominally 14:30 each day.

So unless I run it by hand, I won't get another email from it till 
Tuesday afternoon.  So we'll see if its a fluke.

> the message is pretty clear - warning: suspicious shared memory
> segments
>
> might be rkhunter got smarter or there was really something messed in
> memory?

Dunno. Ran it by hand, and found this:
Warning: The following suspicious shared memory segments have been found:
[21:15:19]  Process: /usr/lib/firefox-esr/firefox-esrPID: 
16994Owner: gene
[21:15:19]  Process: /usr/lib/firefox-esr/firefox-esrPID: 
16994Owner: gene

And at the end of the log, "possible rootkits: 3", scanning back up the 
log now. Its fussing about the ports portsentry uses. Running it again 
after a --propupd run.

Didn't change much if anything. System "feels" absolutely normal. Goes 
off to see about an interface card I am changing on one of the other 
machines. If it keeps it up, I'll rejoin the rkhunter list and post it 
there.

rkhunter itself hasn't been updated in yonks, config files, yes, but not 
rkhunter itself.

Sorry bout the noise.

> regards


Cheers Deloptes, 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 

Re: [rkhunter] coyote.coyote.den - Daily report

[Brian]

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]
> >
> > > How should I restore?
> >
> > Restore what?
> 
> An obviously contaminated firefox-esr. Or whatever in this list is 
> contaminated: Its to complete list from the last wheezy update.
> 
> Turns out that rkhunter looked over firefox-esr on its previous run and 
> apparently gave it a passing grade. So I have to assume its something in 
> yesterdays list:

[Long list 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.

-- 
Brian.

Re: [rkhunter] coyote.coyote.den - Daily report

[deloptes]

Gene Heskett wrote:

> Warning: The following suspicious shared
>> memory segments have been found: Process:
>> /usr/lib/firefox-esr/firefox-esr    PID: 16994    Owner: gene Process:
>> /usr/lib/firefox-esr/firefox-esr    PID: 16994    Owner: gene Warning:

do you have this same today?

the message is pretty clear - warning: suspicious shared memory segments

might be rkhunter got smarter or there was really something messed in
memory?

regards

Re: [rkhunter] coyote.coyote.den - Daily report

[Gene Heskett]

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]
>
> > How should I restore?
>
> Restore what?

An obviously contaminated firefox-esr. Or whatever in this list is 
contaminated: Its to complete list from the last wheezy update.

Turns out that rkhunter looked over firefox-esr on its previous run and 
apparently gave it a passing grade. So I have to assume its something in 
yesterdays list:
 
ark-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
atlantik-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
atlantikdesigner-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
kaddressbook-plugins-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
kasteroids-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kate-plugins-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
katomic-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kbackgammon-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kbattleship-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kblackbox-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kbounce-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kcalc-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kcharselect-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kdf-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kedit-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kenolaba-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kfloppy-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kfouleggs-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kgoldrunner-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kgpg-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
khexedit-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kicker-applets-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
kjots-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kjumpingcube-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
klaptopdaemon-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
klickety-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
klines-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kmahjongg-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kmilo-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kmines-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
knetwalk-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kolf-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
konq-plugins-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
konquest-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kpat-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kpoker-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kregexpeditor-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
kreversi-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ksame-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kshisen-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ksig-trinity (4:14.0.5~pre7-0debian7.0.0+7) to 
4:14.0.5~pre8-0debian7.0.0+7
ksim-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
ksirtet-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ksmiletris-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ksnake-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ksokoban-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
kspaceduel-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ktimer-trinity (4:14.0.5~pre9-0debian7.0.0+1) to 
4:14.0.5~pre10-0debian7.0.0+1
ktron-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
ktuberling-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
libpython2.6 (2.6.8-1.1) to 2.6.8-1.1+deb7u1
libpython2.7 (2.7.3-6+deb7u3) to 2.7.3-6+deb7u4
libtdegames1-trinity (4:14.0.5~pre7-0debian7.0.0+1) to 
4:14.0.5~pre8-0debian7.0.0+1
libxml2 (2.8.0+dfsg1-7+wheezy9) to 2.8.0+dfsg1-7+wheezy10
libxml2-dev (2.8.0+dfsg1-7+wheezy9) to 

Re: [rkhunter] coyote.coyote.den - Daily report

[Brian]

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]

> How should I restore?

Restore what?

-- 
Brian.

Re: [rkhunter] coyote.coyote.den - Daily report

[Gene Heskett]

On Monday 27 November 2017 14:35:17 root wrote:

Installed new firefox-esr yesterday, from the wheezy repos. Today, 
rkhunter has a cow:

> Warning: The command '/sbin/chkconfig' has been replaced by a script:
> /sbin/chkconfig: Perl script, ASCII text executable Warning: The
> command '/bin/which' has been replaced by a script: /bin/which: POSIX
> shell script, ASCII text executable Warning: The command
> '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser:
> Perl script, ASCII text executable Warning: The command '/usr/bin/ldd'
> has been replaced by a script: /usr/bin/ldd: Bourne-Again shell
> script, ASCII text executable Warning: The following suspicious shared
> memory segments have been found: Process:
> /usr/lib/firefox-esr/firefox-esrPID: 16994Owner: gene Process:
> /usr/lib/firefox-esr/firefox-esrPID: 16994Owner: gene Warning:
> Found enabled xinetd service: /etc/xinetd.d/amanda
> Warning: Found enabled xinetd service: /etc/xinetd.d/saned
> Warning: Found enabled xinetd service: /etc/xinetd.d/sshd-xinetd
> Warning: Network TCP port 1524 is being used by /usr/sbin/portsentry.
> Possible rootkit: Possible FreeBSD (FBRK) Rootkit backdoor Use the
> 'lsof -i' or 'netstat -an' command to check this. Warning: Network TCP
> port 6667 is being used by /usr/sbin/portsentry. Possible rootkit:
> Possible rogue IRC bot Use the 'lsof -i' or 'netstat -an' command to
> check this. Warning: Network TCP port 31337 is being used by
> /usr/sbin/portsentry. Possible rootkit: Historical backdoor port Use
> the 'lsof -i' or 'netstat -an' command to check this. Warning: The SSH
> and rkhunter configuration options should be the same: SSH
> configuration option 'PermitRootLogin': yes
>  Rkhunter configuration option 'ALLOW_SSH_ROOT_USER': no
> Warning: Hidden directory found: /etc/.java

How should I restore?

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