By the way, do not have sshd installed (and there is no /usr/sbin/sshd).
I mentioned sshd as an example. There are plenty of ways to do remote
connection to the host (telnet, VNC, XDMCP), all of them can be used
for the root access.
Just to be on a safe side, scan your host with 'nmap -sT
Please note the difference between *are/is* installed, and *were* installed.
I would expect dpkg -S to fail if those packages had been wrongly
removed (corrupting dpkg database) but the pam and man files are
extremely unlikely to be the result of malware. The OP never responded
to my query
Hi
On Tue, Feb 25, 2014 at 11:17:12AM +0100, ha wrote:
Please note the difference between *are/is* installed, and *were* installed.
I would expect dpkg -S to fail if those packages had been wrongly
removed (corrupting dpkg database) but the pam and man files are
extremely unlikely to be
My guess is that this situation is the result of invoking:
dpkg -X *deb /
or, simply unpacking a tarball into /.
But your guess is as good as mine.
The only package I installed via dpkg was youtube-dl, as I couldn't get
it by invoking apt-get install (and I still can't).
I downloaded it
I'd hate to hold anyone responsible for their memory - AFAIK no one can
remember what they don't remember (this is why we take notes and run
script) - I can only assume their memory is complete. With other areas a
guess/instinct may be good enough - with security I prefer proof.
Even if they
Looking at those files makes me think of a possible installation error:
that one or more partitions on the old install were used and mounted
without reformatting for the new install.
Is there a timestamp check that could be performed (install time/date
for the file, rather than the datetime
On 25/02/14 21:40, ha wrote:
I'd hate to hold anyone responsible for their memory - AFAIK no one can
remember what they don't remember (this is why we take notes and run
script) - I can only assume their memory is complete. With other areas a
guess/instinct may be good enough - with security
Hi.
On Tue, 25 Feb 2014 18:24:50 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
My guess is that this situation is the result of invoking:
dpkg -X *deb /
or, simply unpacking a tarball into /.
But your guess is as good as mine.
Maybe, certainly my guesses as to
On 26/02/14 02:23, Reco wrote:
Hi.
On Tue, 25 Feb 2014 18:24:50 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
My guess is that this situation is the result of invoking:
dpkg -X *deb /
or, simply unpacking a tarball into /.
But your guess is as good as mine.
Maybe,
Hi.
On Wed, 26 Feb 2014 09:32:37 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
No, of course not. debsums only checks files which belong to an
installed package. Such 'orphan' files are invisible to debsums,
regardless of the way they landed into filesystem.
Which,
I have a relatively new installation (2 months) of Debian Wheezy, and
not many additionaly packages installed. I *never* installed any virtual
machine on this computer, however, after some problems (that I first
though were hardware related) I found that vmtoolsd is installed on this
computer.
Hi
On Mon, Feb 24, 2014 at 01:14:10PM +0100, ha wrote:
I have a relatively new installation (2 months) of Debian Wheezy,
and not many additionaly packages installed. I *never* installed any
virtual machine on this computer, however, after some problems (that
I first though were hardware
Hi
I cannot see a package named vmtoolsd in the debian archives. But I
can see a package named open-vm-tools, which has files named like
that:
Yes, I know. No, I do not have open-vm-tools package.
This package seems to be the VMware Tools bit intended to be installed
on a guest VM - i.e.
Le 24.02.2014 13:14, ha a écrit :
I have a relatively new installation (2 months) of Debian Wheezy, and
not many additionaly packages installed. I *never* installed any
virtual machine on this computer, however, after some problems (that
I
first though were hardware related) I found that
FYI, this was a log entry that caught my attention:
vmusr[3785]: [ warning] [vmtoolsd] The vmusr service needs to run inside
a virtual machine.
... And I repeat once again: This is not a virtual machine and I did not
install any VM software.
--
To UNSUBSCRIBE, email to
Hi!
Try to find that file. ( run something like find / -name vmtoolsd )
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
dpkg ( or apt, aptitude, synaptic, etc ) is not the only way to install
things. It's only the most efficient ( on Debian ) and secure.
It
Hi.
On Mon, 24 Feb 2014 16:24:19 +0100
ha hiei.arh...@gmail.com wrote:
Hi!
Try to find that file. ( run something like find / -name vmtoolsd )
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
…
echo $PATH
does not shows my home directory
I did
On Monday, February 24, 2014 04:40:39 PM ha wrote:
On 02/24/14 16:24, ha wrote:
Hi!
Try to find that file. ( run something like find / -name vmtoolsd )
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
By the way, there is also /etc/vmware-tools
On 02/24/14 16:24, ha wrote:
Hi!
Try to find that file. ( run something like find / -name vmtoolsd )
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
By the way, there is also /etc/vmware-tools folder
--
To UNSUBSCRIBE, email to
Hi
On Mon, Feb 24, 2014 at 09:43:39AM -0600, y...@marupa.net wrote:
On Monday, February 24, 2014 04:40:39 PM ha wrote:
On 02/24/14 16:24, ha wrote:
Hi!
Try to find that file. ( run something like find / -name vmtoolsd )
I did. It only shows that files are there:
On Monday, February 24, 2014 03:48:04 PM Karl E. Jorgensen wrote:
Hi
On Mon, Feb 24, 2014 at 09:43:39AM -0600, y...@marupa.net wrote:
On Monday, February 24, 2014 04:40:39 PM ha wrote:
On 02/24/14 16:24, ha wrote:
Hi!
Try to find that file. ( run something like find / -name
Hi,
On Mon, Feb 24, 2014 at 09:43:39AM -0600, y...@marupa.net wrote:
This rather highlights why I like Arch's package manager (Pacman.) more than
APT. Pacman features a command (pacman -Qo file) that explicitly checks a
file
you specify for package ownership.
Interesting.
I don't have a
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
By the way, there is also /etc/vmware-tools folder
This rather highlights why I like Arch's package manager (Pacman.) more
than APT. Pacman features a command (pacman -Qo file) that explicitly
checks a file you
debsums -ac -r /mnt
Great, thanks! I didn't know about debsums.
However, it does not report anything when started from the debian live usb.
4) If, and only if debsums won't report anything unusual - purge
vmtoolsd, cleanup anything in /usr/local, change root password,
remove any ssh public
On Mon, 2014-02-24 at 16:17 +0100, ha wrote:
FYI, this was a log entry that caught my attention:
vmusr[3785]: [ warning] [vmtoolsd] The vmusr service needs to run inside
a virtual machine.
... And I repeat once again: This is not a virtual machine and I did not
install any VM
On Mon, 24 Feb 2014 17:28:32 +0100
ha hiei.arh...@gmail.com wrote:
debsums -ac -r /mnt
Great, thanks! I didn't know about debsums.
However, it does not report anything when started from the debian live usb.
Well, that's good. Meaning, that's simply a misuse of root, not a
rooted host.
2014-02-24 18:05 keltezéssel, Reco írta:
Well, that's good. Meaning, that's simply a misuse of root, not a
rooted host. No reinstall in necessary, probably, simple removal of:
/etc/init.d/vmtoolsd
/etc/pam.d/vmtoolsd
/usr/bin/vmtoolsd
should do it.
Or simply apt-get purge open-vm-tools.
On Mon, 24 Feb 2014 18:26:30 +0100
Nemeth Gyorgy fri...@freemail.hu wrote:
2014-02-24 18:05 keltezéssel, Reco írta:
Well, that's good. Meaning, that's simply a misuse of root, not a
rooted host. No reinstall in necessary, probably, simple removal of:
/etc/init.d/vmtoolsd
On Mon, 2014-02-24 at 09:51 -0600, y...@marupa.net wrote:
Thank you. Using that command it'd be trivial to see if those files
were installed by the package manager, maybe a dependency, which is
more likely than being compromised, in all honesty.
When something is installed as a dependency,
On Mon 24 Feb 2014 at 19:23:29 +0100, Ralf Mardorf wrote:
On Mon, 2014-02-24 at 09:51 -0600, y...@marupa.net wrote:
Thank you. Using that command it'd be trivial to see if those files
were installed by the package manager, maybe a dependency, which is
more likely than being compromised, in
Yes - you are paranoid. There is no conspiracy. Those files were
installed by the operator/user/sysadmin.
So relax. :)
If you want to remove them:-
# apt-get remove open-vm-tools open-vm-toolbox
On 25/02/14 03:04, ha wrote:
I did. It only shows that files are there:
/etc/pam.d/vmtoolsd
On 25/02/14 04:44, Reco wrote:
On Mon, 24 Feb 2014 18:26:30 +0100
Nemeth Gyorgy fri...@freemail.hu wrote:
2014-02-24 18:05 keltezéssel, Reco írta:
Well, that's good. Meaning, that's simply a misuse of root, not a
rooted host. No reinstall in necessary, probably, simple removal of:
On 25/02/14 11:03, Scott Ferguson wrote:
Yes - you are paranoid. There is no conspiracy. Those files were
installed by the operator/user/sysadmin.
So relax. :)
If you want to remove them:-
# apt-get remove open-vm-tools open-vm-toolbox
and
# apt-get remove zerofree open-vm-dkms libdumbnet1
Hi.
On Tue, 25 Feb 2014 11:07:23 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
Am I missing part of the thread?
Probably no, as you've replied in it:
https://lists.debian.org/debian-user/2014/02/msg01346.html
Where did the OP check to see if
open-vm-tools and
On 25/02/14 16:16, Reco wrote:
Hi.
On Tue, 25 Feb 2014 11:07:23 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
Am I missing part of the thread?
Probably no, as you've replied in it:
https://lists.debian.org/debian-user/2014/02/msg01346.html
Where did the OP
Hi.
On Tue, 25 Feb 2014 16:48:37 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
Please note the difference between *are/is* installed, and *were* installed.
There's a difference, indeed.
I would expect dpkg -S to fail if those packages had been wrongly
removed
On Mon, 24 Feb 2014, Scott Ferguson wrote:
Yes - you are paranoid. There is no conspiracy. Those files were
installed by the operator/user/sysadmin.
So relax. :)
Besides, we're not scheduled to come after you until next month.
--|
John L. Ries |
Salford
debsums -ac -r /mnt
Great, thanks! I didn't know about debsums.
However, it does not report anything when started from the debian live
usb.
Hopefully you realise that should take quite a while to run, and you
correctly mounted etc for your check...
Well, that's good. Meaning, that's
On 2/25/14, Zenaan Harkness z...@freedbms.net wrote:
debsums -ac -r /mnt
Great, thanks! I didn't know about debsums.
However, it does not report anything when started from the debian live
usb.
Hopefully you realise that should take quite a while to run, and you
correctly mounted etc for
Thanks for replying
On 25/02/14 17:10, Reco wrote:
Hi.
On Tue, 25 Feb 2014 16:48:37 +1100
Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:
Please note the difference between *are/is* installed, and *were* installed.
There's a difference, indeed.
I would expect dpkg -S
On 25/02/14 17:22, John L. Ries wrote:
On Mon, 24 Feb 2014, Scott Ferguson wrote:
Yes - you are paranoid. There is no conspiracy. Those files were
installed by the operator/user/sysadmin.
So relax. :)
Besides, we're not scheduled to come after you until next month.
That's what you want us
41 matches
Mail list logo
