The paranoia is getting out of hand. Let's take this one point by point. I've deleted the poster's name, because this note is just an example; it's not the only such posting. Certainly that may be so.. but in this case they didn't merely tell 'you' with a simple note, instead they did atleast 2 things which really are bothersome and overstepping common 'courtesy' of merely informing 'you': ``You''? Who is ``you''? The CERT note didn't mention any individual. They might not have the information. If they did, it might be because the account was compromised. (That was the case the last time I helped a friend investigate ftp droppings. In that case, though, it was only the ftp account, not the login account, so notifying the owner would not have been damaging. Btw -- remember the recent CERT advisory on bugs in the WUSTL ftpd?) 1) Instead of going directly to the owner of the directory in question or the administator of the host they jumped over 'your' head and went to the domain administrator. I can see going to a site administrator if they had reason to believe the owner of the directory was doing something illegal.. but then again they have no authority to make/enforce/etc any kind of laws. They were just plain out of line. Consider this example (and I'll give them the benefit of doubt here that someone really did complain to them and they aren't on some witchhunt of their own): I am Cert and Mr Von Karman has emailed me to say that a /jet/Enigma-cypher-code directory appears to have illegal software of some kind.. so I send up my email.. not to you.. but to Goldin, the new NASA head that I believe this directory owned by you has illegal software on it. Well that is a good way to put some bad marks on your record even if you do prove it untrue to your boss.. maybe you had just removed the evidence before he checks out your acct.. either way he shuts down your net access for a while..'just to be sure', and look out next time you want a promotion.. can't be to safe.. you might be a security risk! As I said before, they might not know who was involved. Even if they did, and even if the account wasn't compromised, it's the SA's responsibility to investigate. What if a local user is doing un- authorized things? Take this particular case -- they could easily end up being sued for contributing to copyright infringement. They might win -- but defending against a lawsuit is expensive. 2) They didn't check the system out before hand and blatantly said as much.. what kind of service to you is that? my friend met a guy who knows bigfoot..but certainly you don't see me bothering the people who own the land where bigfoot is supposed to live. Check it out? How? Apart from the question of whether or not you want CERT looking through your directories (and I can just hear the complaints now -- ``On no evidence but an anonymous tip, CERT logged in, listed everything, looked for *my* hidden areas that I used to distribute restricted software, and tied up my link to the Internet for hours while the downloaded everything in sight'') -- it isn't feasible. I just ftp'd to soda for a quick look-see. A ls-lRa generated 160K bytes. Simply screening that takes time. Many of the files showed only numeric uid's; the ftpd passwd file was obviously not up to date. Even if I knew the suspect files, I might not know who the responsible user was. Many of the files had informative names like ``packet123.Z''. They mirrored the full X11R5 distribution. How much time and effort should CERT put in?!?!! A competent SA will at least know the putative ownership and reliability of the owner of most of that stuff; CERT sure doesn't (except, of course, for the list of hackers they may or may not have, and which has been (rightly) objected to). 3) They want to confiscate logs from the system.. That sure as heck isn't any of their business.. Confiscate? Confiscate? They asked for a copy, if available. ``Confiscate'' generally means ``take away''. They're not taking anything from you. If the logs do show anything, it's precisely their business -- evidence of someone abusing your system (I'm assuming here that there really was 3rd-party deposits and retrieval of files). Quick -- how many of those file transfers are coming from stolen accounts? In my experience, a goodly number. Look, I have my own concerns about CERT in this matter, notably the questions of what evidence they're acting on, and whether or not they're being used (consciously or not) to silence unpopular sites. I've sent them a note asking those questions. But let's try to keep things in perspective. Oh yeah -- as an added bonus, I've enclosed a transcript of the kinds of things I do when trying to find an administrative contact for some machine. I don't see any avenues of contact more likely than ``root'' or ``postmaster''. And it's clearly a large-scale timesharing machine, where there's no one individual clearly responsible for it. --Steve Bellovin ----- $ whois -h rs.internic.net soda.berkeley.edu No match for "SODA.BERKELEY.EDU". The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. $ finger root@soda.berkeley.edu [soda.berkeley.edu] Login: root Name: The Allmighty Directory: / Shell: /bin/csh Office: E238, x2-7453 Last login Mon May 31 22:17 (PST) on console No Plan. $ finger postmaster@soda.berkeley.edu [soda.berkeley.edu] finger: postmaster: no such user. $ dig mx soda.berkeley.edu ; <<>> DiG 2.0 <<>> mx soda.berkeley.edu ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 3, Addit: 8 ;; QUESTIONS: ;; soda.berkeley.edu, type = MX, class = IN ;; ANSWERS: soda.berkeley.edu. 55780 MX 4 soda.Berkeley.EDU. soda.berkeley.edu. 55780 MX 6 scotch.Berkeley.EDU. ;; AUTHORITY RECORDS: Berkeley.EDU. 161050 NS VANGOGH.CS.BERKELEY.EDU. Berkeley.EDU. 161050 NS VIOLET.Berkeley.EDU. Berkeley.EDU. 161050 NS UCBVAX.BERKELEY.EDU. ;; ADDITIONAL RECORDS: soda.Berkeley.EDU. 55780 A 128.32.149.19 scotch.Berkeley.EDU. 55780 A 128.32.131.179 VANGOGH.CS.BERKELEY.EDU. 161050 A 128.32.130.2 VIOLET.Berkeley.EDU. 161050 A 128.32.136.22 UCBVAX.BERKELEY.EDU. 39151 A 128.32.137.3 UCBVAX.BERKELEY.EDU. 161050 A 128.32.130.12 UCBVAX.BERKELEY.EDU. 161050 A 128.32.149.36 UCBVAX.BERKELEY.EDU. 51896 A 128.32.133.1 ;; Sent 1 pkts, answer found in time: 0 msec ;; FROM: inet to SERVER: default -- 0.0.0.0 ;; WHEN: Tue Jun 8 20:16:07 1993 ;; MSG SIZE sent: 35 rcvd: 295 $ telnet soda.berkeley.edu 25 Trying... Connected to soda.berkeley.edu. Escape character is '^]'. 220 soda.berkeley.edu Sendmail 5.65/KAOS-1 ready at Tue, 8 Jun 93 17:10:50 -0700 helo research.att.com 250 soda.berkeley.edu Hello research.att.com, pleased to meet you vrfy root 250-Eric Hollander <"|/accounts/hh/remail/slocal.pl"> 250-Keir Morgan <kmorgan> 250-ERic MeHlHaFf <mehlhaff@ocf> 250-ERic MeHlHaFf <\mehlhaff> 250-Tom Holub <tom> 250-John S. Jacob <jsjacob> 250-Matthew L. Seidl <seidl> 250-Shannon D. Appel <"| /usr/local/lib/mh/slocal -user appel -verbose"> 250-Sean N. Welch <welch@xcf.berkeley.edu> 250-Dan Wallach <dwallach@postgres.berkeley.edu> 250-Donald J. Kubasak <kube> 250-David G. Paschich <dpassage> 250-Adam Glass <\glass> 250 Adam Glass <glass@postgres > vrfy postmaster 250-Eric Hollander <"|/accounts/hh/remail/slocal.pl"> 250-Keir Morgan <kmorgan> 250-ERic MeHlHaFf <mehlhaff@ocf> 250-ERic MeHlHaFf <\mehlhaff> 250-Tom Holub <tom> 250-John S. Jacob <jsjacob> 250-Matthew L. Seidl <seidl> 250-Shannon D. Appel <"| /usr/local/lib/mh/slocal -user appel -verbose"> 250-Sean N. Welch <welch@xcf.berkeley.edu> 250-Dan Wallach <dwallach@postgres.berkeley.edu> 250-Donald J. Kubasak <kube> 250-David G. Paschich <dpassage> 250-Adam Glass <\glass> 250 Adam Glass <glass@postgres > quit 221 soda.berkeley.edu closing connection Connection closed by foreign host. $ finger @soda.berkeley.edu [soda.berkeley.edu] Login Name Tty Idle Login Time Office Office Phone aaron Aaron C. Smith qR Jun 8 08:58 Limbo 643-7217 aaron Aaron C. Smith *qT Jun 8 08:58 Limbo 643-7217 achoi Andrew Choi pB 3 Jun 7 18:19 appel Shannon D. Appel pK Jun 8 09:57 CEA 643-5657 aswan Andrew Swan pW Jun 8 17:06 calvin Wa Pak qe 22:11 Jun 7 18:57 cgd Chris G. Demetriou qf Jun 7 22:15 278 Cory 510-642-7520 cliffwd Cliff Draper pe 36 Jun 8 16:30 9-204a 643-3426 cynthia cynthia leigh haynes *pr 3 Jun 8 16:43 cynthia cynthia leigh haynes ps Jun 8 16:43 deb Debra Waldorf *p7 Jun 8 16:20 deb Debra Waldorf *qg 51 Jun 8 15:27 eganloo Egan Loo pJ Jun 8 16:57 eric Eric van Bezooijen qz 1:01 Jun 8 15:50 238E gwh George William Herbe pc 1 Jun 8 14:13 238E gwh George William Herbe pm Jun 8 14:26 238E henchiu Henry Chiu pR Jun 8 17:02 ho Kinson Ho *q3 1:13 Jun 8 15:08 608-1 Evan 642-8290 hughes Eric Hughes *qm 36 Jun 8 10:34 238E isaac Isaac Cheng *pE 12 Jun 8 09:51 isaac Isaac Cheng *qw 12 Jun 8 10:59 jenn Jennifer Hom *pF Jun 8 16:52 238E 415-688-8034 jlb Jordana Brown pQ Jun 8 14:45 karlht Karl Thiessen *pb 13 Jun 8 16:28 238 Evans 642-7453 kenji Kenji Hubbard *pX Jun 8 17:08 238E kube Donald J. Kubasak pU 2 Jun 8 17:05 CEA ESOC 643-7367 marco Marco Nicosia qI Jun 8 15:58 238E 510-283-9587 maroo Maroo Lieuw *qx Jun 8 13:33 849-9872 michelle Michelle Tisi *qZ 5:30 Jun 8 11:34 ming Tje Ming *qj 9 Jun 8 15:28 ming Tje Ming *qO 2:17 Jun 8 13:50 mlee Michael Lee *pD Jun 8 16:49 mlee Michael Lee *qC Jun 8 15:52 nancy Nancy Cheng *pf 1:18 Jun 8 14:17 nancy Nancy Cheng *qV 1:53 Jun 8 13:52 payam Payam Mirrashidi po 19:13 Jun 7 20:54 199MD Cory 642-1297 psb partha s. banerjee *py 2:25 Jun 8 14:32 IBM Almade 510-649-7505 psb partha s. banerjee *pz 2:38 Jun 8 14:32 IBM Almade 510-649-7505 ralbers Rick Albers *pV Jun 8 17:06 rmgee Randall Gee *pn Jun 8 14:28 robert Roberto Boyd *pA Jun 8 16:47 rsr Roy S Rapoport *pY Jun 8 17:09 510-540-5535 seidl Matthew L. Seidl qk 1 Jun 8 10:31 238E x2-7453 seidl Matthew L. Seidl *qB Jun 8 08:32 238E x2-7453 sfd Scott Drellishak pl Jun 8 16:40 Kerr 3-202 tom Tom Holub *pH Jun 8 16:53 tom Tom Holub pI Jun 8 16:53 welch Sean N. Welch *p0 Jun 8 09:04 MTV21-122 415-336-4289
As I said before, they might not know who was involved. Even if they did, and even if the account wasn't compromised, it's the SA's responsibility to investigate. What if a local user is doing un- authorized things? Take this particular case -- they could easily end up being sued for contributing to copyright infringement. They might win -- but defending against a lawsuit is expensive.
Yes. Agree. And I would have had no problem had they contacted the SA at my site (me) or even my connectivity service provider (EUnet), but they didn't. They contacted the domain admin for Finland. A high-level "political" authority on a national level! Without consulting anyone involved... Julf
participants (2)
-
Johan Helsingius
-
smb@research.att.com