In light of recent abusive actions, what are the main security goals of
Cyberspace Communications and the staff of Grex server? We have
primarily seen attacks attempting to compromise the availability or
usability of resources, ranging from access to the usability of the
forums and email. Security is typically looked at in terms of
confidentiality (keeping an adversary from learning a secret), integrity
(making sure something is not changed without permission) and
availability (assuring that a resource is there when you expect it to
be) and the prevention of being used to attack the security of others.
If we have no security goals at all, why not just post the root password
on the web page and put everyone into wheel group? (For the humour
impaired like myself, that was not a real suggestion). In order to
effectively and reasonably defend the security of our asset (Grex
server), we need to define the asset and resources that it provides, and
decide what we are trying to protect about it. If we do not care about
secrecy, we do not need to read-protect files, do not need to use
cryptography. If we do not care about integrity, why write-lock files or
use check-sums or cryptography? If we are not concerned with
availability, we should not take backups or pursue the perpetrators of
DOS attacks or consider redundant storage or have any files schg. If we
have no real security concerns, then we can make our lives much easier
and let staff have some time off (just put the root password on the
webpage and let everyone volunteer to help manage the server). 



-maus 

68 responses total.

*laugh* OK maus, even we humor-impaired folks can see your point.

Since STeve hasn't had time I will relate my understanding of our
conversation earlier this week.

STeve essentially said that the internet ain't what it used to be, and
that goals like open access to Grex had reached its limits.  If I
understood him correctly, he suggested that we implement a version of
social validation for creating new accounts on Grex.  

In this case, no one could create a new account without first going
through some kind of process, which could be handled by the semi-staff. 


If an account caused a problem, it could be shut off, and the offending
IP address flagged so that no new accounts could come from that address.
   Anonymity would no longer be allowed at the IP address level.   

This is, in his mind, the best balance we can come to in 2007, between
Grex's founding principles and the reality of the current population of
the Internet.  

I really have a problem with STeve's paranoid solution. No, the internet
isn't what it used to be- so that means we turn tail and hide our heads?
That we take what's already a slowly decreasing community and takes
steps to insure it continues to decrease? 

I really don't like the direction Grex is going with this. As I
mentioned in Agora- mail was supposed to be a temporary solution- but
it's not. I don't like this idea of 'social validation' in order to get
someone to get an account. 

Are we trying to kill off Grex here? Or is it simply to keep the current
group here and everyone else out?

I think this solution is trying to stop the "killing off Grex" that
occurred when the only way to use grex was through Backtalk.  

Those of us who use ssh or telnet for anything:  mail, conferencing,
unix, were totally shut out while the latest attack was going on.  It
was not visible to backtalk users, but the vandal had literally shut
down Grex to the point that staff could not get in remotely to do
anything.  

In my mind, that will kill off Grex faster than vetting new users.  In
addition the previous vandal attack was directed at discouraging people
from using Backtalk.  By flooding the conferences with the auto-posting
script, the vandal stopped all conversations on Grex for several days.


I don't see how leaving newuser open will keep Grex alive.  

 #3: "but the vandal had literally shut down Grex to the point that
 staff could not get in remotely to do anything."

Actually, there was a way to get in.  I didn't know it at the time,
but I've learned a few things during all this abuse.  One is that if
something similar should happen again, I could still get in.  I wouldn't
be able to use any full-screen programs, like vim or mutt, but I could
still get things done.  I could edit files with ed or ex, and read or
send mail with the old standby unix mail program.  If necessary, I
could transfer files to my own computer, edit them here, and transfer
them back with rsync (scp still doesn't seem to work, though, for some
reason, or it didn't the last time I tried).

Basically, all the vandal (scholar) did was to tie up all of the ptys
(pseudo-terminals).  Each time you log in through telnet or ssh, you
are connected to one of these.  There are a fixed number of ptys
available, and once they're gone, further logins are rejected, at least
through telnet.  ssh will still allow you to connect and run programs,
if you know how, and scholar knew how, because he was doing it.  When
I managed to slip in somehow once, he was connected, but invisible.
He didn't appear when I ran the finger, w, or who commands, and the
"last" command didn't show him there, but ps did.  It took me awhile
to figure that out.  I saw him with ps, but I didn't recognize what I
was looking at.  Someone with more experience may have figured it out
quicker, but I eventually did figure it out, and I'll know next time
(if there is a next time) what to look for.

If newuser were disabled, would it still be possible to use the conferences
via the web?  How would we validate someone that did not already know someone
at grex?  Vandals can exhibit rational behavior if they choose to.

I don't see how closing newuser will help, either, unless and until we
have an alternative *in place* and *ready to deploy*. Otherwise, past
history suggests that we'll repeat the story of mail access and outgoing
internet - we hastily shut it off for new users, throw around some ideas
about putting a system in place for people to request it - and then
nothing happens for *months and months*, and still hasn't as far as I
can see.

The incidents that led to this discussion seem somewhat isolated to me.
I don't think we're dealing with an emergency situation that calls for a
sky-is-falling response. Let's leave newuser open for now while we
discuss what kind of a system might replace it. If we reach a consensus
on what we want, *and* have it ready to go, then we can put changes in
place.

(Resp:4 and resp:5 slipped in.  I was responding to resp:2 and 
resp:3.)

John, it would be helpful to me to have you take a look at the list of
capabilities that we are trying to sort into open, social validation,
and government ID validation. in item 28.  

If some need to be added to that list, please suggest them.  The
conversation on that topic hasn't given me enough feedback (as a board
member) to feel comfortable making a decision.  

