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
