Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Paul Johnson
On Tue, 2008-08-26 at 23:10 +0100, Adam Hardy wrote:

> All the hacker needs to do, before rooting the system, is to run my cronjobs 
> and 
> save the output, and then change the cronjobs to email me these 'all clear' 
> reports instead. The reports don't even have dates or times that require 
> updating. I have been known to let my server run for weeks without logging on.

One way to get around this problem is to have mails to root sent to an
email account you have off-site.  Since rkhunter's output isn't sitting
in a local mail spool, an intruder trying to hide his footsteps would
have to compromise a second system to get at your email to stop you from
receiving it's output.

-- 
Paul Johnson
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Sam Kuper
2008/8/27 Eduardo M KALINOWSKI <[EMAIL PROTECTED]>:
> What I could recommend is to run only the necessary services, and if
> possible restrict the IPs allowed to connect to them, keep the system
> updated with security fixes, make frequent backups, and other obvious
> things that we all already know of. :-)

This, essentially, is what I am aiming to do. Without physical access
to my server, it really does seem to be the best possible approach. At
the moment, I'm working on a script to automate the initial deployment
of the various security/hardening packages, on the basis that the
faster those are installed and set up once the server is live, the
greater the chance of security.

It's no small task to write that script though, that's for sure. Each
package has its own quirks that have to be accounted for one way or
another. I can't quite believe how much time it's taking me to finish!

Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Eduardo M KALINOWSKI
Sam Kuper wrote:
> 2) Assuming your server is hosted with VPSVille, Slicehost or some
> other hosting company that doesn't give you physical access but does
> have a facility for reinstalling your OS on demand, you could, in the
> following order:
>
> - Back up your data from it locally;
> - Prepare a script that will run iptables to disable all connections
> except SSH access and apt-get connections;
> - Reinstall the OS;
> - Immediately log in, upload the script and run it;
> - apt-get install rkhunter;
> - Generate the hashes (if you're on Etch, this won't work, as the
> rkhunter in Etch doesn't include the -propupd option, but on Lenny it
> should be possible. For ways to generate rkhunter hashes on Etch, see
> my recent mailing list thread, "rkhunter on Etch");
> - download copies to your local machine.
>
> Congratulations. Unless someone rooted you in the few minutes it took
> to do this (this is very unlikely unless your hosting provider
> installs the OS in some crazy-ass wide-open-to-exploitation fashion -
> see point 1 above), you now have a set of hashes you can trust, and
> which you can write to RO media from your local machine.
>
> NB. I haven't tried this myself, but I'm putting together a plan for
> securing my own VPS, and this is the general principle (I should add,
> I won't be relying solely on rkhunter!). So, if anyone reads the above
> and spots that I've missed something crucial, please let me know :)
>   

It looks like a fine plan, the probability that someone attacked the
system in the small interval it was open is as small as it can get.

However, how will  you do verification? If the worst happen and someone
gets access to the system, it is possible to hide their traces, and in
some way return the valid hashes instead of the actual ones for the
infected files. That is, however, not necessarily feasible, and
combining this with other checks, the probability of an attack going
undetected is small, though it could happen.

What I could recommend is to run only the necessary services, and if
possible restrict the IPs allowed to connect to them, keep the system
updated with security fixes, make frequent backups, and other obvious
things that we all already know of. :-)

-- 
White dwarf seeks red giant for binary relationship.

Eduardo M KALINOWSKI
[EMAIL PROTECTED]
http://move.to/hpkb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Sam Kuper
2008/8/26 Adam Hardy <[EMAIL PROTECTED]>:
> The more I think about it, the more I believe some sharp hacker out there
> could easily have fooled me for months.
>
> Any suggestions now?

1) Be slightly less paranoid :)

2) Assuming your server is hosted with VPSVille, Slicehost or some
other hosting company that doesn't give you physical access but does
have a facility for reinstalling your OS on demand, you could, in the
following order:

- Back up your data from it locally;
- Prepare a script that will run iptables to disable all connections
except SSH access and apt-get connections;
- Reinstall the OS;
- Immediately log in, upload the script and run it;
- apt-get install rkhunter;
- Generate the hashes (if you're on Etch, this won't work, as the
rkhunter in Etch doesn't include the -propupd option, but on Lenny it
should be possible. For ways to generate rkhunter hashes on Etch, see
my recent mailing list thread, "rkhunter on Etch");
- download copies to your local machine.

Congratulations. Unless someone rooted you in the few minutes it took
to do this (this is very unlikely unless your hosting provider
installs the OS in some crazy-ass wide-open-to-exploitation fashion -
see point 1 above), you now have a set of hashes you can trust, and
which you can write to RO media from your local machine.

