Re: Mersenne: hackerz attackerz
[EMAIL PROTECTED] wrote: > My ftp server has suffered its first (to my knowledge) hacker penetration. > First of all, I take offence at the use of the term "hacker" here. I would havthought most people following this list are knowledgeable enough to make the distinction - what GIMPS for example does is hacking, what the "script-kiddies" did with Amazon etc. is best characterized as cracking. These peoplere crackers - they go around cracking software licenses/copy protection and site security. By definition you can never "secure" your sytem against them, since breaking into systems is what they do. You can make it harder, or not (seemingly) wort their trouble. As somebody else alreaaid, though, it doesn't look like what you were dealing with were crackers, either, or DoS attacks for that matter. You were just dealing with somebody who thouht they had found an open server to store and share their cracks/scripts on. Because these files are borderline-illegal, they try to sneak them in without the systems adminstration knowing. > So my question to the sysadmins out there is: what's the best way to avoid > this sort of thing, without installing a firewall and while still permitting > ftp access? > Permit only read access, no write access. If you need to keep write access, set up a quota on the FTP user/daemon (Or better yet, put the FTP directory on separate filesystem from the rest of the system) and allow writing only on /incoming, but disable reading from that directory. This leaves possible abusers with no incencitive to upload files. If you need to allow write access to certain directories to certain people, set them up with accounts with needed access to the FTP directories. -Jukka Santala _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: hackerz attackerz
>So my question to the sysadmins out there is: what's the best way to avoid >this sort of thing, without installing a firewall and while still permitting >ftp access? > >In re-reading the DEC Unix manpage for ftpd, it seems to me the weakest >link is the guideline for the ~ftp/pub directory, which the manpage >says to make owned by ftp and writeable by anyone. I've changed it >to be owned by root and unwriteable except by root, but that may >not be an option for folks who maintain public ftp archives that >multiple users must be able to write to. Make sure that no one logging in as anonymous can write to the ftp archive (which it sounds like you did), and no one can log in as himself and upload anything (which I'm not sure how to do). Allow only rsync, either with modules or over ssh, to update the ftp space. phma _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: hackerz attackerz
First I am not a real expert. Turning off write permission on the blanks directory is not enough. You need to turn off permission on all the subdirectories also. Use find ' ' -type d -print | xargs chown root (between the quotes are 3 spaces). >From your description, it sounds like your system was not really violated. They just uploaded a bunch of stuff because the permissions on ftp/pub allowed it. If you think they may have gotten root permission, it is probably too late to ever trust the system again. It will need to be reinstalled from cd-rom (or other trusted media). Most ftp sites I have seen keep ftp/pub restrictive and make an ftp/incoming that is writable by user anonymous. As far as the steps you can take to protect yourself: 1. If your machine is a Linux box, installing a firewall is not that hard. My home gateway Linux box has the firewall enabled and it rejects 10 probes a day. If your machine has a static IP address it must get probed much more often. 2. There are programs (like tripwire) that are meant to catch intruders and watch for sensitive files being changed. They basically compute a checksum on all sensitive system files and then periodically check the system files have not changed. Some store the checksums on a read-only floppy to keep the hacker from changing the checksums. 3. Install a program that makes users use secure passwords. It should disallow very short passwords and words in the dictionary. 4. Turn off unused/insecure network daemons. Things like telnetd, portmap, nfs, rshd, rlogind, fingerd, identd, and bind can be off. If you can, just run the ftp daemon, and maybe a secure shell daemon for remote administration. If you need a web server, there is no way around being an expert in the web server app to configure it securely. Use a program like lsof to find all the ports on your machine accepting connections, and understand why you need that program running. If you don't really need it, disable it. 5. Get on a mailing list for security notices about your OS. If a hacker has discovered a weakness on someone else's system, you know the bad guys are going to try it on your system eventually. As one security expert put it "There be dragons out there." Good Luck, Brian Beuning [EMAIL PROTECTED] wrote: > Dear all: > > This is off-topic, except in the sense that it involves the ftp server where > I maintain the Mlucas software for mersenne testing Unix clients. > > My ftp server has suffered its first (to my knowledge) hacker penetration. > I think I stopped the attack before any serious damage was done, but > thought I'd recap what happened and ask the sysadmins out there for > advice as to how best prevent this sort of thing in the future. > > I've already contacted the local FBI field office, but this sort of thing > (I'm not exactly eBay here :) may not be high on their priorities list. > > Summary: this morning I noticed a lot of ftp traffic on my server (not in > itself unusual), and at the same time that one of my jobs had crashed > while attempting to write to disk due to a full filesystem. After eliminating > all the obvious candidates (large core files and such), I started a detailed > account of disk usage for various directories, and found that the directory > containing my public ftp archive was several hundred MB larger than it > was 24 hours ago. After some more sleuthing, I found that someone had > logged on via anonymous ftp, created a directory with a name consisting > of several blank spaces in /usr/users/ftp/pub, and was busily uploading > hacker-sounding files into the new directory. I immediately halted network > services and changed the ownership of the blank dir from 'ftp' to 'root.' I > haven't deleted the directory in question, since there may be clues as to > the source and nature of the attach in there. > > I think someone may have been trying to turn my server into a "zombie" > such as in the recent denial-of-service attacks on several popular websites. > > Here's where my checks of disk usage first turned up the anomaly: > > # du -rsk /usr/users/ftp/pub/* > 284260 /usr/users/ftp/pub/ <==this wasn't there yesterday... > 7050/usr/users/ftp/pub/alpha_docs > 1416/usr/users/ftp/pub/amd_docs > 1503/usr/users/ftp/pub/archived > 87 /usr/users/ftp/pub/c_translations > 1200/usr/users/ftp/pub/ia64_docs > 431 /usr/users/ftp/pub/ibm_docs > 21759 /usr/users/ftp/pub/mayer > 3704/usr/users/ftp/pub/mips_docs > 5440/usr/users/ftp/pub/powerpc_docs > 149 /usr/users/ftp/pub/spec98 > 168 /usr/users/ftp/pub/transmeta_docs > 104 /usr/users/ftp/pub/usgov_docs > > This shows the blank-named dir created by the hacker, with owner = 'ftp': > > # cd /usr/users/ftp/pub/ > # ls -l > total 104 > drwxr-xr-x 3 ftp users 8192 Feb 26 22:38 <==directory name > = 3 spaces > drwxr-xr-x 2 mayerusers 819
Re: Mersenne: hackerz attackerz
> My ftp server has suffered its first (to my knowledge) hacker penetration. You can't have anonymous writable directories in FTP anymores. there are just too many abusers. Offhand, I'd say you weren't hacked, that was just the 'warez' crowd using you as a nice anoymous archive for their pirated software and MP3 files. Sounds like DEC Unix by default has this writable PUB so they probably targetted you because of this. The spaces directory is a typical 'warez' trick for hiding one of their file caches. -jrp _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: hackerz attackerz
Dear all: This is off-topic, except in the sense that it involves the ftp server where I maintain the Mlucas software for mersenne testing Unix clients. My ftp server has suffered its first (to my knowledge) hacker penetration. I think I stopped the attack before any serious damage was done, but thought I'd recap what happened and ask the sysadmins out there for advice as to how best prevent this sort of thing in the future. I've already contacted the local FBI field office, but this sort of thing (I'm not exactly eBay here :) may not be high on their priorities list. Summary: this morning I noticed a lot of ftp traffic on my server (not in itself unusual), and at the same time that one of my jobs had crashed while attempting to write to disk due to a full filesystem. After eliminating all the obvious candidates (large core files and such), I started a detailed account of disk usage for various directories, and found that the directory containing my public ftp archive was several hundred MB larger than it was 24 hours ago. After some more sleuthing, I found that someone had logged on via anonymous ftp, created a directory with a name consisting of several blank spaces in /usr/users/ftp/pub, and was busily uploading hacker-sounding files into the new directory. I immediately halted network services and changed the ownership of the blank dir from 'ftp' to 'root.' I haven't deleted the directory in question, since there may be clues as to the source and nature of the attach in there. I think someone may have been trying to turn my server into a "zombie" such as in the recent denial-of-service attacks on several popular websites. Here's where my checks of disk usage first turned up the anomaly: # du -rsk /usr/users/ftp/pub/* 284260 /usr/users/ftp/pub/ <==this wasn't there yesterday... 7050/usr/users/ftp/pub/alpha_docs 1416/usr/users/ftp/pub/amd_docs 1503/usr/users/ftp/pub/archived 87 /usr/users/ftp/pub/c_translations 1200/usr/users/ftp/pub/ia64_docs 431 /usr/users/ftp/pub/ibm_docs 21759 /usr/users/ftp/pub/mayer 3704/usr/users/ftp/pub/mips_docs 5440/usr/users/ftp/pub/powerpc_docs 149 /usr/users/ftp/pub/spec98 168 /usr/users/ftp/pub/transmeta_docs 104 /usr/users/ftp/pub/usgov_docs This shows the blank-named dir created by the hacker, with owner = 'ftp': # cd /usr/users/ftp/pub/ # ls -l total 104 drwxr-xr-x 3 ftp users 8192 Feb 26 22:38 <==directory name = 3 spaces drwxr-xr-x 2 mayerusers 8192 Feb 27 03:10 alpha_docs drwxr-xr-x 2 root users 8192 Feb 27 03:10 amd_docs drwxr-xr-x 2 mayerusers 8192 Nov 26 02:38 archived drwxr-xr-x 2 mayerusers 8192 Jun 2 1998 c_translations drwxr-xr-x 2 mayerusers 8192 Feb 27 03:10 ia64_docs drwxr-xr-x 2 root users 8192 Feb 27 03:10 ibm_docs drwxr-xr-x 6 mayerusers 8192 Feb 27 01:20 mayer drwxr-xr-x 4 mayerusers 8192 Mar 31 1999 mips_docs drwxr-xr-x 3 mayerusers 8192 May 4 1999 powerpc_docs drwxr-xr-x 3 mayerusers 8192 Apr 19 1999 spec98 drwxr-xr-x 2 root users 8192 Feb 27 03:10 transmeta_docs drwxr-xr-x 2 root users 8192 Feb 27 03:10 usgov_docs The blank dirname is designed to make it harder to see what's in there, so one needs to do something to avoid directly entering a blank dirname, like # ls -l /usr/users/ftp/pub/* /usr/users/ftp/pub/ : total 8 drwxr-xr-x 3 ftp users 8192 Feb 26 22:38 4_mboca Within the directory 4_mboca was another directory named 'by_hitekfraud', containing the following goodies Mr. hacker uploaded: # ls -l total 168 drwxr-xr-x 2 ftp users 8192 Feb 27 10:23 AutoBot.v1.1.Cracked-DQF drwxr-xr-x 2 ftp users 8192 Feb 27 11:36 BEATMANIA_DA-SCAR drwxr-xr-x 2 ftp users 8192 Feb 27 02:49 Invictus-CLS drwxr-xr-x 2 ftp users 8192 Feb 27 10:14 Invictus_Manual_REPACK_FTFdOCs drwxr-xr-x 2 ftp users 8192 Feb 27 02:47 Invictus_music drwxr-xr-x 2 ftp users 8192 Feb 27 10:11 Revenant.Patch.1.2-FLTDOX drwxr-xr-x 2 ftp users 8192 Feb 27 01:08 boa.bite.3d-razor drwxr-xr-x 2 ftp users 8192 Feb 27 01:08 boa.bite.3d.trainer-paradigm drwxr-xr-x 2 ftp users 8192 Feb 27 02:24 easycert_easy_nt_server_4_v4.0_win9xnt_incl_keymaker-ucf drwxr-xr-x 2 ftp users 8192 Feb 27 02:24 flashfxp.v1.2.build.475.with.keygen--core drwxr-xr-x 2 ftp users 8192 Feb 27 02:24 flashfxp.v1.2.keygen.and.blacklist.checker.only--core drwxr-xr-x 2 ftp users 8192 Feb 27 02:25 invisible_secrets_v2.0_incl_keygen-ucf drwxr-xr-x 2 ftp users 8192 Feb 27 02:29 novell.netware.v5.0.unlimited.connection.licenses-dod drwxr-xr-x 2 ftp users 8192 Feb 27 02:46 pba.bowling.2-cls drwxr-xr-x 2 ftp users 8192 Feb 26 22:45 red.thunder-minime drwxr-xr-x 2 ftp users
