home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / 5720 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.1 KB
  1. Xref: sparky comp.protocols.tcp-ip:5720 comp.unix.bsd:10560
  2. Newsgroups: comp.protocols.tcp-ip,comp.unix.bsd
  3. Path: sparky!uunet!caen!mtu.edu!tony
  4. From: tony@mtu.edu (Tony Dal Santo)
  5. Subject: Re: Limiting Telnet access.
  6. Message-ID: <1992Dec22.183213.10002@mtu.edu>
  7. Organization: Michigan Technological University
  8. References: <1992Dec21.211508.9555@mtu.edu>
  9. Date: Tue, 22 Dec 1992 18:32:13 GMT
  10. Lines: 37
  11.  
  12. tony@mtu.edu (Tony Dal Santo) writes:
  13. >
  14. >Along these lines, I am curious if anyone has an idea how to allow
  15. >certain users access to the network, and deny others.  Something
  16. >like putting the user in group "network" to grant them access.  By
  17. >access, I mean system call level access like socket().  Even better
  18. >would be to provide a list of addresses/networks that are restricted/
  19. >allowed.
  20. >
  21. >I imagine with a streams implementation of tcp/ip, you could change
  22. >the perms on /dev/ip or /dev/tcp.
  23. >
  24. >Does anyone have any utilities for tracing a TCP port to a process number?
  25. >
  26. >Tony Dal Santo
  27. >tony@mtu.edu
  28.  
  29. Evidently I was not too clear since I have received a few pointers
  30. directing me to inetd wrappers.  I am interested in restricting/granting
  31. users access TO the network FROM my hosts.  I can restrict access to
  32. the binaries (telnet, ftp, etc), but this doesn't stop them from compiling
  33. their own copies of these utilities.  The only way I see to filter access
  34. is to control system calls like socket(), bind(), accept().  I can limit
  35. access to networks via routing tables, but this doesn't provide user-level
  36. granularity.
  37.  
  38. While inetd wrappers are nice, I don't see them addressing the problem.
  39. Once I get access to your machine, I will bring my own set of utilities
  40. with me (inetd), and avoid the administrators attempts at logging.
  41. Granted that some of the users "daemons" (e.g. ftpd) won't be as functional
  42. as the real ones because they don't run as root, but they will certainly
  43. let me gain access and avoid being logged.  Sure, as an administrator I
  44. can see these processes, and kill them off.  Then the users will restart
  45. them via cron(8) and at(1).  I don't have the time to play hide and seek
  46. with users.
  47.  
  48. Tony Dal Santo
  49.