BTW, we have a BoD meeting on Aug 5.  If, in the next week and a half,
we can get some consensus on these topics, I'm sure the Board would vote
on the appropriate policy changes.  

Just thought of something else.

The solutions we put into place *must* start with the assumption that
staff will not be available for several days (or longer) to deal with
the problems.  

The two different vandal attacks interfered with people's use of Grex
not simply because of the vandals' actions, but also because it takes a
week or so for staff to have time for indepth analysis and crafting of
solutions that fit Grex's philosophy.  

Attacks that would have been over in hours in the past are now days-long
events.  

Bottom line - I think the days of open newuser are over.

We are only as healthy as the people we attract.  If we don't draw an 
interesting and diverse group we're hosed.  If we attract a lot of 
attention seeking twits who think it's great sport to spoil the system for 
everyone else, we're likewise in big trouble.  As the internet has 
exploded there are lots more places for people to play on the net but not 
a whole lot of 'em allow people to instantly join the party whether they 
are taking their meds or not.  But we do.  And for the longest time I 
thought our community was big enough to bask in such tolerance.

No longer.  We are a shrinking pool of diehards, here to a great degree, 
out of habit or loyalty.  And every time a twit comes through screaming 
for attention, we lose ground.  With our open newuser we are screening for 
users who NEED an open newuser.  I don't know how else to put it.  Our 
ideals worked for a long time but they are now working against us.  We may 
have already waited too long to turn things around.

What I'd suggest is this - have our system be open for anyone wanting to 
read our conferences.  I'd even suggest having all new conferences / 
discussions indexed to search engines and visible to the whole public 
internet.  Let people see us when they are looking for content of 
interest.  But in order to join the discussion you need to be known, 
meaning some sort of validation, including an email address and a small 
fee to facilitate identification.  I'm not sure how agressive we'd need to 
be with ID so we could start with a soft touch and see how it goes.

Folks could find us, check us out, and decide if we're worth taking out an 
account.  Posting privileges might take a few days or more.  Sure that's a 
hoop for a new user to jump through and it will be a hassle to validate 
folks.  But what we have now really isn't going to sustain the kind of 
community we want to be.  Not anymore.  In my opinion.  And it pains me to 
say so.

Why not start by fixing the holes that currently exist in the system and are
well known, and well documented? 
It seems every time the system has been brought down, its from using some
exploit that was well known in advance. I realize no one has the time to keep
up with all the happenings here, but, it seems like lack of
planning/preventative maintenance is what is causing the issues. Once the
issue happens, everyone runs around trying to figure out a non technical
solution to the isuse, such as turning off newuser. I predict turning off
newuser will mark the long demise of grex. I don't think anyone will go thru
the hassle of being validated/verified/whatever to become a member. 
It also seems that its not usually the new comers who are creating havoc on
the system, but ones who are well known and who have been around a while.
 
my worthless 0.02cents

If we do index our conferences and make them open to the web, we should 
be careful that old/current postings arent included. 

"Why not start by fixing the holes that currently exist in the system
and are well known, and well documented?"

Staff doesn't have the time.  

The reason nontechnical solutions are proposed is because we don't have
the expertise to implement the technical ones.  I believe that every
person currently on staff knows about and knows how to fix the holes.  I
believe that if they had time, they'd fix them.  

