home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / unix / portmap.sha / README < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.4 KB  |  170 lines
  1. @(#) README 1.2 92/07/06 19:53:25
  2.  
  3. Description
  4. -----------
  5.  
  6. This is a portmapper replacement with access control in the style of
  7. the tcp wrapper (log_tcp) package.  It provides a simple mechanism to
  8. discourage access to the NIS (YP), NFS, and other services registered
  9. with the portmapper. 
  10.  
  11. In some cases, better or equivalent alternatives are available: 
  12.  
  13.     The SunOS portmap that is provided with patch id 100482-02 should
  14.     close the same security holes.  In addition, it provides NIS
  15.     daemons with their own access control lists. This is better than
  16.     just portmapper access control.
  17.  
  18.     The "securelib" shared library (eecs.nwu.edu:/pub/securelib.tar)
  19.     implements access control for all kinds of (RPC) services, not
  20.     just the portmapper.
  21.  
  22.     Reportedly, Irix 4.0.x already has a secured portmapper.
  23.  
  24. However, many vendors still ship portmap implementations that allow
  25. anyone to read or modify its tables and that will happily forward any
  26. request so that it appears to come from the local system.
  27.  
  28. Features
  29. --------
  30.  
  31. - optional: host access control. The local host is always considered
  32. authorized. This feature requires the libwrap.a library that comes with
  33. recent tcp wrapper (log_tcp) implementations.
  34.  
  35. - requests to change the portmap tables are accepted only when they
  36. come from the local system.
  37.  
  38. - optional: requests to (un)register services on privileged ports (port
  39. < 1024) are accepted only when they come from a privileged port. This
  40. feature is optional because some RPC implementations still run all RPC
  41. daemons of an unprivileged port.  Bug your vendor if your RPC is like
  42. that.
  43.  
  44. - requests that are forwarded by the portmapper will be forwarded
  45. through an unprivileged port.
  46.  
  47. - the portmapper refuses to forward requests to rpc daemons that do (or
  48. should) verify the origin of the request: at present, the list includes
  49. most of the calls to the NFS mountd/nfsd daemons and the NIS daemons.
  50.  
  51. Restrictions
  52. ------------
  53.  
  54. Limiting access to the portmapper does not protect you from direct
  55. attacks on the rpc daemons; the main task of portmap is to maintain a
  56. table of available RPC services and the network ports that they are
  57. listening on. The securelib can be used to protect individual RPC
  58. daemons, and the latest SunOS portmap+NIS fix already protects the NIS
  59. daemons and implements limited forwarding.
  60.  
  61. On the other hand, even though a portmapper with access control only
  62. makes an attack more difficult, it still provides an excellent early
  63. warning system.
  64.  
  65. Origin and portability
  66. ----------------------
  67.  
  68. The sources in this distribution are derived from code on the second
  69. BSD networking tape, which was derived from Sun's RPCSRC 4.0 code, and
  70. from Sun's TIRPC (transport-independent rpc) distribution. 
  71.  
  72. The code compiles fine with SunOS 4.1.1, Ultrix 4.x and ESIX System V
  73. release 4.0, but I expect it will work with many other UNIX flavours.
  74. Tested with SunOS 4.1.1; an earlier version was also tested with Ultrix
  75. 3.0.  If anyone can get this thing working with SYSV4 let me know; it
  76. didn't with ESIX.
  77.  
  78. Installation
  79. ------------
  80.  
  81. (1) Follow the instructions in the Makefile, then build the portmap and
  82. auxiliary executables.
  83.  
  84. (2) Before killing the present portmap process, save the present
  85. portmapper tables using the command:
  86.  
  87.     ./pmap_dump >table
  88.  
  89. If you kill the portmap process without saving its tables you will have
  90. to reboot the machine.
  91.  
  92. Note: the information in the portmap tables is dynamic: For example, it
  93. will be different after each reboot. On a Sun, it even changes each
  94. time a windowing system is started that uses the selection service.
  95.  
  96. (3) Kill the running portmap process and start the new portmap
  97. program.  Then (still as root) initialize the portmap tables with:
  98.  
  99.     ./pmap_set <table
  100.  
  101. (4) If you get error messages of the form: "not registered: xxxx",
  102. disable the CHECK_PORT feature in the Makefile, remove pmap_check.o and
  103. rebuild the portmap program.  Then proceed with step 3.
  104.  
  105. In order to revert to the original portmap daemon, kill off the running
  106. one, restart the original one and reload its tables using the
  107. "pmap_set" command as shown above.
  108.  
  109. Suggested entries for the host access-control files are:
  110.  
  111.     /etc/hosts.allow:
  112.     portmap: your.sub.net.number/your.sub.net.mask
  113.     portmap: 255.255.255.255 0.0.0.0
  114.  
  115.     /etc/hosts.deny
  116.     portmap: ALL: (finger -l @%h | mail root) &
  117.  
  118. The syntax of the access-control files is described in the
  119. hosts_access.5 manual page that comes with the tcp wrapper (log_tcp)
  120. sources. The second line in the hosts.allow file may be needed if
  121. there are PC-NFS systems on your network segment.
  122.  
  123. For security reasons, the portmap process does not run as root. The
  124. access control files should therefore be group readable.
  125.  
  126. In order to avoid deadlocks, the portmap program does not attempt to
  127. look up the remote host name, nor will it try to match NIS netgroups.
  128. If you do not want to accept requests from everyone on your subnet you
  129. will have to enumerate the addresses of authorised hosts.  There is no
  130. need to specify the local system: since it runs the portmap daemon, it
  131. is authorized by definition.
  132.  
  133. Testing:
  134. --------
  135.  
  136. Normally, only rejected requests will be reported via the syslog
  137. daemon.  Logging is done in a child process, in order to avoid
  138. possible deadlock in case the logging code needs assistance from
  139. the portmapper.
  140.  
  141. By default, the portmapper will be utterly silent. In fact, the portmap
  142. daemon is not consulted that often. Sending a SIGINT signal to the
  143. portmap process will enable the logging of all requests. 
  144.  
  145. Warning:  with some systems, such as HP-UX, the logging code needs
  146. assistance from the portmapper. If verbose logging is on, these calls
  147. for assistance will also be logged, so that you end up with a system
  148. full of portmap processes.
  149.  
  150. With verbose logging turned on, requests such as "ypcat" or "rpcinfo
  151. -p" should show up with log file entries such as:
  152.  
  153.  MMM dd hh:mm:ss hostname portmap[pid]: connect from x.x.x.x to getport(ypserv)
  154.  MMM dd hh:mm:ss hostname portmap[pid]: connect from y.y.y.y to dump()    
  155.  
  156. Send another SIGINT to the portmapper to turn the verbose logging off.
  157.  
  158. Acknowledgements
  159. ----------------
  160.  
  161. Casper H.S. Dik (casper@fwi.uva.nl) provided lots of valuable
  162. information on RPC security and tested an intermediate version of the
  163. portmapper with SunOS 4.1.2.  Lyford D. Rich (rich@ece.nps.navy.mil)
  164. was helpful with porting the daemon to Ultrix 3.0.
  165.  
  166.     Wietse Venema (wietse@wzv.win.tue.nl)
  167.     Mathematics and Computing Science
  168.     Eindhoven University of Technology
  169.     The Netherlands
  170.