|
Grex > Coop11 > #49: Reasons to not allow verified non-members net access | |
|
| Author |
Message |
| 25 new of 57 responses total. |
aruba
|
|
response 25 of 57:
| 
Dec 4 04:02 UTC 1998 |
Re #18: from /usr/local/grexdoc/archives/prvote/prvote01
PROPOSAL:
Cyberspace Communications (Grex) will restrict outgoing
Internet access such that only those who are verified and
paying membership dues will receive this service.
VOTE RESULTS:
Posted on April 6, 1994
32 out of 57 eligible members voted. The tally: Yes 21 No 11
The proposal passed.
from /usr/local/grexdoc/archives/prvote/prvote02
PROPOSAL:
The following internet services enrich the Grex community, do not use
much bandwidth, and do not provide much potential for internet
mischief; therefore they should be made available to all:
Finger
Whois
Ping
Mail (incoming and outgoing)
Incoming Usenet News
Incoming Telnet
Incoming FTP
Incoming Lynx
Talk (and it's various permutations)
Archie
Veronica
WAIS
Gopher (with all Telnet capabilities disabled)
The following services will be restricted to VERIFIED GREX MEMBERS and
VERIFIED GREX USERS (however the board shall define that term) because of
the potential for world-wide mischief:
Outgoing Usenet News
The following services will be restricted to VERIFIED GREX MEMBERS in good
standing, because these services utilize a lot of bandwidth, offer
less of a benefit to the Grex community as a whole, and/or hold the
potential for system cracking and other undesirable activities:
Outgoing FTP
Outgoing Telnet
Outgoing Lynx
Gopher (with telnet capability enabled.)
IRC
Being that the major objection to open access for the above
services is the lack of available bandwidth on Grex's internet
link, It is understood that any of these services may be made
available to all VERIFIED USERS as well as VERIFIED MEMBERS as soon as Grex
acquires a link of suitable power and robustness.
In order to maintain the integrity of both Grex, and of the Internet as a
whole, the Grex board shall have the power to restrict or deny internet
access to groups or individuals who pose a security risk, or who engage in
inappropriate behavior (as defined by the Grex board).
The board may also make modifications to this proposal without resorting
to a member vote in the case of an emergency situation, or if some
provision of this proposal proves to be technically impossible to implement.
VOTE RESULTS:
Results were posted on Wednesday, August 17, 1994.
49 out of 80 eligible voters cast ballots. The Tally: Yes 36 No 13
The proposal passed.
Hmmm - unless I read that wrong, I don't think our current lynx policy is in
accord with that motion. It says that we could extend access to lynx to
verified users & members when Grex gets a big enough connection, but in fact
we extended it to *all* users. Go figure.
|
rtg
|
|
response 26 of 57:
|
Dec 4 05:43 UTC 1998 |
exactly what is 'incoming lynx'?
|
remmers
|
|
response 27 of 57:
|
Dec 4 10:56 UTC 1998 |
I think the intent of the motions was to define access to protocols,
not particular applications. So replace "lynx" with "http" everywhere
it occurs.
You're right, we've allowed outgoing http to all users for some time
now, and this does appear inconsistent with the voted-on policy. I'm
not sure how that came about. I don't recall any proposals other than
the above two. However, there have been *no problems* that I'm aware
of with allowing outgoing http to unverified users. I'd like to see
open access continue.
|
steve
|
|
response 28 of 57:
|
Dec 4 15:19 UTC 1998 |
Unforunately, there have been problems with allowing unverified
http access. There are several vandal tools, the most popular being
'phf' that try some old tricks to steal things like passwd files. a
couple of times I think its worked, to actaully steal something. I've
also seen a couple of cases of people writing *very* strange code,
hitting on certain files on a server, where it looked very much like
an attempt at a Denial Of Service attack. Both times when I saw this
I asked them what they were doing, and poof, instant log off.
So, yes, there have been some problems with it. The good news is
that a vandal can't do that much--there aren't as many creative ways
to try messing about, so that I know of we've never had a horrid
problem because of this.
I want the open access to continue as well.
|
aruba
|
|
response 29 of 57:
|
Dec 4 15:38 UTC 1998 |
Maybe we should officially change the policy (it would take a member vote, I
think) to allow http access to everyone.
In any case, it's clear that the intention of the second proposal was to
extend full internet access to all verified users when we got a fast enough
link. Do we have a fast enough link now?
|
mta
|
|
response 30 of 57:
|
Dec 4 16:10 UTC 1998 |
Steve, I understand your reluctance to open up outgoing telnet to
everyone...it is potentially *a lot* more woek for staff. But given what Jan
says and given that my instincts say that the sheer amount of time involved
in sending in ID (fake or otherwise) and waiting to be verified will slow down
a major portion of the would-be vandals, I think it's worth a tial run.
Maybe, to make life easier for the folks who have to clean up the mess, if
one results, we should agree about what constitutes an "unfortunate but
acceptable" vandal control problem and what constitutes reason to shut the
trial down...
|
steve
|
|
response 31 of 57:
|
Dec 4 16:24 UTC 1998 |
Thats right: it is potentially a lot more work, and why? It isn't
the case that anyone who comes into Grex remotely doesn't ALREADY have
telnet access. That, coupled with the fact that we allow the more
important interfaces (email, http), why is there is feeling of moral
failing that we don't offer telnet to the masses?
Also, if there is a movement to open telnet to all, then shouldn't
FTP be included in the list? Only, we have an immediate problem--Grex
is not a place to download files from and if we let people FTP, we'd
be giving out yet another mechanism to let people bring over endless
streams of graphical/audio files to Grex.
I'm sorry Misti, but this doesn't buy Grex anything. We're already
generous in what we offer, and what we don't isn't nearly as important
as what we currently do.
Why is there this feeling that we should do things that only cause
us more work, *have real security problems*, and aren't nearly important
now as they were back when we first started Grex? Time moves on and
technology changes. That which was once important is less so, now.
Lastly, there are several vandal sites that have very good details
on how to create fake IDs. I can just about guarantee that no one on
Grex has the ability to detect them.
|
danr
|
|
response 32 of 57:
|
Dec 4 16:40 UTC 1998 |
Interesting item. I'd be inclined to offer outgoing telnet to dial-in users who
have sent in id. In fact, I'd be inclined to limit it to folks for whom a call
to Grex is a local call. This would make the work load mangeable and yet still
provide a real community service.
Maybe I missed it, but I don't see any reason to allow people who telnet in
from telnetting back out.
|
aruba
|
|
response 33 of 57:
|
Dec 4 17:40 UTC 1998 |
I guess I don't see any reason for that either. Is it technically feasible
to modify the kernel blocks to check not only whether someone is in the
internet group, but whether they are dialed in?
Re #31: I think that granting telnet/irc/ftp rights to local users is a
charitable venture, and I think it would benefit the greater Ann Arbor
community. It may not be as important as it was a few years ago (though
there is a lot more to see on the net than there was then), but it is still
important to people who have no other access than Grex.
Maybe the best compromise is to only validate users who have a local address
and show some ID that we can check locally. If that goes OK, we could talk
about expansion later. If some local kid trashes whitehouse.gov from Grex,
we can send STeve around to his house to read him the riot act. :)
|
steve
|
|
response 34 of 57:
|
Dec 4 18:15 UTC 1998 |
Sure, we could keep track of those coming in from the terminal server. I
think we'd have to modify login perhaps, but regardless we could do something.
That comment about allowing IRC scares me, however. I could see a whole
lot of people discovering that Grex was a free IRC portal, and being jammed.
|
krj
|
|
response 35 of 57:
|
Dec 4 18:34 UTC 1998 |
In other words, Grex can only offer services no one wants. :/
I feel another item coming on. :)
|
steve
|
|
response 36 of 57:
|
Dec 4 18:39 UTC 1998 |
IRC is a really interesting thing to deal with. People who administrate
systems hate it, and a lot of users LOVE it. IRC uses a tremendous amount
of bandwidth. Not CPU or disk unorunately, but bandwidth: it ties up dial
in modei for hours at a time, and many universities have had problems with
IRC taking up significant amounts of bandwidth. Today part of the IRC
"problem" has been solved by sites that are specifically set up for IRC
servers, and most users have ISPs from whom they get a small PPP pipe and
can do whatever they want.
But back when I used to watch people at the AA public library use the
six systems on the third floor, there were always people using real-time
chat systems, IRC being quite popular.
|
cmcgee
|
|
response 37 of 57:
|
Dec 4 21:05 UTC 1998 |
#4 of 36: by John Ellis Perry Jr. (jep) on Wed, Dec 2, 1998 (17:05):
I see no reason why we offer telnet at all, to anyone. I'll bet there
isn't one user on Grex who depends on it; who wants to be able to telnet
(or use ftp) but doesn't have other, better resources available.
Gosh, I hope you bet lots and lots of money! You owe it all to me. (I'm
willing to share with others who depend on it _and_ doesn't have other, better
resources available).
#4 of 36: by John Ellis Perry Jr. (jep) on Wed, Dec 2, 1998 (17:05):
I see no reason why we offer telnet at all, to anyone. I'll bet there
isn't one user on Grex who depends on it; who wants to be able to telnet
(or use ftp) but doesn't have other, better resources available.
Gosh I hope you bet lots and lots of money! You owe it all to me. (I'm
willing to share with others who depend on it _and_ don't have other, better
resources available.)
|
jep
|
|
response 38 of 57:
|
Dec 4 22:32 UTC 1998 |
I really don't care, personally, if telnet is offered or not offered,
but I agree with Mary's preference that it be offered regardless of
money sent.
|
scg
|
|
response 39 of 57:
|
Dec 4 23:34 UTC 1998 |
If I'm remembering the bylaws correctly, member votes and board votes carry
the same weight, so if the members vote for something the board is free to
overturn it the next day if it wants, but the members could then overturn
the board's overturning of the member vote, or recall the board members, or
something like that. Bylaw ammendments can only be done by member vote, and
the board is obligated to obey the bylaws, so if the members really want a
policy set in stone and don't trust the board, they can do their poilcy as
a bylaw ammendment. Otherwise, if a member vote and a board vote contradict
eachother, the more recent one wins. The board, of course, is elected by the
members, and the members probably won't vote for people who are likely to
overrule them.
The decision to allow everybody to use Lynx to access the web was made by the
board, a couple of years after the member vote. Technology changes, and that
decision did seem to fit in with the intent of the earlier member vote. I
think it's safe to say, at this point, that most people who use the Internet
and think they know it is wouldn't even recognize the names of most of the
programs and protocols that were talked about in the proposal that the members
voted on. WAIS and Archie, for example, and probably gopher as well. Also,
lots of the people who were members when that proposal was voted on are no
longer around, and lots of our current members weren't around then. If we're
developing new policies now, I'd be rather hesitant to use that vote from five
years ago or whenever it was as anything more than a very rough guideline of
what the membership once thought Grex should be doing in a different
technological era.
re IRC:
Allowing IRC for the masses would be a mess, given the fights that tend
to break out on IRC, which often lead to denial of service attacks that can
really create havoc on a network. At a commercial ISP that does allow people
to use IRC, I'd say about 90% of the ping floods, smurf attacks, winNukings,
etc. have involved kids getting mad at eachoter on IRC and trying to make
eachoters computers crash, causing large problems for the networks inbetween
them. I have nothing against IRC's protocols, or against probably most IRC
users, but IRC seems to have a culture that's not really compatible with
having a low budget, low bandwidth, maintainable system.
|
aruba
|
|
response 40 of 57:
|
Dec 5 00:17 UTC 1998 |
Hmmm, I can't seem to find the board vote you're referring to, Steve, and I
don't remember voting on it. Do you remember when it was?
|
scg
|
|
response 41 of 57:
|
Dec 5 01:36 UTC 1998 |
I remember the discussion, but I don't remember when, and I don't remember
voting. Perhaps it was discussed at a staff meeting instead, but I'm assuming
staff wouldn't have opened http to the masses without getting authorization
from the board first.
|
rcurl
|
|
response 42 of 57:
|
Dec 5 08:08 UTC 1998 |
It was voted on here. Did Steve Weiss write it up?
Re #39: so you think, Steve, that since the U.S. Constitution is pretty
old and has lots of provisions that haven't been voted on for a long time,
that we can just ignore it? A vote is a pact, which should be as firm as
the day it was adopted, until it is changed. However, since it wasn't a
bylaw, the board can change any policy on its own, and did in this
instance, without re-running a member vote on the revision.
|
mdw
|
|
response 43 of 57:
|
Dec 5 10:22 UTC 1998 |
I think it's already been observed that there's a fair amount of
continuity amongst grex staff and members (see the cliquishness item in
agora). Once these kinds of decisions get made, they tend to propagate
themselves, as new people who come on board either decide they like the
result, and stay around, or don't like it, and leave fairly quickly. So
it would be quite surprising if if the memberhips's opinion as whole has
changed all that much.
|
scg
|
|
response 44 of 57:
|
Dec 5 16:48 UTC 1998 |
re 42:
No, I don't thik that at all, Rane. I'm not saying that the staff
shoudl feel free to ignore the policy. I'm saying that we have procedures,
either through board votes or membership votes, to change the policies, and
I was suggesting that the current policy, being rather specific about some
obsolete protocols while not covering the current common protocols very well,
might be something that our policy changing mechanisms should be taking a look
at.
Likewise, the US Constitution also has mechansims to change it when parts of
no longer make sense. If it didn't, slavery would still be legal in the US.
|
mdw
|
|
response 45 of 57:
|
Dec 5 23:24 UTC 1998 |
Between 29 nov 1998 01:20:44 and 5 dec 1998 17:37:41, approximately
32562 attempts by 511 people were made to bypass the kernel blocks.
31330 of these attempts were made by only 4 people.
31 programs were run to do this, as follows:
1 <server.c.out> 2 <rusers> 13 <bnc> 540 <telnet>
1 <thamind> 3 <tt++> 29 <irc-2.8.2> 767 <b>
1 <trn_real> 3 <ytalk> 33 <portscan> 818 <sc>
1 <wh00f> 4 <datapipe> 34 <pine> 2481 <perl>
1 <xnet> 4 <tf> 38 <netscan> 3720 <eggdrop>
2 <hr> 6 <irc-2.8.2.old> 10895 <bo>
2 <nc> 9 <a.out> 245 <ftp> 12591 <nmap>
2 <redir> 11 <mt> 392 <lynx271>
(the #'s here are the number of runs of each program detected.)
Some of these programs are port forwarding programs; used by vandals
to hide their tracks, and used by people behind firewalls to
bypass firewall policies. Eggdrop is used by irc users to hold
party channels open; it is probably *the* most popular program
people try to run on grex.
Telnet attempts were made to 369 destinations. The top 40 are as
follows:
2 207.167.112.10:23, 3 152.163.210.13:23, 4 198.202.86.17:23,
2 207.211.200.71:23, 3 152.163.210.24:23, 4 198.41.0.6:23,
2 207.99.5.2:23, 3 152.163.210.25:23, 4 198.59.118.51:23,
2 208.244.48.1:23, 3 152.163.210.27:23, 4 208.217.205.11:23,
2 209.51.183.2:23, 3 152.163.210.28:23, 4 209.73.132.137:23,
2 210.34.0.12:23, 3 152.163.210.29:23, 4 24.234.16.135:23,
3 129.24.96.10:110, 3 152.163.210.7:23, 5 192.168.1.3:23,
3 144.16.203.107:23, 3 152.163.210.8:23, 5 208.217.205.12:23,
3 144.16.78.240:23, 3 152.163.210.9:23, 6 207.170.104.32:23,
3 149.132.130.48:4000, 3 198.59.115.24:19, 7 129.24.96.10:25,
3 151.196.216.252:23, 3 206.124.29.1:23, 12 207.82.252.251:23,
3 152.163.210.10:23, 3 206.210.93.60:2323, 14 209.142.209.161:23,
3 152.163.210.11:23, 4 192.35.39.37:23, 15 207.126.100.96:23,
3 152.163.210.12:23,
(format: count ip-address:port. port 23 = telnet. port 25 = smtp.
port 19 = chargen. port 110 = pop-3.)
DNS names for some selected sites here:
152.163.210.10 = www04a.web.aol.com
208.217.205.12 = 12.0.205.217.208.IN-ADDR.ARPA (who is Trent Arsenault?)
207.170.104.32 = sdf.lonestar.org
129.24.96.10 = callisto.unm.edu (someone eager to forge mail?)
251.252.82.207 = hotmail.com
209.142.209.161 = m-net.arbornet.org
207.126.100.96 = diversion.com
diversion.com is apparently a for-pay live chat/multi-player game/internet
services system based in Palo Alto, CA.
|
steve
|
|
response 46 of 57:
|
Dec 6 01:33 UTC 1998 |
These are typical of what we see in a given week.
Some of those programs are most likely:
nc - netcat a program to display network traffic. A useful
tool, but also usable as something to sniff networks; with a
small perl program can be a good password sniffer.
redir and datapipe - IP "repeaters" which can redirect packets
to another site/port. Great too to run on several machines to
pass a telnet session between multiple machines, so as so really
hide ones tracks.
mt - don't know which one this is: could be a simple tiny fuge
program, or it could be a port scanner that looks for specific
things and does a ping flood based on what its sees. I've also
seen other less interesintg things called mt.
portscan - program to see what ports on a given machine are active,
for further probing. I've seen versions which then tried poking
various ports after its discovered what ports are free. Rumored
Rumored other versions are far more nasty but I haven't seen those
yet.
netscan - something similar to portscan, but I've never seen a
version which worked here.
sc - another port scanning program
bo - the wonderful Back Ofifice program, designed to cause havok
with MicroSoft back office
I have quite a collection of these little things at this point.
I've given up on keeping track of all of them. For a while, I
kept track of what was being brought over here but I abandoned
numerical recordkeeping after I'd encountered my 400th copy of
telnet--and I mean the 400th copy. These days, I keep track of
things I can't automatically identify.
|
dpc
|
|
response 47 of 57:
|
Dec 6 16:23 UTC 1998 |
Good Goddess! It's amazing we're still alive in this environment.
Thanx (again) to the staff.
|
srw
|
|
response 48 of 57:
|
Dec 6 20:24 UTC 1998 |
My thoughts mirror scg's resp:39 fairly closely, but I will put them in
my own words.
There was a long gap of time between when the member vote took place
regarding which services should be open-access and the subsequent
implementation of that policy. During that interval, as I recall (only
vaguely after this much time) there was a big shift in usage. Most
notably, gopher services on the net were substantially replaced with
http services. Although this was gradual, the substantial conversion
from gopher to http took a surprisingly short amount of time. Note:
there still are gopher servers out there, but very few.
When the policy was implemeted I do remember a discussion about the
question of whether we should implement a modified version of the kernel
blocks, including http along with gopher among the open-access services,
since it had largely replaced gopher by the time of implementation.
I am confident it was discussed at a board meeting.
My interpretation is that the staff implemented what it thought was
the intent (if not the letter) of the member vote by transferring http
to the open-access side. As I recall from my memory of the many
discussions regarding this vote, the intent was primarily to open some
things up (as opposed to restrict opening things). I definitely played a
role in this staff decision, but I would *never* implement what the
voters did not want me to. Probably the disparity between the member
vote and the actual code in the kernel blocks was never reconciled by
having another vote, although it should have been.
The system has worked this way for along time now. I think it would be a
huge mistake to block outgoing http access to free accounts. If we were
to vote now on this one access issue, I would support keeping it open.
|
aruba
|
|
response 49 of 57:
|
Dec 6 22:59 UTC 1998 |
I certainly don't want to change the de facto policy either, but I think
we should make it official, so I'll propose it at the next board meeting
(unless someone beats me to it.
|