I think that anything more complex than supplying a valid email address,
and not being allowed to post until you reply to a social-handshake
email sent to that address is a higher barrier than most other sites on
the web.  *Paying* to be validated is probably not feasible.   

I agree with slynne, only new conferences or new items should be
indexed.  

 re #13:  
 > Staff doesn't have the time.  

 Nonsense.  The syslog issue that was recently exploited was just
 another holdover from the bizarrely bad default configuration that
 came with OpenBSD, as far as I can tell.  It probably took about
 a minute to fix once the abuse became evident.  10 minutes tops.

 As for the abuse of the write/tel programs..  well, perhaps it's
 time to (temporarily) turn off write, or at least change the 
 default permissions to make write & tel opt-in, rather than opt-out.
 I'd much rather see that than see newuser restricted.

McNally, are you saying that staff has the time but wants to see Grex
hit by vandals?  

"Staff doesn't have the time" simply means that people with the ability
to fix the problem have better things to do with their time.  If you've
got more time now, I'd love to see you back on staff.  

While the comment about giving out full root access was meant in jest,
those questions are serious, and I would like to ask that a member
formally put the questions to the board in the next meeting. We cannot
effectively protect something if we have no idea what we are trying to
protect. 

We are the Borg, maus.  slynne and I are board members, as is cross,
aruba, polygon, janc, and bhoward.  

The board has always tried to run Grex by seeking consensus in Coop. 
What Grex is is what the members want it to be, not some vision that the
 Board provides.  

I'll throw it back at you:  What do you think we should be protecting?  

maus, mickeyd and mcnally's comments are right on the money.

 re #15:
 > McNally, are you saying that staff has the time but wants
 > to see Grex hit by vandals?

 No, nor do I think that you can fairly read that into what I wrote.

Sorry, mcnally, my frustration is showing.  

It does us no good to talk about how staff *should* behave.  We have
burnt out staff members who have left, burnt out staff members who are
still on staff, busy staff members who don't make Grex the highest
priority in their life, and a dearth of volunteers who want to take up
the burden.  
  
To claim that staff *does* have time is to imply that they are wasting
that time doing less important things, or that they are willfully
leaving work undone.  

It sounds like you believe that the Grex board has some power to get
staff to change their life's priorities, to somehow make Grex more
important than whatever is pushing it down in the queue.  That's what is
nonsense.  

Nah, we lack the homogeneity to be the borg. We are more like the
anarcho-syndicalyst commune in MP's Holy Grail. 

It seems to me that the attacks that most piss off the users and members
are attacks against access to resources. There are no major attempts at
securing confidentiality of user data or system data not hardened in the
installation. Anonymity is neither protected nor blown open, it's just
not really thought about much, and several users who go by a handle are
referred to by their given names. Integrity does not seem to be a great
priority, though it gets occasional mention. People piss and moan most
when the system "goes away" (or worse, when part of it does). 

I would recommend that we take an honest look at what resources people
value, and evaluate the controls around them. This is nontrivial, as it
requires not only triaging the services that we provide, but also what
those services depend upon. As an example, people value basic access: 

 - Is the server on and in a non-hung/non-panicked state 
 - Does the server have an internet connection and at least some
available throughput
 - Is the server accessible by name (i.e. is DNS still pointing
grex.cyberspace.org to 216.86.77.194 --- few people remember that IP
number)
 - Is inetd running and working correctly
 - Is /etc/inetd.conf correct and readable
 - Is /usr/libexec/telnetd still there and still working 
 - Is the authentication subsystem working
 - Is /etc/passwd unmangled (ditto the shadow database)
 - Is our equivalent of /home mounted and accessible and not full
 - Ditto /var
 - Are ptys available 
 

This is just to log in. Similar questions would have to be asked for
other services, such as the conferences, email, talk, the webpage. Then
there are unglamourous services, such as syslog, pf, DNS, et al. 

If a service is desirable, controls need to be put around the facilities
on which it depends. If there is too much bother to control a service,
then that is a pretty good indication that the service has less value
(ignoring for the moment sentimental value). Anything that is too much
bother to control should be shut off to prevent it from being used to
attack a facility or service that we do care about. At least, that is
how I understand it, but I wouldn't know so much about these things. 

Since we are being hosted in a hosting provider's datacenter, it might
be worth it to ask if they have professional systems managers that they
rent/contract out by the hour, and set aside a chunk of cash
specifically for that, so that when an emergency happens, we call them,
describe the problem, tell them the maximum we want to spend researching
and fixing it,and give them a P.O. number. I think when we get the new
system, we should also look into a chassis that offers monitoring and
control via a BMC (basically a separate board with its own processor,
RAM and a tiny RTOS, whose only job is to take measurements, and reboot
the main system on demand --- look up [1] and [2]) and investing the
money into a kvm-over-modem or kvm-over-IP adapter [3] so that a person
can be as good as having a real physical console from wherever their
laptop is or something. 


