Re: tlug: telnet: different question + others

["Thomas O'Dowd" <tom@example.com>]

Hi Everyone,

At this stage everyone is going "oh no" as they see this subject pop up in
their mail box... I would like to bring this back to a more technical view
point and this time from the SA perspective and to see if the security of
the system is really in danger because of these suggestions. So let's go 
through the suggestions one by one...

The problem was how to fake your attendance at class when attendance is
taken with the w command. The person asking the question said that he used
to log in from home but that had since been disabled and access to these
machines was only possible from within the lab. He also mentioned cron,
telnet and ssh as possible suggestions.

Reply A: check last and who commands to find out where else access to these
machines may be coming from as it is likely that some routes to the lab machines
have been left open for administration reasons. Can possibly log in from home
by going through a couple of machines first.

Security. No security has been broken, although if our hero finds such a path
it is obviously not what the SA wanted. Depending on the situation, have a quick
rethink and block the user out from using those paths.

There were two other kinds of responses, one type using cron and and the other
using a "daemon" although I'm not sure of the responders defination. I think the
word daemon frightened people.

Reply B: Write a "daemon", just a program that stays alive after disconnecting
in this sense, which traps various signals which may be sent to the process when
it is about to be killed, or the machine rebooting. The daemon would then send
a quick mail to the user to tell him, he better have a sick note ready unless he
logs in and restarts it before class. The idea is just that a program is started
and hangs around after the hero leaves and therefore fakes his class attendance
by hopefully showing up on w.

Security Risks. Zilch. This "daemon" as suggested by the author, doesn't give
away any secrets etc, it doesn't open up any gates for any hacker. All it is, is
a program running on a machine. What it does do, is it takes computing cycles.
If the "daemon" is written correctly though, this will not be serious in that all
it has to do is trap signals and sleep.

The following responses were all using cron.

Reply C: Put an entry in your .rhosts file for the machine your going to run cron
on. ie if the machine is called x.com and the user is boti then the entry will 
look like "x.com boti" on a line of its own in .rhosts file. Now call rsh from
cron to login and execute some command to look busy for an hour of labs. It looks
like they read source code with netscape during this lab, so just write a simple
C program that sleeps for the lab duration and call it netscape and keep it in
your directory.

Security: rhosts really gets peoples blood boiling and rightly so. If it is 
allowed on the machines, then just disable it. If it is turned on for a reason
then well the user isn't really breaking the system security just weakening it
by having an entry. But given the fact that we allow the rcommands, then this
is an acceptable well defined entry. Also given the fact that our man said that
login to these machines was restricted to coming from within the labs, this makes
it perhaps that little bit safer. In my opinion, the user is again within 
system privilage and not weakening the security beyond its current state.

Reply D: Using expect with your id and password, telnet to the machine from cron
and run a program to emulate your class appearance. In this case, the users
password, must be either stored in a script or in a file picked up by the script.

Security: The login/password info is key here. The question is if the login and
password are available to anyone else because of doing this... If the file is
permissioned readonly to the user, then the root is the onlyone that can read
the file (assuming that there are no id conflicts). If incorrectly permissioned
yes, the password may get into the wrong hands. Even though only readable to
people already with a login who find the file, it may be told to others along
the way and lead to an unauthorised account access. File permissioning is key
here and generally, SAs don't like to see users leave there passwords on the
system unencrypted, even if permissioning is okay.

Disabling cron for this particular user and possibly others should do the trick.
This is a clear case of system resources getting tighter because of abuse.

Reply E: Share passwords with a friend and have them login for you.

Security: As good as your friend. Not a good thing to tell someone. For example
if someone later gets into your account and the only person you told your 
password to was your friend, then even though your friend may have kept your
password good, it looks bad for both of you.

Reply F: Go to class

Security: Using the lab computers, our hero, jets off to rootshell.com, then
onto /., perhaps popping in on a couple of news sites, he likes linux a lot so
he heads over to lwn for a little bit and pretty soon the lab is over. That wasn't
so bad, but I think more cpu cycles and bandwidth got used, then if he had just
stayed at home sleeping. Of course, he should have been doing his course work!!!

I think I got everyones responses in there. I really don't see what all the fuss
is about.

Cheers,

Tom.
-- 
Thomas O'Dowd
tom@example.com
--------------------------------------------------------------------
Next Nomikai Meeting: June 16 (Fri), 19:00   Tengu TokyoEkiMae
Next Technical Meeting: July 8 (Sat) 13:30   Topic: TBA
--------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan