I never heard anything about 5 months, but first...

    The computation centers' policy about security is kind of strange.  They
believe
(Note: this is my interpretation from working there) that there is a balance
between
security and offering services the academic community wants.  That balance
shifts from
time to time.  Many people want particular programs and certain access
capabilites to
on CC machines.  Many of these compromise security or reduce the level of
security on
the machines or a particular machine.  Many times, at the expense of
security, the CC has
opted to shift on the side of offering services.  IRC is an example.  An IRC
server is not something
that was really needed by UT.  It was a service (not even administered by
the unix guys) allowed
to run on CCWF because there were so many requests to run it.  After too
many IRC related problems, -
they decided it want a good idea to keep it running (not the irc ops fault).
CCWF runs a lot of other not so safe services as
well.

    On a side note, I dont think UT will be able to get a seperate IRC
machine. They have to justify EVERYTHING
they buy (besides the stupid HUB program, thats another story), and get the
money for it.  An irc standalone server
isnt a big seller to the dean or the budget committees. It also is hard to
ask for money for another machine when they
need money to upgrade the old one. I would also like to have a IRC/game
server running on
campus round the clock.  The CC was ok when it was running on another
machine (CCWF) which was being utilized
with other work as well.  I agree that it would lessen the security load on
CCWF if we had a seperate server, but once
again we are stuck within the limits of the CC budget. I tried as well doug
:(   The unix guys were very receptive to the ideas, -
but they couldnt get any support.

    I admit, there can be more security measures taken by the CC, but they
are not that bad.  There are far
more break-ins to labs on campus which the CC does not administer.  The
sheer size of the CC machines
and notariety is the biggest problem.  UT is a major target for hacking, and
I mean MAJOR.  About every type
of attack is tried on UT every week, if not on a daily basis.  We used to
sit there and look through logs of
ppl just probing machines on the network.  Most of these tries are harmless;
last years rootshell.com
programs or just looking at the services running.  Not all of the CC ppl are
genuises when it comes to security.
I think as a community (linux), we should help them find potential problems.
The more we help, the better pull
you will have with them when it comes to services/and or security.

    I do not blame the CC for not investigating all probing activity on the
network.  It happens all of the time.  They do not
have the manpower for it.  If we should be complaining, it should be to the
dean. They need more people running
those machines.  With the money they pay CC employees now, I think they have
some pretty good UNIX guys.  They do
seem to lose a good one each year though



Do note that CCWF is probably not the best machine to have an account on, if
you want security. There are more secure
machines. Of course, they dont always do as much :)

Also note: I think the latest security info on the list is a great thing.
Keep asking questions and keep answering/debating them.


Alright, Ive bored you guys/gals enough.  Oh, and save any flames for me
personally, keep em off the list. I included my email
 for the ne1 who wishes to hate me.

Later,

Dave
Programmer
[EMAIL PROTECTED]

-----Original Message-----
From: Doug McLaren <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, September 26, 1998 5:43 PM
Subject: Re: news


>This is the first I'd ever heard of this, and I used ssh to and from
>piglet all the time.  If this is actually true, they should have done
>a *much* better job about getting the word out!  This may explain some
>problems I had a month or two ago, and I really would have liked to
>know this then ...
>
>| Nothing personal to the ccw people or anything like that ... but I've
heard
>| of those machines getting hacked more often than any other system I've
ever
>| worked with ... wasn't the reason piglet got pulled off efnet the fact
>| that it was so utterly hacked that they didn't trust the server anymore?
>
>Actually, piglet wasn't pulled off of Efnet, we just gave up on it and
>disconnected it ourselves.  My account had been wiped at least four
>times in the time that I'd run the server, and who knows how many
>times people had gotten in and played around without actually making
>it obvious.  At least once when the hacker had come in after the ircd
>he'd started deleting ALL of the home directories when I'd caught him
>...  took about fifteen minutes to convince the guy who was on duty at
>the Comp center at the time (it was late Sunday night) that this was a
>problem and that maybe he should call somebody who would actually do
>something about it ... *sigh*
>
>In addition to the security problems, piglet had performance problems
>that caused ircd to inhale vociferously on it.  We'd asked for a
>dedicated machine, we'd even offered to provide one, but they couldn't
>do that, so we finally just gave up on it.
>
>| I think they should actually get someone in that job that knows security
...
>| *hint*hint*
>
>Jim McCoy seemed to know security pretty well, actually.  But he's now
>at io.com if I recall correctly.
>
>In any event, it's next to impossible to keep on top of keeping a
>shell box like piglet secure, and for the most part the computation
>center did as well as could be expected.  Still, I think they should
>have provided a dedicated box for high profile cracker targets like
>the IRC server - it would have made piglet much less of a target, and
>therefore made their job easier, but oh well - I tried.
>
>--
>Doug McLaren, [EMAIL PROTECTED]
>---------------------------------------------------------------------------
>Send administrative requests to [EMAIL PROTECTED]

---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]

Reply via email to