----

1:
http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface 
2: http://en.wikipedia.org/wiki/Baseboard_management_controller 3:
http://www.kvms.com/1-port-kvm-over-ip.asp

1. What's up with robocop - I thought that guy did a pretty good job
controlling resource usage.
2. I totally agree with mcnally, that write should be opt-in!
3. Flooding party via the openpty mechanism is no big deal because the
user can just ignore the idiot. (though - your disk may run out -
trivial to fix)

The main problem is:
4. Flooding the BBS, misusing mail and DOS'ing the box by scripting
account creation.

Possible solution: Web based account creation (you'll solve the whole
scripted account creation nonsense - captcha).

I used to play this MUD on New Moon (telnet://eclipse.cs.pdx.edu:7680).
Go create a account there and then try to get to the main area :) Spend
1/2 an hour there, you'll see what i mean. Those guys have done a great
job!

Right now what we do is use a sledge-hammer (staff) to swat flies. We
have designed a system where WE waste energy chasing after flies - then
everyone debates and ponders the merits of that action because WE wasted
a lot of time calling staff. Instead simplify the process of kicking
someone out and killing his processes - make HIM cool his heels :) BUT
only for 1-6 hours. How?

1. Broaden the scope of a helper: no root access, but with access to
scripts that can block someone for a predefined amount of time. You can
then give this sort of facility to more people without expecting them to
love, honor and obey.

2. Free up staff time so that they are more productive! Staff should
code and add new features, not sit around playing robocop!

Properly designed, the helpers aren't going to abuse it, if you make
what constitutes abuse explicitly clear. Then if a helper makes a
mistake, you just boot him out and let him relax for some time. If you
feel like trusting him again, it's not a problem.

Make the script snapshot (ps,who,netstat,du) the box every time it is
run. That way staff has independent evidence that's mailed to them.
Spammer logs on and Nate has already kicked him out - Cross just gets a
mail with a tail -100 of /var/log/mailog. Once a week Cross checks his
Grex mail to see if Nate is behaving. Better still - auto update to a
web page so everyone else keeps an eye on helper.

Also note: helper is uncool! Helper = lowly peon. Staff = power,
prestige, fame, cross, god; bad connotation <g>

[OT below - but related to helper]

3. Helpers could update our outdated web pages, they could make the motd
more interesting. Consider our motd: That is prime real-estate! Look at
what we have on it? Some crud about B'Days and tons of officialdom that
i never read. I mean once your past 18 years, does anyone actually feel
pleased about being born? Given that they are like 5978 accounts and 10
BBS users, is some hello.c guy going to feel joyous because a computer
auto reminded him that he was born today??

Instead what if helpers could update the motd to point to interesting
things that are going on in the BBS? A chess game in #chess (we need a
ASCII board and I'm working on it). A tutorial on fun stuff that we
could do on Grex (maybe fuzzball could write something for figlet). A
lot of Chinese folk log in - the first thing they will see is the motd.
Maybe bhelliom could write something on China (in ASCII Chinese?) and
maybe someone will see the link on the motd and use the BBS. Maybe we
could have a Chinese day with some ASCII chinese text? Scholar plays
poker, maybe he could organize online poker games? We could post
challenges on the motd asking chicks to play games and stuff. Instead we
have some stuff on a walk in a garden in far away Timbuktoo <looks at
the ceiling>

This would involve people and make them think about Grex as a entity and
not as toilet paper to be used and discarded. Right now people login,
write hello.sh and walk. Remember one thing: if we had a 1000 active
users on the BBS, staff wouldn't be bored to the gills, we wouldn't be
bored to the gills and there would be a lot less argument because we'd
have interesting things to do. Plus we'd have a lot more loot!

You know...I think that provide.net *does* have technical support 
services. Maybe we should consider setting aside some money to hire 
them in emergencies?

re #24 - Would the current staff be okay with Provide.net having root access
to the box? Even if it were just temporary? 
Just curious

Various thoughts.
 