NB. I haven't tried this myself, but I'm putting together a plan for
securing my own VPS, and this is the general principle (I should add,
I won't be relying solely on rkhunter!). So, if anyone reads the above
and spots that I've missed something crucial, please let me know :)

Sam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Adam Hardy

Eduardo M KALINOWSKI on 26/08/08 13:45, wrote:

Adam Hardy escreveu:
After-the-attack identification of a rootkit attack, it seems, can 
always be compromised if there is no safe read-only hash or encryption 
of the known-good system binaries.


Unfortunately, I think that if you do not have physical access to the 
machine, this problem is (at least theoretically) unsolveable.


The checksums must be created when the system is in a known good state, 
preferably just after system installation, and stored somewhere else. 
With physical access, you can burn them on a CD. Without that, the 
machine must be connected to the network for the installation of 
packages, checksum generation and final transfer of the checksum file to 
another machine. In theory there could be an attack during that time, 
and you could end up with a file with false checksums, but the attacker 
must be able to use that time opportunity, and since you only need a ssh 
server, I'd say it's quite unlikely that the checksum file is someway 
invalid.


The biggest problem is in verification time. If you have physical 
access, you can boot a Live-CD and run the checkum verification with a 
program that is known to be good. However, without physical access, 
you'd have to resort to checking the system as it is, that is, in a 
possibly infected state. And in this case, you'd end up using the 
checksum program that is in the system, which could be modified to hide 
the rootkit, and you'd not find the infection.


There are ways to try to circumvent that (such as copying a statically 
linked checksum program and using that instead of the system one), but 
if the rootkit is running, it could, at least in theory, hide itself, 
for example by intercepting system calls that read infected files and 
returning instead data corresponding to a good file.


The only way to be completely sure that you are getting reliable results 
is to run the verification when the rootkit could not be running - and 
this requires you booting in another system via a Live CD, or removing 
the HD, installing it in another machine and booting that second 
machine, for example. Both cases require physical access.


I also ignored the relatively larger vulnerability - where I rely on the email 
message from a cronjob to forward me the results of chkrootkit or rkhunter or 
any software I might use.


All the hacker needs to do, before rooting the system, is to run my cronjobs and 
save the output, and then change the cronjobs to email me these 'all clear' 
reports instead. The reports don't even have dates or times that require 
updating. I have been known to let my server run for weeks without logging on.


:(

The more I think about it, the more I believe some sharp hacker out there could 
easily have fooled me for months.


Any suggestions now?

Regards
Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Eduardo M KALINOWSKI

Adam Hardy escreveu:
After the attack, I quickly realized that I have no definitive way of 
deciding if my system was rooted or not, and so I installed rkhunter. 
This provides a simple hash-based mechanism to create an image of the 
clean system (although I can't actually do that with the Etch version).


However even if I had been able to create the hashes on my system for 
rkhunter, they would have to be on read-write media, i.e. the system's 
local hard drive, and therefore could also be 'rooted' by the hacker, 
preventing rkhunter from identifying the attack.


I am not aware of an actual Debian package or indeed any program that 
can get around this simple conundrum.


After-the-attack identification of a rootkit attack, it seems, can 
always be compromised if there is no safe read-only hash or encryption 
of the known-good system binaries.


Unfortunately, I think that if you do not have physical access to the 
machine, this problem is (at least theoretically) unsolveable.


The checksums must be created when the system is in a known good state, 
preferably just after system installation, and stored somewhere else. 
With physical access, you can burn them on a CD. Without that, the 
machine must be connected to the network for the installation of 
packages, checksum generation and final transfer of the checksum file to 
another machine. In theory there could be an attack during that time, 
and you could end up with a file with false checksums, but the attacker 
must be able to use that time opportunity, and since you only need a ssh 
server, I'd say it's quite unlikely that the checksum file is someway 
invalid.


The biggest problem is in verification time. If you have physical 
access, you can boot a Live-CD and run the checkum verification with a 
program that is known to be good. However, without physical access, 
you'd have to resort to checking the system as it is, that is, in a 
possibly infected state. And in this case, you'd end up using the 
checksum program that is in the system, which could be modified to hide 
the rootkit, and you'd not find the infection.


There are ways to try to circumvent that (such as copying a statically 
linked checksum program and using that instead of the system one), but 
if the rootkit is running, it could, at least in theory, hide itself, 
for example by intercepting system calls that read infected files and 
returning instead data corresponding to a good file.


The only way to be completely sure that you are getting reliable results 
is to run the verification when the rootkit could not be running - and 
this requires you booting in another system via a Live CD, or removing 
the HD, installing it in another machine and booting that second 
machine, for example. Both cases require physical access.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881 - conundrum

2008-08-26 Thread Adam Hardy

Osamu Aoki on 25/08/08 16:41, wrote:

Hi,

On Thu, Aug 14, 2008 at 10:51:56PM +0100, Adam Hardy wrote:

Adam Hardy on 13/08/08 10:27, wrote:

Martin on 12/08/08 16:34, wrote:

On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy <[EMAIL PROTECTED]>
wrote:

The question is, what do I replace chkrootkit with, especially if stuff
like rkhunter's not much better?

tripwire maybe?

apt-cache show tripwire Description: file and directory integrity
checker Tripwire is a tool that aids system administrators and users
in monitoring a designated set of files for any changes.  Used with
system files on a regular (e.g., daily) basis, Tripwire can notify
system administrators of corrupted or tampered files, so damage
control measures can be taken in a timely manner. 

I don't have access to a floppy or cdrom drive - the server is hosted
somewhere at an ISP. I think any cracker would just re-run tripwire
if they found it installed.

The only suggestion so far is that I script a solution (or adapt existing ones).


Have you looked at harden-doc and its friends in archive.  (Many are
virtual packages to lead you to the good tools) tripwire is just one of
the tools.   


I do not think you need to have CDROM to be sure and your quick
scripting may not come close to tripwire which protect itself with
cryptographies.

Even for simple hush you do not need home made hush.  Have you looked
at debsum?  If a pakage is tampered, debsum gets updated and detectable.

Surely there's a package available that's made for people with 1 or 2 
hosted servers that need a foolproof cracker alarm? 


Are you saying package available is not good enough?


Looking through apt-cache search, there seem to be loads of nasty
packages available for people who might want to attack my server, but
not much that I can use to check whether I've been rooted.


I do not understand what is "nasty".

Anyway, all your answer is in harden-doc.

Also available on web as:
 http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html


After reading up on this and thinking about the situation, I believe that it's 
not actually solveable for me.


As stated previously, I saw what was possibly a false alarm from chkrootkit 
recently on my webserver, hosted somewhere where I only have ssh access and 
definitely no physical access to provide a CD or any read-only media.


After the attack, I quickly realized that I have no definitive way of deciding 
if my system was rooted or not, and so I installed rkhunter. This provides a 
simple hash-based mechanism to create an image of the clean system (although I 
can't actually do that with the Etch version).


However even if I had been able to create the hashes on my system for rkhunter, 
they would have to be on read-write media, i.e. the system's local hard drive, 
and therefore could also be 'rooted' by the hacker, preventing rkhunter from 
identifying the attack.


I am not aware of an actual Debian package or indeed any program that can get 
around this simple conundrum.


After-the-attack identification of a rootkit attack, it seems, can always be 
compromised if there is no safe read-only hash or encryption of the known-good 
system binaries.


Regards
Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-25 Thread Adam Hardy

Osamu Aoki on 25/08/08 16:41, wrote:

On Thu, Aug 14, 2008 at 10:51:56PM +0100, Adam Hardy wrote:

Adam Hardy on 13/08/08 10:27, wrote:

apt-cache show tripwire Description: file and directory integrity
checker Tripwire is a tool that aids system administrators and users
in monitoring a designated set of files for any changes.  Used with
system files on a regular (e.g., daily) basis, Tripwire can notify
system administrators of corrupted or tampered files, so damage
control measures can be taken in a timely manner. 

I don't have access to a floppy or cdrom drive - the server is hosted
somewhere at an ISP. I think any cracker would just re-run tripwire
if they found it installed.

The only suggestion so far is that I script a solution (or adapt existing ones).


Have you looked at harden-doc and its friends in archive.  (Many are
virtual packages to lead you to the good tools) tripwire is just one of
the tools.   


I do not think you need to have CDROM to be sure and your quick
scripting may not come close to tripwire which protect itself with
cryptographies.

Even for simple hush you do not need home made hush.  Have you looked
at debsum?  If a pakage is tampered, debsum gets updated and detectable.


That's a distinct possibility. For instance,

debsums procps

would give an immediate sign that something has been rooted.

That is assuming that the rootkit is not smart enough to cover its tracks in the 
package MD5 checksums. Could that be 'rooted' too?


Thanks and regards
Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-25 Thread Osamu Aoki
Hi,

On Thu, Aug 14, 2008 at 10:51:56PM +0100, Adam Hardy wrote:
> Adam Hardy on 13/08/08 10:27, wrote:
>> Martin on 12/08/08 16:34, wrote:
>>> On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy <[EMAIL PROTECTED]>
>>> wrote:
 The question is, what do I replace chkrootkit with, especially if stuff
 like rkhunter's not much better?
>>>
>>> tripwire maybe?
>>>
>>> apt-cache show tripwire Description: file and directory integrity
>>> checker Tripwire is a tool that aids system administrators and users
>>> in monitoring a designated set of files for any changes.  Used with
>>> system files on a regular (e.g., daily) basis, Tripwire can notify
>>> system administrators of corrupted or tampered files, so damage
>>> control measures can be taken in a timely manner. 
>>
>> I don't have access to a floppy or cdrom drive - the server is hosted
>> somewhere at an ISP. I think any cracker would just re-run tripwire
>> if they found it installed.
>
> The only suggestion so far is that I script a solution (or adapt existing 
> ones).

Have you looked at harden-doc and its friends in archive.  (Many are
virtual packages to lead you to the good tools) tripwire is just one of
the tools.   

I do not think you need to have CDROM to be sure and your quick
scripting may not come close to tripwire which protect itself with
cryptographies.

Even for simple hush you do not need home made hush.  Have you looked
at debsum?  If a pakage is tampered, debsum gets updated and detectable.

> Surely there's a package available that's made for people with 1 or 2 
> hosted servers that need a foolproof cracker alarm? 

Are you saying package available is not good enough?

> Looking through apt-cache search, there seem to be loads of nasty
> packages available for people who might want to attack my server, but
> not much that I can use to check whether I've been rooted.

I do not understand what is "nasty".

Anyway, all your answer is in harden-doc.

Also available on web as:
 http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881

2008-08-14 Thread Adam Hardy

Adam Hardy on 13/08/08 10:27, wrote:

Martin on 12/08/08 16:34, wrote:

On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy <[EMAIL PROTECTED]>
wrote:

The question is, what do I replace chkrootkit with, especially if stuff
like rkhunter's not much better?


tripwire maybe?

apt-cache show tripwire Description: file and directory integrity checker 
Tripwire is a tool that aids system administrators and users in monitoring

a designated set of files for any changes.  Used with system files on a
regular (e.g., daily) basis, Tripwire can notify system administrators of
corrupted or tampered files, so damage control measures can be taken in a
timely manner. 


I don't have access to a floppy or cdrom drive - the server is hosted 
somewhere at an ISP. I think any cracker would just re-run tripwire if they

found it installed.


The only suggestion so far is that I script a solution (or adapt existing ones).

Surely there's a package available that's made for people with 1 or 2 hosted 
servers that need a foolproof cracker alarm? Looking through apt-cache search, 
there seem to be loads of nasty packages available for people who might want to 
attack my server, but not much that I can use to check whether I've been rooted.



regards
Adam




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-14 Thread David Barrett

Adam Hardy wrote:

David Barrett on 13/08/08 20:22, wrote:

Adam Hardy wrote:

Martin on 12/08/08 16:34, wrote:
On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy 
<[EMAIL PROTECTED]> wrote:
The question is, what do I replace chkrootkit with, especially if 
stuff like

rkhunter's not much better?

[snip]

One script I use for a similar purpose is "hashall.sh":

#!/bin/sh
find / \( ! -wholename "/sys/*" \) \( ! -wholename "/proc/*" \) -type 
f -print0 | sort -z | xargs -0 sha1sum > `date | sed -e 'y/ 
:/__/'`.hashes


Basically, find every file on disk, take sha1sum, and output it in a 
sorted list.  Run this twice and the resulting output is comparable 
with "diff" to quickly see what has changed.


I currently use this after a new install just to get a snapshot of the 
base state so I can identify changes.  But my plan is to have two 
servers monitor each other by having each


1) SCP over a "clean" copy of find, sort, xargs, and sha1sum
2) Run this on the whole server
3) Compare the result to a known "clean run"

Granted, a recursive sha1sum isn't cheap, but it can be toned down by 
tightening up the rules to cut out files you don't care about.


David,

what does \( ! -wholename "/sys/*" \) do? Excludes sys directory?

regards
Adam


Correct.

-david


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-14 Thread Adam Hardy

David Barrett on 13/08/08 20:22, wrote:

Adam Hardy wrote:

Martin on 12/08/08 16:34, wrote:
On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy 
<[EMAIL PROTECTED]> wrote:
The question is, what do I replace chkrootkit with, especially if 
stuff like

rkhunter's not much better?

[snip]

One script I use for a similar purpose is "hashall.sh":

#!/bin/sh
find / \( ! -wholename "/sys/*" \) \( ! -wholename "/proc/*" \) -type f 
-print0 | sort -z | xargs -0 sha1sum > `date | sed -e 'y/ :/__/'`.hashes


Basically, find every file on disk, take sha1sum, and output it in a 
sorted list.  Run this twice and the resulting output is comparable with 
"diff" to quickly see what has changed.


I currently use this after a new install just to get a snapshot of the 
base state so I can identify changes.  But my plan is to have two 
servers monitor each other by having each


1) SCP over a "clean" copy of find, sort, xargs, and sha1sum
2) Run this on the whole server
3) Compare the result to a known "clean run"

