Re: chkrootkit infected ports 2881 - conundrum
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/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
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/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
