· 10 years ago · Dec 05, 2015, 08:48 AM
1
2
3 InfoHax Digest, Number 1
4
5 Saturday, January 25th 1992
6
7Today's Topics:
8
9 welcome.hax
10 form.0
11 sysadmin.comments
12 frm.paper
13 frm.mentor.paper
14 shell.tools
15 phone.trace.evsn
16 BSD.accnt.files
17 trace.fakemail.gd
18 IP.tracing
19 more.IP.tracing
20 rfc931
21 hacker.trkr.tools
22 hideum.pl
23----------------------------------------------------------------------
24
25Date: Fri, 24 Jan 92 18:04:41 -0700
26Subject: welcome.hax
27
28*****************************************************************************
29 WELCOME TO PROJECT: INFOHAX
30*****************************************************************************
31 Project: INFOHAX is an invitation only project to write the most explicit
32and complete guide to hacking UNIX systems that has ever been put out. We
33are starting with a 150k paper as an outline, filling in all the holes/tricks
34and expanding on it substantially.
35 Project durration is set at 1+ year, with digests comming out once a week,
36delphi style, perhaps more often if the traffic warrents it.
37***IN ORDER TO GET FURTHER DIGESTS YOU NEED TO SUBSCRIBE TO THE LISTSERV.***
38 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
39we also have a passworded fileserver, Details to follow.
40send mail to:
41 LISTSERV@STORMKING.COM
42with
43 SUBSCRIBE INFOHAX User_Name
44in the msg body
45if you have not been confirmed, you will be rebuffed.
46to access the fileserver send mail to:
47 LISTSERV@STORMKING.COM
48with
49 HELP
50 INDEX INFOHAX /silicon_lollipop
51in the msg body
52for confirmation or to get a copy of the 'outline paper' contact
53XXXXXXXXXXXXXX
54so far confirmed people are:
55 XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
56 XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
57 XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
58 XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
59some people we havn't heard back from or havn't got confirmations from:
60XXXXXXXX
61XXXXXXXX
62you're in if you wanna be, let us know.
63These people have been recomended by someone and need to be voted on:
64please vote on a 0-10 scale, 0=NO 5=I_DONT_CARE 10=YES
65
66XXXXXXXX
67XXXXXXXX
68XXXXXXXX
69if anyone has suggestions for additional people, please let me know.
70if anyone has strong feelings one way or the other on any of these people,
71voice um!
72SO HOW DOES THIS WORK?
73 We're trying to work it like a delphi right now. A delphi is a think tank
74technique where you present an idea to work on, and send it out to people
75to work on, solve problems, submit info, ask/answer questions, comment on,
76etc. in a little less than a week send in what you have so far, and it will
77all be bundled into digests and sent out again... the list is moderated so
78some sorting/organising can happen before it goes out again. then people
79keep working on what they were, but have feedback and fresh material from
80everyone else... it's a really powerfull technique, so I hope it works for
81us. I think there will be some rough edges to work out, as to the methods,
82hopefully this wont take too long.
83 I put out a form (see below: form.0) to help organise info, and keep
84track of things, please use it! the header and tail should be used for
85feedback, and discussions, please save bandwidth and nuke the 'DATA:'
86section, except for BRIEF extracts of the text being commented on.
87 Also PLEASE SEND COMMENTS ON DIFFERENT SECTIONS IN DIFFERENT E-MAIL,
88that will make sorting sooooo mutch easier, a section name in the
89'Subject' field would be nice too...
90 PLEASE NOTE THAT THE LISTSERV WILL NUKE THE FROM LINE OF YOUR EMAIL,
91if you want people to know who wrote what you just sent in, put your
92name or handle in the body of the message.
93 If you're submitting original material, please use the whole thing. We
94will assighn a section # to avoid chaos...
95 Also if you have input on the genneral form of the project, discussions
96that don't relate to a particular area, etc. please send a form with a
97header/subject line of DISCUSSION these will be collected together at the
98begiinning of the digests. The methods/form of the project are totally
99variable, and I encourage you to suggest changes, we may throw the delphi
100out all together, it's a starting point, nothing more. If you don't like
101it say so!
102 If you see something referenced that you don't understand, ask about it.
103If you see a trick mentioned, but not explained, that you know something
104about, or have ideas on - even if you don't totally grok it, send in what
105you know, or ideas about how it might work. There are alot of little
106sections that need to be worked on. If you have something to say about it
107do!, even if you're not the person working on it. If you see a section
108that you'd like to work on, adopt it. basicly we get alot better info if
109people arn't territorial about a section they are working on, and accept
110/incorperate input.
111 In other words we're working under total anarchy! be nice to each other,
112cooperate, and lets not have any flame wars...
113PROJECT OUTLINE:
114 the main sections of the original paper follow, after that some additions:
115Theory Devices
116Network Security Monitoring
117Other Network Services Net Monitoring
118Accnt Security Accnt Monitoring
119File System Security File System Monitoring
120Setgid Programs Know your System
121Startup Files Improving Your Security
122User Utils Pollicies
123Programming Utils Countermeasures
124Encryption Biblio
125additions:
126How not to get caught - logging, covering tracks, laundering calls, becoming
127 invisable to the system, who's on, housecleaning, hiding setuid, trojans,..
128Getting in the Door...
129Getting Root
130Setuid Progs/shells
131Passive Snooping
132Network Spoofing
133Patch Level and Version History
134 this list is far from complete, please suggest additions!, oh yeah, a large
135collection of exploitation type code/scripts at the end.
136 if anyone would like to start filling in the outline/TOC that would be
137great!
138 This first chapter is on how not to get caught. It will effect all the
139other areas of the paper and is going to be revisited/added to as we visit
140every other chapter. It's also a good springboard to get folks started in
141on other areas. I'm not shure if it's best to hop arround at random doing
142different sections in parrallel, or sequentially chapter by chapter...
143feedback?
144 This first digest has the following areas to stimmulate discussion:
145sec01: sysadmin.comments - on logging
146sec02: frm.paper - what we're expanding on
147sec03: frm.mentor.paper - prev work to build on
148sec04: shell.tools - proposed tools by calculite, some comments
149 by tangent
150sec05: phone.trace.evsn - info in evading phone traces
151sec06: BSD.accnt.files - summary of w/ notes on exploiting
152sec07: trace.fakemail.gd - slightly dated, lotta good tricks to tease out
153sec08: IP.tracing - discussions on hacker trackers
154sec09: more.IP.tracing - more of above
155sec10: rfc931 - bad news... need to find ways arround this.
156sec11: hacker.trkr.tools - how we get caught...
157sec12: hideum.pl - pearl script for nuking /utmp entries
158 Some areas that need discussion are weather we should include available
159material, or just ref it. examples include mentors paper, rfc931, phracks
160'hiding out under unix', and another phrack artical on getting lost (title?)
161 My thoughts are to include it if it's short, or at least stick it on the
162file server... feedback?
163Obvious areas (in this chapter) that need something written about them are:
164 UUCP logging evading phone traces
165 SysV log summary UNIX as outdial
166 IP spoofing terminal servers and gateways
167 If you feel you have a specialty area, please list it, and start work on
168that area (with a partner or two if there's overlap), though everyone should
169comment/contribute to all areas, if possable. This is supposed to be a
170democracy, so if you want to change what I'm outlining, please submit your
171ideas and the group can hash it out. Don't get overwelmed!, if we took 2wks
172on eash major area, this project would take a year, It's probably going to
173take more than that... remember, we're basicly writing a BOOK!
174 we can officially consider this project underway, expect mailings every wk,
175perhaps twice a wk when things get going well!
176 Happy Hacking!
177 Tangent
178-----------------------------------------------------------------------------
179------------------------------
180
181Date: Fri, 24 Jan 92 18:14:48 -0700
182Subject: form.0
183
184 In an attempt to keep things organised from the start I put together a
185form for communication. The sole purpose of this is to be able to easily
186refer to what's been done, keep track of revisions, and cross ref comments
187and pointers to other sections...
188 Please buffer, and USE this for communication:
189--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<----
190==============================================================================
191Section Name chapter.sec.version 00/00/00
192------------------------------------------------------------------------------
193DATA:
194------------------------------------------------------------------------------
195Comments:
196Q's:
197Biblio:
198CrossRef:
199Code/shRef:
200==============================================================================
201---8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<---
202where:
203Section Name - is the name of the sevtion within the chapter.
204chapter.sec.version - is the overall ref, version starts at 0, and goes up
205 just like software or OS releases
20600/00/00 - is the last revision date
207DATA: - is material submitted, or commented on, or exploitation type code (for
208 this chapter = code, and sec = chapter), etc. another chapter Biblio: - works
209 the same way. The DATA area is for ORIGINAL material being submitted, or for
210 REVISIONS (one person ties all replies together, and puts together a revision)
211 the idea here is to keep the bandwidth down, and avoid the redundancy of
212 newsgroups...
213------------------------------------------------------------------------------
214Comments: this is a 'maybe this would be possable' type area, or gen comments
215 on the DATA sec, you can eithor reply by interspercing comments in the data
216 via '>'s or put um here, and nuke the data for replies, as everyone will
217 allready have the data.
218Q's: how is this done, anyone know about this, etc... type area...
219Biblio: refs to go in the biblio chapter
220CrossRef: this ties in to, or could be used in chp#,sec#...
221Code/shRef: exploitation type code, or shell scripts for the code chapter, ref
222 to, code should go in the Data sec of message.
223------------------------------------------------------------------------------
224 OK, so maybe this isn't perfect, not shure how it will work, but it WILL
225make life soooo mutch easier a couple of months down the road, and when it
226goes to final edit...
227 If anyone has comments on how to improve this, or do it better, speak up!,
228once this is set, we're going to be stuck with it for the whole project.
229 Also, to make things more clear, the DATA area is what will be eventually
230published. The leading, and trailing headers are to keep track of it, and
231talk about it(DATA).
232------------------------------------------------------------------------------
233------------------------------
234
235Date: Fri, 24 Jan 92 18:20:48 -0700
236Subject: sysadmin.comments
237
238==============================================================================
239Section Name chapter.sec.version 00/00/00
240sysadmin.comments 01.01.0 01/21/92
241------------------------------------------------------------------------------
242DATA:
24317) OK, finally, logs. I read every log that grows without bounds,
244including daemonlogs that would show unauthorized reboots if not altered.
245I never found anything odd in ptydaemonlog or vtdaemonlog, or any unreason-
246able reboots, startups, shutdowns, etc., although I kept reading the logs
247anyway.
248Obviously I reviewed sulog, but I never found anything in there
249either, although possibly the fact that I disabled su early on had something
250to do with that :).
251I also read my own .x11startlog, which would show startup times for
252X windows on the console; that was always clean.
253The ones that I did find things in were /etc/btmp and /etc/wtmp,
254expecially wtmp...I'm not sure how familiar you are with the format of
255these, so just to summarize, they give username, tty, time on and time off.
256btmp is the bad login attempt log, wtmp the successful login attempt log.
257I rather imagine that a dialup cracking attempt by an outsider would tend
258to generate more btmp entries, but on my system the interesting stuff was
259usually in wtmp. Anyway:
260In the log of bad logins, btmp, you look for repeated login attempts
261for a single user, especially if they are clustered around the same time,
262and especially if there are a large number of login attempts which don't
263show any typographical errors in the user name. A third to a half of
264legitimate entries--that is, failed logins by authorized users--in btmp
265will show typos in entering the username, or sometimes weird character
266strings that indicate somebody leaned on the keyboard. Some of them will
267show passwords typed in where usernames should be, which is why btmp is
268supposed to be readable only by root. I imagine that dialup will show
269some 'line noise' failures. My users were on hardwired terminals, so that
270didn't appear.
271Large numbers of failed entries for a single user in which the user-
272name is typed correctly mean either that a legitimate user has forgotten his
273password, a legitimate user is typing spastically this morning, or somebody's
274trying to crack that account. I'd ask the user if he was doing something
275that would have led to all the bad attempts; sometimes the answer was yes,
276in which case I could get him a new password or forget it. If it's no,
277I know I have a problem.
278The other pattern that sometimes occurs is 'sweeps' across large
279numbers of usernames, usually typed correctly, clustered at the same time
280and originating from the same terminal. This is almost always cracking,
281if it shows up in btmp.
282What is never anything but cracking is the appearance of login attempts
283for reasonable guesses at usernames that don't happen to exist on your system.
284The 'sweep' pattern, in our company, could be legitimate if it showed
285up in wtmp, the log of successful logins, because certain trusted department
286heads were authorized to login as their subordinates and occasionally did so
287for administrative purposes. In this case, the sweep usually originates at
288a single terminal, generally the department head's, and covers that department
289only.
290I looked for a string of fairly obvious things in wtmp: simultaneous
291logins by the same user, users logged in at unusual times or from unusual
292ports, off-console root logins, etc. This actually took the most time, and
293is the one I did the most asking about--hey, Rita, did you log in in Ben's
294office yesterday? and so forth.
295The larger the system and # of users, obviously, the harder this
296is to do. I could have started correlating wtmp and btmp entries, but
297never got the time to write the script. We also didn't have auditing enabled
298because I didn't get a chance to put it up, because I was under pressure to
299get the system operational. That was probably a mistake, although it wouldn't
300really have changed the final outcome of anything.
301I did pin down a major security breach with this procedure, because
302I found one more off-console root login than I knew was legitimate, which
303neither I nor the assistant administrators could account for. I found the
304damage not long after, although it took me, honestly, about two weeks to
305figure out why that particular item had been changed (It's not a secret, but
306definitely belongs in another letter, so I'll save it).
307This approach obviously has a flaw (aside from not having auditing)
308in that I obviously wouldn't see a breach that involved someone else logging
309in at a user's regular terminal at a reasonable time for that user to be
310there, which I strongly suspect happened more than once. Auditing would
311have caught anomalous system activity in that case if file permissions
312had been changed. It couldn't have caught the falsifying of information
313within the scope of the user's normal routine--if someone logged in as
314the bookkeeper in the right place at the right time calls up the usual
315programs and does everything except enter the numbers straight, there is
316no way to pick that up with auditing.
317Since I will have auditing up when I go up on the net, the report
318we ought to be able to compile on this subject after the experiments ought
319to be much more complete, and I'm looking forward to it as it should be
320fascinating. Thanks :)
321------------------------------------------------------------------------------
322Comments:
323Q's:
324Biblio:
325CrossRef:
326Code/shRef:
327==============================================================================
328------------------------------
329
330Date: Fri, 24 Jan 92 18:25:13 -0700
331Subject: frm.paper
332
333==============================================================================
334Section Name chapter.sec.version 00/00/00
335frm.paper 01.02.0 01/21/92
336------------------------------------------------------------------------------
337DATA:
338 In general the intruder can cover his own tracks. Detecting Intrusion
339therefor depends on on the intruder neglecting to do so, plus the
340installation of log keeping. The existence of log keeping should be
341somewhat secret to increase the probability that the intruder will
342unwittingly reveal his acts and methods.
343 The best logkeeping consists of writing to a hardcopy device so that
344the intruder cannot erase the log.
345 Sometimes a single slip-up by an intruder will reveal a huge case of
346previously unsuspected penetration.
347SYSLOG
348------
349 The syslog facility is a mechanism that enables any command to log error
350messages and informational messages to the system console, as well as to a
351log file. Typically error messages are logged in the file
352/usr/spool/log/syslog along with the date, time, and name of the program
353sending the message to the program.
354Example:
355DEC 24 12:10:06 WS1 NNTPXMIT: greet=520 SAMT 19 NNTP server can't talk to you
356DEC 24 14:53:37 WS1 LOGIN: root login ttyp3 from WS2.podunk.edu
357DEC 25 08:02:03 WS1 LOGIN: root login ttyp4 from wizard.hack.com
358DEC 25 08:28:52 WS1 SU: joueuser on /dev/ttyp3
359DEC 25 10:23:41 WS1 VMUNIX: /: file system full
360DEC 25 11:30:42 WS1 LOGIN: repeated login failures on ttyp3 from
361 sys1.podunk.edu, daemon
362DEC 25 11:45:08 WS1 NNTPD: rnews: inews: comp.foo: no valid newsgroup found
363 Of particular interest are the messages from the login and su programs.
364Wheneverr someone logs in as root login logs this informtion. In general
365logging in as root directly, as opposed to using the su program is better
366as it is harder to tell which person is actually using the accnt.
367 Login also logs any case of someone repeatedly trying to log into an
368account and failing, 3 consecutive times.
369 These messages can be used to check for users sharring accounts, as well
370as hacking attempts.
371SHOWMOUNT
372---------
373 Can be used on a NFS file server to show the names of all hosts that
374currently have something mounted from that server.
375 w/ no options just shows a list of all the hosts.
376 w/ '-A' shows all the hosts and directory combinations ie:
377 ws1.cs.podunk.edu:/usr/local
378 bart.podunk.edu:/var/spool/mail
379 maggie.podunk.edu:/usr/local
380 w/ '-D' shows a list of all directories mounted by some host.
381 Showmount's output is checked for 2 things, first, only machines local
382to the systems organization should appear there. Second, only "normal"
383directories should be mounted - unusual directories being mounted may
384indicate a hacking attempt.
385FTP LOGGING
386-----------
387 Some versions of ftp allow administrators to turn on and off logging
388information. The standard BSD4.2 does not, but there are publiclly
389available patches to the code to enable this feature.
390 Example:
391 @ws5.cs.podunk.edu (bsimpson) wed may 30 19:32:11 1990
392 get /pub/gnu/gcc-11.37.tar.Z
393 @131.170.8.11 (intruder) wed may 30 22:13:01 1990
394 get /etc/passwd
395 put /pub/annoying-msg
396 jueuser@podunk.edu wed june 6 08:19:16 1990
397 get /pub/sun-source/faces-1.3.tar.Z
398 get /pub/gnuemacs-18.55.tar.Z
399 In the case where lines begin w/ an '@', an anonymous ftp was done. The
400password given by the user (they ask for username, sometimes site name /
401address - will usually take anything) is in parenthesis after the hostname.
402 In the case where lines start w/ a username, a normal user has logged on
403to transfer files.
404 Whenever you transfer files with ftp, the manager will know what login
405was used, what files were transfered, and to what site.
406 (use a login, not your own , rename the files, and site hop...)
407ACCOUNT MONITORING:
408-------------------
409 Accounts are monitored to check for:
410 A) users logged in when they shouldn't be (i.e. late at night, when
411 the're on vacation, etc)
412 B) users executing commands they wouldn't normally be expected to use.
413LAST
414----
415 Last looks back in the wtmp file which records all logins and logouts
416for information about a user, a teletype or any group of users and teletypes.
417Arguments specify names of users or teletypes of interest. Names of teletypes
418may be given fully or abbreviated. For example, LAST 0 is the same as LAST
419TTY0. If multiple arguments are given, the information which applies to any
420of the arguments is printed. For example "last root console" would list all
421of root's sessions, as well as all sessions on the console terminal.
422 Last displays the sessions of of the specified users and teletypes, most
423recent first, indicating the times at which the session began, the duration
424of the session, and the teletype the session took place on. If the session
425is still continuing or was cut short by a reboot.
426 With no arguments, last displays a list of all logins and logouts, in
427reverse order.
428 Example:
429$ last -4 joeuser
430joeuser ttyp1 ws1.cs.podunk.e wed jun 6 10:04 still logged in
431joeuser ttyp3 bart.poduke.edu tue jun 5 15:01 - 15:01 (00:00)
432joeuser ttyp0 maggie.podunk.e tue jun 5 10:05 - 19:44 (09:38)
433joeuser console ws2.cs.poduke.e tue jun 5 09:49 - 10:05 (00:16)
434LASTCOMM
435--------
436 Lastcomm gives information about previously executed commands. Without
437any arguments it gives information about all the commands recorded durring
438the the current accounting files lifetime. If called with no arguments, it
439displays information about all the commands recorded durring the current
440accounting files lifetime. If called with arguments it only displays
441accounting records with a matching command name, user name, or terminal name.
442 Example:
443 $ lastcomm
444 who simsonb ttyp0 0 secs wed jun 6 10:03
445 mesg joeuser ttyp1 0 secs wed jun 6 10:03
446 biff joeuser ttyp1 0 secs wed jul 6 10:03
447 csh F joeuser ttyp1 0 secs wed jul 6 10:03
448 killercracker intruder ttyp4 7240 secs wed jul 6 08:01
449 . . .
450 For each process entry, lastcom displays the following items of
451information:
452 The command name under which the proccess was called
453 One or more flaggs indicating special information about the process,
454 the flags have the following meanings:
455 F The process performed a fork, but not an exec
456 S The process ran as a set-user-id program
457 D The process dumped memory
458 X The process was killed by some signal
459 The name of the user who ran the process
460 The terminal which the user was logged onto at the time (if applicable)
461 The ammount of CPU time used by the process (in seconds)
462 The date and time the process exited
463------------------------------------------------------------------------------
464Comments:
465Q's:
466Biblio:
467CrossRef:
468Code/shRef:
469==============================================================================
470------------------------------
471
472Date: Fri, 24 Jan 92 18:34:31 -0700
473Subject: frm.mentor.paper
474
475==============================================================================
476Section Name chapter.sec.version 00/00/00
477frm.mentor.paper 01.03.0 01/21/92
478------------------------------------------------------------------------------
479DATA:
480 ls -l will tell you the last time a file was modified, make a note of
481this when you tamper w/ a file, and set it back w/ the touch command when
482you are finnished, syntax is:
483touch hhmmMMdd [file]
484 Where hh is hour, mm is minute, MM, is month, and dd is the day, [file]
485is obvious...
486 What usually gives away hackers is the files they create on systems. If
487you must make files and directories on systems, make use of the hidden file
488feature ('.filename'). Also try to hide them in directories that are rarely
489ls'd, such as /usr/spool/lp, /usr/lib/uucp, etc.
490 If you replace a users file with a modified copy, this copy will be owned
491by your account and group instead of the account which owned the original.
492You can change the group back w/ the chgrp command. syntax is:
493chgrp [groupname] [file]
494and change the owner back w/ the chown command:
495chown [user] [file]
496 If you do something wrong, assume a note of it was recorded somewhere on
497the system. Leave the system and it's files exactly as you found them.
498 If you think it would go unknowticed, and your expection to ring alot of
499bells you can turn off system logging (if you have root).
500BSD ERROR LOGGING
501-----------------
502 Type "cat /etc/syslog.pid", this file contains the process number of the
503syslog (error logging) program. Kill this process, and you have stopped
504error logging. Remember to start it back up when your through.
505 If you want to see where the error logging messages are sent, type:
506cat /etc/syslog.config
507Entries are in the form:
508#file
509Such as:
5105/etc/errorlogfile
511 The number is the priority of the error, and the file is the file that
512errors of that level are sent to. If you see an entry with /dev/console as
513it's log file, watch out! Errors of that priority are sent to the system
514console. Sometimes a list of usernames will follow an entry for errorlogging.
515This means that these users will be notified of any errors of that priority
516or higher.
517 There are 9 levels of error priority's, 1 is lowest, 5 is the lever of
518errors gennerally caused by hackers - security violations, bad login and su
519attemps, attempts to access files w/ out proper permissions..., level 9
520is a system crash.
521SysV ERROR LOGGING
522------------------
523 The SysV error logging prog is errdaemon, to find it's pid type "ps -uroot"
524among roots processes you will find /etc/errdaemon. If you kill it there will
525be no more logging till you start it again. By default it writes errors to
526the /usr/admin/errorfile.
527 To get a report of errors type:
528errpt [-a] /usr/adm/errfile
529------------------------------------------------------------------------------
530Comments:
531Q's:
532Biblio:
533CrossRef:
534Code/shRef:
535==============================================================================
536------------------------------
537
538Date: Fri, 24 Jan 92 18:44:10 -0700
539Subject: shell.tools
540
541==============================================================================
542Section Name chapter.sec.version 00/00/00
543shell.tools 01.04.1 01/22/92
544------------------------------------------------------------------------------
545DATA:
546I'll try to write a summary right now. It won't be in the proper format, but
547it's not a final submission, either...
548BEGIN SHELL SCRIPT SUMMARY
549-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
550Something that could come in handy for hacking UNIX systems would be a shell
551script that would automate the following:
5521) disable logging
5532) edit standard logs to remove lines containing the account name that's being
554 used (when logs don't exist, inform the user)
5553) remove information from the utmp file for the account name that's being
556 used in order to avoid detection
557 (write privs to utmp requires root privs on anything but a sun)
5584) reenable logging when the user is done
559 (unless you are alone, it might not be a great idea to disable/reenable
560 logging, might look abit fishy ... how about just nuking log entries
561 for your username/uid/pid)
562and possibly do the following:
5631) alert the user when users log on and off
564 (how about just people w/ privs, or owner of accnt)
5652) attempt to exploit known bugs and edit appropriate logs
566This script could be uploaded after the user has obtained access to a system
567and be executed with possible options to disable functions when they're not
568desired.
569(other things: set up a working subdir
570 store + restore .history (if present)
571 1 key macro to nuke subdir, logout, and suicide process )
572END SHELL SCRIPT SUMMARY
573-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
574BEGIN HACK PROGRAM SUMMARY
575-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
576Another useful tool would be a program that would connect to port 25 of a
577target system and attempt passwords from a dictionary on standard usernames
578(guest, anonymous, ingres, new, apply, etc..) and usernames obtained manually
579by the user. This would operate much like an /etc/passwd cracker, but would
580actually try acct/passwd combinations over the net. NOTE: This should be used
581only as a last effort from a safe acct. It will, no doubt, affect logs on
582systems that log failed attempts. Possible sources for code: generic net
583interface code, MUD 'bot code, telnet source.
584A friend of mine wrote a telnet scanner that brought net connections to a crawl,
585he just did it sequentially, w/ no delay... a very irate sysadmin dragged him
586into his office and very nicely told him to never ever do that again...
587 a little break between calls is important!
588END SUMMARY
589-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
590--
591-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
592Shannon Robert Madsen / Calculite | mtymp10@ux.acs.umn.edu
593"To err is human; to moo, bovine." | "Religion is the opiate of the masses."
594-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
595------------------------------------------------------------------------------
596Comments:
597Q's:
598Biblio:
599CrossRef:
600Code/shRef:
601==============================================================================
602------------------------------
603
604Date: Fri, 24 Jan 92 18:52:14 -0700
605Subject: phone.trace.evsn
606
607==============================================================================
608Section Name chapter.sec.version 00/00/00
609phone.trace.evsn 01.05.0 01/24/92
610------------------------------------------------------------------------------
611DATA:
612 Don't have mutch for this area yet. some stratagies are:
613use a goldbox
614use a diverter
615radio or cordless phone 1/2 in a bbox, 1/2 a safe distance away.
616use call forwarding to forward to a phone in a different babybell's area,
617then send it through MCI (refuses to provide call records in court) or to
618thriftytell(flat rate service w/ no call detail records)
619 PLEASE ADD TO THIS!
620------------------------------------------------------------------------------
621Comments:
622Q's:
623Biblio:
624CrossRef:
625Code/shRef:
626==============================================================================
627------------------------------
628
629Date: Fri, 24 Jan 92 18:57:04 -0700
630Subject: BSD.accnt.files
631
632==============================================================================
633Section Name chapter.sec.version 00/00/00
634BSD.acct.files 01.06.1 01/18/92
635------------------------------------------------------------------------------
636DATA:
637SUMMARY OF BSD ACCOUNTING FILES:
638--------------------------------
639data kept filename type owner group mode note
640----------------------------------------------------------------------------
641CPU,memory,i/o /usr/adm/acct binary root system 644 (1)
642connect time /usr/adm/wtmp binary root system 644 (2)
643disk usage the file system n/a root operator 640 (3)
644printer usage /usr/adm/lpacct text daemon daemon 644 (4)
645dialout usage /usr/adm/aculog text uucp daemon 644 (5)
646console msgs /usr/adm/messages ? root system 664 (6)
647shutdown reasons /usr/adm/shutdownlog ? root system 664 (7)
648time daemon log /usr/adm/timed.log ? root system 644 (8)
649uucp transaction /usr/spool/uucp/LOGFILE ? uucp daemon 664 (9)
650uucp file transfer /usr/spool/uucp/SYSLOG ? uucp daemon 664 (10)
651network routing /usr/adm/gatedlog ? root system 644 (11)
652news connection .../news/nntp/logfile ? news news 644 (12)
653----------------------------------------------------------------------------
6541)accton(?) turns on accounting, sa(?) used to read, with the '-s' flag will
655summerize CPU usage by command, and TRUNCATES /usr/adm/acct to ZERO LENGTH!
656all commands executed once or with unprintable chars show up as '***other'
657(hmmm..), the system automatically suspends accounting if the file system
658that contains the accounting data becomes 95% full. If the machine crashes
659or is rebooted, processes that were running are not recorded in the CPU acct
660file, you can avoid cpu accounting by having your program sleep indefininatly
661upon completion as a program that never terminates does not produce any
662accounting record. (sleep(?) is also a good alternative to at and cron for
663hiding periodic processes). man acct(5)
6644)can also be set via a macro in /etc/printcap
6655)records login name, date, time, phone number, and status of all calls made
666through a dial out modem via the cu(?), tip(?) and uucp family of commands.
667If you are allowed to talk directly to the modem via a dialer entry in the
668file /etc/remote then the command 'tip dialer' will circumvent the
669accounting process.
6706)also messages.N where N is from 0 to 6, usually.
6719/10)This is for V7 UUCP, HDB (as in SunOS 4.x) is under /usr/spool/uucp/.Log
672/{uucp,uucio,uux,???}/<system name>
6738/11/12)These are not standard, though many systems have them. Also, the
674filenames are compile time options (or set in config files)...
675----------------------------------------------------------------------------
676Q's)"owner, group, and mode(octal) of the accounting data files is important
677and that any program used to reinitialize these files should be shure to
678chown, chgrp, and chmod appropriatly" - so what happens if these are altered?
679 will a prog that 'unlink argv[0];'s be logged?
680 what about if the utmp entry is zero'd out?
681 other tricks?
682------------------------------------------------------------------------------
683Comments:
684Q's:
685Biblio:
686CrossRef:
687Code/shRef:
688==============================================================================
689------------------------------
690
691Date: Fri, 24 Jan 92 19:29:37 -0700
692Subject: trace.fakemail.gd
693
694==============================================================================
695Section Name chapter.sec.version 00/00/00
696trace.fakemail.guide 01.07.0 01/21/92
697------------------------------------------------------------------------------
698DATA:
699Phil Goetz asked how to trace forged mail. The short answer is: use
700log files and talk to other sysadmins so they'll do the same.
701A forged messages is injected into the mail system at some point, with
702a particular set of header lines. The header lines inserted after that
703point will be real. You can verify that the lines are real by checking
704the logs on each system to see that they match what's in the message.
705When you find a discrepancy, you are close to the insertion point.
706Then you can poke around there to determine how the forged message was
707inserted into the mail system, and by who. As you'll see, there are
708lots of places where it could've come in.
709The long answer is specific to the programs involved. My description
710covers sendmail and uucp. I encourage people to clean up this
711description and add their own ideas, suggestions, and mailer programs.
712Look in the message for its message-ID and Received: lines. These will
713tell you what systems the message has gone through. Start with the
714last system (the recipient's system). Check the sendmail log (or
715equivalent) for that message-ID. This will let you map the message-ID
716to a queue-ID (generally AAxxxxx or ABxxxxx) which is in every log line
717that refers to this message. The log will show the message-ID, a from=
718line, and a set of to= lines indicating how it was delivered. If the
719log entries are there, you can probably believe the Received: line for
720that time, which indicates where the message came from. If it came
721from an Internet site, go back to that site and check its logs. If it
722came from uucp, sendmail won't know its origin, but you can check the
723uucp logs for a line at that time indicating "XQT (...rmail...)". [If
724you don't find one, the message was probably inserted onto your system
725by running sendmail or /bin/mail manually.]
726The system name in the uucp log "XQT" line will tell you part of the
727file name of the incoming mail. Probably the message came from that
728system, but uucp doesn't check for this, so somebody could've sent you
729uucp files containing somebody else's system name. Look back in the
730log for files coming in with this system name in the filename. You can
731also look in the uucp SYSLOG file, which contains the size of each file
732transferred, to help figure out which file contained the message. In
733some cases there is no way to unambiguously track the message here
734(until uux and uuxqt logging is improved to show the queue ID that it's
735executing). But in most cases you'll find where the message came in
736from. Contact the site admin for that site, indicate that you received
737the message at such and such a time, and have them check their uucp
738logs. They should find that the message was transferring at the same
739time. If not, it means somebody called your system and claimed to be
740them doing uucp; if you have a separate uucp login/password per site,
741you'll know that either you or they let the password get out. Change
742it. (Note that anyone who is root on their system can read this
743password out of their L.sys file.) If you don't have a separate uucp
744login/password for each site, fix this! You can't tell when your
745password is leaked, which site it leaked through! Also, don't put
746phone numbers and uucp logins in email; tell the remote site by phone.
747If you don't know their phone number, find it out -- how are you going
748to tell them about troubles on your uucp link when your link is broken?
749If the other site finds that the same files were moving in their logs
750as in your logs, then have them scan back through the log to find an
751XQT QUE'D entry for this message. You should know what's in the rmail
752command's arguments (since they're in your XQT log message) and the
753same arguments will appear in the XQT QUE'D message. That shows you
754the date and time when the message entered the uucp queue on their
755system. Then their site admin can cross-reference to the sendmail log
756to verify that the message exited sendmail at the same time it entered
757uucp (if not, the message was inserted manually by someone running a
758"uux" command on their system), and trace the sendmail log back. They
759can also check the Received: lines in the message to help find it in
760the sendmail log, or simply grep for the message-ID.
761If the message had come into sendmail via an SMTP connection rather
762than via uucp, the Received: line should say "Received: from xxxxx".
763If there are two addresses in XXXXX then check both of them; one is how
764that site identified itself in the SMTP protocol; the other is what the
765host table said about the Internet address where the connection is
766coming from. Have the site admin on that/those sites check their logs
767and work back from there. If there is no record of sendmail handling
768the message on that site, but your sendmail says it was received from
769that site, either someone on that site inserted the message (e.g. by
770doing "telnet yoursite smtp") or some other site impersonated their IP
771address. (A third possibility is that your host table or domain name
772cache has been hacked to make the site-they-connected-from appear to
773have the name of some other site). Start poking around with what
774users and processes were running on their system, and double-check
775the name server or hosts file on your system.
776Checking the "last" and "lastcomm" and cron logs may also be quite
777helpful to find sendmail and uucico and uux runs, either to
778disambiguate other log entries or if you lose the trail. It would help
779a lot to have an inetd log, too; has anyone hacked this into inetd?
780(Inetd is the master daemon that handles incoming connections for a
781whole mess of protocols, including telnet, rlogin, ftp, etc -- but not
782smtp).
783It's harder to trace a forgery that occurs by changing the contents of
784an existing message. E.g. the sender sent one version, the recipient
785got another. It could have been modified at each site along the way as
786it sat in a queue. It may be possible to track this down by checking
787the mesasge sizes at each site, but you have to account for the header
788lines changing. You could send a second message through the same path,
789with the same initial byte count, see what transformations happen
790to it along the way, and compare its logged byte counts to the counts
791of the forged message.
792If you can trace the message all the way back to the sender's site, but
793they claim they didn't send it, then the last and lastcomm and cron
794logs are useful for seeing who was on the system and what processes
795were running. Lastcomm (Unix process accounting) really should be
796logging the PID of each process so that its log can be backtraced into
797the other log files (sendmail and uucp both log the PID). Perhaps some
798other user sent the mail while su'd to that user, or injected it into
799the local sendmail daemon by connecting to the SMTP port on the local
800machine. Perhaps they used the TIOCSTI ioctl to insert fake 'typing'
801into one of the user's windows (perhaps even an iconified window) that
802caused the message to be sent "by them". This can be done when nobody
803else is logged in, but requires a process left around from some earlier
804time -- which should show up in lastcomm logs. Or perhaps someone just
805walked by their terminal, popped up a shell window, sent the message,
806and destroyed the window. This can be done in seconds if the message
807is in a prepared file (e.g. in /tmp), but again you'll find it in the
808process logs.
809If the user logs into that system via TCP, the TCP connection can be
810compromised (e.g. by forging a packet to appear to be from their
811workstation or x terminal). The next packet that is sent from the real
812TCP connection will cause the connection to reset, but that could
813happen hours later, and will just look like temporary network trouble
814(the window disappears or the rlogin says "Connection closed"). This
815is harder to spot since neither end of the link won't see anything odd
816until much later (except that the terminal may get some output
817resulting from the mail being sent, like another shell prompt; this
818could be disguised by clever use of terminal escape codes so it
819overprints the previous shell prompt). Lastcomm showing that the last
820thing to run on that pty was the mailer, even if the end of the pty
821(its shell terminating) happens much later, is probably your best clue
822there. An SMTP tcp connection can also be altered in this way. I have
823heard that someone at MIT is logging the first 50 bytes of every packet
824that goes through their Internet gateways, and keeping it for days. If
825you were really desperate, and the breakin happened at MIT, you could
826try locating the person doing the logging. (Needless to say the log is
827not available to everyone, since it includes all the login names and
828passwords used through the gateway!!!)
829Also don't forget that a claimed forgery may be a real message that the
830sender wishes to repudiate.
831As you can see, tracking a message back through five or ten sites this
832way would involve a lot of work and coordination, as well as requiring
833quick action so that that the forgery is noticed and traced before each
834of those sites' logs are removed. I encourage sites to keep a few
835weeks' worth of uucp and sendmail logs so that this kind of forgery can
836be more easily traced. Compress them to save space. Suns come with
837shell scripts that keep the log files for N days; you can hack these to
838alter N, move logs to places where there's more space, compress, or
839whatever.
840------------------------------------------------------------------------------
841Comments:
842Q's:
843Biblio:
844CrossRef:
845Code/shRef:
846==============================================================================
847------------------------------
848
849Date: Fri, 24 Jan 92 19:36:13 -0700
850Subject: IP.tracing
851
852==============================================================================
853Section Name chapter.sec.version 00/00/00
854IP.tracing 01.08.0 01/21/92
855------------------------------------------------------------------------------
856DATA:
857>one question: how do you trace someone through the net? in progress/after the
858>fact. - needed for current section of paper, thanks.
859It is directly related to the method they used to enter the net. For instance
860the /var/log/syslog file contains alot of information from folks using
861sendmail. There are obviously uucp logs. Some folks run front ends to the
862progs run out of inetd, which causes some logging -- to where... I dunno,
863depends on how they compiled the software. Best bet is to watch these
864directories:
865/var/log
866/var/adm
867>ok, on the logging thing, I was thinking of tracing IP packets... could you
868>expand on that a little?
869Again, nothing in *standard* unix. Sure, theoretically, I could, and I know
870that some sites do, trap and log all IP packets.
871>netstat, ofiles, rfc931, and packages that will log
872>what it sends all seem to have something to do with it...
873Yes, sites *could* run some of this stuff, but to say WHERE they are logging
874it is impossible. One would certainly want to do a long ps listing to see
875what processes are running. One implementation of RFC931 has a daemon called
876authd, but most folks run it out of inetd, so that would go un-noticed. I
877personally feel that the easiest way to detect such changes is to do a
878comparison to an "out of the box" system. For instance, compare inetd.conf
879files -- files created under /var/log and /var/adm, and so on....
880>'last' reads some file and tells where the connect to a particular accnt ...
881It reads wtmp (on suns /var/adm/wtmp). It logs normal logins, but not things
882like rsh. This obviously makes things like rsh HOST sh -i very useful. Also
883note that certain versions of utils like xterm and screen don't do logging,
884due to the non-writability of utmp on some systems and those apps not being
885setuid to a uid that can write to it. Basically, if you come in and even
886touch the "login" program, wtmp will have mention of it. Again, not rsh
887doesn't.
888>also what methods could be used to enter the net (brief, for now)
889Well, obviously you need to make it to a node on "the net". This is done
890by either:
891dialing up a host
892dialing up a terminal server*
893*= Some terminal servers are WIDE OPEN. Ask some folks about terminus...
894There are other ways, but I don't know much more about them. I know there
895is a packet radio network and a few sites will actually forward their packets.
896------------------------------------------------------------------------------
897Comments:
898Q's:
899Biblio:
900CrossRef:
901Code/shRef:
902==============================================================================
903------------------------------
904
905Date: Fri, 24 Jan 92 19:47:24 -0700
906Subject: more.IP.tracing
907
908==============================================================================
909Section Name chapter.sec.version 00/00/00
910more.IP.tracing 01.09.0 01/22/92
911------------------------------------------------------------------------------
912DATA:
913Subject: Finding out where someone remotely logged in from
914>Suppose a program is running as the login shell under telnetd (or is a
915>script run by the login shell, or some such). Is there a good way it
916>can discover the remote host from which the login was made?
917>The best way I've been able to figure out is to get the tty name (from
918>'who am i') and look it up in /etc/utmp. Unfortunately, utmp only
919>contains the first 16 characters of the remote host name. It seems to
920>me that there should be a good way to do this, since the telnetd could
921>just do a getpeername and find out its address. (In fact, either
922>telnetd or login *does*, in order to make the entry in utmp.) But
923>this information doesn't seem to be easily available to child
924>processes.
925The quick answer is that you can use either netstat or ofiles.
926netstat gives you a list of connections, and you have to pick out the one
927that corresponds to the utmp entry, then use netstat -n to get the IP address.
928Alternatively, you can use ofiles on the corresponding in.telnetd process
929(the parent of the shell), and see where file descriptors 0, 1 and 2 point to.
930That's where they're coming from.
931--------------------
932I have a similar problem only we are using System V and thus our hostname of
933origin isn't in /etc/utmp
934Is there a way to use netstat (which _does_ show the origin) and associate
935the results with individual terminals or users?
936[...]
937Paul Mc Auley | God is real . . . . . .
938--------------------------|
939AKA pmcauley@maths.tcd.ie | . . . . . . . . Unless Declared an Integer.
940----------------------
941Ok, not much of a solution, but at least it works:
942I had to do this for a client a couple of years ago. The solution I
943used then was (lacking source at their site) as follows:
944If you are using inetd (if not, the same _principle_ applies but the
945implementation is a trifle more complex), simply write a short programme that
946replaces telnetd. This programme does a getpeername() on it's stdin descrip-
947tor and squirrels it away somewhere before invoking the _real_ telnet or login
948daemon (with any arguments IT was originally called with).
949Places to squirrel the information:
9501/ In an environment variable. This sometimes works but can allow a
951user to `fake' their location and anyway, some telnetd/rlogind programmes
952refuse to pass over an inherited environment.
9532/ In a file indexed by something. Pick a suitable index - I used
954the PID since I already had (fast) routines to trace process parentage that
955would allow you to find the highest parent (closest to init) who'se parent
956WAS init - this would be the telnet/rlogin daemon (having the same PID as
957the new programme). It would be nice to know the tty name that the daemon
958will allocate, but unfortunately this hasn't been decided yet (there are
959frigs round this but they're unpleasant).
9603/ fork/exec - child exec's the real daemon, parent closes it's
961descriptors and watches for the PGRP of the child at which point the tty
962name is known (hackity hack).
963----------------------
964> netstat gives you a list of connections, and you have to pick out
965> the one that corresponds to the utmp entry, then use netstat -n to
966> get the IP address.
967> Alternatively, you can use ofiles on the corresponding in.telnetd
968> process (the parent of the shell), and see where file descriptors
969> 0, 1 and 2 point to. That's where they're coming from.
970I've looked into this, and run into some problems:
971netstat will truncate a symbolic host name to 16 characters (as does
972finger and the entry in utmp). This can be easily overcome with -n,
973which causes it to give numeric IP addresses.
974Unfortunately, netstat gives no way to associate a particular
975connection with the telnetd that it feeds. In fact, all incoming
976telnet connections list the same address on "this end" (port 512).
977ofiles might be useful, but we don't have it (we're running SunOS
9784.1.1), as far as I can tell.
979I have found that pstat -u will give all sorts of useful information
980about a process, including where internal control blocks are located.
981The 'files' field has pointers to the open files table, and pstat -f
982will list information about the open files table. But, alas, the peer
983address is not listed.
984Does anybody know of any other utilities to investigate?
985-----------------
986 RARP can catch IP forgery; encryption systems like Kerberose, simply
987ignore forged packets.
988------------------
989> "any desired IP address" Seems to me that you're limited to using ip
990>addresses in the range assigned to the subnet of your local wire.
991>Otherwise, you're not going to be able to interact with (or attack) any
992>systems (even ones on the local wire). And if you do change the ip address
993>to an unused one and then back to the real one when you're done, you will
994>have given away your site and genneral location.
995 This is a common misconception.
996 Yes, you need to use an address in your sub-net if you wish to receive
997any reverse traffic, but not all popular protocols rely on two-way
998communications. NFS servers, for instance, perform the requested operation
999and then send the reply back; if the reply can't reach the sender, the
1000operation has still been carried out, so who cares if the reverse
1001communication isn't possable? Simmilarly, many network time protocols use
1002one-way datagrams.
1003----------------
1004 [...]look at the /etc/services file. Each of these services is a possable
1005security problem.
1006-----------------
1007ME: Hmmm, someone tried to break in from 'foo.bar.edu'.
1008 <in e-mail> "Hey, root@foo.bar.edu. Someone tried to crack my
1009 machine from yours. Could you check your logs for
1010 Wed Jan 22 07:00:00 EST? Thanks."
1011ROOT: <in e-mail> "Someone from baz.bletch.com logged into our guest
1012 account from 04:00:00 to 08:30:00 this morning. Hmm, I think I'm
1013 going to start keeping a closer eye on the use of my guest account
1014 from now on."
1015ME: "Thanks, root@foo.bar.edu." "Hey, root@baz.bletch.com ..."
1016--------------
1017 There are many other groups working on reducing internet anonymity: for
1018example, Athena, the auth-acct list, SAAG, even rfc931-users.
1019 ^^^^^^^^^^^^^^ ^^^^
1020 anyone know who these groups are?
1021--------------
1022Try tracing this...
1023telnet to nsf.sun.ac.uk
1024log into janet pad
1025connect to {some janet site}
1026now connect from there ta a certain SPAN node
1027now patch out to the internet
1028There are at least 2 of the SPAN-IP gateways (where?)
1029Try tracing that convaluded mess!
1030It makes your terminus look like a kindergarden session:
1031You have involved 3 networks, 2 countries, and about 5 science/networking
1032agencies. Its a game of hunt the duristiction folks.
1033-------------
1034------------------------------------------------------------------------------
1035Comments:
1036Q's:
1037Biblio:
1038CrossRef:
1039Code/shRef:
1040==============================================================================
1041------------------------------
1042
1043Date: Fri, 24 Jan 92 19:55:52 -0700
1044Subject: rfc931
1045
1046==============================================================================
1047Section Name chapter.sec.version 00/00/00
1048rfc.931 01.10.0 01/22/92
1049------------------------------------------------------------------------------
1050DATA:
1051Network Working Group Mike StJohns
1052Request for Comments: 931 TPSC
1053Supersedes: RFC 912 January 1985
1054 Authentication Server
1055STATUS OF THIS MEMO
1056 This RFC suggests a proposed protocol for the ARPA-Internet
1057 community, and requests discussion and suggestions for improvements.
1058 This is the second draft of this proposal (superseding RFC 912) and
1059 incorporates a more formal description of the syntax for the request
1060 and response dialog, as well as a change to specify the type of user
1061 identification returned. Distribution of this memo is unlimited.
1062INTRODUCTION
1063 The Authentication Server Protocol provides a means to determine the
1064 identity of a user of a particular TCP connection. Given a TCP port
1065 number pair, it returns a character string which identifies the owner
1066 of that connection on the server's system. Suggested uses include
1067 automatic identification and verification of a user during an FTP
1068 session, additional verification of a TAC dial up user, and access
1069 verification for a generalized network file server.
1070OVERVIEW
1071 This is a connection based application on TCP. A server listens for
1072 TCP connections on TCP port 113 (decimal). Once a connection is
1073 established, the server reads one line of data which specifies the
1074 connection of interest. If it exists, the system dependent user
1075 identifier of the connection of interest is sent out the connection.
1076 The service closes the connection after sending the user identifier.
1077RESTRICTIONS
1078 Queries are permitted only for fully specified connections. The
1079 local/foreign host pair used to fully specify the connection are
1080 taken from the query connection. This means a user on Host A may
1081 only query the server on Host B about connections between A and B.
1082QUERY/RESPONSE FORMAT
1083 The server accepts simple text query requests of the form
1084 <local-port>, <foreign-port>
1085 where <local-port> is the TCP port (decimal) on the target (server)
1086 system, and <foreign-port> is the TCP port (decimal) on the source
1087 (user) system.
1088 For example:
1089 23, 6191
1090 The response is of the form
1091 <local-port>, <foreign-port> : <response-type> : <additional-info>
1092 where <local-port>,<foreign-port> are the same pair as the query,
1093 <response-type> is a keyword identifying the type of response, and
1094 <additional info> is context dependent.
1095 For example:
1096 23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
1097 23, 6193 : USERID : TAC : MCSJ-MITMUL
1098 23, 6195 : ERROR : NO-USER
1099RESPONSE TYPES
1100 A response can be one of two types:
1101 USERID
1102 In this case, <additional-info> is a string consisting of an
1103 operating system name, followed by a ":", followed by user
1104 identification string in a format peculiar to the operating system
1105 indicated. Permitted operating system names are specified in
1106 RFC-923, "Assigned Numbers" or its successors. The only other
1107 names permitted are "TAC" to specify a BBN Terminal Access
1108 Controller, and "OTHER" to specify any other operating system not
1109 yet registered with the NIC.
1110 ERROR
1111 For some reason the owner of <TCP-port> could not be determined,
1112 <additional-info> tells why. The following are suggested values
1113 of <additional-info> and their meanings.
1114 INVALID-PORT
1115 Either the local or foreign port was improperly specified.
1116 NO-USER
1117 The connection specified by the port pair is not currently in
1118 use.
1119 UNKNOWN-ERROR
1120 Can't determine connection owner; reason unknown. Other values
1121 may be specified as necessary.
1122CAVEATS
1123 Unfortunately, the trustworthiness of the various host systems that
1124 might implement an authentication server will vary quite a bit. It
1125 is up to the various applications that will use the server to
1126 determine the amount of trust they will place in the returned
1127 information. It may be appropriate in some cases restrict the use of
1128 the server to within a locally controlled subnet.
1129APPLICATIONS
1130 1) Automatic user authentication for FTP
1131 A user-FTP may send a USER command with no argument to the
1132 server-FTP to request automatic authentication. The server-FTP
1133 will reply with a 230 (user logged in) if it can use the
1134 authentication. It will reply with a 530 (not logged in) if it
1135 cannot authenticate the user. It will reply with a 500 or 501
1136 (syntax or parameter problem) if it does not implement automatic
1137 authentication. Please note that no change is needed to currently
1138 implemented servers to handle the request for authentication; they
1139 will reject it normally as a parameter problem. This is a
1140 suggested implementation for experimental use only.
1141 2) Verification for privileged network operations. For example,
1142 having the server start or stop special purpose servers.
1143 3) Elimination of "double login" for TAC and other TELNET users.
1144 This will be implemented as a TELNET option.
1145FORMAL SYNTAX
1146 <request> ::= <port-pair> <CR> <LF>
1147 <port-pair> ::= <integer-number> "," <integer-number>
1148 <reply> ::= <reply-text> <CR> <LF>
1149 <reply-text> ::= <error-reply> | <auth-reply>
1150 <error-reply> ::= <port-pair> ":" ERROR ":" <error-type>
1151 <auth-reply> ::= <port-pair> ":" USERID ":" <opsys> ":" <user-id>
1152 <error-type> ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR
1153 <opsys> ::= TAC | OTHER | MULTICS | UNIX ...etc.
1154 (See "Assigned Numbers")
1155 Notes on Syntax:
1156 1) White space (blanks and tab characters) between tokens is not
1157 important and may be ignored.
1158 2) White space, the token separator character (":"), and the port
1159 pair separator character (",") must be quoted if used within a
1160 token. The quote character is a back-slash, ASCII 92 (decimal)
1161 ("\"). For example, a quoted colon is "\:". The back-slash must
1162 also be quoted if its needed to represent itself ("\\").
1163Notes on User Identification Format:
1164 The user identifier returned by the server should be the standard one
1165 for the system. For example, the standard Multics identifier
1166 consists of a PERSONID followed by a ".", followed by a PROJECTID,
1167 followed by a ".", followed by an INSTANCE TAG of one character. An
1168 instance tag of "a" identifies an interactive user, and instance tag
1169 of "m" identifies an absentee job (batch job) user, and an instance
1170 tag of "z" identifies a daemon (background) user.
1171 Each set of operating system users must come to a consensus as to
1172 what the OFFICIAL user identification for their systems will be.
1173 Until they register this information, they must use the "OTHER" tag
1174 to specify their user identification.
1175Notes on User Identification Translation:
1176 Once you have a user identifier from a remote system, you must then
1177 have a way of translating it into an identifier that meaningful on
1178 the local system. The following is a sketchy outline of table driven
1179 scheme for doing this.
1180 The table consists of four columns, the first three are used to match
1181 against, the fourth is the result.
1182 USERID Opsys Address Result
1183 MCSJ-MITMUL TAC 26.*.*.* StJohns
1184 * MULTICS 192.5.42.* =
1185 * OTHER 10.0.0.42 anonymous
1186 MSJ ITS 10.3.0.44 StJohns
1187 The above table is a sample one for a Multics system on MILNET at the
1188 Pentagon. When an authentication is returned, the particular
1189 application using the userid simply looks for the first match in the
1190 table. Notice the second line. It says that any authentication
1191 coming from a Multics system on Net 192.5.42 is accepted in the same
1192 format.
1193 Obviously, various users will have to be registered to use this
1194 facility, but the registration can be done at the same time the use
1195 receives his login identity from the system.
1196------------------------------------------------------------------------------
1197Comments:
1198Q's:
1199Biblio:
1200CrossRef:
1201Code/shRef:
1202==============================================================================
1203------------------------------
1204
1205Date: Fri, 24 Jan 92 20:04:46 -0700
1206Subject: hacker.trkr.tools
1207
1208==============================================================================
1209Section Name chapter.sec.version 00/00/00
1210hacker.trkr.tools 01.11.0 01/24/92
1211------------------------------------------------------------------------------
1212DATA:
1213There are a number of "Hacker Tracker Tools", most have something to
1214do with rfc931, which is bad news... fortunatly it's not standard yet,
1215but it is becomming so... the documents below came with some of these
1216packages, they are worth reading as certain info can be gleaned from
1217them, such as where they put logs, and the programs names that run
1218these things. From this it should be able to tell if one of these is
1219running on a system, and devise ways to spoof them. They also alude to
1220security holes, that we can tease out... and offer pointers to other
1221programs in the same class... Shortcommings and weaknesses are also
1222identified. I havn't collected all of the programs yet, but am doing so.
1223these docs are chopped extracts from the program docs that come with
1224the programs. They need to be summerised further... (maybe a chart or
1225two...)
1226Programs of this type that I'm awaire of are:
1227AUTHD: 147.28.0.33 /pub/misc/authd301.tar.Z
1228KSTUFF: 128.174.5.50 /pub/kstuff-0.18.tar.Z
1229RARP: 137.208.3.5 /pub/src/datacom/rarpd.tar.Z
1230OFILES: 128.95.136.1 /pub/misc/ofiles.?
1231LOG_TCP: 147.28.0.3 /pub/unix/netware/log_tcp.?
1232LUMBERJACK:(?) 128.218.1.13 /comp.sources.unix/Volume16/lumberjack
1233ACTIV:(?) 128.256.135.4 /mirrors/unix-c/utils/activ.?
1234PAUTHD: ftp.lysator.liu.se /pub/daemons/pauthd-1.2.tar.Z
1235FTPD: wuarchive.wustl.edu /packages/ftpd.wuarchive.shar
1236 also see the 'related software' section of tcp_log docs (below) for
1237pointers to rshd, rlogind, tftp and authutil.
1238 If anyone knows of others please mention them.
1239---------------
1240some news extracts:
1241 There are many anonymous entrances into most systems. Local modem pools
1242are untraceable without a court order. PC's connected to a local Ethernet
1243can run their own copy of software and gain access to mutch they shouldn't
1244 Even on those systems wheree we require authentication, there's often
1245nothing I can do after the fact to trace who attacked you. We don't log
1246every IP connection made, and on a UNIX system with 30 simultanious users
1247often the best I can do is say "it was one of those 30" Indeed on a
1248default SunOS system, even if you tell me while you're being attacked,
1249'bout all I can do is run NETSTAT and agree with you that someone on the
1250local machine is doing it--without OFILES or some other non-standard tool,
1251I don't believe there's a way to trace an IP connection back to the process
1252that owns it.
1253-------------
1254[...]it's still a pain in the neck to figure out which USER made a
1255connection unless you can run PS and OFILES and so on WHILE the
1256connection is in progress. But there are tools like rfc931 which solve
1257this.
1258[...]it's still a pain in the neck to figgure our which MACHINE generated
1259a particular TCP packet, since TCP is insecure, unless you run RARP and
1260various other tools--like secure Ethernets, or Kerberos.
1261------------------------------------------------------------------------
1262TCP-LOG:
1263General description:
1264--------------------
1265With this package you can monitor connections to the SYSTAT, FINGER,
1266FTP, TELNET, RLOGIN, RSH and EXEC network services. Connections are
1267logged through the syslog(3) facility. A requirement is that daemons
1268are started by the inetd program or something similar.
1269The programs are tiny front ends that just report the remote host name
1270and then invoke the real network daemon. In the most common case, no
1271changes should be required to existing software or to configuration
1272files. Just move the vendor-provided daemons to another place and
1273install the front ends into their original places. Installation details
1274are given below.
1275Early versions of the programs were tested with Ultrix >= 2.2, with
1276SunOS >= 3.4 and ISC 2.2. The first official release has been installed
1277on a wide variety of systems (BSD, SYSV, Apollo) without modification.
1278The present release should still run on top of most BSD-style TCP/IP
1279implementations.
1280Optional feature:
1281-----------------
1282When compiled with -DHOSTS_ACCESS, the front-end programs support a
1283simple form of access control that is based on host (or domain) names,
1284internet addresses or network numbers, network daemon process names and
1285(optionally) netgroups (a NIS, formerly YP, feature). Wild cards are
1286supported. If a host requests connection to a network daemon, and if
1287the (daemon, host) pair is matched by an entry in the /etc/hosts.allow
1288file, access is granted. Otherwise, if the (daemon, host) pair is
1289matched by an entry in the /etc/hosts.deny file, access is denied.
1290Otherwise, access is granted. More details are provided in the
1291hosts_access(5) manual page. This form of access control may be useful
1292if it can not be implemented at a more suitable level (such as an
1293internet router).
1294Major enhancement:
1295------------------
1296It has been brought to my attention that AUTHENTICATION BASED ON HOST
1297ADDRESS TO HOST NAME MAPPING CAN EASILY BE SPOOFED BY PLAYING GAMES
1298WITH SOME DOMAIN NAME SERVER. A little research led me to the conclusion
1299that many existing RSHD and RLOGIND implementations do not account for
1300this potential problem.
1301The present versions of the front-end programs provide a way to take
1302care of the problem. After mapping a client host address to a host
1303name, the front-end programs now verify that the host name maps to the
1304same host address. The idea is that it is much easier to compromise
1305the address->name map of some random name server than to compromise the
1306name->address map that is specific to your domain. If the source is
1307compiled with -DPARANOID, the front ends justs drop the connection in
1308case of a host name/address mismatch. Otherwise, the front ends just
1309ignore the bad host name and use the host address when consulting the
1310access control files.
1311Minor enhancements:
1312-------------------
1313The host access control files now support more types of wild cards and
1314(optionally) allow the use of netgroup names. Netgroup support is
1315usually available on systems with NIS (formerly YP) software.
1316Related software:
1317-----------------
1318Versions of rshd and rlogind, hacked to report the remote user name as
1319well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z).
1320That archive also contains a tftpd source that logs the remote host
1321name (nice if you want to know who is interested in your /etc/passwd
1322file). All those programs have been tested only with SunOS >= 4.0.
1323Another way to manage access to tcp/ip services is illustrated by the
1324servers provided with the authutil package (comp.sources.unix volume
132522). This has the advantage that one will get the remote username from
1326any host supporting RFC 931 security. By installing the auth package
1327(same volume) one supports RFC 931 security too (but YOU WILL HAVE TO
1328BELIEVE WHAT THE REMOTE HOST TELLS YOU). Eventually one can start
1329cutting off unauthenticated connections. This is obviously a much more
1330advanced approach than what my front-end programs provide. The present
1331package is more suitable for those who lack the resources to install
1332anything that requires more than just renaming a couple of executables.
1333Configuration and installation (the easy way):
1334----------------------------------------------
1335An advanced installation recipe is given lateron. The "easy way" recipe
1336requires no changes to existing software or configuration files.
1337If you don't run Ultrix, you don't need the miscd front-end program.
1338The Ultrix miscd daemon implements among others the SYSTAT service,
1339which pipes the output from the WHO command to standard output.
1340By default, connections are logged to the same place where the sendmail
1341log entries go. If connections should be logged elsewhere, adjust the
1342LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog
1343configuration file (usually, /etc/syslog.conf). Most Ultrix versions
1344do not provide this flexibility, though.
1345The tcpd program is intended for monitoring connections to the telnet,
1346finger, ftp, exec, rsh and rlogin services. Decide which services you
1347want to be monitored. Move the vendor-provided daemon programs to the
1348location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and
1349copy the tcpd front end to the locations where the vendor-provided
1350daemons used to be. That is, one copy of the tcpd front end for each
1351service that you want to monitor.
1352---------------------------------------------------------------------------
1353AUTHD:
1354authd - authentication server daemon
1355tcpuid, tcpuname - find out which user owns a connection
1356authuser - remote authentication library
1357authd is an implementation of RFC 931, the Authentication Server under
1358BSD. RFC 931 provides the name of the user owning a TCP connection. This
1359helps network security: UNLESS TCP ITSELF IS COMPROMISED, it is
1360impossible to forge mail or news between computers supporting RFC 931.
1361It also BECOMES MUCH EASIER TO TRACE ATTACKERS than in the current,
1362largely anonymous, network. authd requires no changes to current code:
1363every connect() and accept() is authenticated automatically, with no
1364loss of efficiency.
1365tcpuid and tcpuname are the same program, but more suitable for local
1366use from the command line by a user or system administrator. They show
1367which local user created a given TCP connection.
1368authuser is a library encapsulating client use of RFC 931. It talks to a
1369remote Authentication Server to find out the username on the other side
1370of a given connection.
1371Only root can install authd. However, most current systems are insecure
1372enough that any user can run tcpuid and tcpuname. authuser is meant for
1373use by any program.
1374[...]
13752. Requirements
1376authd requires netstat, and it pokes around in several BSD-specific
1377kernel structures. It is not inherently portable code. Nevertheless, it
1378has been compiled under Ultrix, SunOS, and Convex UNIX, and it probably
1379doesn't take much work to get running under pretty much any BSD system.
1380authuser should compile and run without trouble on any BSD system.
1381You must be root to install authd. However, authd's sister utilities,
1382tcpuid and tcpuname, will probably work anyway if /dev/kmem is readable.
1383Any program can use the authuser library.
13843. How to configure authd
1385You can change CC or CCOPTS in Makefile if you want. If you want authd
1386to record connections through syslog at LOG_DEBUG, define -DUSE_SYSLOG
1387in the Makefile.
13885. How to install authd
1389If you don't have privileges, skip this part.
1390By default, authd, tcpuid, and tcpuname are installed in /etc,
1391authuser.o is installed as /usr/lib/libauthuser.a, authuser.h is
1392installed in /usr/include, authuser.3 is installed in /usr/man/man3,
1393and authd.8, tcpuid.8, and tcpuname.8 are installed in /usr/man/man8.
1394The binaries are installed setgid to group kmem. If you want to change
1395these defaults, edit INSTALL.
1396Then run INSTALL in a root shell; the script will check every action
1397with you before doing it.
1398To test tcpuname, make sure it is in your path, and run netstatuid. You
1399should get a report of all active network connections including
1400usernames.
1401To test authuser and authd, run ./test. You should get an ``everything
1402looks okay'' message.
14036. TODO list
1404fast multiple-connection version of tcpuid/tcpuname, like netstatuid?
1405should write a few notes on the exact security provided by rfc 931
1406authd - Authentication Server daemon authd is a daemon implement-
1407ing the RFC 931 Authentication Server protocol. It should be in-
1408voked by a network server, such as or for connections to TCP port
1409113 (auth). The client host gives two numbers separated by a
1410comma. interprets the numbers as TCP port numbers for the local
1411and remote sides respectively of a TCP connection between this
1412host and the client host. It returns a line of the form local-
1413port, remoteport: USERID: UNIX: username where username is the
1414name of the user on this side of the specified connection. If
1415does not have an authentication entry for that connection, it re-
1416turns a line of the form localport, remoteport: ERROR: UNKNOWN-
1417ERROR. None. None known. authd version 3.01, February 7, 1991.
1418Placed into the public domain by Daniel J. Bernstein. Partially
1419inspired by code written by Vic Abell for ofiles. The authenti-
1420cation server is more secure than passwords in some ways, but
1421less secure than passwords in many ways. (It's certainly better
1422than no password at all---e.g., for mail or news.) It is not the
1423final solution. For an excellent discussion of security problems
1424within the TCP/IP protocol suite, see Steve Bellovin's article
1425``Security Problems in the TCP/IP Protocol Suite.'' authtcp(1),
1426attachport(1), authuser(3), tcp(4), inetd(8) tcpuid - show the
1427user id that created a network connection tcpuid prints the
1428numeric user id of the user who created the network connection
1429specified by its arguments. Lots, none of which should happen if
1430the specified connection is valid. None known. tcpuid version
14313.01, February 7, 1991. Placed into the public domain by Daniel
1432J. Bernstein. Partially inspired by code written by Vic Abell
1433for ofiles. authd(8), tcpuname(8) tcpuname - show the user name
1434that created a network connection tcpuname prints the username of
1435nection is valid. None known. tcpuname version 3.01, February
14367, 1991. Placed into the public domain by Daniel J. Bernstein.
1437Partially inspired by code written by Vic Abell for ofiles.
1438authd(8), tcpuid(8)
1439------------------------------------------------------------------------
1440OFILES:
1441ofiles - show owner of open file or network connection [ ] [ ] [
1442] [ ] displays the owner, process identification (PID), type,
1443command and the number of the inode associated with an open in-
1444stance of a file or a network connection. An open file may be a
1445regular file, a file system or a directory; it is specified by
1446its path name. When the path name refers to a file system, will
1447display the owners of all open instances of files in the system.
1448An open network connection is specified by the kernel address of
1449its Protocol Control Block (PCB), as displayed by when its option
1450is specified. displays information about its usage if no options
1451are specified. This option selects verbose, debugging output.
1452This option may be used only on DYNIX hosts. It sets optional
1453name list and core file paths. is the path to the file from
1454which should obtain the addresses of kernel symbols, instead of
1455from is the path to the file from which should obtain the value
1456of kernel symbols, instead of from This option is useful for de-
1457bugging system crash dumps. This option specifies that the argu-
1458ments identify network connections by their hexadecimal, Protocol
1459Control Block (PCB) addresses. PCB addresses can be obtained via
1460the option of This option makes it possible to determine the lo-
1461cal processes that are using network connections in the LISTEN
1462through ESTABLISHED states. This option specifies that should
1463print process identifiers only - e. g., so that the output may be
1464piped to These are path names of files, directories and file sys-
1465tems; or, if the option has been specified, network connections,
1466identified by their hexadecimal Protocol Control Block (PCB) ad-
1467dresses. displays for each for file paths, an interpretation of
1468the type of name - file, directory or file system; for network
1469connections, the kernel address linkages, starting with the file
1470structure and proceeding through the socket structure and the In-
1471ternet Protocol Control Block (INPCB) structure to the PCB the
1472login name of the user of the process that has open the identif-
1473ier of the process that has open a file type explanation: if is
1474the current working directory of the process if is being used as
1475a regular file by the process, optionally followed by: if the
1476process has a shared lock on the file if the process has an ex-
1477clusive lock on the file if is the root directory of the process
1478if is a socket the file descriptor number, local to the process
1479the user command that opened the inode number of the file This
1480example shows the use of to discover the owner of the open, regu-
1481lar file,
1482% ofiles /usr/spool/lpd/lock
1483/usr/spool/lpd/lock
1484USER PID TYPE FD CMD INODE
1485root 110 file/x 3 lpd 26683
1486This example shows the use of and to identify the local endpoint
1487of the ``smtp'' network connection. The first column of output
1488from is the PCB address; it is used as the argument to along with
1489the option.
1490% netstat -aA | grep smtp
149180f6770c tcp 0 0 *.smtp *.* LISTEN
1492% ofiles -n 80f6770c
1493file 80102b64 of socket 80f6758c of INPCB 80f6780c of PCB 80f6770c
1494USER PID TYPE FD CMD
1495root 105 sock 5 sendmail
1496Errors are identified with messages on the standard error file.
1497returns a one (1) if any error was detected, including the
1498failure to locate any It returns a zero (0) if no errors were
1499detected and if it was able to display owner information about
1500all the specified can't identify SunOS 4.0 stream files, so it
1501doesn't follow their file structure pointers correctly when read-
1502ing their inodes. That results in the display of erroneous inode
1503numbers for stream files. The option limits its search to net-
1504work connections in the LISTEN through ESTABLISHED states. Since
1505reads kernel memory in its search for open files and network con-
1506nections, rapid changes in kernel memory may produce unsatisfac-
1507tory results. C. Spencer is the original author. Michael Ditto,
1508Tom Dunigan, Alexander Dupuy, Gary Nebbett and Richard Tobin con-
1509tributed. Michael Spitzer, Ray Moody, and Vik Lall of the Purdue
1510University Computing Center converted the program to a variety of
1511UNIX environments. Vic Abell of the Purdue University Computing
1512Center added the option. inode(5), mount(1), kill(1), tcp(4).
1513----------------------------------------------------------------------
1514RARPD:
1515 * Reverse Address Resolution Protocol server
1516 * Routines that handle network I/O, and process RARP packets.
1517/* EtherRead reads the packet and checks to see it's the right opcode, etc. */
1518/* Make sure we're looking for the right kind of Ethernet address. */
1519* Send a response packet with our addresses in 'source' addresses. rarpPacket
1520 comes in with the target addresses filled in, as well as the sizes, etc. */
1521 /* remember sender's hardware address, so the packet can be returned */
1522 /* fill in reply opcode and source addresses */
1523 * This programs sends a request packet to the rarp server and waits forever
1524 * for a reply, then displays the response packet.
1525/* An IP prototcol address */
1526/* An ethernet addresss for broadcast */
1527/*fill in reply opcode and source and target address*/
1528/* broadcast a request packet */
1529/* prints an array a for n characters (as hexadecimal digits) with dots in
1530 * between.
1531/* prints an array a for n characters (as decimal digits) with dots in
1532 * between.
1533 * test program for Reverse Address Resolution Protocol server
1534 * This programs sends a request packet to the rarp server and waits forever
1535 * for a reply, then displays the response packet.
1536/* An Ethernet hardware address (3Mbps) */
1537/* An IP prototcol address */
1538/* An ethernet addresss for broadcast */
1539/* broadcast a request packet */
1540 * added support for 3Mbps Ethernets.
1541 * This server uses files (/etc/rarpdb.*) to create a table of mappings
1542 * between Ethernet (hardware) addresses and 32-bit IP protocol (logical)
1543 * addresses.
1544 * It can be expanded to include other kinds of hardware and protocol
1545 * addresses, if needed.
1546 * It provides a service for client machines (usually diskless workstations)
1547 * to return a logical address when given a hardware address.
1548 ****************************************************************
1549 * Possible future extensions:
1550 * 1)Fix Our_Ether_Addr to reflect multiple networks. Right now
1551 *gethostid is used, which returns the IP address on the first
1552 *network, not necessarily the 10 Mbit one. (in OpenEthers)
1553 * 2)Change LookUp to use a faster search than sequential.
1554 * 3)Support other kinds of 'hardware' or 'protocol' addresses.
1555/*interval to wait before checking to see if disk file has been changed*/
1556 /* Main mostly does debug and error-checking things. It calls OpenEthers
1557 to establish the networks, and then calls MainLoop to do the serving. *
1558/* save ethermask because "select" changes the bits to indicate
1559 which of the bits that were on in readfds correspond to
1560 files that have packets waiting on their net */
1561/* something to read from this ether */
1562OpenEthers()
1563 /* OpenEthers goes through all nets on this machine and opens a file for
1564 each Ethernet interface. It builds a pernet table for each file
1565 opened. It calls BringInTable to build a table of address pairs for each
1566 net. It sets up a packet filter for each net for RARP packets. */
1567/* gethostid really gets the main id and won't work if > 1 net: */
1568 * Routines for reading and searching the table of
1569 * (Ethernet address, IP address) pairs.
1570 /* Parses the input line "line", entering the IP and Ethernet addresses
1571 * found into "tabent". This routine returns:
1572 * 1 if the line was successfully parsed,
1573 * 0 if the line is empty or begins with a comment character (; or #),
1574 * -1 if a syntax error was found in the line.
1575---------------------------------------------------------------------------
1576------------------------------------------------------------------------------
1577Comments:
1578Q's:
1579Biblio:
1580CrossRef:
1581Code/shRef:
1582==============================================================================
1583------------------------------
1584
1585Date: Fri, 24 Jan 92 21:27:27 -0700
1586Subject: hideum.pl
1587
1588==============================================================================
1589Section Name chapter.sec.version 00/00/00
1590unwho.pl toolbox.01.0 01/23/92
1591------------------------------------------------------------------------------
1592DATA:
1593Here's a little program called "unwho" that deletes all entries for a
1594given user from utmp. You could probably mogrify it trans what you want.
1595#!/usr/bin/perl
1596# This assumes your /etc/utmp file looks like ours
1597$unname = shift;
1598open(UTMP,'+</etc/utmp');
1599@mo = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec);
1600while (read(UTMP,$utmp,36)) {
1601 ($line,$name,$host,$time) = unpack('A8A8A16l',$utmp);
1602 if ($name) {
1603$host = "($host)" if $host;
1604($sec,$min,$hour,$mday,$mon) = localtime($time);
1605printf "%-9s%-8s%s %2d %02d:%02d %s\n",
1606 $name,$line,$mo[$mon],$mday,$hour,$min,$host;
1607if ($name eq $unname) {
1608 seek(UTMP,-36,1);
1609 print UTMP pack('A8a8A16l', "","","",0);
1610 seek(UTMP,0,1);
1611}
1612 }
1613}
1614------------------------------------------------------------------------------
1615Comments:
1616Q's:
1617Biblio:
1618CrossRef:
1619Code/shRef:
1620==============================================================================
1621
1622-------------------------------------
1623
1624To join this group or have your thoughts in the next issue, please
1625send electronic mail to Tangent at the following address;
1626
1627infohax
1628
1629The views expressed in InfoHax Digest
1630are those of the individual authors only.
1631
1632*********************
1633End of InfoHax Digest
1634*********************
1635[.nook] 27)
1636
1637
1638X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
1639 Another file downloaded from: NIRVANAnet(tm)
1640
1641 &TOTSE 510/935-5845 Walnut Creek, CA Taipan Enigma
1642 Burn This Flag 408/363-9766 San Jose, CA Zardoz
1643 realitycheck 415/666-0339 San Francisco, CA Poindexter Fortran
1644 Governed Anarchy 510/226-6656 Fremont, CA Eightball
1645 New Dork Sublime 805/823-1346 Tehachapi, CA Biffnix
1646 Lies Unlimited 801/278-2699 Salt Lake City, UT Mick Freen
1647 Atomic Books 410/669-4179 Baltimore, MD Baywolf
1648 Sea of Noise 203/886-1441 Norwich, CT Mr. Noise
1649 The Dojo 713/997-6351 Pearland, TX Yojimbo
1650 Frayed Ends of Sanity 503/965-6747 Cloverdale, OR Flatline
1651 The Ether Room 510/228-1146 Martinez, CA Tiny Little Super Guy
1652 Hacker Heaven 860/456-9266 Lebanon, CT The Visionary
1653 The Shaven Yak 510/672-6570 Clayton, CA Magic Man
1654 El Observador 408/372-9054 Salinas, CA El Observador
1655 Cool Beans! 415/648-7865 San Francisco, CA G.A. Ellsworth
1656 DUSK Til Dawn 604/746-5383 Cowichan Bay, BC Cyber Trollis
1657 The Great Abyss 510/482-5813 Oakland, CA Keymaster
1658
1659 "Raw Data for Raw Nerves"
1660X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X