*)  I've become much more relaxed about Grex's reliability issues
    since I moved most of my personal email to a professional service.
    
    M-net's recent revival as a community coincides with their 
    decision to terminate email.   Coincidence or causality?
    If nothing else, terminating email could free up a lot of 
    staff resources.
 
    Even if Grex isn't ready to terminate e-mail, we need to 
    make it really clear that relying on Grex for e-mail of any 
    importance is a bad idea, and relying on Grex for business 
    e-mail is, well, extra double bad.   

    The E-mail world has become a poisonous place; services with
    dedicated professional staffs are struggling.  E-mail may have
    become something which Grex no longer has resources to offer.
 
*)  Open newuser and open shell access brings pests to Grex, but 
    they also attract a lot of the constructive users who have shown 
    up in the last few years to join the conferencing & party
    community.   I think closing newuser would be really bad.

*)  It's hard to figure out what do to about defending Grex when 
    there is no clear consensus as to what Grex is, in terms of 
    services offered to users.   Various stakeholders in Grex
    see it as:
    *)  online community with BBS and party
    *)  email service
    *)  place to utilize basic Unix shell services
    *)  place to learn about Unix

    Many of the users in one of these interest groups have 
    no knowledge or interest in the others, and their interests 
    are somewhat in conflict.

    For example, if one were concerned with Grex primarily as 
    an online community, a strategy for going forward would be:
         -- axe e-mail beyond within-Grex communication
         -- develop web interface to party
         -- shut off public shell access, at least to new 
            users -- you could maybe allow heritage users, but 
            getting rid of text interface to conferences would 
            allow you to move into the modern world instead of making
            every web-based conference change compatible with the 
                 the text based conference readers

    This would of course piss off many Grex stakeholders.

*)  In the Good Old Days, nearly all of Grex staff 
    -- found it a privilege to work on Grex, because the opportunity 
       to be a Unix sysadmin was somewhat rare.  So there was a 
       good supply of volunteers.  
    -- were motivated to care for grex, because it was an 
       important hub to their own social lives.

    Now, however --
    -- anyone can be a sysadmin using a free version of Unix on 
       junk/free computers
    -- few of the remaining staff participate in Grex socially

I have no solution for those last problems; I tend to see them as
insolvable.

I find web access much too slow and annoying and if it were the only way to
access the conferences I would probably stop using them.

There's another class of Grex stakeholder I left out:
  *) people depending on Grex for low-tech dialup access to the net
 
 :)

The dialup access is helpful on days when the ISP does not work.

I want e-mail to work.  I want a text interface to conferences.  And I
want a shell.  If those three things were all gone, I would be gone
from here.

I haven't been using the e-mail much yet, but I much prefer e-mail from
a shell over webmail.  In fact, I despise webmail.  I feel that procmail
is far more powerful than anything available at any web site.  I also
think cyberspace.org is a cool domain for an e-mail address.  I even
created a second account (chuck) for times when unicorn may not be
appropriate, although that was after e-mail was turned off for new users,
and that account still doesn't have full e-mail access.  I also dislike
the idea that *everything* needs to be on the web.

If the text interface to conferences was taken away, I would no longer
participate.  Again, I dislike the idea that everything needs to be on
the web, and I don't believe that putting it on the web makes it any
more "modern".  I feel that a text interface is a far superior interface
for most applications, and I realize that is a minority opinion.

I also want a shell for the same reason.  It allows me to do so many
things that would be difficult or impossible from a web interface, and
even those things that can be done from a web interface can be done
much more efficiently from a shell.  If you took away my shell while
still retaining e-mail and conferences, I would never return, because
I would be forced to use webmail and a web interface to conferences,
both of which I will not do.

 I rest my case.  :)

Although I do disagree with Chuck about the BBS being more modern
because it is on the web, I do agree with him on the things he feels are
important to maintain.

I might add that I was responding primarily to the following from krj:

*)  It's hard to figure out what do to about defending Grex when
     there is no clear consensus as to what Grex is, in terms of
     services offered to users.   Various stakeholders in Grex
     see it as:
     *)  online community with BBS and party
     *)  email service
     *)  place to utilize basic Unix shell services
     *)  place to learn about Unix

The point I was trying to make is that I see it as "all of the above."

I guess I was also responding to the parts that said "axe e-mail
beyond within-Grex communication" and "getting rid of text interface
to conferences would allow you to move into the modern world".

(I typed a response but will let others have the soapbox now.)

Sorry, I'm late to the conversation.  I was away for a few weeks doing USMC
stuff; now I'm back.  Well, for a while; I'm going back onto active duty in
late September for more training, but that's a ways off.

Here are my opinions in a nutshell:

