• No results found

Securing your TCP/IP environment

There are steps you can take to reduce the security exposures in the TCP/IP environment on your system.

These tips apply to your entire TCP/IP environment rather than to the specific applications that are discussed in the next topics:

v When you write an application for a TCP/IP port, make sure that the application is properly secure. You should assume that an outsider well try to access that application through that port. A

knowledgeable outsider can attempt to TELNET to that application.

v Monitor the use of TCP/IP ports on your system. A user application that is associated with a TCP/IP port can provide “back-door” entry to your system without a user ID or a password. Someone with sufficient authority on your system can associate an application with a TCP or UDP port.

v As a security administrator, you should be aware of a technique called IP spoofing that is used by hackers. Every system in a TCP/IP network has an IP address. Someone who uses IP spoofing sets up a system (typically a PC) to pretend to be an existing IP address or a trusted IP address. Thus, the imposter can establish a connection with your system by pretending to be a system that you normally connect with.

If you run TCP/IP on your system and your system participates in a network that is not physically protected, such as all nonswitched lines and predefined links, you are vulnerable to IP spoofing. To protect your system from damage by a “spoofer,” start with the suggestions in this chapter, for example, sign-on protection and object security. You should also ensure that your system has

reasonable auxiliary storage limits set. This prevents a spoofer from flooding your system with mail or spooled files to the point that your system becomes inoperable. In addition, you should regularly monitor TCP/IP activity on your system. If you detect IP spoofing, you can try to discover the weak points in your TCP/IP setup and to make adjustments.

For your intranet, your company's private network of systems that do not need to connect directly to the outside, use IP addresses that are reusable. Reusable addresses are intended for use within a private network. The Internet backbone does not route packets that have a reusable IP address. Therefore, reusable addresses provide an added layer of protection inside your firewall. TCP/IP Setup provides more information about how IP addresses are assigned and about the ranges of IP addresses, as well as security information about TCP/IP.

Controlling which TCP/IP servers start automatically:

As security administrator, you need to control which TCP/IP applications start automatically when you start TCP/IP.

Commands for starting and ending TCP/IP and servers

Two commands are available for starting TCP/IP. For each command, the system uses a different method to determine which applications or servers to start.

STRTCP Start TCP/IP

The default behavior of starting TCP/IP is to start every server that specifies AUTOSTART(*YES). This behavior is controlled by the Start application servers (STRSVR) parameter of the STRTCP command. Security recommendations:

v Assign *IOSYSCFG special authority carefully to control who can change the autostart settings. v Carefully control who has authority to use the STRTCP command. The default public authority for

the command is *EXCLUDE.

v Set up object auditing for the Change TCP/IP Server (CHGTCPSVR) and any server-specific commands (such as CHGTELNA) to monitor users who attempt to change the AUTOSTART value for a server.

ENDTCP End TCP/IP

Ending TCP/IP causes all TCP/IP communications and servers to end. Security recommendations: v Carefully control who has authority to use the ENDTCP command. The default public authority for

the command is *EXCLUDE.

v Prevent the accidental ending of TCP/IP, by using the ENDTCP confirmation support. Either add the QIBM_ENDTCP_CONFIRM environment variable and set it to 'Y' or use the change command default (CHGCMDDFT) command: CHGCMDDFT CMD(ENDTCP) NEWDFT(’CONFIRM(*YES)’)

| | | | | | | | | | | | | | | |

STRTCPSVR Start TCP/IP Server

A parameter is used to specify which servers to start. The shipped default for this parameter is to start all servers. Security recommendations:

v Use the Change Command Default (CHGCMDDFT) command to set up the STRTCPSVR command to start only a specific server, which does not prevent users from starting other servers. However, by changing the command default, it is less likely users will start all servers by accident. For example, use the following command to set the default to start only the TELNET server: CHGCMDDFT CMD(STRTCPSVR) NEWDFT(’SERVER(*TELNET)’)

Note: When you change the default value, you can specify only a single server. Choose either a server that you use regularly or a server that is least likely to cause security exposures, such as trivial file transfer protocol (TFTP).

v Carefully control who has authority to use the STRTCPSVR command. The default public authority for the command is *EXCLUDE.

Table 29. System startup values worksheet

Server Default value Your value

Telnet AUTOSTART(*YES)

FTP (file transfer protocol) AUTOSTART(*YES) BOOTP (bootstrap protocol) AUTOSTART(*NO) TFTP (trivial file transfer protocol AUTOSTART(*NO) REXEC (remote EXECution server) AUTOSTART(*NO)

RouteD (route daemon) AUTOSTART(*NO)

SMTP (simple mail transfer protocol) AUTOSTART(*YES) POP (post office protocol) AUTOSTART(*NO) HTTP (hypertext transfer protocol)1

AUTOSTART(*NO) LPD (line printer daemon) AUTOSTART(*YES) SNMP (simple network management

protocol)

AUTOSTART(*YES) DNS (domain name system) AUTOSTART(*NO) DHCP (dynamic host configuration

protocol)

AUTOSTART(*NO)

INETD AUTOSTART(*NO)

1. With the IBM HTTP Server, you use the CHGHTTPA command to set the AUTOSTART value.

Note: Refer to the Start TCP/IP Server (STRTCPSVR) command for a complete list of system-supplied servers.

In addition to the system-supplied servers, it is also possible to add user-defined servers to the list of servers that can be auto-started. User-defined servers are managed using the Add TCP/IP Server, Change TCP/IP Server, and Remove TCP/IP Server command. Carefully control who has authority to these commands since they are shipped with a default public authority of *USE. Carefully consider controlling the End TCP/IP Server command even though it is shipped with a default public authority of

*EXCLUDE. | | | | | | | |

Monitoring TCP/IP processing:

System-supplied TCP/IP server jobs typically run in the QSYSWRK subsystem. However, user-defined TCP/IP servers can run in the QUSRWRK subsystem or even in application provided subsystems. If you have user-defined servers running on your system, be aware of the subsystems and other system

resources that they use.

If you suspect that someone is starting or ending TCP/IP or servers unnecessarily, you can set up object auditing on the appropriate TCP/IP or server-related command. The system writes an audit journal entry whenever a user runs the command.