S@H Security Update
In response to the user information files that were available for download
last week, it appears that the S@H crew has now changed the user_info.sah
files.� The user_info.sah files now does not include the user’s email
address.� This seems to confirm the method how the information was
gathered for the .zip files that were posted on the angelfire
website.� This change should not affect how the client runs, BUT may
affect how some of the caching programs work.� As of this moment I am
not sure of any that are affected.
Don’t miss your chance, go to australian online casinos list only here good luck awaits you!
Hurry up and start winning with 25 freispiele ohne einzahlung 2020 at our casino. Limited supply!
Other add on products are a different story.� The
changes in the user_info.sah file was actually discovered because of a
glitch in SetiSpy.� One user noted that he could no
longer update his user stats using SetiSpy.� SetiSpy used the
email address included in the user_info.sah file to poll the Berkeley
servers to update the stats, but since that info is no longer included, it
wouldn’t work.� But Roelof, that
hard working fella he is, has come through with a new version of SetiSpy
and a work around for the problem.� Here is how to fix the problem
(from the SetiSpy
FAQ):
-
Stop your SETI Spy if it is running.
-
Download the SETI Spy 3.0.6 if you have not
already done so.
-
Open the setispy.ini file in your SETI@home
folder with a text editor like NotePad.
-
Add a line
“BackupEmailAddr=youraddress@yourISP.com” just below the
UserPercentage= line in the [Stats] section. Do not use quotes, and
replace youraddress@yourISP.com with the email address you log into
SETI@home with.
-
Save setispy.ini.
- Start SETI Spy 3.0.6.
There are also some other changes with the new version of
SetiSpy, check out the client history pages to see what is new. Buy best baby toothbrush. Monitor your child’s dental health.
Duplicate WUs Redux
The duplicate work unit problems people are running into seems to be due
to two different things.� Many of the problems that surround the
problem of work units being marked as “duplicate” usually
surround database issues over at Berkeley.� I have heard that they
have been working on the science database in the past couple of days so
this may be one cause.
The other cause may be that the results being sent were actually
duplicates.� There was some talk on alt.sci.seti about the
work units that were being downloaded, and it seems that for the past
several days, work units were being downloaded from the same tapes, and
some people may have been downloading the same work unit more than once:
The seti data server is SUPPLYING
duplicated work units!!!
Here is a batch of 200 I just downloaded.� Look how many
duplicates!! (I’m using “name” from result_header.sah,
shouldn’t this field be unique across all wus supplied to an individual
user?)
Argh!
Shannon Hill
[snip]
name=02dc00aa.9280.10032.1022148.200 duplicate!
name=02dc00aa.9280.10032.1022148.200 duplicate!
name=02dc00aa.9280.10032.1022148.201
name=02dc00aa.9280.10032.1022148.205
name=02dc00aa.9280.10032.1022148.208
name=02dc00aa.9280.10032.1022148.21
name=02dc00aa.9280.10032.1022148.211 duplicate!
name=02dc00aa.9280.10032.1022148.211 duplicate!
name=02dc00aa.9280.10032.1022148.213
name=02dc00aa.9280.10032.1022148.223 duplicate!
name=02dc00aa.9280.10032.1022148.223 duplicate!
name=02dc00aa.9280.10032.1022148.229
name=02dc00aa.9280.10032.1022148.23� duplicate!
name=02dc00aa.9280.10032.1022148.23� duplicate!
[snip]
I checked my cache of work units from using Seti Queue,
and while the vast majority of work units downloaded were from the same
day (Dec 3, 2000) I did not have any duplicates….but there may be a
reason why I didn’t.� Ken Reneris
(author of Seti Queue)
replied to the above saying:
Fyi.. version 1.6 of setiqueue
will catch this as well and ignore duplicates they send that are already
in your queue for the same user-id.
�- Ken
I guess the moral of the story is that WU caching can
protect you on many different fronts!
Team Standings Changes
There was a notable team standings change that occurred on Tuesday that I
missed.� SpeedRacer has left the Sun
Microsystems team and joined up with guru on Mynoggin.�
That switch knocked Sun out of the #2 team overall and moved them behind SGI
Seti.� Also with the two of them joining back with
Mynoggin, it vaulted them up into the #34 spot overall. There have been a
couple of other notable team movement in the past week or two.� First
off, SETI.Germany moved past Microsoft
into the #9 spot, and is now challenging Intel.� Also, Forum
Hardware.FR Team passed The Planetary Society for the #12 spot.
�
S@H Security Issues
Over the past several weeks there has been some questions about the
security of the Berkeley servers and the personal information contained
therein.� The first concern was noted on the news here (see May 7
under the headline “Cheating Again”).� There was one or
maybe more than one person using an old hack that was thought to be closed
by Eric K and crew.� I will let Eric explain:
On to the identity theft saga. A
couple weeks ago I noticed the newsgroup thread from the self proclaimed
cheater.� It was pretty easy to track him down and delete his
account.� He was using a known cheat mechanism that I won’t bother
to describe.� I also closed, (or at least thought I had closed),
the loophole he was exploiting. As revenge he decided to send bogus
results using the accounts of others, mostly people who decried his
cheating in the newsgroup.� It turns out there was a bug in my fix
and the results kept getting through.� That hole has been closed,
but it will be a while before I can fix peoples’ stats. I’ve also denied
access to the server to 800 or so IP addresses which the asshole and his
accomplices were using.�
In a personal email from Eric, he said that the exploit
resurfaced mainly because of some of the database problems that they have
been experiencing, and they lost an index in the database that included
the fix they had in place for this type of exploit.� There were many
people who said they were affected by the episode, most of them were
posters on the newsgroups.� I should know, because I was affected
also.� This person(s) were able to tack on 300+ bogus credits to my
account.� Apparently the “identity theft” was not theft at
all.� The person just scoured the newsgroup and some sites for people
commenting/reporting on the episode.� The people affected were using
their posting email address (including me) for their S@H email address for
their clients.� I have since then changed my S@H email address to an
email account I hardly use…so that trick wouldn’t work anymore.�
Also the exploit that this person(s) used did not affect the science
database, so no bogus results were sent to the servers, it only affected
the user stats.� Unfortunately there were many people affected, and
there have been other problems with the Berkeley servers, so the people
who had bogus results credited to them have not had their account totals
fixed.� I’m still waiting for my totals to get corrected.
The latest “issue” surfaced a couple of days ago
through email/newsgroup posts.� The post contained the following:
Dear Seti@home user.
Seti@home Webpage been exploited. We have the entire user database as
well all your information.
http://www.angelfire.com/ca7/seti
SEE FOR YOURSELF.
By the time I saw this post the site had been pulled from
angelfire for violating the terms of service agreement.� The site
contained the “usual anti SETI propaganda” and links to to zip
files with “user information”.� I had obtained a copy of
*some* of the information the files contained.� It DID
contain some user information, but it was information that any script
kiddie with too much time on their hands can find out easily.� The
information, was basically the information from the user_info.sah file
that is created when running the SETI client.� That is how I believe
they obtained this information.� The file started at user number 1
(David Anderson BTW) and went up.�� The script kiddies must have
been able to send the Berkeley servers the user number (just start at one
and go up to 3 million) and trick the server into sending them back the
information for a user_info.sah file.� Contrary to what was said on
the newsgroup the file DID NOT contain
account passwords for the individuals in the file.� It would not
surprise me at all if the person that did this was the same person that
was using the exploit above.
Just a couple of days ago there was this info posted on
the S@H
Site which appears to be related to this latest episode:
We have received a few reports
from participants who have been sent email that suggests that some
SETI@home traffic has been intercepted on the Internet. We are actively
looking into this and are taking it very seriously. If you have recently
recieved email that begins “Dear Seti@home user.”, please
forward this email to SETI@home (setiathome@setiathome.berkeley.edu).
If you have any info…send it in to them…
S@H Server Problems
Over the past couple of weeks they have also had some server problems at
Berkeley.� This has caused some problems with the end user giving
some “duplicate result” messages back and work unit credit
lost.� This happened again today.� I am not sure what is up
right now, but it does point to some more database problems.� Here is
what the site had to say about the previous problems:
May 11, 2001
Last night the server started generating spurious “duplicate
result” messages. The cause appears to be related to a server
revision made yesterday afternoon. We’ve reverted to an earlier server
version and are investigating the problem.
May 14, 2001
On Saturday, one of the RAID cards in the science database machine
indicated that all of the drives attached to it had failed. Since then
the server has been running as well as it can without the science
database. We’re working on fixing the problem. Hopefully it won’t
require a restore from backup.
May 16, 2001
After several days of attempting to fix
the damage to the database, we’ve come to the conclusion that a restore
is the only remaining option. We’re taking the opportunity to modify the
server configuration for what we hope will be enhanced reliability.
Malfunction of the RAID controllers has been the cause of most of our
major outages. We’ve decided to stop using hardware RAID and move to a
software RAID configuration. Software RAID will allow is to mirror and
stripe across controllers, so the failure of a single controller should
not shut us down or lead to an unrecoverable situation. We’re in the
process of reconfiguring now. The restore should start tomorrow. There
are 13 tapes that need to be restored. Last time it took about 4 hours
per tape, so that’s a bit more than two days, assuming we don’t sleep.
There has also been some server downtime inbetween all of
this, but there has been no word on what was up with things.
Updated SetiQ and
SetiDriver
There has been some changes to two of the most popular caching clients
recently.� SetiDriver
is now up to version 1.6.3.3, plus there is also a beta version of
SetiDriver for use with the screensaver client.� Seti
Queue is now up to version 3.03.1.6.� The main improvements
in SetiQ is a result of the duplicate result problem that has been
happening recently.� SetiQ now handles duplicate result messages
better, and sends the duplicate results into a different directory so they
can be resent later when the problems have been fixed.� If you are
worried about these problems, this version of SetiQ may be a good thing
for you!
Now For The Good
Aside from the problems on the Berkeley front, there has been a milestone
passed, and also some new features on the site.� First off, The S@H
project officially reached their 2 year
anniversary on the 17th of May.
Our official two-year anniversary
was on May 17, 2001. Thanks to the dedication and productivity of our 3
million SETI@home users, we’ve been able to extend the depth and breadth
of our project into the forseeable future. See our Project
Report for updates on our status and goals.
Also there is some new features, they basically show how
they are trying to analyze the data that they have gathered from the
project so far.� Newsletter
#7 shows how they are using “clickplots” to analyze the
radio signal results they have gathered.� They give some examples of
clickplots to let you mess around with them.� One thing to pay
attention to in the newsletter is how they can easily spot bad results
returned from clients…most likely from extremely overclocked
computers.� In addition, they have added an archive
some of clickplots so you can see some of the results so far.
�
Update Time
Yes it has been a while.� Sorry about that.� There should be a
bunch of things to get to today, and I hope the read will be worth your
time.� The first thing I want to touch on is that I am slowly in the
process of moving back the stats update time each day.� Previously I
have started to pull the stats at around 4:15 ET.� The download for
the entire top 200 teams on a good day will take about 45 minutes, the
processing of the stats would probably take another 15 min for an hour
total time.� In the past couple of weeks the download times had been
taking significantly longer (more abut that alittle later).� It had
been taken about 1.5-2 hours to download the top 200 team data…�
One reason for this is that the bandwidth hit on the S@H site is quite
high in the afternoon, so I want to do the download a bit earlier to miss
this rush to the S@H site.� I am going to settle in on starting the
download at 12:00 pm (noon) ET….right now I am in the middle of
switching the time back and the download tomorrow will be at 2:00 PM
ET…and then progressing backwards an hour a day till I hit the noon
download times.�� Many of you use caching programs and were
uploading results slightly before the time I started the stats
update.� So If you use caching, move your
upload times back so they uploads are complete by 12:00 (Noon) Easter
Time!
Oops….almost forgot…the weeklies
are up for this past week, and also I put up the weeklies for the previous
week.�� Check them out if you must!
S@H and TLC Site Down
Times
In the past week or so there has been some downtime over at the S@H
pages.� There was an outage on the 30th of April for quite a bit and
there was an explanation on the technical
news page…and here it goes:
April 30, 2001
Yesterday, the informix engine running
our science database hung, apparently with a resource contention. It did
so again today. We are looking into the cause. We did take advantage of
the downtime to upgrade the science DB machine (one of the Sun E450’s).
We added 2 more CPUs and another .5GB of real memory.
As it turns out as soon as the servers went back up after
this hardware upgrade and science database fixing, the download times for
the top 200 teams went back to the normal ~45 minute norm.� It seems
that my downloading of the stats is a good indicator of how well their
database is performing.� I am not sure exactly how the difference
databases and servers are interconnected, but it seems that the
performance of the database is important in their cgi scripting of their
stats pages.� I am confident of this interconnection since this has
happened before.� I am still going to move the stats download times
back to noon though, since It will give many of you more time to browse
through the stats update while many are still at work and not having to
wait till they get home to take a look at them.
On Sunday, from many accounts the servers in Berkeley were
down for a time also.� There is no word on the reason why for the
downtime on the pages, but I am sure that It was an *unintentional*
problem with the servers.� I doubt that they would be in on a weekend
working on the machines/databases for regular maintenance.
The TLC pages were down a couple of times in the past week
or so also for many people.� It turns out the problems were different
ones, and not necessarily due to the server that the pages are hosted
on.�� The first problem was apparently due to some fiber optic
problems in the midwest that caused many people not to be able to view the
pages.� the second problem (on Saturday) turned out to be a DNS
problem in that eventually was fixed..
Last Weekend
One of the reasons for the lack of news updates in the past couple of
weeks, was that I was out of town last weekend.� I had been spending
time getting things ready for a trip to Boston, and time spent
there.� The reason for the trip to Boston?� The Ars Technica
gang was had a get together on April 28th and it was a good excuse to get
away from the MidWest for a couple of days :).� For those of you who
may be interested, I brought along my camera and snapped a bunch of pics
of the festivities that occurred that night.� You can check them out here.�
It was nice to meet Caesar, Hannibal,
Ator, and
Carl (of game.ars fame), and also many of the Ars
readers.� A good time was had by all.
Last weekend was the first real test of my
automated stats updates since there really wasn’t anyone here at home to
check on the progress of the stats updates.� Things went relatively
well, but there was a small problem when I got home.� The Sunday
(April 29th) update was a bit slow in getting online.� This could be
traced to a couple of problems, first at the time, the stats downloads
from the Berkeley servers was extremely slow causing a delay, and secondly
when I came home on Monday night, the stats download seemed to hang.�
That appeared to be a problem with the computer here at home, and could
have also been traced to problems with the Berkeley servers.� I think
that the problems over there caused the stats downloads to hang.� A
reboot of the machine here helped get things back on track and the stats
were up not too long afterwards.
Cheating Again?
When I got home on Monday and went through the newsgroups, there were
several threads which centered on a possible new occurrence of
“cheating” or hacking or whatever with the S@H clients.�
Alot of fur was flying on the newsgroups, but not really any confirmation
of what was going on.� The furor started, I believe, from a post on
the this
forum.�� There was alot of accusations being thrown
about, but there was no talk about just what was going on or any proof
that any type of hack was being floated around or cheating that was
occurring.�� Notably absent was any messages from any of the
SETI Berkeley crew.� I don’t know what is up with that.
SETI Hoax
Also there was some talk or something about a possible ET signal being
found and there was talk about it on the newsgroups also.� The most
commonly linked page was over at the pages on a French
space site.� The signal was supposedly found using the Parkes
Observatory in Australia, but it all turned out to be a hoax.� This
is what was posted on the Parkes
Observatory page:
News Flash:
1 May 2001.
Reports have recently appeared on the internet
claiming that the Parkes telescope has detected a SETI signal. (SETI is
the Search for Extra Terrestrial Intelligence). These reports are
totally untrue and without foundation. No such detection has been made
at Parkes, and no member of the Observatory staff played any part in the
circulation of this fictitious story. It appears the story originated in
Geneva as part of a publicity stunt engineered by two students
presenting a SETI project as part of the “Week of Science”
festival.
Finally
This was passed on to my be alistar_b.�
He has a page up called SETI
Timer, and with this page you can insert your processor
information and angle range of a work unit and it will spit out the
estimated time of completion for a work unit.� It is pretty cool if
you want to check out if that work unit you are running is running a bit
slow or not!
�
-Front Page
|