Granted, a recursive sha1sum isn't cheap, but it can be toned down by 
tightening up the rules to cut out files you don't care about.


David,

what does \( ! -wholename "/sys/*" \) do? Excludes sys directory?

regards
Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-13 Thread David Barrett

Adam Hardy wrote:

Martin on 12/08/08 16:34, wrote:
On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy 
<[EMAIL PROTECTED]> wrote:
The question is, what do I replace chkrootkit with, especially if 
stuff like

rkhunter's not much better?


tripwire maybe?

apt-cache show tripwire
Description: file and directory integrity checker
 Tripwire is a tool that aids system administrators and users in
 monitoring a designated set of files for any changes.  Used with
 system files on a regular (e.g., daily) basis, Tripwire can notify
 system administrators of corrupted or tampered files, so damage
 control measures can be taken in a timely manner.
Tag: admin::monitoring, interface::commandline, interface::daemon,
role::program, security::ids, security::integrity, use::monitor,
works-with::file, works-with::mail


I don't have access to a floppy or cdrom drive - the server is hosted 
somewhere at an ISP. I think any cracker would just re-run tripwire if 
they found it installed.


Perhaps I could write a script to retrieve some hashes from another 
server? Does that make sense?


One script I use for a similar purpose is "hashall.sh":

#!/bin/sh
find / \( ! -wholename "/sys/*" \) \( ! -wholename "/proc/*" \) -type f 
-print0 | sort -z | xargs -0 sha1sum > `date | sed -e 'y/ :/__/'`.hashes


