Security considerations for limiting TCP/IP roaming

If your system is connected to a network, you may want to limit your users’ ability to roam the network with TCP/IP applications.

One way to do this is to restrict access to the following client TCP/IP commands:
Note: These commands might exist in several libraries on your system. They are in both the QSYS library and the QTCP library, at a minimum. Be sure to locate and secure all occurrences.
  • STRTCPFTP
  • FTP
  • STRTCPTELN
  • TELNET
  • LPR
  • SNDTCPSPLF
  • RUNRMTCMD (REXEC client)
Your users’ possible destinations are determined by the following factors:
  • Entries in your TCP/IP host table.
  • *DFTROUTE entry in the TCP/IP route table. This allows users to enter the IP address of the next-hop system when their destination is an unknown network. A user can reach or contact a remote network by using the default route.
  • Remote name server configuration. This support allows another server in the network to locate host names for your users.
  • Remote system table.
You need to control who can add entries to these tables and change your configuration. You also need to understand the implications of your table entries and your configuration.
Be aware that a knowledgeable user with access to an ILE C compiler can create a socket program capable of attaching to a TCP or UDP port. You can make this more difficult by restricting access to these socket interface files in the QSYSINC library:
  • SYS
  • NETINET
  • H
  • ARPA
  • Sockets and SSL
For service programs, you can restrict use of socket and SSL applications that are already compiled by restricting use of these service programs:
  • QSOSRV1
  • QSOSRV2
  • QSOSSLSR(SSL)
The service programs are shipped with public authority *USE, but the authority can be changed to *EXCLUDE, or another value as needed.