Re: BIND exploited ? -UPDATE
On Sat, Jan 05, 2002 at 01:43:24AM -0500, Thedore Knab wrote: [snip] Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet [snip] Do you really need telnet? Can't you use ssh instead? -- Michael Wood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ? -UPDATE
On Sat, Jan 05, 2002 at 01:43:24AM -0500, Thedore Knab wrote: [snip] Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet [snip] Do you really need telnet? Can't you use ssh instead? -- Michael Wood [EMAIL PROTECTED]
Re: BIND exploited ?
I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? OK. When I described replacing all hard drives I was referring to system disks with the OS and applications not data files. Keeping a backup of your news spool probably doesn't gain you much. Just use find on the data disks (the copy of find on the freshly installed un-cracked system on new system disks) to search for suspicious files (SUID, SGID, and executables where you least expect them). Also search for files and directories starting in '.' in locations where you don't expect them. Another thing to check for is the most recently changed files. On a web server the content may not have changed for a month, any files changed in the last week would be by the intruder... After copying and removing all suspicious files (make sure you use tar or cpio not cp so that permissions and time stamps are preserved) then the data disks will be ready for service again. Make sure that boot sectors are wiped as well (on a Debian installation use install-mbr on every disk that has a partition table). From my experience, police like data untampered and in exactly the same form and such when the intrusion occurred. That means the exact same disks, not a tape backup or something. Sometimes backups can miss stuff, or as mentione previously, the backup software itself could have been rooted. Actually, it would be best to make a duplicate of the disk, USE THE DUPLICATE, and give the police the original. If possible, just yank the power out of the box... the reason being that if you use 'reboot' or 'shutdown' or others, they usually run though the shutdown scripts, and within the shutdown scripts the kiddies could've planted something there as well. You never know. By yanking the power, no software can write/modify the disks, and they are preserved, more or less. Sincerely, Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: BIND exploited ? -UPDATE
You dumbass. Everybody knows you don't try to fix a compromised machine. You take it in stride, wipe the drives and start all over from a clean install. j. -- Jeremy L. Gaddis [EMAIL PROTECTED] -Original Message- From: Ted Knab [mailto:[EMAIL PROTECTED]]On Behalf Of Thedore Knab Sent: Saturday, January 05, 2002 1:43 AM To: [EMAIL PROTECTED] Subject: Re: BIND exploited ? -UPDATE Thanks for your help. This was not a debian box. Maybe the next one will be. I think it was updated from an earilier version that was hacked. I am under the assumption that this server was this way for over 1 year. [ted@moe chkrootkit-0.34]$ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) I just started this .edu sys admin job last week. It is fun. I am finding all types of crazy stuff that would send most normal people to the nut house. It is an adventure. I don't think I will be able to rebuild this DNS for a few days. I have some other projects that need to be rolled out for .edu political reasons. It has been rooted for sometime, so I have a lot of fixing to do. I told everyone that needs to be informed, but they just don't get the gravity of the situation. Since I won't be able to build another, I tried isolating the services. It also seems more fun to try and fix the broken box. I think I have most of the cracked services isolated. Behind door number 1 - less services A nmap scan from my laptop reveals: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 113/tcpopenauth This is an improvement over what it looked like this morning: See your advice helped... :-) Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1533 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 79/tcp openfinger 98/tcp openlinuxconf 111/tcpopensunrpc 113/tcpopenauth 513/tcpopenlogin 514/tcpopenshell 943/tcpopenunknown 1024/tcp openkdm I found the startup location for the scripts. The scripts were starting every reboot. I guess the last time it started was: [ted@moe chkrootkit-0.34]$ uptime 1:40am up 154 days, 9:15, 1 user, load average: 0.00, 0.00, 0.00 [root@moe /etc]# cat rc.d/rc.local #!/bin/sh # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. if [ -f /etc/redhat-release ]; then R=$(cat /etc/redhat-release) ... cut fi ### #The Little Bastards Startup scripts #not very complicated #/etc/.../bindshell #/etc/.../bnc #/etc/.../snif #/etc/.../lsh 31333 v0idzz checkroot kit did not seem to find anything except a snifer. This maybe because I did a chmod 0 on a bunch of the binaries I didn't want starting ever again. [root@moe chkrootkit-0.34]# ./chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not infected Checking `gpm'... not infected Checking `grep'... not infected Checking `hdparm'... not infected Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not infected Checking `killall'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `mail'... not infected Checking `mingetty'... not infected Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not infected Checking `rshd'... not infected Checking `slogin'... not found Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not infected Checking `timed'... not infected Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/.v0id/ptyq /dev/ptyp /dev/ptypr
RE: BIND exploited ? -UPDATE
On Sat, 5 Jan 2002, Jeremy L. Gaddis wrote: You dumbass. Everybody knows you don't try to fix a compromised machine. You take it in stride, wipe the drives and start all over from a clean install. Would you mind terribly not airing your oh-so-superior views in public? With such unbridled arrogance? I'm sure I'm not the only one who finds it offensive and not at all representative of the maturity of discussion expected of this list. The aim of a self-help list such as this is to help and educate -- not to sneer and ridicule. OH -- and would you also mind terribly NOT re-posting the complete history of the current thread in your public e-mails? It's a clear sign of inability to either understand or use the medium properly. Thank you. -- Martin Wheeler [EMAIL PROTECTED] [gpg:1024D/01269BEB 2001-09-29] /debian/ msw [EMAIL PROTECTED] [gpg:1024D/8D6B948B 2001-07-04] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
Good point! Having never dealt with the fuzz after being compromised, I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? In my experience, the police will have computer crime specialists who'll know all about dd. In fact, one of the first things they'll ask when you contact them is whether they can make complete disk images, and they'll be very happy if you say yes. They'll be happier still if you can provide tcpdump (or similar) traces of the intruder's activiy (electronic format is nice, but they'll need a hard copy too, with each page dated and signed to present to the judge). Once they've made the disk images, you can format your disks and put them back into service. You'll still be able to participate in the forensic examination of those images, though, and (again, in my experience only), they're very good at respecting privacy concerns - ie. not going anywhere near the /home partition, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ? -UPDATE
On Sat, Jan 05, 2002 at 01:43:24AM -0500, Thedore Knab wrote: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) ^^ You seem to have only scanned your well-known ports? Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
On Sun, 6 Jan 2002 04:08, Jason Lim wrote: From my experience, police like data untampered and in exactly the same form and such when the intrusion occurred. That means the exact same disks, not a tape backup or something. Sometimes backups can miss stuff, or as mentione previously, the backup software itself could have been rooted. Actually, it would be best to make a duplicate of the disk, USE THE DUPLICATE, and give the police the original. If possible, just yank the power out of the box... the reason being that if you use 'reboot' or 'shutdown' or others, they usually run though the shutdown scripts, and within the shutdown scripts the kiddies could've planted something there as well. You never know. By yanking the power, no software can write/modify the disks, and they are preserved, more or less. Good point. Also that means not running fsck! Sometimes there's interesting data in files that were deleted but open at the time, fsck will usually remove that data while debugfs can get it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ? -UPDATE #2
How does this sound ? The system has been rebuilt. It is running Bind 9.2 chroot version on RH 7.2. Someone else built it. I prefer Debian or OpenBSD. I will add tripwire and chkroot kit to run as a cron job. The harddrives will be saved for further investigation at a later date. Since the harddrives have been modified in a hack effort to patch the problem, I don't think it can be used as evidence. Snort will also be installed on an OPENBSD box at the edge of the nework to monitor the administrave network, and on the administrative network. -Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? OK. When I described replacing all hard drives I was referring to system disks with the OS and applications not data files. Keeping a backup of your news spool probably doesn't gain you much. Just use find on the data disks (the copy of find on the freshly installed un-cracked system on new system disks) to search for suspicious files (SUID, SGID, and executables where you least expect them). Also search for files and directories starting in '.' in locations where you don't expect them. Another thing to check for is the most recently changed files. On a web server the content may not have changed for a month, any files changed in the last week would be by the intruder... After copying and removing all suspicious files (make sure you use tar or cpio not cp so that permissions and time stamps are preserved) then the data disks will be ready for service again. Make sure that boot sectors are wiped as well (on a Debian installation use install-mbr on every disk that has a partition table). From my experience, police like data untampered and in exactly the same form and such when the intrusion occurred. That means the exact same disks, not a tape backup or something. Sometimes backups can miss stuff, or as mentione previously, the backup software itself could have been rooted. Actually, it would be best to make a duplicate of the disk, USE THE DUPLICATE, and give the police the original. If possible, just yank the power out of the box... the reason being that if you use 'reboot' or 'shutdown' or others, they usually run though the shutdown scripts, and within the shutdown scripts the kiddies could've planted something there as well. You never know. By yanking the power, no software can write/modify the disks, and they are preserved, more or less. Sincerely, Jason
RE: BIND exploited ? -UPDATE
You dumbass. Everybody knows you don't try to fix a compromised machine. You take it in stride, wipe the drives and start all over from a clean install. j. -- Jeremy L. Gaddis [EMAIL PROTECTED] -Original Message- From: Ted Knab [mailto:[EMAIL PROTECTED] Behalf Of Thedore Knab Sent: Saturday, January 05, 2002 1:43 AM To: debian-isp@lists.debian.org Subject: Re: BIND exploited ? -UPDATE Thanks for your help. This was not a debian box. Maybe the next one will be. I think it was updated from an earilier version that was hacked. I am under the assumption that this server was this way for over 1 year. [EMAIL PROTECTED] chkrootkit-0.34]$ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) I just started this .edu sys admin job last week. It is fun. I am finding all types of crazy stuff that would send most normal people to the nut house. It is an adventure. I don't think I will be able to rebuild this DNS for a few days. I have some other projects that need to be rolled out for .edu political reasons. It has been rooted for sometime, so I have a lot of fixing to do. I told everyone that needs to be informed, but they just don't get the gravity of the situation. Since I won't be able to build another, I tried isolating the services. It also seems more fun to try and fix the broken box. I think I have most of the cracked services isolated. Behind door number 1 - less services A nmap scan from my laptop reveals: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 113/tcpopenauth This is an improvement over what it looked like this morning: See your advice helped... :-) Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1533 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 79/tcp openfinger 98/tcp openlinuxconf 111/tcpopensunrpc 113/tcpopenauth 513/tcpopenlogin 514/tcpopenshell 943/tcpopenunknown 1024/tcp openkdm I found the startup location for the scripts. The scripts were starting every reboot. I guess the last time it started was: [EMAIL PROTECTED] chkrootkit-0.34]$ uptime 1:40am up 154 days, 9:15, 1 user, load average: 0.00, 0.00, 0.00 [EMAIL PROTECTED] /etc]# cat rc.d/rc.local #!/bin/sh # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. if [ -f /etc/redhat-release ]; then R=$(cat /etc/redhat-release) ... cut fi ### #The Little Bastards Startup scripts #not very complicated #/etc/.../bindshell #/etc/.../bnc #/etc/.../snif #/etc/.../lsh 31333 v0idzz checkroot kit did not seem to find anything except a snifer. This maybe because I did a chmod 0 on a bunch of the binaries I didn't want starting ever again. [EMAIL PROTECTED] chkrootkit-0.34]# ./chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not infected Checking `gpm'... not infected Checking `grep'... not infected Checking `hdparm'... not infected Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not infected Checking `killall'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `mail'... not infected Checking `mingetty'... not infected Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not infected Checking `rshd'... not infected Checking `slogin'... not found Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not infected Checking `timed'... not infected Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens
RE: BIND exploited ? -UPDATE
On Sat, 5 Jan 2002, Jeremy L. Gaddis wrote: You dumbass. Everybody knows you don't try to fix a compromised machine. You take it in stride, wipe the drives and start all over from a clean install. Would you mind terribly not airing your oh-so-superior views in public? With such unbridled arrogance? I'm sure I'm not the only one who finds it offensive and not at all representative of the maturity of discussion expected of this list. The aim of a self-help list such as this is to help and educate -- not to sneer and ridicule. OH -- and would you also mind terribly NOT re-posting the complete history of the current thread in your public e-mails? It's a clear sign of inability to either understand or use the medium properly. Thank you. -- Martin Wheeler [EMAIL PROTECTED] [gpg:1024D/01269BEB 2001-09-29] /debian/ msw [EMAIL PROTECTED] [gpg:1024D/8D6B948B 2001-07-04]
Re: BIND exploited ?
Good point! Having never dealt with the fuzz after being compromised, I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? In my experience, the police will have computer crime specialists who'll know all about dd. In fact, one of the first things they'll ask when you contact them is whether they can make complete disk images, and they'll be very happy if you say yes. They'll be happier still if you can provide tcpdump (or similar) traces of the intruder's activiy (electronic format is nice, but they'll need a hard copy too, with each page dated and signed to present to the judge). Once they've made the disk images, you can format your disks and put them back into service. You'll still be able to participate in the forensic examination of those images, though, and (again, in my experience only), they're very good at respecting privacy concerns - ie. not going anywhere near the /home partition, etc.
Re: BIND exploited ? -UPDATE
On Sat, Jan 05, 2002 at 01:43:24AM -0500, Thedore Knab wrote: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) ^^ You seem to have only scanned your well-known ports? Joachim
Re: BIND exploited ?
On Sun, 6 Jan 2002 04:08, Jason Lim wrote: From my experience, police like data untampered and in exactly the same form and such when the intrusion occurred. That means the exact same disks, not a tape backup or something. Sometimes backups can miss stuff, or as mentione previously, the backup software itself could have been rooted. Actually, it would be best to make a duplicate of the disk, USE THE DUPLICATE, and give the police the original. If possible, just yank the power out of the box... the reason being that if you use 'reboot' or 'shutdown' or others, they usually run though the shutdown scripts, and within the shutdown scripts the kiddies could've planted something there as well. You never know. By yanking the power, no software can write/modify the disks, and they are preserved, more or less. Good point. Also that means not running fsck! Sometimes there's interesting data in files that were deleted but open at the time, fsck will usually remove that data while debugfs can get it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: BIND exploited ? -UPDATE #2
How does this sound ? The system has been rebuilt. It is running Bind 9.2 chroot version on RH 7.2. Someone else built it. I prefer Debian or OpenBSD. I will add tripwire and chkroot kit to run as a cron job. The harddrives will be saved for further investigation at a later date. Since the harddrives have been modified in a hack effort to patch the problem, I don't think it can be used as evidence. Snort will also be installed on an OPENBSD box at the edge of the nework to monitor the administrave network, and on the administrative network. -Ted
Re: BIND exploited ?
Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). I agree, which is exactly why I suggest he get new hard drives... to preserve evidence, and allow you to learn from your mistakes. Otherwise, whats going to stop it happening again? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ? -UPDATE
Thanks for your help. This was not a debian box. Maybe the next one will be. I think it was updated from an earilier version that was hacked. I am under the assumption that this server was this way for over 1 year. [ted@moe chkrootkit-0.34]$ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) I just started this .edu sys admin job last week. It is fun. I am finding all types of crazy stuff that would send most normal people to the nut house. It is an adventure. I don't think I will be able to rebuild this DNS for a few days. I have some other projects that need to be rolled out for .edu political reasons. It has been rooted for sometime, so I have a lot of fixing to do. I told everyone that needs to be informed, but they just don't get the gravity of the situation. Since I won't be able to build another, I tried isolating the services. It also seems more fun to try and fix the broken box. I think I have most of the cracked services isolated. Behind door number 1 - less services A nmap scan from my laptop reveals: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 113/tcpopenauth This is an improvement over what it looked like this morning: See your advice helped... :-) Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1533 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 79/tcp openfinger 98/tcp openlinuxconf 111/tcpopensunrpc 113/tcpopenauth 513/tcpopenlogin 514/tcpopenshell 943/tcpopenunknown 1024/tcp openkdm I found the startup location for the scripts. The scripts were starting every reboot. I guess the last time it started was: [ted@moe chkrootkit-0.34]$ uptime 1:40am up 154 days, 9:15, 1 user, load average: 0.00, 0.00, 0.00 [root@moe /etc]# cat rc.d/rc.local #!/bin/sh # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. if [ -f /etc/redhat-release ]; then R=$(cat /etc/redhat-release) ... cut fi ### #The Little Bastards Startup scripts #not very complicated #/etc/.../bindshell #/etc/.../bnc #/etc/.../snif #/etc/.../lsh 31333 v0idzz checkroot kit did not seem to find anything except a snifer. This maybe because I did a chmod 0 on a bunch of the binaries I didn't want starting ever again. [root@moe chkrootkit-0.34]# ./chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not infected Checking `gpm'... not infected Checking `grep'... not infected Checking `hdparm'... not infected Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not infected Checking `killall'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `mail'... not infected Checking `mingetty'... not infected Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not infected Checking `rshd'... not infected Checking `slogin'... not found Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not infected Checking `timed'... not infected Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/.v0id/ptyq /dev/ptyp /dev/ptypr Searching for sniffer's logs, it may take a while... nothing found Searching for t0rn's default files and dirs... nothing found
Re: BIND exploited ?
On Fri, 4 Jan 2002 19:43, Andy Bastien wrote: Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). Good point! Having never dealt with the fuzz after being compromised, Firstly please note that I don't have much first-hand experience with dealing with the police on such issues. The times when police issues have come up I've been too busy and let other people handle it - those people didn't disturb me so I never bothered finding out exactly what happened... Even if I did have detailed experience of such things it probably wouldn't apply in your jurisdiction - and the law is constantly changing anyway. I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? OK. When I described replacing all hard drives I was referring to system disks with the OS and applications not data files. Keeping a backup of your news spool probably doesn't gain you much. Just use find on the data disks (the copy of find on the freshly installed un-cracked system on new system disks) to search for suspicious files (SUID, SGID, and executables where you least expect them). Also search for files and directories starting in '.' in locations where you don't expect them. Another thing to check for is the most recently changed files. On a web server the content may not have changed for a month, any files changed in the last week would be by the intruder... After copying and removing all suspicious files (make sure you use tar or cpio not cp so that permissions and time stamps are preserved) then the data disks will be ready for service again. Make sure that boot sectors are wiped as well (on a Debian installation use install-mbr on every disk that has a partition table). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
Andy Bastien wrote: Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? One could simply reformat, but I'd strongly consider buying new drives for several reasons: 1) Hard drives are one of the more failure-prone components (and, unless you're running RAID, harder to quickly swap out a failed unit than a failed power supply or something). As long as the machine is down, might as well replace the old hard drives with brand new ones. 2) Good opportunity to re-evaluate your partitioning scheme on the affected machine. (true, this can be done to some extent by re-formatting) 3) Good opportunity to install higher-capacity (and possibly higher-speed) drives. And, finally, keeping the original hard drives around may or may not be useful in studying the intrusion, the effects of the intrusion, and the tools/methods used. --Rich _ Rich Puhek ETN Systems Inc. _
Re: BIND exploited ? -UPDATE
Thanks for your help. This was not a debian box. Maybe the next one will be. I think it was updated from an earilier version that was hacked. I am under the assumption that this server was this way for over 1 year. [EMAIL PROTECTED] chkrootkit-0.34]$ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) I just started this .edu sys admin job last week. It is fun. I am finding all types of crazy stuff that would send most normal people to the nut house. It is an adventure. I don't think I will be able to rebuild this DNS for a few days. I have some other projects that need to be rolled out for .edu political reasons. It has been rooted for sometime, so I have a lot of fixing to do. I told everyone that needs to be informed, but they just don't get the gravity of the situation. Since I won't be able to build another, I tried isolating the services. It also seems more fun to try and fix the broken box. I think I have most of the cracked services isolated. Behind door number 1 - less services A nmap scan from my laptop reveals: Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1540 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 113/tcpopenauth This is an improvement over what it looked like this morning: See your advice helped... :-) Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ ) Interesting ports on dns1.mywork.edu : (The 1533 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 23/tcp opentelnet 53/tcp opendomain 79/tcp openfinger 98/tcp openlinuxconf 111/tcpopensunrpc 113/tcpopenauth 513/tcpopenlogin 514/tcpopenshell 943/tcpopenunknown 1024/tcp openkdm I found the startup location for the scripts. The scripts were starting every reboot. I guess the last time it started was: [EMAIL PROTECTED] chkrootkit-0.34]$ uptime 1:40am up 154 days, 9:15, 1 user, load average: 0.00, 0.00, 0.00 [EMAIL PROTECTED] /etc]# cat rc.d/rc.local #!/bin/sh # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. if [ -f /etc/redhat-release ]; then R=$(cat /etc/redhat-release) ... cut fi ### #The Little Bastards Startup scripts #not very complicated #/etc/.../bindshell #/etc/.../bnc #/etc/.../snif #/etc/.../lsh 31333 v0idzz checkroot kit did not seem to find anything except a snifer. This maybe because I did a chmod 0 on a bunch of the binaries I didn't want starting ever again. [EMAIL PROTECTED] chkrootkit-0.34]# ./chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not infected Checking `gpm'... not infected Checking `grep'... not infected Checking `hdparm'... not infected Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not infected Checking `killall'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `mail'... not infected Checking `mingetty'... not infected Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not infected Checking `rshd'... not infected Checking `slogin'... not found Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not infected Checking `timed'... not infected Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/.v0id/ptyq /dev/ptyp /dev/ptypr Searching for sniffer's logs, it may take a while... nothing found Searching for t0rn's default
Re: BIND exploited ?
On Fri, 4 Jan 2002 19:43, Andy Bastien wrote: Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). Good point! Having never dealt with the fuzz after being compromised, Firstly please note that I don't have much first-hand experience with dealing with the police on such issues. The times when police issues have come up I've been too busy and let other people handle it - those people didn't disturb me so I never bothered finding out exactly what happened... Even if I did have detailed experience of such things it probably wouldn't apply in your jurisdiction - and the law is constantly changing anyway. I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? OK. When I described replacing all hard drives I was referring to system disks with the OS and applications not data files. Keeping a backup of your news spool probably doesn't gain you much. Just use find on the data disks (the copy of find on the freshly installed un-cracked system on new system disks) to search for suspicious files (SUID, SGID, and executables where you least expect them). Also search for files and directories starting in '.' in locations where you don't expect them. Another thing to check for is the most recently changed files. On a web server the content may not have changed for a month, any files changed in the last week would be by the intruder... After copying and removing all suspicious files (make sure you use tar or cpio not cp so that permissions and time stamps are preserved) then the data disks will be ready for service again. Make sure that boot sectors are wiped as well (on a Debian installation use install-mbr on every disk that has a partition table). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: BIND exploited ?
On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Trying to remove root-kits etc might be fun if you're running a honeypot system, but if you are running a business or some other organization that has aims other than playing with Linux machines then a complete re-install is the best option. Otherwise you'll just end up playing cat-and-mouse with the cracker, and they'll probably start randomly deleting data files when they start losing. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Trying to remove root-kits etc might be fun if you're running a honeypot system, but if you are running a business or some other organization that has aims other than playing with Linux machines then a complete re-install is the best option. Otherwise you'll just end up playing cat-and-mouse with the cracker, and they'll probably start randomly deleting data files when they start losing. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? btw, I'd work under the assumption that those *snif* programs actually were functional password sniffers. This means that anyone whose passwords could have possibly been captured needs to change their passwords (in the meantime you could try find out if you can locate a capture file on the compromised system). And if a user's email password could have been captured, don't send him an email informing him of this fact ;). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
On Fri, 4 Jan 2002 17:54, Andy Bastien wrote: On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 17:54, Andy Bastien wrote: On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). Good point! Having never dealt with the fuzz after being compromised, I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BIND exploited ?
On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Trying to remove root-kits etc might be fun if you're running a honeypot system, but if you are running a business or some other organization that has aims other than playing with Linux machines then a complete re-install is the best option. Otherwise you'll just end up playing cat-and-mouse with the cracker, and they'll probably start randomly deleting data files when they start losing. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: BIND exploited ?
On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Trying to remove root-kits etc might be fun if you're running a honeypot system, but if you are running a business or some other organization that has aims other than playing with Linux machines then a complete re-install is the best option. Otherwise you'll just end up playing cat-and-mouse with the cracker, and they'll probably start randomly deleting data files when they start losing. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? btw, I'd work under the assumption that those *snif* programs actually were functional password sniffers. This means that anyone whose passwords could have possibly been captured needs to change their passwords (in the meantime you could try find out if you can locate a capture file on the compromised system). And if a user's email password could have been captured, don't send him an email informing him of this fact ;).
Re: BIND exploited ?
On Fri, 4 Jan 2002 17:54, Andy Bastien wrote: On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: BIND exploited ?
On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 17:54, Andy Bastien wrote: On Fri Jan 04, a day that will live in infamy, Russell Coker wrote: On Fri, 4 Jan 2002 03:16, Thedore Knab wrote: Where do I go from here ? Buy new hard drives, install them and install the latest version of your favourite distribution and configure it in a secure fashion. Make sure that all passwords are different. Is it really necessary to buy new hard drives? Is there a reason why he can't just reformat his current drives before reinstalling? Sure he can, if he wants to lose the evidence of what happened and lose the possibility to hand the drives over to law enforcement officials (which may be demanded of him even if he doesn't want it in the case that his machine was used to attack others). Good point! Having never dealt with the fuzz after being compromised, I have to ask what you would do if your server is a file server with lots of big, expensive drives where a company might not be able to afford replacing them all? Would they be happy with backups (keeping in mind that any tools used to backup the server might no longer be trustworthy)? How about disk images (made with dd, or something similar) of the drives that contain the system stuff?
BIND exploited ?
I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [root@moe ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [root@moe ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [root@moe ...]# cd /etc/... [root@moe ...]# ls -la [root@moe ...]# chmod 0 /etc/rc.d/init.d/apmd [root@moe ...]# chmod 0 /etc/rc.d/init.d/atd Processess running after making a few kills: [root@moe /root]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:28 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e
Re: BIND exploited ?
rooted by some script kiddies,perhaps.. rpc.statd or bind exploited,some say its better to reinstall the box,personally i like diggin' :-)) first,disconnect,kick out all aliens,or save them somewhere,quarantined to check them out later, then,get some new packages on cds,or floppies or from the lan,update the daemons,after assuring they're not trojanized,also,search for traces of adore,get the kstat program to detect it,( sorry no url at hand), check your logs,email the attackers isp addresses if you can find something, and always be aware :) good luck.. At 09:16 PM 1/3/02 -0500, Thedore Knab wrote: I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [root@moe ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [root@moe ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [root@moe ...]# cd /etc/... [root@moe ...]# ls -la [root@moe ...]# chmod 0 /etc/rc.d/init.d/apmd [root@moe ...]# chmod 0 /etc/rc.d/init.d/atd Processess running after making a few kills: [root@moe /root]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:28 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00
Re: BIND exploited ?
I would also strongly suggest getting chkrootkit. chkrootkit - Checks for signs of rootkits on the local system chkrootkit identifies whether the target computer is infected with a rootkit. It can currently identify the following root kits: 1. lrk3, lrk4, lrk5, lrk6 (and some variants); 2. Solaris rootkit; 3. FreeBSD rootkit; 4. t0rn (including latest variant); 5. Ambient's Rootkit for Linux (ARK); 6. Ramen Worm; 7. rh[67]-shaper; 8. RSHA; 9. Romanian rootkit; 10. RK17; 11. Lion Worm; 12. Adore Worm. Please note that this is not a definitive test, it does not ensure that the target has not been cracked. In addition to running chkrootkit, one should perform more specific tests. Hope that helps. What we did was install new hard disks, restore from backups to the new hard disks, immediately find out how they got in by analysing the old hard disks, patch/fix/whatever the new hard disks so the kiddies can't get back in, and slowly and carefully go through the old hard disks and find out what they did and such (if you are interested). Good for a learning experience. Trace their actions, what they did/changed/installed/etc. - Original Message - From: Thedore Knab [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 10:16 AM Subject: BIND exploited ? I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [root@moe ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [root@moe ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [root@moe ...]# cd /etc/... [root@moe ...]# ls -la [root@moe ...]# chmod 0 /etc/rc.d/init.d
BIND exploited ?
I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [EMAIL PROTECTED] ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [EMAIL PROTECTED] ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [EMAIL PROTECTED] ...]# cd /etc/... [EMAIL PROTECTED] ...]# ls -la [EMAIL PROTECTED] ...]# chmod 0 /etc/rc.d/init.d/apmd [EMAIL PROTECTED] ...]# chmod 0 /etc/rc.d/init.d/atd Processess running after making a few kills: [EMAIL PROTECTED] /root]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:28 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420
Re: BIND exploited ?
rooted by some script kiddies,perhaps.. rpc.statd or bind exploited,some say its better to reinstall the box,personally i like diggin' :-)) first,disconnect,kick out all aliens,or save them somewhere,quarantined to check them out later, then,get some new packages on cds,or floppies or from the lan,update the daemons,after assuring they're not trojanized,also,search for traces of adore,get the kstat program to detect it,( sorry no url at hand), check your logs,email the attackers isp addresses if you can find something, and always be aware :) good luck.. At 09:16 PM 1/3/02 -0500, Thedore Knab wrote: I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [EMAIL PROTECTED] ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [EMAIL PROTECTED] ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [EMAIL PROTECTED] ...]# cd /etc/... [EMAIL PROTECTED] ...]# ls -la [EMAIL PROTECTED] ...]# chmod 0 /etc/rc.d/init.d/apmd [EMAIL PROTECTED] ...]# chmod 0 /etc/rc.d/init.d/atd Processess running after making a few kills: [EMAIL PROTECTED] /root]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:28 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0
Re: BIND exploited ?
I would also strongly suggest getting chkrootkit. chkrootkit - Checks for signs of rootkits on the local system chkrootkit identifies whether the target computer is infected with a rootkit. It can currently identify the following root kits: 1. lrk3, lrk4, lrk5, lrk6 (and some variants); 2. Solaris rootkit; 3. FreeBSD rootkit; 4. t0rn (including latest variant); 5. Ambient's Rootkit for Linux (ARK); 6. Ramen Worm; 7. rh[67]-shaper; 8. RSHA; 9. Romanian rootkit; 10. RK17; 11. Lion Worm; 12. Adore Worm. Please note that this is not a definitive test, it does not ensure that the target has not been cracked. In addition to running chkrootkit, one should perform more specific tests. Hope that helps. What we did was install new hard disks, restore from backups to the new hard disks, immediately find out how they got in by analysing the old hard disks, patch/fix/whatever the new hard disks so the kiddies can't get back in, and slowly and carefully go through the old hard disks and find out what they did and such (if you are interested). Good for a learning experience. Trace their actions, what they did/changed/installed/etc. - Original Message - From: Thedore Knab [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Friday, January 04, 2002 10:16 AM Subject: BIND exploited ? I recently inherited a machine that I think has been exploited. It seems to have a stupid root kit installed unless this is a decoy. What does it look like to you professionals? [EMAIL PROTECTED] ...]# uname -a Linux moe. 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown [EMAIL PROTECTED] ...]# ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 1120 476 ?S 2001 0:06 init [3] root 2 0.0 0.0 00 ?SW2001 0:00 [kflushd] root 3 0.0 0.0 00 ?SW2001 0:27 [kupdate] root 4 0.0 0.0 00 ?SW2001 0:00 [kpiod] root 5 0.0 0.0 00 ?SW2001 0:01 [kswapd] root 6 0.0 0.0 00 ?SW 2001 0:00 [mdrecoveryd] root 154 0.0 0.3 1104 392 ?S 2001 0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-scripts/suspend -r /etc/sysconfig/apm-scripts/resume bin315 0.0 0.3 1216 404 ?S 2001 0:00 portmap root 330 0.0 0.0 00 ?SW2001 0:00 [lockd] root 331 0.0 0.0 00 ?SW2001 0:00 [rpciod] root 340 0.0 0.4 1164 516 ?S 2001 0:00 rpc.statd nobody 414 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 415 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 416 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 420 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o nobody 421 0.0 0.4 1308 544 ?S 2001 0:00 identd -e -o daemon 432 0.0 0.2 1144 296 ?S 2001 0:00 /usr/sbin/atd root 446 0.0 0.4 1328 572 ?S 2001 0:00 crond root 464 0.0 0.3 1168 468 ?S 2001 0:00 inetd root 478 0.0 1.6 3160 2120 ?S 2001 14:00 /usr/sbin/snmpd root 543 0.0 0.3 1156 400 ?S 2001 0:00 gpm -t imps2 xfs604 0.0 0.6 1920 876 ?S 2001 0:00 xfs -droppriv -daemon -port -1 root 645 0.0 0.0 852 100 ?S 2001 0:00 /etc/.../bindshell root 646 0.0 0.0 864 124 ?S 2001 0:00 /etc/.../bnc root 650 0.0 0.3 1092 408 tty2 S 2001 0:00 /sbin/mingetty tty2 root 651 0.0 0.3 1092 408 tty3 S 2001 0:00 /sbin/mingetty tty3 root 652 0.0 0.3 1092 408 tty4 S 2001 0:00 /sbin/mingetty tty4 root 653 0.0 0.3 1092 408 tty5 S 2001 0:00 /sbin/mingetty tty5 root 654 0.0 0.3 1092 408 tty6 S 2001 0:00 /sbin/mingetty tty6 root 655 0.0 0.0 856 104 ?S 2001 0:00 /etc/.../lsh 31333 v0idzz named 9928 0.0 4.9 7268 6356 ?S 2001 6:48 named -u named root 11369 0.0 0.3 1092 408 tty1 S 2001 0:00 /sbin/mingetty tty1 root 3574 0.0 0.5 1464 760 ?S20:28 0:00 in.telnetd: calendar-spaces. root 3575 0.0 0.9 2312 1196 pts/0S20:28 0:00 login -- ted ted 3576 0.0 0.7 1696 940 pts/0S20:28 0:00 -bash root 3599 0.0 0.7 2008 900 pts/0S20:28 0:00 su - root 3600 0.0 0.7 1748 996 pts/0S20:29 0:00 -bash root 3719 0.0 0.4 1172 540 ?S20:38 0:00 syslogd -m 0 root 3728 0.0 0.6 1440 768 ?S20:38 0:00 klogd root 3817 0.0 0.5 2332 704 pts/0R20:43 0:00 ps auxww [EMAIL PROTECTED] ...]# cd /etc/... [EMAIL PROTECTED] ...]# ls -la