Basically, find every file on disk, take sha1sum, and output it in a 
sorted list.  Run this twice and the resulting output is comparable with 
"diff" to quickly see what has changed.


I currently use this after a new install just to get a snapshot of the 
base state so I can identify changes.  But my plan is to have two 
servers monitor each other by having each


1) SCP over a "clean" copy of find, sort, xargs, and sha1sum
2) Run this on the whole server
3) Compare the result to a known "clean run"

Granted, a recursive sha1sum isn't cheap, but it can be toned down by 
tightening up the rules to cut out files you don't care about.


-david


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-13 Thread Adam Hardy

Martin on 12/08/08 16:34, wrote:

On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy <[EMAIL PROTECTED]> wrote:

The question is, what do I replace chkrootkit with, especially if stuff like
rkhunter's not much better?


tripwire maybe?

apt-cache show tripwire
Description: file and directory integrity checker
 Tripwire is a tool that aids system administrators and users in
 monitoring a designated set of files for any changes.  Used with
 system files on a regular (e.g., daily) basis, Tripwire can notify
 system administrators of corrupted or tampered files, so damage
 control measures can be taken in a timely manner.
Tag: admin::monitoring, interface::commandline, interface::daemon,
role::program, security::ids, security::integrity, use::monitor,
works-with::file, works-with::mail


I don't have access to a floppy or cdrom drive - the server is hosted somewhere 
at an ISP. I think any cracker would just re-run tripwire if they found it 
installed.


Perhaps I could write a script to retrieve some hashes from another server? Does 
that make sense?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-12 Thread Martin
Hi,

On Tue, Aug 12, 2008 at 5:12 PM, Adam Hardy <[EMAIL PROTECTED]> wrote:
> The question is, what do I replace chkrootkit with, especially if stuff like
> rkhunter's not much better?

tripwire maybe?

apt-cache show tripwire
Description: file and directory integrity checker
 Tripwire is a tool that aids system administrators and users in
 monitoring a designated set of files for any changes.  Used with
 system files on a regular (e.g., daily) basis, Tripwire can notify
 system administrators of corrupted or tampered files, so damage
 control measures can be taken in a timely manner.
Tag: admin::monitoring, interface::commandline, interface::daemon,
role::program, security::ids, security::integrity, use::monitor,
works-with::file, works-with::mail



-- 
http://www.xing.com/profile/Martin_Marcher

You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881

2008-08-12 Thread Adam Hardy

s. keeling on 06/08/08 03:55, wrote:

Joey Hess <[EMAIL PROTECTED]>:

 Thomas Preud'homme wrote:

