|
Grex > Coop11 > #49: Reasons to not allow verified non-members net access | |
|
| Author |
Message |
| 19 new of 57 responses total. |
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.
|
remmers
|
|
response 50 of 57:
|
Dec 7 00:45 UTC 1998 |
I fired up Grex's mighty online search engine (otherwise known as
"grep") and managed to track down the online discussion on opening
up http. It's in Coop 7, Item 93 (item:coop7,93). The reasoning
presented there for doing so was essentially as Steve recollects
it in resp:48.
The feeling seems to have been that board ratification would be
sufficent, and there was mention of bringing the issue to a board
meeting, but that apparently never happened. There's nothing on
it in the agenda item for that month's board meeting (item:coop7,102)
or the minutes (item:coop7,107). So that step evidently just got
forgotten, until now.
(I do recommend reading the agenda item -- Coop 7, item 102 -- for
its entertainment value. It goes on for 93 responses, most of them
having to do with the concept and propriety of the board having
pre-meeting dinners. Amazing stuff. I'd totally forgotten the
discussion ever took place.)
|
rtg
|
|
response 51 of 57:
|
Dec 11 04:40 UTC 1998 |
As I read this whole discussion, I find myself boiling it down to a single
question: What is the maximum level of service we can provide with the
limited resources we have available?
In the light of this, and the general feeling that our internet connection
bandwidth is the single most limiting factor, I ask why we allow ANY
protocols to pass twice over that link? It seems ridiculous to me for
anybody to be using telnet to come into grex, and then expect to go back
out the same link with http or ftp or whatever.
We are here to serve as a community bulletin board, and as an educational
resource. To me, this means that we provide our local services such as
bbs, party, and the tools necessary to write and compile simple programs
so that people can get an idea of how these magic boxes work. As a
service to our geographical community, we provide dialups, email, lynx,
and possibly telnet access to other systems.
I have made the assumption that if a user has the capability to run a
telnet client to access our locally-provided services, then they also have
the capability to run lynx or ftp locally, so it's a waste of our cpu and
especially bandwidth to run them here.
There are lots of people who share internet access with family members, or
have their only internet access at work, so I see us providing a real
service to allow our 'remote' users to receive e-mail here. (aside: What
is the total cumulative data flow for a POP3 session downloading n
messages, vs a telnet session running pine, paging through the same
messages slowly? Would POP3 allow us to serve more users more
efficiently?)
The other protocols they can run themselves, so why do we allow them to
telnet in, then surf from here?
I would support a proposal to broaden the access we allow to dialin
local users, whether they are paying members or not, and severely restrict
the use of any outgoing protocols by remote telnet users, whether they are
paying members or not.
I guess I'm making the assumption that if someone comes here to do
something they could just as easily do at home, then they must be up to no
good, and they're trying to hide behind us.
|
mary
|
|
response 52 of 57:
|
Dec 11 11:23 UTC 1998 |
Good response.
|
davel
|
|
response 53 of 57:
|
Dec 11 12:17 UTC 1998 |
As to why someone might reasonably telnet in & then access the web, consider
me. If I am telnetted in to Grex, it's from a shell account at work. From
that system (and in fact from anywhere) I do not have an ISP account providing
web access. Coming in from work I'm most likely (not always, but usually)
on to get some kind of information for my job. I may find something that has
a URL in it. I can run lynx as well from work, but not while I'm telnetted
in to Grex. (In principle I can suspend the telnet session, but in practice,
when I'm telnetted to Grex in particular, that usually means my connection
will be hung when I get back to it, for some reason.)
|
steve
|
|
response 54 of 57:
|
Dec 11 13:01 UTC 1998 |
There certanly are legimiate reasons to do that, yes. I don't think
we can make blanket statements about the validity of this kind of thing
which of course only makes it harder, trying to come up with policies to
restrict it.
|
sironi
|
|
response 55 of 57:
|
Dec 14 08:05 UTC 1998 |
From Italy I reach better (more speed) north-american sites with lynx on
Grex than using lynx on my own machine.
luca_
|
rtg
|
|
response 56 of 57:
|
Dec 16 06:08 UTC 1998 |
I hear you luca, and just read essentially the same comment from spiff in
another item. Thanks for your input.
|
janc
|
|
response 57 of 57:
|
Dec 16 06:13 UTC 1998 |
I think I'd be willing to support opening telnet and ftp to non-members
coming in on the dial-ins, but I'm not willing to reduce any of the
access now given to people coming in over telnet. I don't see a need
for any reductions in services now.
|