1) Turning off newuser isn't going to be particularly profitable, *however*,
   newuser needs to be changed to not be so trusting.  We should require
   that a user already have an email address that we can verify before we
   open up the system to them.  We should use a CAPTCHA or something to
   verify that users cannot script newuser.  I don't think we need to
   require money, but we do need to be a bit more restrictive.

   Something that I have observed with respect to our vandal problems is
   that the problems most visible to the active user community (as defined
   by those that use party and read the conferences) are not caused by
   random miscreants from the Internet, but rather from a few determined
   users who know the system well.  To me, it makes no sense to shut off
   access to the system for the 50 or so mostly harmless folks who create
   new accounts on grex on any given day to stop the one or two who are
   annoying (and well known).

2) The problem with fixing our existing software isn't necessarily with
   staff time (well, maybe for write; that's Jan's balliwick, and him making
   changes to it has to happen on his schedule), but at least in the case of
   the conferences, that we don't have source code to picospan.  Sure, we
   could try and make binary patches to it, but I'm not going to waste my
   time doing that.  If we had source to it, or moved to something else, I'd
   be far more inclined to look into changing a few things (like, extending
   the twit filtering capabilities so that spin's little games couldn't be
   played again....This would have the additional benefit of not having
   backtalk be hamstrung by the necessity of backwards compatability with
   Picospan).

3) We do need more staff, *and* we need an intermediate level between user
   and staff of folks who can police the system and clean up obvious things
   without staff intervention.  I kind of like Vivek's idea of `helpers.'
   Additionally, such a thing could be used to funnel qualified folks into
   the ranks of the root-privileged staff.

Okay, I'm still playing catch-up at work with email and what not, so I'm
going to take off for right now, but that's my first set of gut feelings....

I would definitely apply for something like what Vivek and Dan suggest 
(an intermediate demi-staff position); I would like to help, but am 
uncomfortable having full-root access on a box on which I am not the 
sole stake-holder. I know I over-react to things and am immature, the 
combination of which makes me think I need to do more growing up before 
considering volunteering for full-on staff. 

Much as I am loathe to say this, I do think the modicum of anonymity 
offered by the incumbant newuser script is causing more problems than 
it solves. I feel dirty for saying this, but we may be at the point at 
which we need to be able to tie users to real-life entities, though I 
would also say that this information must be kept highly secure and off-
server, only for baffers. 

Guys a couple of things: The trouble with our temp fix is that trolls
can still write to /dev/log and dump fake messages into /var/log. 

This is very dangerous for a number of reasons: Say troll doesn't like
someone.  He could fake the entries on our box and then lie to the
noob's ISP and tell the admin to scp whatever and take a look at the
"logs". Poor little noob will get into a LOT of trouble, especially if
he is logging in from college. Noob will not have enough knowledge to
defend himself and the admin will assume that what he sees in
/var/log/messages is legit.

Now Scholar, when we were talking before the fight, suggested removing
(rw) for others, but then exim, named, and other apps will not be able
to log. He suggested we create a separate group called "logger" and then
chgrp logger /dev/log and then add exim, named, etc to logger. Is there
a downside to this?

At the end of the day, no matter how much mary, maus, krj, vivek, steve,
and HCMS McGee want to play sysadmin, the only reason anyone is able to
access Grex right now is because the so-called vandal has apparently
decided not to prevent it, not because of anything staff or anyone else
has done.  The most devastating 'attacks' -- the ones that prevented
people from accessing the system remotely -- would not even have
required the miscreant to have an account on the system.  The syslogd
flooder 'attack' exploited a problem that was well known to steve
because he was told about it, but which he didn't bother to fix or warn
anyone else about for over a year.  You folks can be as frustrated as
you want to be and implement as many community-killing but trivial to
bypass measures as you want, but as much as you might not like it, the
choices you have are to a) do nothing and hope it doesn't happen again
(which isn't as bad as it sounds, believe it or not) or b) find a way to
get someone who has time and commitment and (!) knowhow to block attacks
like this.  I would strongly suggest adding unicorn to staff.  He's
ignorant and naive as fuck (remember how his proposed solution to the
crapflood was to attempt to limit user input to a humanly possible
speed, a suggestion that was lulzy on all levels), but he seems to have
endless hours to commit to Grex, can figure shit out at times, and
totally gets off at the mere thought of being on staff.  Flailing your
arms around wildly and hitting everyone but who you want to hit is an
option, but it's your worst one.

Okay, scholar.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss