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