I don't think it's that important. chkrootkit seems a little hazardous=20
since there was a bug about chkrootkit killing a random process (in=20
fact one of its test was sending a signal to process 12345, this bug=20
has been corrected).

 That anyone could code such a thing was astounding.. until I looked at the =
 part
 of chrootkit's code that's responsible for the "INFECTED PORTS" message:

   bindshell () {
   PORT=3D"114|145|465|511|600|1008|1524|1999|1978|2881|3049|3133|3879|4000|=
 4369|5190|5665|6667|10008|12321|23132|27374|29364|30999|31336|31337|37998|4=
 5454|47017|47889|60001|7222"

 So, rootkits only bind to this small list of high ports? If I were


fwiw, Moe Trin (Old Guy) has been screaming this for years.  Ditto
rkhunter.  Both of them are _false_ sense of security stuff, as their
tests are trivially bypassed.

They should be removed, or discounted loudly.


OK so I'm convinced chkrootkit is only a small help in the fight against wannabe 
crackers. But chkrootkit has been giving me warnings of rootkits alot more 
frequently over the last 10 days since this event happened so I'm going to get 
the system wiped and re-installed.


The question is, what do I replace chkrootkit with, especially if stuff like 
rkhunter's not much better?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-09 Thread Paul Johnson
On Mon, 2008-08-04 at 13:19 -0400, Joey Hess wrote:

> filtered != open
> 
>Filtered means that a firewall, filter,
>or other network obstacle is blocking the port so that Nmap cannot 
> tell whether
>it is open or closed. -- man nmap

I wish nmap would call "filtered" by a more accurate description:
"broken."  Firewalls and routers must send back that the port is closed,
not just silently ignore the connection.  That's in the STDs.

-- 
Paul Johnson
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: chkrootkit infected ports 2881

2008-08-09 Thread Paul Johnson
On Mon, 2008-08-04 at 14:52 +0100, Adam Hardy wrote:

> Yes, you are right, and I have been too slack to get around to changing it. I 
> am 
> looking at installing tripwire (after a fresh install) to be able to check up 
> what is going on after the fact.

If you have more than one machine, you might consider talking to
Tripwire, Inc. about getting Tripwire Enterprise.  The open edition
isn't bad for a few machines and a small number of users, but if you
really need to track changes made by many administrators on many
machines, Tripwire Enterprise is going to be better suited.

-- 
Paul Johnson
[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part


Re: chkrootkit infected ports 2881

2008-08-06 Thread s. keeling
Joey Hess <[EMAIL PROTECTED]>:
> 
>  Thomas Preud'homme wrote:
> > I don't think it's that important. chkrootkit seems a little hazardous=20
> > since there was a bug about chkrootkit killing a random process (in=20
> > fact one of its test was sending a signal to process 12345, this bug=20
> > has been corrected).
> 
>  That anyone could code such a thing was astounding.. until I looked at the =
>  part
>  of chrootkit's code that's responsible for the "INFECTED PORTS" message:
> 
>bindshell () {
>PORT=3D"114|145|465|511|600|1008|1524|1999|1978|2881|3049|3133|3879|4000|=
>  4369|5190|5665|6667|10008|12321|23132|27374|29364|30999|31336|31337|37998|4=
>  5454|47017|47889|60001|7222"
> 
>  So, rootkits only bind to this small list of high ports? If I were

fwiw, Moe Trin (Old Guy) has been screaming this for years.  Ditto
rkhunter.  Both of them are _false_ sense of security stuff, as their
tests are trivially bypassed.

They should be removed, or discounted loudly.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://blinkynet.net/comp/uip5.html  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: chkrootkit infected ports 2881

2008-08-04 Thread Joey Hess
Adam Hardy wrote:
> Not shown: 65529 closed ports
> PORT  STATE SERVICE
> 22/tcpopen  ssh
> 25/tcpopen  smtp
> 80/tcpopen  http
> 443/tcp   open  https
> 3306/tcp  open  mysql
> 12121/tcp open  unknown
>
>
> But when I run nmap from my home machine to scan it remotely, I see these 
> extra ports are open:
>
> Not shown: 65524 closed ports
> PORT  STATESERVICE
> 22/tcpopen ssh
> 25/tcpopen smtp
> 80/tcpopen http
> 443/tcp   open https
> 1720/tcp  filtered H.323/Q.931
> 3306/tcp  open mysql
> /tcp  filtered irc
> 6667/tcp  filtered irc
> 6668/tcp  filtered irc
> 6669/tcp  filtered irc
> 12121/tcp open unknown
>
> So I have 1720, , 6667, 6668 and 6669 open and nmap is ignoring them. 
> Isn't that conclusive evidence that nmap on the suspected machine is some 
> hacker's version?

filtered != open

   Filtered means that a firewall, filter,
   or other network obstacle is blocking the port so that Nmap cannot tell 
whether
   it is open or closed. -- man nmap

The only unusual thing here is that port 12121. netstat -p can probably
tell you what program is listening on that port. (Well, I don't know why
you have a SQL server listening for connections from the outside world
either.)

-- 
see shy jo


signature.asc
Description: Digital signature


Re: chkrootkit infected ports 2881

2008-08-04 Thread Joey Hess
Thomas Preud'homme wrote:
> I don't think it's that important. chkrootkit seems a little hazardous 
> since there was a bug about chkrootkit killing a random process (in 
> fact one of its test was sending a signal to process 12345, this bug 
> has been corrected).

That anyone could code such a thing was astounding.. until I looked at the part
of chrootkit's code that's responsible for the "INFECTED PORTS" message:

  bindshell () {
  
PORT="114|145|465|511|600|1008|1524|1999|1978|2881|3049|3133|3879|4000|4369|5190|5665|6667|10008|12321|23132|27374|29364|30999|31336|31337|37998|45454|47017|47889|60001|7222"

So, rootkits only bind to this small list of high ports? If I were
writing a rootkit, mine wouldn't. I've got a list right here; why would I
choose any of the ports on it? Why is something on port 2881 any
more indicative of a rootkit than something on port 2880? I'd suggest
instead that it's _less_ indicative of a good rootkit!

   OPT="-an"
   for P in `echo $PORT | ${sed} 's/|/ /g'`; do
  if ${netstat} "${OPT}" | ${egrep} "^tcp.*LIST|^udp" | ${egrep} \
  "[.:]${P}[^0-9.:]" >/dev/null 2>&1
  then
 PI="${PI} ${P}"
  fi
   done
   if [ "${PI}" != "" ]
   then
  echo "INFECTED (PORTS: $PI)"

So, the netstat program can be trusted? No rootkit authors will ever
consider replacing it with a version that doesn't show their ports?

And this looks for any processes listening on one of the ports for TCP, or
for any UDP that happens to be using the port whatsoever. That includes
local processes using UDP with that port, but it will also match if the remote
side is using UDP on that port.

Yes, something listening on a strange TCP port is unusual. But only as unusual
as running a ftp client or bittorrent download, or any of a number of other
things.

The UDP part of the check is much less defensible; systems use UDP with random
ports in regular operation. You may have heard of the recent DNS vulnerability
-- the fix for that is to use randomised UDP ports when making queries.

In summary, chrootkit has plenty of false positivies (just check the list
archives), and will only ever have correct positives if rootkit authors are
slower to update than it is, or stupid. When was chkrootkit last updated?
December. The rootkits it's trying to detect? 3 am last night.

-- 
see shy jo


signature.asc
Description: Digital signature


Re: chkrootkit infected ports 2881

2008-08-04 Thread Adam Hardy

Adam Hardy on 04/08/08 14:50, wrote:

thveillon.debian on 04/08/08 13:48, wrote:

Adam Hardy on 03/08/08 14:13, wrote:

[...snip]

I talked to the support at the hosting company and they looked at the
system and said they couldn't see anything wrong with it - but they
can re-image it for me which normally costs a fee.

Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is
infected.


Adam


Hi,
Chkrootkit is known to fall for quite a few false positive, for 
example if you run Portsentry or such anti-portscan demon, it also can 
detect legitimate services like dhcpd or such as sniffers, which isn't 
really incorrect but not a problem. I never heard of 2881 as being one 
of those, but maybe getting in touch with the dev team could give you 
an easy answer.

http://www.chkrootkit.org/

Maybe the only way to know for sure would be scanning all traffic from 
another system regarding this port to see if anything suspicious can 
be spotted, and maybe running an integrity check with debsum or such 
on conf files, comparing the result with a backup from an earlier 
state or a known sane system.


What would really be interesting is to spot the precise day when the 
warning first occurred from your system logs, and see if you can spot 
any change in configuration that could have triggered it (update ?). 
That is, if your system really is infected you cannot trust anything 
and especially not the logs...



I got that message in the email from early Saturday morning's cronjob.

I have been following instructions on

http://www.cert.org/tech_tips/intruder_detection_checklist.html

and I found that step 2 (look for setuid and setgid files) produces a 
file list:


[EMAIL PROTECTED]:~# find / -xdev -user root -perm -4000 -print
/bin/su
/bin/mount
/bin/umount
/bin/ping
/bin/ping6
/sbin/unix_chkpwd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/X
/usr/bin/sudo
/usr/bin/gpg
/usr/bin/sudoedit
/usr/bin/netselect
/usr/bin/traceroute.lbl
/usr/lib/pt_chown
/usr/lib/openssh/ssh-keysign
/usr/lib/apache/suexec.disabled
/usr/lib/libfakeroot-tcp.so
/usr/lib/libfakeroot-sysv.so

Again, I'm stumbling in the dark here. cert.org doesn't explain what 
this list of files signifies, it just implies that I shouldn't see it.


Also, I still have no idea what chkrootkit detected which made it decide 
to send an INFECTED alert on that port.


More suspicious stuff has turned up in my investigations. The following is the 
nmap output when I run it from the suspect rooted system:


Not shown: 65529 closed ports
PORT  STATE SERVICE
22/tcpopen  ssh
25/tcpopen  smtp
80/tcpopen  http
443/tcp   open  https
3306/tcp  open  mysql
12121/tcp open  unknown


But when I run nmap from my home machine to scan it remotely, I see these extra 
ports are open:


Not shown: 65524 closed ports
PORT  STATESERVICE
22/tcpopen ssh
25/tcpopen smtp
80/tcpopen http
443/tcp   open https
1720/tcp  filtered H.323/Q.931
3306/tcp  open mysql
/tcp  filtered irc
6667/tcp  filtered irc
6668/tcp  filtered irc
6669/tcp  filtered irc
12121/tcp open unknown

So I have 1720, , 6667, 6668 and 6669 open and nmap is ignoring them. Isn't 
that conclusive evidence that nmap on the suspected machine is some hacker's 
version?



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-04 Thread Thomas Preud'homme
Monday 04 August 2008, Adam Hardy wrote :
> thveillon.debian on 04/08/08 13:48, wrote:
>  Adam Hardy on 03/08/08 14:13, wrote:
> >
> > [...snip]
> >
>  I talked to the support at the hosting company and they looked
>  at the system and said they couldn't see anything wrong with it
>  - but they can re-image it for me which normally costs a fee.
> 
>  Is it worth re-imaging my system and re-installing everything?
> 
>  I still have no idea what chkrootkit means when it says a port
>  is infected.
> 
> 
>  Adam
> >
> > Hi,
> > Chkrootkit is known to fall for quite a few false positive, for
> > example if you run Portsentry or such anti-portscan demon, it also
> > can detect legitimate services like dhcpd or such as sniffers,
> > which isn't really incorrect but not a problem. I never heard of
> > 2881 as being one of those, but maybe getting in touch with the dev
> > team could give you an easy answer.
> > http://www.chkrootkit.org/
> >
> > Maybe the only way to know for sure would be scanning all traffic
> > from another system regarding this port to see if anything
> > suspicious can be spotted, and maybe running an integrity check
> > with debsum or such on conf files, comparing the result with a
> > backup from an earlier state or a known sane system.
> >
> > What would really be interesting is to spot the precise day when
> > the warning first occurred from your system logs, and see if you
> > can spot any change in configuration that could have triggered it
> > (update ?). That is, if your system really is infected you cannot
> > trust anything and especially not the logs...
>
> I got that message in the email from early Saturday morning's
> cronjob.
>
> I have been following instructions on
>
> http://www.cert.org/tech_tips/intruder_detection_checklist.html
>
> and I found that step 2 (look for setuid and setgid files) produces a
> file list:
>
> [EMAIL PROTECTED]:~# find / -xdev -user root -perm -4000 -print
> /bin/su
> /bin/mount
> /bin/umount
> /bin/ping
> /bin/ping6
> /sbin/unix_chkpwd
> /usr/bin/newgrp
> /usr/bin/chfn
> /usr/bin/chsh
> /usr/bin/gpasswd
> /usr/bin/passwd
> /usr/bin/X
> /usr/bin/sudo
> /usr/bin/gpg
> /usr/bin/sudoedit
> /usr/bin/netselect
> /usr/bin/traceroute.lbl
> /usr/lib/pt_chown
> /usr/lib/openssh/ssh-keysign
> /usr/lib/apache/suexec.disabled
> /usr/lib/libfakeroot-tcp.so
> /usr/lib/libfakeroot-sysv.so
>
> Again, I'm stumbling in the dark here. cert.org doesn't explain what
> this list of files signifies, it just implies that I shouldn't see
> it.
>
> Also, I still have no idea what chkrootkit detected which made it
> decide to send an INFECTED alert on that port.
>
>
> Regards
> Adam

Executables with setuid set and user root will have root rights even if 
they are launched by a user not being root. Programs with setuid set 
are launched with the right of the owner of the program (here root).

So it could be security hole and the list of such programs must be as 
smaller as possible. Here I don't see strange program which shouldn't 
have setuid set so it's fine don't worry.

Regards,

Thomas Preud'homme

-- 
Why Debian : http://www.debian.org/intro/why_debian


signature.asc
Description: This is a digitally signed message part.


Re: chkrootkit infected ports 2881

2008-08-04 Thread Adam Hardy

Thomas Preud'homme on 04/08/08 13:39, wrote:

Monday 04 August 2008, Adam Hardy wrote :

Thomas Preud'homme on 04/08/08 11:48, wrote:

Le lundi 4 août 2008, Adam Hardy a écrit :

Adam Hardy on 03/08/08 14:13, wrote:

My webserver system is actually a UML slice of a system at
memset.co.uk and all it does is run Apache Tomcat and sshd and
the stuff from memset - I thought it was pretty safe until I came
back today and found my nightly email report from chkrootkit
said:

The following suspicious files and directories were found:
/lib/init/rw/.ramfs

INFECTED (PORTS:  2881)

The .ramfs started appearing when I upgraded chkrootkit, so I
never worried about it, but Friday night's INFECTED alert was a
slap in the face with a wet fish. Saturday night's report went
back to normal - no mention of the port.

I scanned it from grc.com/x/portprobe and it came back as closed.

The only mention I can find in the logs is:

[EMAIL PROTECTED]:~# grep 2881 /var/log/*
/var/log/setuid.today:
2881   660   1 root   disk   0 Wed Apr 30
11:32:37 2008 /dev/rd/c1d30
r

and that's a PID, not a port, right?

So how bad does this look? Should I clean the system? If it is
rooted, how can I tell what the security flaw was? My password at
that point (since changed) was CE0dff2*£ so if it was a brute
force attack, then wow, they did well.

I talked to the support at the hosting company and they looked at
the system and said they couldn't see anything wrong with it - but
they can re-image it for me which normally costs a fee.

Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is
infected.


Adam

I don't think it's that important. chkrootkit seems a little
hazardous since there was a bug about chkrootkit killing a random
process (in fact one of its test was sending a signal to process
12345, this bug has been corrected).

I think a good anti-rootkit should be launched from another system
to be sure it's not deactivated by a smart rootkit.

Hopefully that is simpler than it sounds! What anti-rootkit are you
thinking of? I use chkrootkit and rkhunter.


Unfortunetely I haven't any reference but hoping a rootkit on your 
computer being launched once a day will protect you is like hoping an 
anti-virus will protect you even if a smart virus infect your computer 
between 2 launch. It's better than nothing but I don't think it's 
sufficient.


Yes, you are right, and I have been too slack to get around to changing it. I am 
looking at installing tripwire (after a fresh install) to be able to check up 
what is going on after the fact.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-04 Thread Adam Hardy

thveillon.debian on 04/08/08 13:48, wrote:

Adam Hardy on 03/08/08 14:13, wrote:

[...snip]

I talked to the support at the hosting company and they looked at the
system and said they couldn't see anything wrong with it - but they
can re-image it for me which normally costs a fee.

Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is
infected.


Adam


Hi,
Chkrootkit is known to fall for quite a few false positive, for example 
if you run Portsentry or such anti-portscan demon, it also can detect 
legitimate services like dhcpd or such as sniffers, which isn't really 
incorrect but not a problem. I never heard of 2881 as being one of 
those, but maybe getting in touch with the dev team could give you an 
easy answer.

http://www.chkrootkit.org/

Maybe the only way to know for sure would be scanning all traffic from 
another system regarding this port to see if anything suspicious can be 
spotted, and maybe running an integrity check with debsum or such on 
conf files, comparing the result with a backup from an earlier state or 
a known sane system.


What would really be interesting is to spot the precise day when the 
warning first occurred from your system logs, and see if you can spot 
any change in configuration that could have triggered it (update ?). 
That is, if your system really is infected you cannot trust anything and 
especially not the logs...



I got that message in the email from early Saturday morning's cronjob.

I have been following instructions on

http://www.cert.org/tech_tips/intruder_detection_checklist.html

and I found that step 2 (look for setuid and setgid files) produces a file list:

[EMAIL PROTECTED]:~# find / -xdev -user root -perm -4000 -print
/bin/su
/bin/mount
/bin/umount
/bin/ping
/bin/ping6
/sbin/unix_chkpwd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/X
/usr/bin/sudo
/usr/bin/gpg
/usr/bin/sudoedit
/usr/bin/netselect
/usr/bin/traceroute.lbl
/usr/lib/pt_chown
/usr/lib/openssh/ssh-keysign
/usr/lib/apache/suexec.disabled
/usr/lib/libfakeroot-tcp.so
/usr/lib/libfakeroot-sysv.so

Again, I'm stumbling in the dark here. cert.org doesn't explain what this list 
of files signifies, it just implies that I shouldn't see it.


Also, I still have no idea what chkrootkit detected which made it decide to send 
an INFECTED alert on that port.



Regards
Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-04 Thread thveillon.debian

Adam Hardy on 03/08/08 14:13, wrote:

[...snip]

I talked to the support at the hosting company and they looked at the
system and said they couldn't see anything wrong with it - but they
can re-image it for me which normally costs a fee.

Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is
infected.


Adam


Hi,
Chkrootkit is known to fall for quite a few false positive, for example 
if you run Portsentry or such anti-portscan demon, it also can detect 
legitimate services like dhcpd or such as sniffers, which isn't really 
incorrect but not a problem. I never heard of 2881 as being one of 
those, but maybe getting in touch with the dev team could give you an 
easy answer.

http://www.chkrootkit.org/

Maybe the only way to know for sure would be scanning all traffic from 
another system regarding this port to see if anything suspicious can be 
spotted, and maybe running an integrity check with debsum or such on 
conf files, comparing the result with a backup from an earlier state or 
a known sane system.


What would really be interesting is to spot the precise day when the 
warning first occurred from your system logs, and see if you can spot 
any change in configuration that could have triggered it (update ?). 
That is, if your system really is infected you cannot trust anything and 
especially not the logs...


Tom


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-04 Thread Thomas Preud'homme
Monday 04 August 2008, Adam Hardy wrote :
> Thomas Preud'homme on 04/08/08 11:48, wrote:
> > Le lundi 4 août 2008, Adam Hardy a écrit :
> >> Adam Hardy on 03/08/08 14:13, wrote:
> >>> My webserver system is actually a UML slice of a system at
> >>> memset.co.uk and all it does is run Apache Tomcat and sshd and
> >>> the stuff from memset - I thought it was pretty safe until I came
> >>> back today and found my nightly email report from chkrootkit
> >>> said:
> >>>
> >>> The following suspicious files and directories were found:
> >>> /lib/init/rw/.ramfs
> >>>
> >>> INFECTED (PORTS:  2881)
> >>>
> >>> The .ramfs started appearing when I upgraded chkrootkit, so I
> >>> never worried about it, but Friday night's INFECTED alert was a
> >>> slap in the face with a wet fish. Saturday night's report went
> >>> back to normal - no mention of the port.
> >>>
> >>> I scanned it from grc.com/x/portprobe and it came back as closed.
> >>>
> >>> The only mention I can find in the logs is:
> >>>
> >>> [EMAIL PROTECTED]:~# grep 2881 /var/log/*
> >>> /var/log/setuid.today:
> >>> 2881   660   1 root   disk   0 Wed Apr 30
> >>> 11:32:37 2008 /dev/rd/c1d30
> >>> r
> >>>
> >>> and that's a PID, not a port, right?
> >>>
> >>> So how bad does this look? Should I clean the system? If it is
> >>> rooted, how can I tell what the security flaw was? My password at
> >>> that point (since changed) was CE0dff2*£ so if it was a brute
> >>> force attack, then wow, they did well.
> >>
> >> I talked to the support at the hosting company and they looked at
> >> the system and said they couldn't see anything wrong with it - but
> >> they can re-image it for me which normally costs a fee.
> >>
> >> Is it worth re-imaging my system and re-installing everything?
> >>
> >> I still have no idea what chkrootkit means when it says a port is
> >> infected.
> >>
> >>
> >> Adam
> >
> > I don't think it's that important. chkrootkit seems a little
> > hazardous since there was a bug about chkrootkit killing a random
> > process (in fact one of its test was sending a signal to process
> > 12345, this bug has been corrected).
> >
> > I think a good anti-rootkit should be launched from another system
> > to be sure it's not deactivated by a smart rootkit.
>
> Hopefully that is simpler than it sounds! What anti-rootkit are you
> thinking of? I use chkrootkit and rkhunter.

Unfortunetely I haven't any reference but hoping a rootkit on your 
computer being launched once a day will protect you is like hoping an 
anti-virus will protect you even if a smart virus infect your computer 
between 2 launch. It's better than nothing but I don't think it's 
sufficient.

I think you can safely discard this warning from chkrootkit or if you're 
cautious (it's very good) then ask to the maintener or better to the 
upstream developer of this software.

>
>
> Adam



Regards,

Thomas Preud'homme

-- 
Why Debian : http://www.debian.org/intro/why_debian


signature.asc
Description: This is a digitally signed message part.


Re: chkrootkit infected ports 2881

2008-08-04 Thread Adam Hardy

Thomas Preud'homme on 04/08/08 11:48, wrote:

Le lundi 4 août 2008, Adam Hardy a écrit :

Adam Hardy on 03/08/08 14:13, wrote:

My webserver system is actually a UML slice of a system at
memset.co.uk and all it does is run Apache Tomcat and sshd and the
stuff from memset - I thought it was pretty safe until I came back
today and found my nightly email report from chkrootkit said:

The following suspicious files and directories were found:
/lib/init/rw/.ramfs

INFECTED (PORTS:  2881)

The .ramfs started appearing when I upgraded chkrootkit, so I never
worried about it, but Friday night's INFECTED alert was a slap in
the face with a wet fish. Saturday night's report went back to
normal - no mention of the port.

I scanned it from grc.com/x/portprobe and it came back as closed.

The only mention I can find in the logs is:

[EMAIL PROTECTED]:~# grep 2881 /var/log/*
/var/log/setuid.today:
2881   660   1 root   disk   0 Wed Apr 30
11:32:37 2008 /dev/rd/c1d30
r

and that's a PID, not a port, right?

So how bad does this look? Should I clean the system? If it is
rooted, how can I tell what the security flaw was? My password at
that point (since changed) was CE0dff2*£ so if it was a brute force
attack, then wow, they did well.

I talked to the support at the hosting company and they looked at the
system and said they couldn't see anything wrong with it - but they
can re-image it for me which normally costs a fee.

Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is
infected.


Adam


I don't think it's that important. chkrootkit seems a little hazardous 
since there was a bug about chkrootkit killing a random process (in 
fact one of its test was sending a signal to process 12345, this bug 
has been corrected).


I think a good anti-rootkit should be launched from another system to be 
sure it's not deactivated by a smart rootkit.


Hopefully that is simpler than it sounds! What anti-rootkit are you thinking of? 
I use chkrootkit and rkhunter.



Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: chkrootkit infected ports 2881

2008-08-04 Thread Thomas Preud'homme
Le lundi 4 août 2008, Adam Hardy a écrit :
> Adam Hardy on 03/08/08 14:13, wrote:
> > My webserver system is actually a UML slice of a system at
> > memset.co.uk and all it does is run Apache Tomcat and sshd and the
> > stuff from memset - I thought it was pretty safe until I came back
> > today and found my nightly email report from chkrootkit said:
> >
> > The following suspicious files and directories were found:
> > /lib/init/rw/.ramfs
> >
> > INFECTED (PORTS:  2881)
> >
> > The .ramfs started appearing when I upgraded chkrootkit, so I never
> > worried about it, but Friday night's INFECTED alert was a slap in
> > the face with a wet fish. Saturday night's report went back to
> > normal - no mention of the port.
> >
> > I scanned it from grc.com/x/portprobe and it came back as closed.
> >
> > The only mention I can find in the logs is:
> >
> > [EMAIL PROTECTED]:~# grep 2881 /var/log/*
> > /var/log/setuid.today:
> > 2881   660   1 root   disk   0 Wed Apr 30
> > 11:32:37 2008 /dev/rd/c1d30
> > r
> >
> > and that's a PID, not a port, right?
> >
> > So how bad does this look? Should I clean the system? If it is
> > rooted, how can I tell what the security flaw was? My password at
> > that point (since changed) was CE0dff2*£ so if it was a brute force
> > attack, then wow, they did well.
>
> I talked to the support at the hosting company and they looked at the
> system and said they couldn't see anything wrong with it - but they
> can re-image it for me which normally costs a fee.
>
> Is it worth re-imaging my system and re-installing everything?
>
> I still have no idea what chkrootkit means when it says a port is
> infected.
>
>
> Adam

I don't think it's that important. chkrootkit seems a little hazardous 
since there was a bug about chkrootkit killing a random process (in 
fact one of its test was sending a signal to process 12345, this bug 
has been corrected).

I think a good anti-rootkit should be launched from another system to be 
sure it's not deactivated by a smart rootkit.

Regards,

Thomas Preud'homme

-- 
Why Debian : http://www.debian.org/intro/why_debian


signature.asc
Description: This is a digitally signed message part.


Re: chkrootkit infected ports 2881

2008-08-04 Thread Adam Hardy

Adam Hardy on 03/08/08 14:13, wrote:
My webserver system is actually a UML slice of a system at memset.co.uk 
and all it does is run Apache Tomcat and sshd and the stuff from memset 
- I thought it was pretty safe until I came back today and found my 
nightly email report from chkrootkit said:


The following suspicious files and directories were found:
/lib/init/rw/.ramfs

INFECTED (PORTS:  2881)

The .ramfs started appearing when I upgraded chkrootkit, so I never 
worried about it, but Friday night's INFECTED alert was a slap in the 
face with a wet fish. Saturday night's report went back to normal - no 
mention of the port.


I scanned it from grc.com/x/portprobe and it came back as closed.

The only mention I can find in the logs is:

[EMAIL PROTECTED]:~# grep 2881 /var/log/*
/var/log/setuid.today:
2881   660   1 root   disk   0 Wed Apr 30 11:32:37 
2008 /dev/rd/c1d30

r

and that's a PID, not a port, right?

So how bad does this look? Should I clean the system? If it is rooted, 
how can I tell what the security flaw was? My password at that point 
(since changed) was CE0dff2*£ so if it was a brute force attack, then 
wow, they did well.


I talked to the support at the hosting company and they looked at the system and 
said they couldn't see anything wrong with it - but they can re-image it for me 
which normally costs a fee.


Is it worth re-imaging my system and re-installing everything?

I still have no idea what chkrootkit means when it says a port is infected.


Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]