|
Grex > Coop > #34: Cyberspace Communications and Grexserver security |  |
|
| Author |
Message |
maus
|
|
Cyberspace Communications and Grexserver security
| 
Jul 26 00:52 UTC 2007 |
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. |
cmcgee
|
|
response 1 of 68:
|
Jul 26 01:47 UTC 2007 |
*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.
|
jadecat
|
|
response 2 of 68:
|
Jul 26 12:58 UTC 2007 |
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?
|
cmcgee
|
|
response 3 of 68:
|
Jul 26 14:28 UTC 2007 |
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.
|
unicorn
|
|
response 4 of 68:
|
Jul 26 18:51 UTC 2007 |
#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.
|
keesan
|
|
response 5 of 68:
|
Jul 26 19:02 UTC 2007 |
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.
|
remmers
|
|
response 6 of 68:
|
Jul 26 19:05 UTC 2007 |
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.)
|
cmcgee
|
|
response 7 of 68:
|
Jul 26 19:23 UTC 2007 |
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.
|
cmcgee
|
|
response 8 of 68:
|
Jul 26 19:26 UTC 2007 |
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.
|
cmcgee
|
|
response 9 of 68:
|
Jul 26 20:11 UTC 2007 |
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.
|
mary
|
|
response 10 of 68:
|
Jul 26 21:57 UTC 2007 |
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.
|
mickeyd
|
|
response 11 of 68:
|
Jul 26 22:50 UTC 2007 |
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
|
slynne
|
|
response 12 of 68:
|
Jul 26 22:54 UTC 2007 |
If we do index our conferences and make them open to the web, we should
be careful that old/current postings arent included.
|
cmcgee
|
|
response 13 of 68:
|
Jul 26 23:46 UTC 2007 |
"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.
|
mcnally
|
|
response 14 of 68:
|
Jul 26 23:52 UTC 2007 |
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.
|
cmcgee
|
|
response 15 of 68:
|
Jul 27 00:00 UTC 2007 |
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.
|
maus
|
|
response 16 of 68:
|
Jul 27 00:06 UTC 2007 |
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.
|
cmcgee
|
|
response 17 of 68:
|
Jul 27 00:14 UTC 2007 |
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?
|
cyklone
|
|
response 18 of 68:
|
Jul 27 00:16 UTC 2007 |
maus, mickeyd and mcnally's comments are right on the money.
|
mcnally
|
|
response 19 of 68:
|
Jul 27 00:25 UTC 2007 |
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.
|
cmcgee
|
|
response 20 of 68:
|
Jul 27 00:33 UTC 2007 |
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.
|
maus
|
|
response 21 of 68:
|
Jul 27 00:51 UTC 2007 |
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.
|
maus
|
|
response 22 of 68:
|
Jul 27 01:26 UTC 2007 |
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
|
vivekm1234
|
|
response 23 of 68:
|
Jul 27 06:29 UTC 2007 |
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!
|
slynne
|
|
response 24 of 68:
|
Jul 27 13:06 UTC 2007 |
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?
|