API tools faq
paste
Advertisement
Guest User

INFOHAX1

a guest
Dec 5th, 2015
1,084
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 89.85 KB | None | 0 0
raw download clone embed print report
  1.  
  2.  
  3. InfoHax Digest, Number 1
  4.  
  5. Saturday, January 25th 1992
  6.  
  7. Today'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.  
  25. Date: Fri, 24 Jan 92 18:04:41 -0700
  26. Subject: welcome.hax
  27.  
  28. *****************************************************************************
  29. WELCOME TO PROJECT: INFOHAX
  30. *****************************************************************************
  31. Project: INFOHAX is an invitation only project to write the most explicit
  32. and complete guide to hacking UNIX systems that has ever been put out. We
  33. are starting with a 150k paper as an outline, filling in all the holes/tricks
  34. and expanding on it substantially.
  35. Project durration is set at 1+ year, with digests comming out once a week,
  36. delphi style, perhaps more often if the traffic warrents it.
  37. ***IN ORDER TO GET FURTHER DIGESTS YOU NEED TO SUBSCRIBE TO THE LISTSERV.***
  38. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  39. we also have a passworded fileserver, Details to follow.
  40. send mail to:
  41. LISTSERV@STORMKING.COM
  42. with
  43. SUBSCRIBE INFOHAX User_Name
  44. in the msg body
  45. if you have not been confirmed, you will be rebuffed.
  46. to access the fileserver send mail to:
  47. LISTSERV@STORMKING.COM
  48. with
  49. HELP
  50. INDEX INFOHAX /silicon_lollipop
  51. in the msg body
  52. for confirmation or to get a copy of the 'outline paper' contact
  53. XXXXXXXXXXXXXX
  54. so far confirmed people are:
  55. XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
  56. XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
  57. XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
  58. XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
  59. some people we havn't heard back from or havn't got confirmations from:
  60. XXXXXXXX
  61. XXXXXXXX
  62. you're in if you wanna be, let us know.
  63. These people have been recomended by someone and need to be voted on:
  64. please vote on a 0-10 scale, 0=NO 5=I_DONT_CARE 10=YES
  65.  
  66. XXXXXXXX
  67. XXXXXXXX
  68. XXXXXXXX
  69. if anyone has suggestions for additional people, please let me know.
  70. if anyone has strong feelings one way or the other on any of these people,
  71. voice um!
  72. SO HOW DOES THIS WORK?
  73. We're trying to work it like a delphi right now. A delphi is a think tank
  74. technique where you present an idea to work on, and send it out to people
  75. to work on, solve problems, submit info, ask/answer questions, comment on,
  76. etc. in a little less than a week send in what you have so far, and it will
  77. all be bundled into digests and sent out again... the list is moderated so
  78. some sorting/organising can happen before it goes out again. then people
  79. keep working on what they were, but have feedback and fresh material from
  80. everyone else... it's a really powerfull technique, so I hope it works for
  81. us. I think there will be some rough edges to work out, as to the methods,
  82. hopefully this wont take too long.
  83. I put out a form (see below: form.0) to help organise info, and keep
  84. track of things, please use it! the header and tail should be used for
  85. feedback, and discussions, please save bandwidth and nuke the 'DATA:'
  86. section, except for BRIEF extracts of the text being commented on.
  87. Also PLEASE SEND COMMENTS ON DIFFERENT SECTIONS IN DIFFERENT E-MAIL,
  88. that 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,
  91. if you want people to know who wrote what you just sent in, put your
  92. name or handle in the body of the message.
  93. If you're submitting original material, please use the whole thing. We
  94. will assighn a section # to avoid chaos...
  95. Also if you have input on the genneral form of the project, discussions
  96. that don't relate to a particular area, etc. please send a form with a
  97. header/subject line of DISCUSSION these will be collected together at the
  98. begiinning of the digests. The methods/form of the project are totally
  99. variable, and I encourage you to suggest changes, we may throw the delphi
  100. out all together, it's a starting point, nothing more. If you don't like
  101. it say so!
  102. If you see something referenced that you don't understand, ask about it.
  103. If you see a trick mentioned, but not explained, that you know something
  104. about, or have ideas on - even if you don't totally grok it, send in what
  105. you know, or ideas about how it might work. There are alot of little
  106. sections that need to be worked on. If you have something to say about it
  107. do!, even if you're not the person working on it. If you see a section
  108. that you'd like to work on, adopt it. basicly we get alot better info if
  109. people 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,
  112. cooperate, and lets not have any flame wars...
  113. PROJECT OUTLINE:
  114. the main sections of the original paper follow, after that some additions:
  115. Theory Devices
  116. Network Security Monitoring
  117. Other Network Services Net Monitoring
  118. Accnt Security Accnt Monitoring
  119. File System Security File System Monitoring
  120. Setgid Programs Know your System
  121. Startup Files Improving Your Security
  122. User Utils Pollicies
  123. Programming Utils Countermeasures
  124. Encryption Biblio
  125. additions:
  126. How not to get caught - logging, covering tracks, laundering calls, becoming
  127. invisable to the system, who's on, housecleaning, hiding setuid, trojans,..
  128. Getting in the Door...
  129. Getting Root
  130. Setuid Progs/shells
  131. Passive Snooping
  132. Network Spoofing
  133. Patch Level and Version History
  134. this list is far from complete, please suggest additions!, oh yeah, a large
  135. collection of exploitation type code/scripts at the end.
  136. if anyone would like to start filling in the outline/TOC that would be
  137. great!
  138. This first chapter is on how not to get caught. It will effect all the
  139. other areas of the paper and is going to be revisited/added to as we visit
  140. every other chapter. It's also a good springboard to get folks started in
  141. on other areas. I'm not shure if it's best to hop arround at random doing
  142. different sections in parrallel, or sequentially chapter by chapter...
  143. feedback?
  144. This first digest has the following areas to stimmulate discussion:
  145. sec01: sysadmin.comments - on logging
  146. sec02: frm.paper - what we're expanding on
  147. sec03: frm.mentor.paper - prev work to build on
  148. sec04: shell.tools - proposed tools by calculite, some comments
  149. by tangent
  150. sec05: phone.trace.evsn - info in evading phone traces
  151. sec06: BSD.accnt.files - summary of w/ notes on exploiting
  152. sec07: trace.fakemail.gd - slightly dated, lotta good tricks to tease out
  153. sec08: IP.tracing - discussions on hacker trackers
  154. sec09: more.IP.tracing - more of above
  155. sec10: rfc931 - bad news... need to find ways arround this.
  156. sec11: hacker.trkr.tools - how we get caught...
  157. sec12: hideum.pl - pearl script for nuking /utmp entries
  158. Some areas that need discussion are weather we should include available
  159. material, 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
  162. file server... feedback?
  163. Obvious 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
  168. that area (with a partner or two if there's overlap), though everyone should
  169. comment/contribute to all areas, if possable. This is supposed to be a
  170. democracy, so if you want to change what I'm outlining, please submit your
  171. ideas and the group can hash it out. Don't get overwelmed!, if we took 2wks
  172. on eash major area, this project would take a year, It's probably going to
  173. take more than that... remember, we're basicly writing a BOOK!
  174. we can officially consider this project underway, expect mailings every wk,
  175. perhaps twice a wk when things get going well!
  176. Happy Hacking!
  177. Tangent
  178. -----------------------------------------------------------------------------
  179. ------------------------------
  180.  
  181. Date: Fri, 24 Jan 92 18:14:48 -0700
  182. Subject: form.0
  183.  
  184. In an attempt to keep things organised from the start I put together a
  185. form for communication. The sole purpose of this is to be able to easily
  186. refer to what's been done, keep track of revisions, and cross ref comments
  187. and 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. ==============================================================================
  191. Section Name chapter.sec.version 00/00/00
  192. ------------------------------------------------------------------------------
  193. DATA:
  194. ------------------------------------------------------------------------------
  195. Comments:
  196. Q's:
  197. Biblio:
  198. CrossRef:
  199. Code/shRef:
  200. ==============================================================================
  201. ---8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<---
  202. where:
  203. Section Name - is the name of the sevtion within the chapter.
  204. chapter.sec.version - is the overall ref, version starts at 0, and goes up
  205. just like software or OS releases
  206. 00/00/00 - is the last revision date
  207. DATA: - 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. ------------------------------------------------------------------------------
  214. Comments: 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.
  218. Q's: how is this done, anyone know about this, etc... type area...
  219. Biblio: refs to go in the biblio chapter
  220. CrossRef: this ties in to, or could be used in chp#,sec#...
  221. Code/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
  225. make life soooo mutch easier a couple of months down the road, and when it
  226. goes to final edit...
  227. If anyone has comments on how to improve this, or do it better, speak up!,
  228. once 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
  230. published. The leading, and trailing headers are to keep track of it, and
  231. talk about it(DATA).
  232. ------------------------------------------------------------------------------
  233. ------------------------------
  234.  
  235. Date: Fri, 24 Jan 92 18:20:48 -0700
  236. Subject: sysadmin.comments
  237.  
  238. ==============================================================================
  239. Section Name chapter.sec.version 00/00/00
  240. sysadmin.comments 01.01.0 01/21/92
  241. ------------------------------------------------------------------------------
  242. DATA:
  243. 17) OK, finally, logs. I read every log that grows without bounds,
  244. including daemonlogs that would show unauthorized reboots if not altered.
  245. I never found anything odd in ptydaemonlog or vtdaemonlog, or any unreason-
  246. able reboots, startups, shutdowns, etc., although I kept reading the logs
  247. anyway.
  248. Obviously I reviewed sulog, but I never found anything in there
  249. either, although possibly the fact that I disabled su early on had something
  250. to do with that :).
  251. I also read my own .x11startlog, which would show startup times for
  252. X windows on the console; that was always clean.
  253. The ones that I did find things in were /etc/btmp and /etc/wtmp,
  254. expecially wtmp...I'm not sure how familiar you are with the format of
  255. these, so just to summarize, they give username, tty, time on and time off.
  256. btmp is the bad login attempt log, wtmp the successful login attempt log.
  257. I rather imagine that a dialup cracking attempt by an outsider would tend
  258. to generate more btmp entries, but on my system the interesting stuff was
  259. usually in wtmp. Anyway:
  260. In the log of bad logins, btmp, you look for repeated login attempts
  261. for a single user, especially if they are clustered around the same time,
  262. and especially if there are a large number of login attempts which don't
  263. show any typographical errors in the user name. A third to a half of
  264. legitimate entries--that is, failed logins by authorized users--in btmp
  265. will show typos in entering the username, or sometimes weird character
  266. strings that indicate somebody leaned on the keyboard. Some of them will
  267. show passwords typed in where usernames should be, which is why btmp is
  268. supposed to be readable only by root. I imagine that dialup will show
  269. some 'line noise' failures. My users were on hardwired terminals, so that
  270. didn't appear.
  271. Large numbers of failed entries for a single user in which the user-
  272. name is typed correctly mean either that a legitimate user has forgotten his
  273. password, a legitimate user is typing spastically this morning, or somebody's
  274. trying to crack that account. I'd ask the user if he was doing something
  275. that would have led to all the bad attempts; sometimes the answer was yes,
  276. in which case I could get him a new password or forget it. If it's no,
  277. I know I have a problem.
  278. The other pattern that sometimes occurs is 'sweeps' across large
  279. numbers of usernames, usually typed correctly, clustered at the same time
  280. and originating from the same terminal. This is almost always cracking,
  281. if it shows up in btmp.
  282. What is never anything but cracking is the appearance of login attempts
  283. for reasonable guesses at usernames that don't happen to exist on your system.
  284. The 'sweep' pattern, in our company, could be legitimate if it showed
  285. up in wtmp, the log of successful logins, because certain trusted department
  286. heads were authorized to login as their subordinates and occasionally did so
  287. for administrative purposes. In this case, the sweep usually originates at
  288. a single terminal, generally the department head's, and covers that department
  289. only.
  290. I looked for a string of fairly obvious things in wtmp: simultaneous
  291. logins by the same user, users logged in at unusual times or from unusual
  292. ports, off-console root logins, etc. This actually took the most time, and
  293. is the one I did the most asking about--hey, Rita, did you log in in Ben's
  294. office yesterday? and so forth.
  295. The larger the system and # of users, obviously, the harder this
  296. is to do. I could have started correlating wtmp and btmp entries, but
  297. never got the time to write the script. We also didn't have auditing enabled
  298. because I didn't get a chance to put it up, because I was under pressure to
  299. get the system operational. That was probably a mistake, although it wouldn't
  300. really have changed the final outcome of anything.
  301. I did pin down a major security breach with this procedure, because
  302. I found one more off-console root login than I knew was legitimate, which
  303. neither I nor the assistant administrators could account for. I found the
  304. damage not long after, although it took me, honestly, about two weeks to
  305. figure out why that particular item had been changed (It's not a secret, but
  306. definitely belongs in another letter, so I'll save it).
  307. This approach obviously has a flaw (aside from not having auditing)
  308. in that I obviously wouldn't see a breach that involved someone else logging
  309. in at a user's regular terminal at a reasonable time for that user to be
  310. there, which I strongly suspect happened more than once. Auditing would
  311. have caught anomalous system activity in that case if file permissions
  312. had been changed. It couldn't have caught the falsifying of information
  313. within the scope of the user's normal routine--if someone logged in as
  314. the bookkeeper in the right place at the right time calls up the usual
  315. programs and does everything except enter the numbers straight, there is
  316. no way to pick that up with auditing.
  317. Since I will have auditing up when I go up on the net, the report
  318. we ought to be able to compile on this subject after the experiments ought
  319. to be much more complete, and I'm looking forward to it as it should be
  320. fascinating. Thanks :)
  321. ------------------------------------------------------------------------------
  322. Comments:
  323. Q's:
  324. Biblio:
  325. CrossRef:
  326. Code/shRef:
  327. ==============================================================================
  328. ------------------------------
  329.  
  330. Date: Fri, 24 Jan 92 18:25:13 -0700
  331. Subject: frm.paper
  332.  
  333. ==============================================================================
  334. Section Name chapter.sec.version 00/00/00
  335. frm.paper 01.02.0 01/21/92
  336. ------------------------------------------------------------------------------
  337. DATA:
  338. In general the intruder can cover his own tracks. Detecting Intrusion
  339. therefor depends on on the intruder neglecting to do so, plus the
  340. installation of log keeping. The existence of log keeping should be
  341. somewhat secret to increase the probability that the intruder will
  342. unwittingly reveal his acts and methods.
  343. The best logkeeping consists of writing to a hardcopy device so that
  344. the intruder cannot erase the log.
  345. Sometimes a single slip-up by an intruder will reveal a huge case of
  346. previously unsuspected penetration.
  347. SYSLOG
  348. ------
  349. The syslog facility is a mechanism that enables any command to log error
  350. messages and informational messages to the system console, as well as to a
  351. log file. Typically error messages are logged in the file
  352. /usr/spool/log/syslog along with the date, time, and name of the program
  353. sending the message to the program.
  354. Example:
  355. DEC 24 12:10:06 WS1 NNTPXMIT: greet=520 SAMT 19 NNTP server can't talk to you
  356. DEC 24 14:53:37 WS1 LOGIN: root login ttyp3 from WS2.podunk.edu
  357. DEC 25 08:02:03 WS1 LOGIN: root login ttyp4 from wizard.hack.com
  358. DEC 25 08:28:52 WS1 SU: joueuser on /dev/ttyp3
  359. DEC 25 10:23:41 WS1 VMUNIX: /: file system full
  360. DEC 25 11:30:42 WS1 LOGIN: repeated login failures on ttyp3 from
  361. sys1.podunk.edu, daemon
  362. DEC 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.
  364. Wheneverr someone logs in as root login logs this informtion. In general
  365. logging in as root directly, as opposed to using the su program is better
  366. as 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
  368. account and failing, 3 consecutive times.
  369. These messages can be used to check for users sharring accounts, as well
  370. as hacking attempts.
  371. SHOWMOUNT
  372. ---------
  373. Can be used on a NFS file server to show the names of all hosts that
  374. currently 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
  382. to the systems organization should appear there. Second, only "normal"
  383. directories should be mounted - unusual directories being mounted may
  384. indicate a hacking attempt.
  385. FTP LOGGING
  386. -----------
  387. Some versions of ftp allow administrators to turn on and off logging
  388. information. The standard BSD4.2 does not, but there are publiclly
  389. available 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
  400. password given by the user (they ask for username, sometimes site name /
  401. address - 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
  403. to transfer files.
  404. Whenever you transfer files with ftp, the manager will know what login
  405. was used, what files were transfered, and to what site.
  406. (use a login, not your own , rename the files, and site hop...)
  407. ACCOUNT 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.
  413. LAST
  414. ----
  415. Last looks back in the wtmp file which records all logins and logouts
  416. for information about a user, a teletype or any group of users and teletypes.
  417. Arguments specify names of users or teletypes of interest. Names of teletypes
  418. may be given fully or abbreviated. For example, LAST 0 is the same as LAST
  419. TTY0. If multiple arguments are given, the information which applies to any
  420. of the arguments is printed. For example "last root console" would list all
  421. of 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
  423. recent first, indicating the times at which the session began, the duration
  424. of the session, and the teletype the session took place on. If the session
  425. is still continuing or was cut short by a reboot.
  426. With no arguments, last displays a list of all logins and logouts, in
  427. reverse order.
  428. Example:
  429. $ last -4 joeuser
  430. joeuser ttyp1 ws1.cs.podunk.e wed jun 6 10:04 still logged in
  431. joeuser ttyp3 bart.poduke.edu tue jun 5 15:01 - 15:01 (00:00)
  432. joeuser ttyp0 maggie.podunk.e tue jun 5 10:05 - 19:44 (09:38)
  433. joeuser console ws2.cs.poduke.e tue jun 5 09:49 - 10:05 (00:16)
  434. LASTCOMM
  435. --------
  436. Lastcomm gives information about previously executed commands. Without
  437. any arguments it gives information about all the commands recorded durring
  438. the the current accounting files lifetime. If called with no arguments, it
  439. displays information about all the commands recorded durring the current
  440. accounting files lifetime. If called with arguments it only displays
  441. accounting 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
  451. information:
  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. ------------------------------------------------------------------------------
  464. Comments:
  465. Q's:
  466. Biblio:
  467. CrossRef:
  468. Code/shRef:
  469. ==============================================================================
  470. ------------------------------
  471.  
  472. Date: Fri, 24 Jan 92 18:34:31 -0700
  473. Subject: frm.mentor.paper
  474.  
  475. ==============================================================================
  476. Section Name chapter.sec.version 00/00/00
  477. frm.mentor.paper 01.03.0 01/21/92
  478. ------------------------------------------------------------------------------
  479. DATA:
  480. ls -l will tell you the last time a file was modified, make a note of
  481. this when you tamper w/ a file, and set it back w/ the touch command when
  482. you are finnished, syntax is:
  483. touch hhmmMMdd [file]
  484. Where hh is hour, mm is minute, MM, is month, and dd is the day, [file]
  485. is obvious...
  486. What usually gives away hackers is the files they create on systems. If
  487. you must make files and directories on systems, make use of the hidden file
  488. feature ('.filename'). Also try to hide them in directories that are rarely
  489. ls'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
  491. by your account and group instead of the account which owned the original.
  492. You can change the group back w/ the chgrp command. syntax is:
  493. chgrp [groupname] [file]
  494. and change the owner back w/ the chown command:
  495. chown [user] [file]
  496. If you do something wrong, assume a note of it was recorded somewhere on
  497. the 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
  499. bells you can turn off system logging (if you have root).
  500. BSD ERROR LOGGING
  501. -----------------
  502. Type "cat /etc/syslog.pid", this file contains the process number of the
  503. syslog (error logging) program. Kill this process, and you have stopped
  504. error logging. Remember to start it back up when your through.
  505. If you want to see where the error logging messages are sent, type:
  506. cat /etc/syslog.config
  507. Entries are in the form:
  508. #file
  509. Such as:
  510. 5/etc/errorlogfile
  511. The number is the priority of the error, and the file is the file that
  512. errors of that level are sent to. If you see an entry with /dev/console as
  513. it's log file, watch out! Errors of that priority are sent to the system
  514. console. Sometimes a list of usernames will follow an entry for errorlogging.
  515. This means that these users will be notified of any errors of that priority
  516. or higher.
  517. There are 9 levels of error priority's, 1 is lowest, 5 is the lever of
  518. errors gennerally caused by hackers - security violations, bad login and su
  519. attemps, attempts to access files w/ out proper permissions..., level 9
  520. is a system crash.
  521. SysV ERROR LOGGING
  522. ------------------
  523. The SysV error logging prog is errdaemon, to find it's pid type "ps -uroot"
  524. among roots processes you will find /etc/errdaemon. If you kill it there will
  525. be no more logging till you start it again. By default it writes errors to
  526. the /usr/admin/errorfile.
  527. To get a report of errors type:
  528. errpt [-a] /usr/adm/errfile
  529. ------------------------------------------------------------------------------
  530. Comments:
  531. Q's:
  532. Biblio:
  533. CrossRef:
  534. Code/shRef:
  535. ==============================================================================
  536. ------------------------------
  537.  
  538. Date: Fri, 24 Jan 92 18:44:10 -0700
  539. Subject: shell.tools
  540.  
  541. ==============================================================================
  542. Section Name chapter.sec.version 00/00/00
  543. shell.tools 01.04.1 01/22/92
  544. ------------------------------------------------------------------------------
  545. DATA:
  546. I'll try to write a summary right now. It won't be in the proper format, but
  547. it's not a final submission, either...
  548. BEGIN SHELL SCRIPT SUMMARY
  549. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  550. Something that could come in handy for hacking UNIX systems would be a shell
  551. script that would automate the following:
  552. 1) disable logging
  553. 2) edit standard logs to remove lines containing the account name that's being
  554. used (when logs don't exist, inform the user)
  555. 3) 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)
  558. 4) 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)
  562. and possibly do the following:
  563. 1) alert the user when users log on and off
  564. (how about just people w/ privs, or owner of accnt)
  565. 2) attempt to exploit known bugs and edit appropriate logs
  566. This script could be uploaded after the user has obtained access to a system
  567. and be executed with possible options to disable functions when they're not
  568. desired.
  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 )
  572. END SHELL SCRIPT SUMMARY
  573. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  574. BEGIN HACK PROGRAM SUMMARY
  575. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  576. Another useful tool would be a program that would connect to port 25 of a
  577. target system and attempt passwords from a dictionary on standard usernames
  578. (guest, anonymous, ingres, new, apply, etc..) and usernames obtained manually
  579. by the user. This would operate much like an /etc/passwd cracker, but would
  580. actually try acct/passwd combinations over the net. NOTE: This should be used
  581. only as a last effort from a safe acct. It will, no doubt, affect logs on
  582. systems that log failed attempts. Possible sources for code: generic net
  583. interface code, MUD 'bot code, telnet source.
  584. A friend of mine wrote a telnet scanner that brought net connections to a crawl,
  585. he just did it sequentially, w/ no delay... a very irate sysadmin dragged him
  586. into his office and very nicely told him to never ever do that again...
  587. a little break between calls is important!
  588. END SUMMARY
  589. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  590. --
  591. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  592. Shannon 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. ------------------------------------------------------------------------------
  596. Comments:
  597. Q's:
  598. Biblio:
  599. CrossRef:
  600. Code/shRef:
  601. ==============================================================================
  602. ------------------------------
  603.  
  604. Date: Fri, 24 Jan 92 18:52:14 -0700
  605. Subject: phone.trace.evsn
  606.  
  607. ==============================================================================
  608. Section Name chapter.sec.version 00/00/00
  609. phone.trace.evsn 01.05.0 01/24/92
  610. ------------------------------------------------------------------------------
  611. DATA:
  612. Don't have mutch for this area yet. some stratagies are:
  613. use a goldbox
  614. use a diverter
  615. radio or cordless phone 1/2 in a bbox, 1/2 a safe distance away.
  616. use call forwarding to forward to a phone in a different babybell's area,
  617. then send it through MCI (refuses to provide call records in court) or to
  618. thriftytell(flat rate service w/ no call detail records)
  619. PLEASE ADD TO THIS!
  620. ------------------------------------------------------------------------------
  621. Comments:
  622. Q's:
  623. Biblio:
  624. CrossRef:
  625. Code/shRef:
  626. ==============================================================================
  627. ------------------------------
  628.  
  629. Date: Fri, 24 Jan 92 18:57:04 -0700
  630. Subject: BSD.accnt.files
  631.  
  632. ==============================================================================
  633. Section Name chapter.sec.version 00/00/00
  634. BSD.acct.files 01.06.1 01/18/92
  635. ------------------------------------------------------------------------------
  636. DATA:
  637. SUMMARY OF BSD ACCOUNTING FILES:
  638. --------------------------------
  639. data kept filename type owner group mode note
  640. ----------------------------------------------------------------------------
  641. CPU,memory,i/o /usr/adm/acct binary root system 644 (1)
  642. connect time /usr/adm/wtmp binary root system 644 (2)
  643. disk usage the file system n/a root operator 640 (3)
  644. printer usage /usr/adm/lpacct text daemon daemon 644 (4)
  645. dialout usage /usr/adm/aculog text uucp daemon 644 (5)
  646. console msgs /usr/adm/messages ? root system 664 (6)
  647. shutdown reasons /usr/adm/shutdownlog ? root system 664 (7)
  648. time daemon log /usr/adm/timed.log ? root system 644 (8)
  649. uucp transaction /usr/spool/uucp/LOGFILE ? uucp daemon 664 (9)
  650. uucp file transfer /usr/spool/uucp/SYSLOG ? uucp daemon 664 (10)
  651. network routing /usr/adm/gatedlog ? root system 644 (11)
  652. news connection .../news/nntp/logfile ? news news 644 (12)
  653. ----------------------------------------------------------------------------
  654. 1)accton(?) turns on accounting, sa(?) used to read, with the '-s' flag will
  655. summerize CPU usage by command, and TRUNCATES /usr/adm/acct to ZERO LENGTH!
  656. all commands executed once or with unprintable chars show up as '***other'
  657. (hmmm..), the system automatically suspends accounting if the file system
  658. that contains the accounting data becomes 95% full. If the machine crashes
  659. or is rebooted, processes that were running are not recorded in the CPU acct
  660. file, you can avoid cpu accounting by having your program sleep indefininatly
  661. upon completion as a program that never terminates does not produce any
  662. accounting record. (sleep(?) is also a good alternative to at and cron for
  663. hiding periodic processes). man acct(5)
  664. 4)can also be set via a macro in /etc/printcap
  665. 5)records login name, date, time, phone number, and status of all calls made
  666. through a dial out modem via the cu(?), tip(?) and uucp family of commands.
  667. If you are allowed to talk directly to the modem via a dialer entry in the
  668. file /etc/remote then the command 'tip dialer' will circumvent the
  669. accounting process.
  670. 6)also messages.N where N is from 0 to 6, usually.
  671. 9/10)This is for V7 UUCP, HDB (as in SunOS 4.x) is under /usr/spool/uucp/.Log
  672. /{uucp,uucio,uux,???}/<system name>
  673. 8/11/12)These are not standard, though many systems have them. Also, the
  674. filenames are compile time options (or set in config files)...
  675. ----------------------------------------------------------------------------
  676. Q's)"owner, group, and mode(octal) of the accounting data files is important
  677. and that any program used to reinitialize these files should be shure to
  678. chown, 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. ------------------------------------------------------------------------------
  683. Comments:
  684. Q's:
  685. Biblio:
  686. CrossRef:
  687. Code/shRef:
  688. ==============================================================================
  689. ------------------------------
  690.  
  691. Date: Fri, 24 Jan 92 19:29:37 -0700
  692. Subject: trace.fakemail.gd
  693.  
  694. ==============================================================================
  695. Section Name chapter.sec.version 00/00/00
  696. trace.fakemail.guide 01.07.0 01/21/92
  697. ------------------------------------------------------------------------------
  698. DATA:
  699. Phil Goetz asked how to trace forged mail. The short answer is: use
  700. log files and talk to other sysadmins so they'll do the same.
  701. A forged messages is injected into the mail system at some point, with
  702. a particular set of header lines. The header lines inserted after that
  703. point will be real. You can verify that the lines are real by checking
  704. the logs on each system to see that they match what's in the message.
  705. When you find a discrepancy, you are close to the insertion point.
  706. Then you can poke around there to determine how the forged message was
  707. inserted into the mail system, and by who. As you'll see, there are
  708. lots of places where it could've come in.
  709. The long answer is specific to the programs involved. My description
  710. covers sendmail and uucp. I encourage people to clean up this
  711. description and add their own ideas, suggestions, and mailer programs.
  712. Look in the message for its message-ID and Received: lines. These will
  713. tell you what systems the message has gone through. Start with the
  714. last system (the recipient's system). Check the sendmail log (or
  715. equivalent) for that message-ID. This will let you map the message-ID
  716. to a queue-ID (generally AAxxxxx or ABxxxxx) which is in every log line
  717. that refers to this message. The log will show the message-ID, a from=
  718. line, and a set of to= lines indicating how it was delivered. If the
  719. log entries are there, you can probably believe the Received: line for
  720. that time, which indicates where the message came from. If it came
  721. from an Internet site, go back to that site and check its logs. If it
  722. came from uucp, sendmail won't know its origin, but you can check the
  723. uucp logs for a line at that time indicating "XQT (...rmail...)". [If
  724. you don't find one, the message was probably inserted onto your system
  725. by running sendmail or /bin/mail manually.]
  726. The system name in the uucp log "XQT" line will tell you part of the
  727. file name of the incoming mail. Probably the message came from that
  728. system, but uucp doesn't check for this, so somebody could've sent you
  729. uucp files containing somebody else's system name. Look back in the
  730. log for files coming in with this system name in the filename. You can
  731. also look in the uucp SYSLOG file, which contains the size of each file
  732. transferred, to help figure out which file contained the message. In
  733. some 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
  735. executing). But in most cases you'll find where the message came in
  736. from. Contact the site admin for that site, indicate that you received
  737. the message at such and such a time, and have them check their uucp
  738. logs. They should find that the message was transferring at the same
  739. time. If not, it means somebody called your system and claimed to be
  740. them doing uucp; if you have a separate uucp login/password per site,
  741. you'll know that either you or they let the password get out. Change
  742. it. (Note that anyone who is root on their system can read this
  743. password out of their L.sys file.) If you don't have a separate uucp
  744. login/password for each site, fix this! You can't tell when your
  745. password is leaked, which site it leaked through! Also, don't put
  746. phone numbers and uucp logins in email; tell the remote site by phone.
  747. If you don't know their phone number, find it out -- how are you going
  748. to tell them about troubles on your uucp link when your link is broken?
  749. If the other site finds that the same files were moving in their logs
  750. as in your logs, then have them scan back through the log to find an
  751. XQT QUE'D entry for this message. You should know what's in the rmail
  752. command's arguments (since they're in your XQT log message) and the
  753. same arguments will appear in the XQT QUE'D message. That shows you
  754. the date and time when the message entered the uucp queue on their
  755. system. Then their site admin can cross-reference to the sendmail log
  756. to verify that the message exited sendmail at the same time it entered
  757. uucp (if not, the message was inserted manually by someone running a
  758. "uux" command on their system), and trace the sendmail log back. They
  759. can also check the Received: lines in the message to help find it in
  760. the sendmail log, or simply grep for the message-ID.
  761. If the message had come into sendmail via an SMTP connection rather
  762. than via uucp, the Received: line should say "Received: from xxxxx".
  763. If there are two addresses in XXXXX then check both of them; one is how
  764. that site identified itself in the SMTP protocol; the other is what the
  765. host table said about the Internet address where the connection is
  766. coming from. Have the site admin on that/those sites check their logs
  767. and work back from there. If there is no record of sendmail handling
  768. the message on that site, but your sendmail says it was received from
  769. that site, either someone on that site inserted the message (e.g. by
  770. doing "telnet yoursite smtp") or some other site impersonated their IP
  771. address. (A third possibility is that your host table or domain name
  772. cache has been hacked to make the site-they-connected-from appear to
  773. have the name of some other site). Start poking around with what
  774. users and processes were running on their system, and double-check
  775. the name server or hosts file on your system.
  776. Checking the "last" and "lastcomm" and cron logs may also be quite
  777. helpful to find sendmail and uucico and uux runs, either to
  778. disambiguate other log entries or if you lose the trail. It would help
  779. a 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
  781. whole mess of protocols, including telnet, rlogin, ftp, etc -- but not
  782. smtp).
  783. It's harder to trace a forgery that occurs by changing the contents of
  784. an existing message. E.g. the sender sent one version, the recipient
  785. got another. It could have been modified at each site along the way as
  786. it sat in a queue. It may be possible to track this down by checking
  787. the mesasge sizes at each site, but you have to account for the header
  788. lines changing. You could send a second message through the same path,
  789. with the same initial byte count, see what transformations happen
  790. to it along the way, and compare its logged byte counts to the counts
  791. of the forged message.
  792. If you can trace the message all the way back to the sender's site, but
  793. they claim they didn't send it, then the last and lastcomm and cron
  794. logs are useful for seeing who was on the system and what processes
  795. were running. Lastcomm (Unix process accounting) really should be
  796. logging the PID of each process so that its log can be backtraced into
  797. the other log files (sendmail and uucp both log the PID). Perhaps some
  798. other user sent the mail while su'd to that user, or injected it into
  799. the local sendmail daemon by connecting to the SMTP port on the local
  800. machine. Perhaps they used the TIOCSTI ioctl to insert fake 'typing'
  801. into one of the user's windows (perhaps even an iconified window) that
  802. caused the message to be sent "by them". This can be done when nobody
  803. else is logged in, but requires a process left around from some earlier
  804. time -- which should show up in lastcomm logs. Or perhaps someone just
  805. walked by their terminal, popped up a shell window, sent the message,
  806. and destroyed the window. This can be done in seconds if the message
  807. is in a prepared file (e.g. in /tmp), but again you'll find it in the
  808. process logs.
  809. If the user logs into that system via TCP, the TCP connection can be
  810. compromised (e.g. by forging a packet to appear to be from their
  811. workstation or x terminal). The next packet that is sent from the real
  812. TCP connection will cause the connection to reset, but that could
  813. happen hours later, and will just look like temporary network trouble
  814. (the window disappears or the rlogin says "Connection closed"). This
  815. is harder to spot since neither end of the link won't see anything odd
  816. until much later (except that the terminal may get some output
  817. resulting from the mail being sent, like another shell prompt; this
  818. could be disguised by clever use of terminal escape codes so it
  819. overprints the previous shell prompt). Lastcomm showing that the last
  820. thing 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
  822. there. An SMTP tcp connection can also be altered in this way. I have
  823. heard that someone at MIT is logging the first 50 bytes of every packet
  824. that goes through their Internet gateways, and keeping it for days. If
  825. you were really desperate, and the breakin happened at MIT, you could
  826. try locating the person doing the logging. (Needless to say the log is
  827. not available to everyone, since it includes all the login names and
  828. passwords used through the gateway!!!)
  829. Also don't forget that a claimed forgery may be a real message that the
  830. sender wishes to repudiate.
  831. As you can see, tracking a message back through five or ten sites this
  832. way would involve a lot of work and coordination, as well as requiring
  833. quick action so that that the forgery is noticed and traced before each
  834. of those sites' logs are removed. I encourage sites to keep a few
  835. weeks' worth of uucp and sendmail logs so that this kind of forgery can
  836. be more easily traced. Compress them to save space. Suns come with
  837. shell scripts that keep the log files for N days; you can hack these to
  838. alter N, move logs to places where there's more space, compress, or
  839. whatever.
  840. ------------------------------------------------------------------------------
  841. Comments:
  842. Q's:
  843. Biblio:
  844. CrossRef:
  845. Code/shRef:
  846. ==============================================================================
  847. ------------------------------
  848.  
  849. Date: Fri, 24 Jan 92 19:36:13 -0700
  850. Subject: IP.tracing
  851.  
  852. ==============================================================================
  853. Section Name chapter.sec.version 00/00/00
  854. IP.tracing 01.08.0 01/21/92
  855. ------------------------------------------------------------------------------
  856. DATA:
  857. >one question: how do you trace someone through the net? in progress/after the
  858. >fact. - needed for current section of paper, thanks.
  859. It is directly related to the method they used to enter the net. For instance
  860. the /var/log/syslog file contains alot of information from folks using
  861. sendmail. There are obviously uucp logs. Some folks run front ends to the
  862. progs run out of inetd, which causes some logging -- to where... I dunno,
  863. depends on how they compiled the software. Best bet is to watch these
  864. directories:
  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?
  869. Again, nothing in *standard* unix. Sure, theoretically, I could, and I know
  870. that 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...
  873. Yes, sites *could* run some of this stuff, but to say WHERE they are logging
  874. it is impossible. One would certainly want to do a long ps listing to see
  875. what processes are running. One implementation of RFC931 has a daemon called
  876. authd, but most folks run it out of inetd, so that would go un-noticed. I
  877. personally feel that the easiest way to detect such changes is to do a
  878. comparison to an "out of the box" system. For instance, compare inetd.conf
  879. files -- 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 ...
  881. It reads wtmp (on suns /var/adm/wtmp). It logs normal logins, but not things
  882. like rsh. This obviously makes things like rsh HOST sh -i very useful. Also
  883. note that certain versions of utils like xterm and screen don't do logging,
  884. due to the non-writability of utmp on some systems and those apps not being
  885. setuid to a uid that can write to it. Basically, if you come in and even
  886. touch the "login" program, wtmp will have mention of it. Again, not rsh
  887. doesn't.
  888. >also what methods could be used to enter the net (brief, for now)
  889. Well, obviously you need to make it to a node on "the net". This is done
  890. by either:
  891. dialing up a host
  892. dialing up a terminal server*
  893. *= Some terminal servers are WIDE OPEN. Ask some folks about terminus...
  894. There are other ways, but I don't know much more about them. I know there
  895. is a packet radio network and a few sites will actually forward their packets.
  896. ------------------------------------------------------------------------------
  897. Comments:
  898. Q's:
  899. Biblio:
  900. CrossRef:
  901. Code/shRef:
  902. ==============================================================================
  903. ------------------------------
  904.  
  905. Date: Fri, 24 Jan 92 19:47:24 -0700
  906. Subject: more.IP.tracing
  907.  
  908. ==============================================================================
  909. Section Name chapter.sec.version 00/00/00
  910. more.IP.tracing 01.09.0 01/22/92
  911. ------------------------------------------------------------------------------
  912. DATA:
  913. Subject: 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.
  925. The quick answer is that you can use either netstat or ofiles.
  926. netstat gives you a list of connections, and you have to pick out the one
  927. that corresponds to the utmp entry, then use netstat -n to get the IP address.
  928. Alternatively, 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.
  930. That's where they're coming from.
  931. --------------------
  932. I have a similar problem only we are using System V and thus our hostname of
  933. origin isn't in /etc/utmp
  934. Is there a way to use netstat (which _does_ show the origin) and associate
  935. the results with individual terminals or users?
  936. [...]
  937. Paul Mc Auley | God is real . . . . . .
  938. --------------------------|
  939. AKA pmcauley@maths.tcd.ie | . . . . . . . . Unless Declared an Integer.
  940. ----------------------
  941. Ok, not much of a solution, but at least it works:
  942. I had to do this for a client a couple of years ago. The solution I
  943. used then was (lacking source at their site) as follows:
  944. If you are using inetd (if not, the same _principle_ applies but the
  945. implementation is a trifle more complex), simply write a short programme that
  946. replaces telnetd. This programme does a getpeername() on it's stdin descrip-
  947. tor and squirrels it away somewhere before invoking the _real_ telnet or login
  948. daemon (with any arguments IT was originally called with).
  949. Places to squirrel the information:
  950. 1/ In an environment variable. This sometimes works but can allow a
  951. user to `fake' their location and anyway, some telnetd/rlogind programmes
  952. refuse to pass over an inherited environment.
  953. 2/ In a file indexed by something. Pick a suitable index - I used
  954. the PID since I already had (fast) routines to trace process parentage that
  955. would allow you to find the highest parent (closest to init) who'se parent
  956. WAS init - this would be the telnet/rlogin daemon (having the same PID as
  957. the new programme). It would be nice to know the tty name that the daemon
  958. will allocate, but unfortunately this hasn't been decided yet (there are
  959. frigs round this but they're unpleasant).
  960. 3/ fork/exec - child exec's the real daemon, parent closes it's
  961. descriptors and watches for the PGRP of the child at which point the tty
  962. name 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.
  970. I've looked into this, and run into some problems:
  971. netstat will truncate a symbolic host name to 16 characters (as does
  972. finger and the entry in utmp). This can be easily overcome with -n,
  973. which causes it to give numeric IP addresses.
  974. Unfortunately, netstat gives no way to associate a particular
  975. connection with the telnetd that it feeds. In fact, all incoming
  976. telnet connections list the same address on "this end" (port 512).
  977. ofiles might be useful, but we don't have it (we're running SunOS
  978. 4.1.1), as far as I can tell.
  979. I have found that pstat -u will give all sorts of useful information
  980. about a process, including where internal control blocks are located.
  981. The 'files' field has pointers to the open files table, and pstat -f
  982. will list information about the open files table. But, alas, the peer
  983. address is not listed.
  984. Does anybody know of any other utilities to investigate?
  985. -----------------
  986. RARP can catch IP forgery; encryption systems like Kerberose, simply
  987. ignore 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
  997. any reverse traffic, but not all popular protocols rely on two-way
  998. communications. NFS servers, for instance, perform the requested operation
  999. and then send the reply back; if the reply can't reach the sender, the
  1000. operation has still been carried out, so who cares if the reverse
  1001. communication isn't possable? Simmilarly, many network time protocols use
  1002. one-way datagrams.
  1003. ----------------
  1004. [...]look at the /etc/services file. Each of these services is a possable
  1005. security problem.
  1006. -----------------
  1007. ME: 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."
  1011. ROOT: <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."
  1015. ME: "Thanks, root@foo.bar.edu." "Hey, root@baz.bletch.com ..."
  1016. --------------
  1017. There are many other groups working on reducing internet anonymity: for
  1018. example, Athena, the auth-acct list, SAAG, even rfc931-users.
  1019. ^^^^^^^^^^^^^^ ^^^^
  1020. anyone know who these groups are?
  1021. --------------
  1022. Try tracing this...
  1023. telnet to nsf.sun.ac.uk
  1024. log into janet pad
  1025. connect to {some janet site}
  1026. now connect from there ta a certain SPAN node
  1027. now patch out to the internet
  1028. There are at least 2 of the SPAN-IP gateways (where?)
  1029. Try tracing that convaluded mess!
  1030. It makes your terminus look like a kindergarden session:
  1031. You have involved 3 networks, 2 countries, and about 5 science/networking
  1032. agencies. Its a game of hunt the duristiction folks.
  1033. -------------
  1034. ------------------------------------------------------------------------------
  1035. Comments:
  1036. Q's:
  1037. Biblio:
  1038. CrossRef:
  1039. Code/shRef:
  1040. ==============================================================================
  1041. ------------------------------
  1042.  
  1043. Date: Fri, 24 Jan 92 19:55:52 -0700
  1044. Subject: rfc931
  1045.  
  1046. ==============================================================================
  1047. Section Name chapter.sec.version 00/00/00
  1048. rfc.931 01.10.0 01/22/92
  1049. ------------------------------------------------------------------------------
  1050. DATA:
  1051. Network Working Group Mike StJohns
  1052. Request for Comments: 931 TPSC
  1053. Supersedes: RFC 912 January 1985
  1054. Authentication Server
  1055. STATUS 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.
  1062. INTRODUCTION
  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.
  1070. OVERVIEW
  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.
  1077. RESTRICTIONS
  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.
  1082. QUERY/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
  1099. RESPONSE 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.
  1122. CAVEATS
  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.
  1129. APPLICATIONS
  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.
  1145. FORMAL 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 ("\\").
  1163. Notes 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.
  1175. Notes 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. ------------------------------------------------------------------------------
  1197. Comments:
  1198. Q's:
  1199. Biblio:
  1200. CrossRef:
  1201. Code/shRef:
  1202. ==============================================================================
  1203. ------------------------------
  1204.  
  1205. Date: Fri, 24 Jan 92 20:04:46 -0700
  1206. Subject: hacker.trkr.tools
  1207.  
  1208. ==============================================================================
  1209. Section Name chapter.sec.version 00/00/00
  1210. hacker.trkr.tools 01.11.0 01/24/92
  1211. ------------------------------------------------------------------------------
  1212. DATA:
  1213. There are a number of "Hacker Tracker Tools", most have something to
  1214. do with rfc931, which is bad news... fortunatly it's not standard yet,
  1215. but it is becomming so... the documents below came with some of these
  1216. packages, they are worth reading as certain info can be gleaned from
  1217. them, such as where they put logs, and the programs names that run
  1218. these things. From this it should be able to tell if one of these is
  1219. running on a system, and devise ways to spoof them. They also alude to
  1220. security holes, that we can tease out... and offer pointers to other
  1221. programs in the same class... Shortcommings and weaknesses are also
  1222. identified. I havn't collected all of the programs yet, but am doing so.
  1223. these docs are chopped extracts from the program docs that come with
  1224. the programs. They need to be summerised further... (maybe a chart or
  1225. two...)
  1226. Programs of this type that I'm awaire of are:
  1227. AUTHD: 147.28.0.33 /pub/misc/authd301.tar.Z
  1228. KSTUFF: 128.174.5.50 /pub/kstuff-0.18.tar.Z
  1229. RARP: 137.208.3.5 /pub/src/datacom/rarpd.tar.Z
  1230. OFILES: 128.95.136.1 /pub/misc/ofiles.?
  1231. LOG_TCP: 147.28.0.3 /pub/unix/netware/log_tcp.?
  1232. LUMBERJACK:(?) 128.218.1.13 /comp.sources.unix/Volume16/lumberjack
  1233. ACTIV:(?) 128.256.135.4 /mirrors/unix-c/utils/activ.?
  1234. PAUTHD: ftp.lysator.liu.se /pub/daemons/pauthd-1.2.tar.Z
  1235. FTPD: wuarchive.wustl.edu /packages/ftpd.wuarchive.shar
  1236. also see the 'related software' section of tcp_log docs (below) for
  1237. pointers to rshd, rlogind, tftp and authutil.
  1238. If anyone knows of others please mention them.
  1239. ---------------
  1240. some news extracts:
  1241. There are many anonymous entrances into most systems. Local modem pools
  1242. are untraceable without a court order. PC's connected to a local Ethernet
  1243. can 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
  1245. nothing I can do after the fact to trace who attacked you. We don't log
  1246. every IP connection made, and on a UNIX system with 30 simultanious users
  1247. often the best I can do is say "it was one of those 30" Indeed on a
  1248. default 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
  1250. local machine is doing it--without OFILES or some other non-standard tool,
  1251. I don't believe there's a way to trace an IP connection back to the process
  1252. that owns it.
  1253. -------------
  1254. [...]it's still a pain in the neck to figure out which USER made a
  1255. connection unless you can run PS and OFILES and so on WHILE the
  1256. connection is in progress. But there are tools like rfc931 which solve
  1257. this.
  1258. [...]it's still a pain in the neck to figgure our which MACHINE generated
  1259. a particular TCP packet, since TCP is insecure, unless you run RARP and
  1260. various other tools--like secure Ethernets, or Kerberos.
  1261. ------------------------------------------------------------------------
  1262. TCP-LOG:
  1263. General description:
  1264. --------------------
  1265. With this package you can monitor connections to the SYSTAT, FINGER,
  1266. FTP, TELNET, RLOGIN, RSH and EXEC network services. Connections are
  1267. logged through the syslog(3) facility. A requirement is that daemons
  1268. are started by the inetd program or something similar.
  1269. The programs are tiny front ends that just report the remote host name
  1270. and then invoke the real network daemon. In the most common case, no
  1271. changes should be required to existing software or to configuration
  1272. files. Just move the vendor-provided daemons to another place and
  1273. install the front ends into their original places. Installation details
  1274. are given below.
  1275. Early versions of the programs were tested with Ultrix >= 2.2, with
  1276. SunOS >= 3.4 and ISC 2.2. The first official release has been installed
  1277. on a wide variety of systems (BSD, SYSV, Apollo) without modification.
  1278. The present release should still run on top of most BSD-style TCP/IP
  1279. implementations.
  1280. Optional feature:
  1281. -----------------
  1282. When compiled with -DHOSTS_ACCESS, the front-end programs support a
  1283. simple form of access control that is based on host (or domain) names,
  1284. internet addresses or network numbers, network daemon process names and
  1285. (optionally) netgroups (a NIS, formerly YP, feature). Wild cards are
  1286. supported. If a host requests connection to a network daemon, and if
  1287. the (daemon, host) pair is matched by an entry in the /etc/hosts.allow
  1288. file, access is granted. Otherwise, if the (daemon, host) pair is
  1289. matched by an entry in the /etc/hosts.deny file, access is denied.
  1290. Otherwise, access is granted. More details are provided in the
  1291. hosts_access(5) manual page. This form of access control may be useful
  1292. if it can not be implemented at a more suitable level (such as an
  1293. internet router).
  1294. Major enhancement:
  1295. ------------------
  1296. It has been brought to my attention that AUTHENTICATION BASED ON HOST
  1297. ADDRESS TO HOST NAME MAPPING CAN EASILY BE SPOOFED BY PLAYING GAMES
  1298. WITH SOME DOMAIN NAME SERVER. A little research led me to the conclusion
  1299. that many existing RSHD and RLOGIND implementations do not account for
  1300. this potential problem.
  1301. The present versions of the front-end programs provide a way to take
  1302. care of the problem. After mapping a client host address to a host
  1303. name, the front-end programs now verify that the host name maps to the
  1304. same host address. The idea is that it is much easier to compromise
  1305. the address->name map of some random name server than to compromise the
  1306. name->address map that is specific to your domain. If the source is
  1307. compiled with -DPARANOID, the front ends justs drop the connection in
  1308. case of a host name/address mismatch. Otherwise, the front ends just
  1309. ignore the bad host name and use the host address when consulting the
  1310. access control files.
  1311. Minor enhancements:
  1312. -------------------
  1313. The host access control files now support more types of wild cards and
  1314. (optionally) allow the use of netgroup names. Netgroup support is
  1315. usually available on systems with NIS (formerly YP) software.
  1316. Related software:
  1317. -----------------
  1318. Versions of rshd and rlogind, hacked to report the remote user name as
  1319. well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z).
  1320. That archive also contains a tftpd source that logs the remote host
  1321. name (nice if you want to know who is interested in your /etc/passwd
  1322. file). All those programs have been tested only with SunOS >= 4.0.
  1323. Another way to manage access to tcp/ip services is illustrated by the
  1324. servers provided with the authutil package (comp.sources.unix volume
  1325. 22). This has the advantage that one will get the remote username from
  1326. any host supporting RFC 931 security. By installing the auth package
  1327. (same volume) one supports RFC 931 security too (but YOU WILL HAVE TO
  1328. BELIEVE WHAT THE REMOTE HOST TELLS YOU). Eventually one can start
  1329. cutting off unauthenticated connections. This is obviously a much more
  1330. advanced approach than what my front-end programs provide. The present
  1331. package is more suitable for those who lack the resources to install
  1332. anything that requires more than just renaming a couple of executables.
  1333. Configuration and installation (the easy way):
  1334. ----------------------------------------------
  1335. An advanced installation recipe is given lateron. The "easy way" recipe
  1336. requires no changes to existing software or configuration files.
  1337. If you don't run Ultrix, you don't need the miscd front-end program.
  1338. The Ultrix miscd daemon implements among others the SYSTAT service,
  1339. which pipes the output from the WHO command to standard output.
  1340. By default, connections are logged to the same place where the sendmail
  1341. log entries go. If connections should be logged elsewhere, adjust the
  1342. LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog
  1343. configuration file (usually, /etc/syslog.conf). Most Ultrix versions
  1344. do not provide this flexibility, though.
  1345. The tcpd program is intended for monitoring connections to the telnet,
  1346. finger, ftp, exec, rsh and rlogin services. Decide which services you
  1347. want to be monitored. Move the vendor-provided daemon programs to the
  1348. location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and
  1349. copy the tcpd front end to the locations where the vendor-provided
  1350. daemons used to be. That is, one copy of the tcpd front end for each
  1351. service that you want to monitor.
  1352. ---------------------------------------------------------------------------
  1353. AUTHD:
  1354. authd - authentication server daemon
  1355. tcpuid, tcpuname - find out which user owns a connection
  1356. authuser - remote authentication library
  1357. authd is an implementation of RFC 931, the Authentication Server under
  1358. BSD. RFC 931 provides the name of the user owning a TCP connection. This
  1359. helps network security: UNLESS TCP ITSELF IS COMPROMISED, it is
  1360. impossible to forge mail or news between computers supporting RFC 931.
  1361. It also BECOMES MUCH EASIER TO TRACE ATTACKERS than in the current,
  1362. largely anonymous, network. authd requires no changes to current code:
  1363. every connect() and accept() is authenticated automatically, with no
  1364. loss of efficiency.
  1365. tcpuid and tcpuname are the same program, but more suitable for local
  1366. use from the command line by a user or system administrator. They show
  1367. which local user created a given TCP connection.
  1368. authuser is a library encapsulating client use of RFC 931. It talks to a
  1369. remote Authentication Server to find out the username on the other side
  1370. of a given connection.
  1371. Only root can install authd. However, most current systems are insecure
  1372. enough that any user can run tcpuid and tcpuname. authuser is meant for
  1373. use by any program.
  1374. [...]
  1375. 2. Requirements
  1376. authd requires netstat, and it pokes around in several BSD-specific
  1377. kernel structures. It is not inherently portable code. Nevertheless, it
  1378. has been compiled under Ultrix, SunOS, and Convex UNIX, and it probably
  1379. doesn't take much work to get running under pretty much any BSD system.
  1380. authuser should compile and run without trouble on any BSD system.
  1381. You must be root to install authd. However, authd's sister utilities,
  1382. tcpuid and tcpuname, will probably work anyway if /dev/kmem is readable.
  1383. Any program can use the authuser library.
  1384. 3. How to configure authd
  1385. You can change CC or CCOPTS in Makefile if you want. If you want authd
  1386. to record connections through syslog at LOG_DEBUG, define -DUSE_SYSLOG
  1387. in the Makefile.
  1388. 5. How to install authd
  1389. If you don't have privileges, skip this part.
  1390. By default, authd, tcpuid, and tcpuname are installed in /etc,
  1391. authuser.o is installed as /usr/lib/libauthuser.a, authuser.h is
  1392. installed in /usr/include, authuser.3 is installed in /usr/man/man3,
  1393. and authd.8, tcpuid.8, and tcpuname.8 are installed in /usr/man/man8.
  1394. The binaries are installed setgid to group kmem. If you want to change
  1395. these defaults, edit INSTALL.
  1396. Then run INSTALL in a root shell; the script will check every action
  1397. with you before doing it.
  1398. To test tcpuname, make sure it is in your path, and run netstatuid. You
  1399. should get a report of all active network connections including
  1400. usernames.
  1401. To test authuser and authd, run ./test. You should get an ``everything
  1402. looks okay'' message.
  1403. 6. TODO list
  1404. fast multiple-connection version of tcpuid/tcpuname, like netstatuid?
  1405. should write a few notes on the exact security provided by rfc 931
  1406. authd - Authentication Server daemon authd is a daemon implement-
  1407. ing the RFC 931 Authentication Server protocol. It should be in-
  1408. voked by a network server, such as or for connections to TCP port
  1409. 113 (auth). The client host gives two numbers separated by a
  1410. comma. interprets the numbers as TCP port numbers for the local
  1411. and remote sides respectively of a TCP connection between this
  1412. host and the client host. It returns a line of the form local-
  1413. port, remoteport: USERID: UNIX: username where username is the
  1414. name of the user on this side of the specified connection. If
  1415. does not have an authentication entry for that connection, it re-
  1416. turns a line of the form localport, remoteport: ERROR: UNKNOWN-
  1417. ERROR. None. None known. authd version 3.01, February 7, 1991.
  1418. Placed into the public domain by Daniel J. Bernstein. Partially
  1419. inspired by code written by Vic Abell for ofiles. The authenti-
  1420. cation server is more secure than passwords in some ways, but
  1421. less secure than passwords in many ways. (It's certainly better
  1422. than no password at all---e.g., for mail or news.) It is not the
  1423. final solution. For an excellent discussion of security problems
  1424. within the TCP/IP protocol suite, see Steve Bellovin's article
  1425. ``Security Problems in the TCP/IP Protocol Suite.'' authtcp(1),
  1426. attachport(1), authuser(3), tcp(4), inetd(8) tcpuid - show the
  1427. user id that created a network connection tcpuid prints the
  1428. numeric user id of the user who created the network connection
  1429. specified by its arguments. Lots, none of which should happen if
  1430. the specified connection is valid. None known. tcpuid version
  1431. 3.01, February 7, 1991. Placed into the public domain by Daniel
  1432. J. Bernstein. Partially inspired by code written by Vic Abell
  1433. for ofiles. authd(8), tcpuname(8) tcpuname - show the user name
  1434. that created a network connection tcpuname prints the username of
  1435. nection is valid. None known. tcpuname version 3.01, February
  1436. 7, 1991. Placed into the public domain by Daniel J. Bernstein.
  1437. Partially inspired by code written by Vic Abell for ofiles.
  1438. authd(8), tcpuid(8)
  1439. ------------------------------------------------------------------------
  1440. OFILES:
  1441. ofiles - show owner of open file or network connection [ ] [ ] [
  1442. ] [ ] displays the owner, process identification (PID), type,
  1443. command and the number of the inode associated with an open in-
  1444. stance of a file or a network connection. An open file may be a
  1445. regular file, a file system or a directory; it is specified by
  1446. its path name. When the path name refers to a file system, will
  1447. display the owners of all open instances of files in the system.
  1448. An open network connection is specified by the kernel address of
  1449. its Protocol Control Block (PCB), as displayed by when its option
  1450. is specified. displays information about its usage if no options
  1451. are specified. This option selects verbose, debugging output.
  1452. This option may be used only on DYNIX hosts. It sets optional
  1453. name list and core file paths. is the path to the file from
  1454. which should obtain the addresses of kernel symbols, instead of
  1455. from is the path to the file from which should obtain the value
  1456. of kernel symbols, instead of from This option is useful for de-
  1457. bugging system crash dumps. This option specifies that the argu-
  1458. ments identify network connections by their hexadecimal, Protocol
  1459. Control Block (PCB) addresses. PCB addresses can be obtained via
  1460. the option of This option makes it possible to determine the lo-
  1461. cal processes that are using network connections in the LISTEN
  1462. through ESTABLISHED states. This option specifies that should
  1463. print process identifiers only - e. g., so that the output may be
  1464. piped to These are path names of files, directories and file sys-
  1465. tems; or, if the option has been specified, network connections,
  1466. identified by their hexadecimal Protocol Control Block (PCB) ad-
  1467. dresses. displays for each for file paths, an interpretation of
  1468. the type of name - file, directory or file system; for network
  1469. connections, the kernel address linkages, starting with the file
  1470. structure and proceeding through the socket structure and the In-
  1471. ternet Protocol Control Block (INPCB) structure to the PCB the
  1472. login name of the user of the process that has open the identif-
  1473. ier of the process that has open a file type explanation: if is
  1474. the current working directory of the process if is being used as
  1475. a regular file by the process, optionally followed by: if the
  1476. process has a shared lock on the file if the process has an ex-
  1477. clusive lock on the file if is the root directory of the process
  1478. if is a socket the file descriptor number, local to the process
  1479. the user command that opened the inode number of the file This
  1480. example shows the use of to discover the owner of the open, regu-
  1481. lar file,
  1482. % ofiles /usr/spool/lpd/lock
  1483. /usr/spool/lpd/lock
  1484. USER PID TYPE FD CMD INODE
  1485. root 110 file/x 3 lpd 26683
  1486. This example shows the use of and to identify the local endpoint
  1487. of the ``smtp'' network connection. The first column of output
  1488. from is the PCB address; it is used as the argument to along with
  1489. the option.
  1490. % netstat -aA | grep smtp
  1491. 80f6770c tcp 0 0 *.smtp *.* LISTEN
  1492. % ofiles -n 80f6770c
  1493. file 80102b64 of socket 80f6758c of INPCB 80f6780c of PCB 80f6770c
  1494. USER PID TYPE FD CMD
  1495. root 105 sock 5 sendmail
  1496. Errors are identified with messages on the standard error file.
  1497. returns a one (1) if any error was detected, including the
  1498. failure to locate any It returns a zero (0) if no errors were
  1499. detected and if it was able to display owner information about
  1500. all the specified can't identify SunOS 4.0 stream files, so it
  1501. doesn't follow their file structure pointers correctly when read-
  1502. ing their inodes. That results in the display of erroneous inode
  1503. numbers for stream files. The option limits its search to net-
  1504. work connections in the LISTEN through ESTABLISHED states. Since
  1505. reads kernel memory in its search for open files and network con-
  1506. nections, rapid changes in kernel memory may produce unsatisfac-
  1507. tory results. C. Spencer is the original author. Michael Ditto,
  1508. Tom Dunigan, Alexander Dupuy, Gary Nebbett and Richard Tobin con-
  1509. tributed. Michael Spitzer, Ray Moody, and Vik Lall of the Purdue
  1510. University Computing Center converted the program to a variety of
  1511. UNIX environments. Vic Abell of the Purdue University Computing
  1512. Center added the option. inode(5), mount(1), kill(1), tcp(4).
  1513. ----------------------------------------------------------------------
  1514. RARPD:
  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 */
  1562. OpenEthers()
  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. ------------------------------------------------------------------------------
  1577. Comments:
  1578. Q's:
  1579. Biblio:
  1580. CrossRef:
  1581. Code/shRef:
  1582. ==============================================================================
  1583. ------------------------------
  1584.  
  1585. Date: Fri, 24 Jan 92 21:27:27 -0700
  1586. Subject: hideum.pl
  1587.  
  1588. ==============================================================================
  1589. Section Name chapter.sec.version 00/00/00
  1590. unwho.pl toolbox.01.0 01/23/92
  1591. ------------------------------------------------------------------------------
  1592. DATA:
  1593. Here's a little program called "unwho" that deletes all entries for a
  1594. given 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;
  1598. open(UTMP,'+</etc/utmp');
  1599. @mo = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec);
  1600. while (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);
  1605. printf "%-9s%-8s%s %2d %02d:%02d %s\n",
  1606. $name,$line,$mo[$mon],$mday,$hour,$min,$host;
  1607. if ($name eq $unname) {
  1608. seek(UTMP,-36,1);
  1609. print UTMP pack('A8a8A16l', "","","",0);
  1610. seek(UTMP,0,1);
  1611. }
  1612. }
  1613. }
  1614. ------------------------------------------------------------------------------
  1615. Comments:
  1616. Q's:
  1617. Biblio:
  1618. CrossRef:
  1619. Code/shRef:
  1620. ==============================================================================
  1621.  
  1622. -------------------------------------
  1623.  
  1624. To join this group or have your thoughts in the next issue, please
  1625. send electronic mail to Tangent at the following address;
  1626.  
  1627. infohax
  1628.  
  1629. The views expressed in InfoHax Digest
  1630. are those of the individual authors only.
  1631.  
  1632. *********************
  1633. End of InfoHax Digest
  1634. *********************
  1635. [.nook] 27)
  1636.  
  1637.  
  1638. X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-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"
  1660. X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!