share/doc/smm/01.setup/5.t

   1 .\" Copyright (c) 1980, 1986, 1988, 1993 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. Neither the name of the University nor the names of its contributors
  13 .\"    may be used to endorse or promote products derived from this software
  14 .\"    without specific prior written permission.
  15 .\"
  16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\"     @(#)5.t 8.1 (Berkeley) 7/27/93
  29 .\" $FreeBSD: head/share/doc/smm/01.setup/5.t 263142 2014-03-14 03:07:51Z eadler $
  30 .\"
  31 .ds lq ``
  32 .ds rq ''
  33 .ds LH "Installing/Operating \*(4B
  34 .ds RH Network setup
  35 .ds CF \*(Dy
  36 .Sh 1 "Network setup"
  37 .PP
  38 \*(4B provides support for the standard Internet
  39 protocols IP, ICMP, TCP, and UDP.  These protocols may be used
  40 on top of a variety of hardware devices ranging from
  41 serial lines to local area network controllers
  42 for the Ethernet.  Network services are split between the
  43 kernel (communication protocols) and user programs (user
  44 services such as TELNET and FTP).  This section describes
  45 how to configure your system to use the Internet networking support.
  46 \*(4B also supports the Xerox Network Systems (NS) protocols.
  47 IDP and SPP are implemented in the kernel,
  48 and other protocols such as Courier run at the user level.
  49 \*(4B provides some support for the ISO OSI protocols CLNP
  50 TP4, and ESIS.  User level process
  51 complete the application protocols such as X.400 and X.500.
  52 .Sh 2 "System configuration"
  53 .PP
  54 To configure the kernel to include the Internet communication
  55 protocols, define the INET option.
  56 Xerox NS support is enabled with the NS option.
  57 ISO OSI support is enabled with the ISO option.
  58 In either case, include the pseudo-devices
  59 ``pty'', and ``loop'' in your machine's configuration
  60 file.
  61 The ``pty'' pseudo-device forces the pseudo terminal device driver
  62 to be configured into the system, see
  63 .Xr pty (4),
  64 while the ``loop'' pseudo-device forces inclusion of the software loopback
  65 interface driver.
  66 The loop driver is used in network testing
  67 and also by the error logging system.
  68 .PP
  69 If you are planning to use the Internet network facilities on a 10Mb/s
  70 Ethernet, the pseudo-device ``ether'' should also be included
  71 in the configuration; this forces inclusion of the Address Resolution
  72 Protocol module used in mapping between 48-bit Ethernet
  73 and 32-bit Internet addresses.
  74 .PP
  75 Before configuring the appropriate networking hardware, you should
  76 consult the manual pages in section 4 of the Programmer's Manual
  77 selecting the appropriate interfaces for your architecture.
  78 .PP
  79 All network interface drivers including the loopback interface,
  80 require that their host address(es) be defined at boot time.
  81 This is done with
  82 .Xr ifconfig (8)
  83 commands included in the
  84 .Pn /etc/netstart
  85 file.
  86 Interfaces that are able to dynamically deduce the host
  87 part of an address may check that the host part of the address is correct.
  88 The manual page for each network interface
  89 describes the method used to establish a host's address.
  90 .Xr Ifconfig (8)
  91 can also be used to set options for the interface at boot time.
  92 Options are set independently for each interface, and
  93 apply to all packets sent using that interface.
  94 Alternatively, translations for such hosts may be set in advance
  95 or ``published'' by a \*(4B host by use of the
  96 .Xr arp (8)
  97 command.
  98 Note that the use of trailer link-level is now negotiated between \*(4B hosts
  99 using ARP,
 100 and it is thus no longer necessary to disable the use of trailers
 101 with
 102 .Xr ifconfig .
 103 .PP
 104 The OSI equivalent to ARP is ESIS (End System to Intermediate System Routing
 105 Protocol); running this protocol is mandatory, however one can manually add
 106 translations for machines that do not participate by use of the
 107 .Xr route (8)
 108 command.
 109 Additional information is provided in the manual page describing
 110 .Xr ESIS (4).
 111 .Sh 2 "Local subnets"
 112 .PP
 113 In \*(4B the Internet support
 114 includes the notion of ``subnets''.  This is a mechanism
 115 by which multiple local networks may appears as a single Internet
 116 network to off-site hosts.  Subnetworks are useful because
 117 they allow a site to hide their local topology, requiring only a single
 118 route in external gateways;
 119 it also means that local network numbers may be locally administered.
 120 The standard describing this change in Internet addressing is RFC-950.
 121 .PP
 122 To set up local subnets one must first decide how the available
 123 address space (the Internet ``host part'' of the 32-bit address)
 124 is to be partitioned.
 125 Sites with a class A network
 126 number have a 24-bit host address space with which to work, sites with a
 127 class B network number have a 16-bit host address space, while sites with
 128 a class C network number have an 8-bit host address space\**.
 129 .FS
 130 If you are unfamiliar with the Internet addressing structure, consult
 131 ``Address Mappings'', Internet RFC-796, J. Postel; available from
 132 the Internet Network Information Center at SRI.
 133 .FE
 134 To define local subnets you must steal some bits
 135 from the local host address space for use in extending the network
 136 portion of the Internet address.  This reinterpretation of Internet
 137 addresses is done only for local networks; i.e. it is not visible
 138 to hosts off-site.  For example, if your site has a class B network
 139 number, hosts on this network have an Internet address that contains
 140 the network number, 16 bits, and the host number, another
 141 16 bits.  To define 254 local subnets, each
 142 possessing at most 255 hosts, 8 bits may be taken from the local part.
 143 (The use of subnets 0 and all-1's, 255 in this example, is discouraged
 144 to avoid confusion about broadcast addresses.)
 145 These new network
 146 numbers are then constructed by concatenating the original 16-bit network
 147 number with the extra 8 bits containing the local subnet number.
 148 .PP
 149 The existence of local subnets is communicated to the system at the time a
 150 network interface is configured with the
 151 .I netmask
 152 option to the
 153 .Xr ifconfig
 154 program.  A ``network mask'' is specified to define the
 155 portion of the Internet address that is to be considered the network part
 156 for that network.
 157 This mask normally contains the bits corresponding to the standard
 158 network part as well as the portion of the local part
 159 that has been assigned to subnets.
 160 If no mask is specified when the address is set,
 161 it will be set according to the class of the network.
 162 For example, at Berkeley (class B network 128.32) 8 bits
 163 of the local part have been reserved for defining subnets;
 164 consequently the
 165 .Pn /etc/netstart
 166 file contains lines of the form
 167 .DS
 168 .ft CW
 169 /sbin/ifconfig le0 netmask 0xffffff00 128.32.1.7
 170 .DE
 171 This specifies that for interface ``le0'', the upper 24 bits of
 172 the Internet address should be used in calculating network numbers
 173 (netmask 0xffffff00), and the interface's Internet address is
 174 ``128.32.1.7'' (host 7 on network 128.32.1).  Hosts \fIm\fP on
 175 sub-network \fIn\fP of this network would then have addresses of
 176 the form ``128.32.\fIn\fP.\fIm\fP'';  for example, host
 177 99 on network 129 would have an address ``128.32.129.99''.
 178 For hosts with multiple interfaces, the network mask should
 179 be set for each interface,
 180 although in practice only the mask of the first interface on each network
 181 is really used.
 182 .Sh 2 "Internet broadcast addresses"
 183 .PP
 184 The address defined as the broadcast address for Internet networks
 185 according to RFC-919 is the address with a host part of all 1's.
 186 The address used by 4.2BSD was the address with a host part of 0.
 187 \*(4B uses the standard broadcast address (all 1's) by default,
 188 but allows the broadcast address to be set (with
 189 .Xr ifconfig )
 190 for each interface.
 191 This allows networks consisting of both 4.2BSD, \*(Ps and \*(4B hosts
 192 to coexist while the upgrade process proceeds.
 193 In the presence of subnets, the broadcast address uses the subnet field
 194 as for normal host addresses, with the remaining host part set to 1's
 195 (or 0's, on a network that has not yet been converted).
 196 \*(4B hosts recognize and accept packets
 197 sent to the logical-network broadcast address as well as those sent
 198 to the subnet broadcast address, and when using an all-1's broadcast,
 199 also recognize and receive packets sent to host 0 as a broadcast.
 200 .Sh 2 "Routing"
 201 .PP
 202 If your environment allows access to networks not directly
 203 attached to your host you will need to set up routing information
 204 to allow packets to be properly routed.  Two schemes are
 205 supported by the system.  The first scheme
 206 employs a routing table management daemon.
 207 Optimally, you should use the routing daemon
 208 .Xr gated
 209 available from Cornell university.
 210 We use it on our systems and it works well,
 211 especially for multi-homed hosts using Serial Line IP (SLIP).
 212 Unfortunately, we were not able to obtain permission to
 213 include it on \*(4B.
 214 .PP
 215 If you do not wish to or cannot obtain
 216 .Xr gated ,
 217 the distribution does include
 218 .Xr routed (8)
 219 to maintain the system routing tables.  The routing daemon
 220 uses a variant of the Xerox Routing Information Protocol
 221 to maintain up to date routing tables in a cluster of local
 222 area networks.  By using the
 223 .Pn /etc/gateways
 224 file, the routing daemon can also be used to initialize static routes
 225 to distant networks (see the next section for further discussion).
 226 When the routing daemon is started up
 227 (usually from
 228 .Pn /etc/rc )
 229 it reads
 230 .Pn /etc/gateways
 231 if it exists and installs those routes defined there,
 232 then broadcasts on each local network
 233 to which the host is attached to find other instances of the routing
 234 daemon.  If any responses are received, the routing daemons
 235 cooperate in maintaining a globally consistent view of routing
 236 in the local environment.  This view can be extended to include
 237 remote sites also running the routing daemon by setting up suitable
 238 entries in
 239 .Pn /etc/gateways ;
 240 consult
 241 .Xr routed (8)
 242 for a more thorough discussion.
 243 .PP
 244 The second approach is to define a default or wildcard
 245 route to a smart
 246 gateway and depend on the gateway to provide ICMP routing
 247 redirect information to dynamically create a routing data
 248 base.  This is done by adding an entry of the form
 249 .DS
 250 .ft CW
 251 /sbin/route add default \fIsmart-gateway\fP 1
 252 .DE
 253 to
 254 .Pn /etc/netstart ;
 255 see
 256 .Xr route (8)
 257 for more information.  The default route
 258 will be used by the system as a ``last resort''
 259 in routing packets to their destination.  Assuming the gateway
 260 to which packets are directed is able to generate the proper
 261 routing redirect messages, the system will then add routing
 262 table entries based on the information supplied.  This approach
 263 has certain advantages over the routing daemon, but is
 264 unsuitable in an environment where there are only bridges (i.e.
 265 pseudo gateways that, for instance, do not generate routing
 266 redirect messages).  Further, if the
 267 smart gateway goes down there is no alternative, save manual
 268 alteration of the routing table entry, to maintaining service.
 269 .PP
 270 The system always listens, and processes, routing redirect
 271 information, so it is possible to combine both of the above
 272 facilities.  For example, the routing table management process
 273 might be used to maintain up to date information about routes
 274 to geographically local networks, while employing the wildcard
 275 routing techniques for ``distant'' networks.  The
 276 .Xr netstat (1)
 277 program may be used to display routing table contents as well
 278 as various routing oriented statistics.  For example,
 279 .DS
 280 \fB#\fP \fInetstat \-r\fP
 281 .DE
 282 will display the contents of the routing tables, while
 283 .DS
 284 \fB#\fP \fInetstat \-r \-s\fP
 285 .DE
 286 will show the number of routing table entries dynamically
 287 created as a result of routing redirect messages, etc.
 288 .Sh 2 "Use of \*(4B machines as gateways"
 289 .PP
 290 Several changes have been made in \*(4B in the area of gateway support
 291 (or packet forwarding, if one prefers).
 292 A new configuration option, GATEWAY, is used when configuring
 293 a machine to be used as a gateway.
 294 This option increases the size of the routing hash tables in the kernel.
 295 Unless configured with that option,
 296 hosts with only a single non-loopback interface never attempt
 297 to forward packets or to respond with ICMP error messages to misdirected
 298 packets.
 299 This change reduces the problems that may occur when different hosts
 300 on a network disagree on the network number or broadcast address.
 301 Another change is that \*(4B machines that forward packets back through
 302 the same interface on which they arrived
 303 will send ICMP redirects to the source host if it is on the same network.
 304 This improves the interaction of \*(4B gateways with hosts that configure
 305 their routes via default gateways and redirects.
 306 The generation of redirects may be disabled with the configuration option
 307 IPSENDREDIRECTS=0 or while the system is running by using the command:
 308 .DS
 309 .ft CW
 310 sysctl -w net.inet.ip.redirect=0
 311 .DE
 312 in environments where it may cause difficulties.
 313 .Sh 2 "Network databases"
 314 .PP
 315 Several data files are used by the network library routines
 316 and server programs.  Most of these files are host independent
 317 and updated only rarely.
 318 .br
 319 .ne 1i
 320 .TS
 321 lfC l l.
 322 File    Manual reference        Use
 323 _
 324 /etc/hosts      \fIhosts\fP\|(5)        local host names
 325 /etc/networks   \fInetworks\fP\|(5)     network names
 326 /etc/services   \fIservices\fP\|(5)     list of known services
 327 /etc/protocols  \fIprotocols\fP\|(5)    protocol names
 328 /etc/hosts.equiv        \fIrshd\fP\|(8) list of ``trusted'' hosts
 329 /etc/netstart   \fIrc\fP\|(8)   command script for initializing network
 330 /etc/rc \fIrc\fP\|(8)   command script for starting standard servers
 331 /etc/rc.local   \fIrc\fP\|(8)   command script for starting local servers
 332 /etc/ftpusers   \fIftpd\fP\|(8) list of ``unwelcome'' ftp users
 333 /etc/hosts.lpd  \fIlpd\fP\|(8)  list of hosts allowed to access printers
 334 /etc/inetd.conf \fIinetd\fP\|(8)        list of servers started by \fIinetd\fP
 335 .TE
 336 The files distributed are set up for Internet hosts.
 337 Local networks and hosts should be added to describe the local
 338 configuration; the Berkeley entries may serve as examples
 339 (see also the section on
 340 .Pn /etc/hosts ).
 341 Network numbers will have to be chosen for each Ethernet.
 342 For sites connected to the Internet,
 343 the normal channels should be used for allocation of network
 344 numbers (contact hostmaster@SRI-NIC.ARPA).
 345 For other sites,
 346 these could be chosen more or less arbitrarily,
 347 but it is generally better to request official numbers
 348 to avoid conversion if a connection to the Internet (or others on the Internet)
 349 is ever established.
 350 .Sh 3 "Network servers"
 351 .PP
 352 Most network servers are automatically started up at boot time
 353 by the command file
 354 .Pn /etc/rc
 355 or by the Internet daemon (see below).
 356 These include the following:
 357 .TS
 358 lfC l l.
 359 Program Server  Started by
 360 _
 361 /usr/sbin/syslogd       error logging server    \f(CW/etc/rc\fP
 362 /usr/sbin/named Internet name server    \f(CW/etc/rc\fP
 363 /sbin/routed    routing table management daemon \f(CW/etc/rc\fP
 364 /usr/sbin/rwhod system status daemon    \f(CW/etc/rc\fP
 365 /usr/sbin/timed time synchronization daemon     \f(CW/etc/rc\fP
 366 /usr/sbin/sendmail      SMTP server     \f(CW/etc/rc\fP
 367 /usr/libexec/rshd       shell server    inetd
 368 /usr/libexec/rexecd     exec server     inetd
 369 /usr/libexec/rlogind    login server    inetd
 370 /usr/libexec/telnetd    TELNET server   inetd
 371 /usr/libexec/ftpd       FTP server      inetd
 372 /usr/libexec/fingerd    Finger server   inetd
 373 /usr/libexec/tftpd      TFTP server     inetd
 374 .TE
 375 Consult the manual pages and accompanying documentation (particularly
 376 for named and sendmail) for details about their operation.
 377 .PP
 378 The use of
 379 .Xr routed
 380 and
 381 .Xr rwhod
 382 is controlled by shell
 383 variables set in
 384 .Pn /etc/netstart .
 385 By default,
 386 .Xr routed
 387 is used, but
 388 .Xr rwhod
 389 is not; they are enabled by setting the variables \fIroutedflags\fP and
 390 .Xr rwhod
 391 to strings other than ``NO.''
 392 The value of \fIroutedflags\fP provides host-specific options to
 393 .Xr routed .
 394 For example,
 395 .DS
 396 .ft CW
 397 routedflags=-q
 398 rwhod=NO
 399 .DE
 400 would run
 401 .Xr "routed -q"
 402 and would not run
 403 .Xr rwhod .
 404 .PP
 405 To have other network servers started as well,
 406 commands of the following sort should be placed in the site-dependent file
 407 .Pn /etc/rc.local .
 408 .DS
 409 .ft CW
 410 if [ -f /usr/sbin/timed ]; then
 411         /usr/sbin/timed & echo -n ' timed'                      >/dev/console
 412 f\&i
 413 .DE
 414 .Sh 3 "Internet daemon"
 415 .PP
 416 In \*(4B most of the servers for user-visible services are started up by a
 417 ``super server'', the Internet daemon.  The Internet
 418 daemon,
 419 .Pn /usr/sbin/inetd ,
 420 acts as a master server for
 421 programs specified in its configuration file,
 422 .Pn /etc/inetd.conf ,
 423 listening for service requests for these servers, and starting
 424 up the appropriate program whenever a request is received.
 425 The configuration file contains lines containing a service
 426 name (as found in
 427 .Pn /etc/services ),
 428 the type of socket the
 429 server expects (e.g. stream or dgram), the protocol to be
 430 used with the socket (as found in
 431 .Pn /etc/protocols ),
 432 whether to wait for each server to complete before starting up another,
 433 the user name by which the server should run, the server
 434 program's name, and at most five arguments to pass to the
 435 server program.
 436 Some trivial services are implemented internally in
 437 .Xr inetd ,
 438 and their servers are listed as ``internal.''
 439 For example, an entry for the file
 440 transfer protocol server would appear as
 441 .DS
 442 .ft CW
 443 ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd
 444 .DE
 445 Consult
 446 .Xr inetd (8)
 447 for more detail on the format of the configuration file
 448 and the operation of the Internet daemon.
 449 .Sh 3 "The \f(CW/etc/hosts.equiv\fP file"
 450 .PP
 451 The remote login and shell servers use an
 452 authentication scheme based on trusted hosts.  The
 453 .Pn hosts.equiv
 454 file contains a list of hosts that are considered trusted
 455 and, under a single administrative control.  When a user
 456 contacts a remote login or shell server requesting service,
 457 the client process passes the user's name and the official
 458 name of the host on which the client is located.  In the simple
 459 case, if the host's name is located in
 460 .Pn hosts.equiv
 461 and the user has an account on the server's machine, then service
 462 is rendered (i.e. the user is allowed to log in, or the command
 463 is executed).  Users may expand this ``equivalence'' of
 464 machines by installing a
 465 .Pn \&.rhosts
 466 file in their login directory.
 467 The root login is handled specially, bypassing the
 468 .Pn hosts.equiv
 469 file, and using only the
 470 .Pn /.rhosts
 471 file.
 472 .PP
 473 Thus, to create a class of equivalent machines, the
 474 .Pn hosts.equiv
 475 file should contain the \fIofficial\fP names for those machines.
 476 If you are running the name server, you may omit the domain part
 477 of the host name for machines in your local domain.
 478 For example, four machines on our local
 479 network are considered trusted, so the
 480 .Pn hosts.equiv
 481 file is of the form:
 482 .DS
 483 .ft CW
 484 vangogh.CS.Berkeley.EDU
 485 picasso.CS.Berkeley.EDU
 486 okeeffe.CS.Berkeley.EDU
 487 .DE
 488 .Sh 3 "The \f(CW/etc/ftpusers\fP file"
 489 .PP
 490 The FTP server included in the system provides support for an
 491 anonymous FTP account.  Because of the inherent security problems
 492 with such a facility you should read this section carefully if
 493 you consider providing such a service.
 494 .PP
 495 An anonymous account is enabled by creating a user
 496 .Xr ftp .
 497 When a client uses the anonymous account a
 498 .Xr chroot (2)
 499 system call is performed by the server to restrict the client
 500 from moving outside that part of the filesystem where the
 501 user ftp home directory is located.  Because a
 502 .Xr chroot
 503 call is used, certain programs and files used by the server
 504 process must be placed in the ftp home directory.
 505 Further, one must be
 506 sure that all directories and executable images are unwritable.
 507 The following directory setup is recommended.  The
 508 use of the
 509 .Xr awk
 510 commands to copy the
 511 .Pn /etc/passwd
 512 and
 513 .Pn /etc/group
 514 files are \fBSTRONGLY\fP recommended.
 515 .DS
 516 \fB#\fP \fIcd ~ftp\fP
 517 \fB#\fP \fIchmod 555 .; chown ftp .; chgrp ftp .\fP
 518 \fB#\fP \fImkdir bin etc pub\fP
 519 \fB#\fP \fIchown root bin etc\fP
 520 \fB#\fP \fIchmod 555 bin etc\fP
 521 \fB#\fP \fIchown ftp pub\fP
 522 \fB#\fP \fIchmod 777 pub\fP
 523 \fB#\fP \fIcd bin\fP
 524 \fB#\fP \fIcp /bin/sh /bin/ls .\fP
 525 \fB#\fP \fIchmod 111 sh ls\fP
 526 \fB#\fP \fIcd ../etc\fP
 527 \fB#\fP \fIawk -F: '{$2="*";print$1":"$2":"$3":"$4":"$5":"$6":"}' < /etc/passwd > passwd\fP
 528 \fB#\fP \fIawk -F: '{$2="*";print$1":"$2":"}' < /etc/group > group\fP
 529 \fB#\fP \fIchmod 444 passwd group\fP
 530 .DE
 531 When local users wish to place files in the anonymous
 532 area, they must be placed in a subdirectory.  In the
 533 setup here, the directory
 534 .Pn ~ftp/pub
 535 is used.
 536 .PP
 537 Aside from the problems of directory modes and such,
 538 the ftp server may provide a loophole for interlopers
 539 if certain user accounts are allowed.
 540 The file
 541 .Pn /etc/ftpusers
 542 is checked on each connection.
 543 If the requested user name is located in the file, the
 544 request for service is denied.  This file normally has
 545 the following names on our systems.
 546 .DS
 547 uucp
 548 root
 549 .DE
 550 Accounts without passwords need not be listed in this file as the ftp
 551 server will refuse service to these users.
 552 Accounts with nonstandard shells (any not listed in
 553 .Pn /etc/shells )
 554 will also be denied access via ftp.