The Netperm-Table File

This file controls who can access the services of the TIS FWTK. You should think about the traffic using the firewall from both sides. People outside your network should identify themselves before gaining access, but the people inside your network might be allowed to just pass through.

So people can identify themselves, the firewall uses a program called authsrv to keep a database of user IDs and passwords. The authentication section of the netperm-table controls where the database is keep and who can access it.

I had some trouble closing the access to this service. Note the premit-hosts line I show uses a '*' to give everyone access. The correct setting for this line is '' authsrv: premit-hosts localhost if you can get it working.

  #
  # Proxy configuration table
  #
  # Authentication server and client rules
  authsrv:      database /usr/local/etc/fw-authdb
  authsrv:      permit-hosts *
  authsrv:      badsleep 1200
  authsrv:      nobogus true
  # Client Applications using the Authentication server
  *:            authserver 127.0.0.1 114

To initialize the database, su to root, and run ./authsrv in the /var/local/etc directory to create the administrative user record. Here is a sample session.

Read the FWTK documentation to learn how to add users and groups.

    #
    # authsrv
    authsrv# list
    authsrv# adduser admin "Auth DB admin"
    ok - user added initially disabled
    authsrv# ena admin
    enabled
    authsrv# proto admin pass
    changed
    authsrv# pass admin "plugh"
    Password changed.
    authsrv# superwiz admin
    set wizard
    authsrv# list
    Report for users in database
    user   group  longname           ok?    proto   last
    ------ ------ ------------------ -----  ------  -----
    admin         Auth DB admin      ena    passw   never
    authsrv# display admin
    Report for user admin (Auth DB admin)
    Authentication protocol: password
    Flags: WIZARD
    authsrv# ^D
    EOT
    #

The telnet gateway (tn-gw) controls are straight forward and the first you should set up.

In my example, I permit host from inside the private network to pass through without authenticating themselves. (permit-hosts 19961.2.* -passok) But, any other user must enter their user ID and password to use the proxy. (permit-hosts * -auth)

I also allow one other system (192.1.2.202) to access the firewall directly without going through the firewall at all. The two inetacl-in.telnetd lines do this. I will explain how these lines are called latter.

The Telnet timeout should be keep short.

  # telnet gateway rules:
  tn-gw:                denial-msg      /usr/local/etc/tn-deny.txt
  tn-gw:                welcome-msg     /usr/local/etc/tn-welcome.txt
  tn-gw:                help-msg        /usr/local/etc/tn-help.txt
  tn-gw:                timeout 90
  tn-gw:                permit-hosts 192.1.2.* -passok -xok
  tn-gw:                permit-hosts * -auth
  # Only the Administrator can telnet directly to the Firewall via Port 24
  netacl-in.telnetd: permit-hosts 192.1.2.202 -exec /usr/sbin/in.telnetd

The r-commands work the same way as telnet.

  # rlogin gateway rules:
  rlogin-gw:    denial-msg      /usr/local/etc/rlogin-deny.txt
  rlogin-gw:    welcome-msg     /usr/local/etc/rlogin-welcome.txt
  rlogin-gw:    help-msg        /usr/local/etc/rlogin-help.txt
  rlogin-gw:    timeout 90
  rlogin-gw:    permit-hosts 192.1.2.* -passok -xok
  rlogin-gw:    permit-hosts * -auth -xok
  # Only the Administrator can telnet directly to the Firewall via Port
  netacl-rlogind: permit-hosts 192.1.2.202 -exec /usr/libexec/rlogind -a

You shouldn't have anyone accessing your firewall directly and that includes FTP so don't put an FTP, server on you firewall.

Again, the permit-hosts line allows anyone in the protected network free access to the Internet and all others must authenticate themselves. I included logging of every file sent and received to my controls. (-log { retr stor })

The ftp timeout controls how long it will take to drop a bad connections as well as how long a connection will stay open with out activity.

  # ftp gateway rules:
  ftp-gw:               denial-msg      /usr/local/etc/ftp-deny.txt
  ftp-gw:               welcome-msg     /usr/local/etc/ftp-welcome.txt
  ftp-gw:               help-msg        /usr/local/etc/ftp-help.txt
  ftp-gw:               timeout 300
  ftp-gw:               permit-hosts 192.1.2.* -log { retr stor }
  ftp-gw:               permit-hosts * -authall -log { retr stor }

Web, gopher and browser based ftp are contorted by the http-gw. The first two lines create a directory to store ftp and web documents as they are passing through the firewall. I make these files owned by root and put the in a directory accessible only by root.

The Web connection should be kept short. It controls how long the user will wait on a bad connections.

  # www and gopher gateway rules:
  http-gw:      userid          root
  http-gw:      directory       /jail
  http-gw:      timeout 90
  http-gw:      default-httpd   www.afs.net
  http-gw:      hosts           192.1.2.* -log { read write ftp }
  http-gw:      deny-hosts      *

The ssl-gw is really just a pass anything gateway. Be carefully with it. In this example I allow anyone inside the protected network to connect to any server outside the network except the addresses 127.0.0.* and 192.1.1.* and then only on ports 443 through 563. Ports 443 through 563 are known SSL ports.

  # ssl gateway rules:
  ssl-gw:         timeout 300
  ssl-gw:         hosts           192.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
  ssl-gw:         deny-hosts      *

Here is an example of how to use the plug-gw to allow connections to a news server. In this example I allow anyone inside the protected network to connect to only one system and only to it's news port.

The seconded line allows the news server to pass its data back to the protected network.

Because most clients expect to stay connected while the user read news, the timeout for a news server should be long.

  # NetNews Pluged gateway
  plug-gw:        timeout 3600
  plug-gw: port nntp 192.1.2.* -plug-to 24.94.1.22 -port nntp
  plug-gw: port nntp 24.94.1.22 -plug-to 192.1.2.* -port nntp

The finger gateway is simple. Anyone inside the protected network must login first and then we allow them to use the finger program on the firewall. Anyone else just gets a message.

  # Enable finger service
  netacl-fingerd: permit-hosts 192.1.2.* -exec /usr/libexec/fingerd
  netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt

I haven't setup the Mail and X-windows services so I'm not including examples. If anyone has a working example, please send me email.