In the trusted internal network model, the server is protecting traffic that originates from hosts inside a privately controlled network.
Before you begin
The following statements, concepts, and files are covered in the discussion of this model:
- IpFilterRule
- IpService
- IpGenericFilterAction
- References
- Groups
- Stack-specific IP security configuration file
- Common IP security configuration file
Figure 1 shows the trusted internal network portion of the security model network.
For this example, assume that the following requirements must be met to control traffic on the internal network:
- Give FTP access to an administrator from a host inside the internal network (9.1.1.2) to the secure server (9.1.1.1). Log any traffic that matches this traffic pattern.
- Allow web access (HTTP, port 80) to the secure server from any host on the internal network (9.1.1.0/24). Do not log any traffic that matches this traffic pattern.
- Deny all other traffic.
Procedure
Perform the following steps to meet these requirements and configure the trusted internal network model.
- Determine the number of zones to be protected. There is only one zone for this example, the internal network 9.1.1.0/24.
- For each zone, determine what services are allowed
and define an IpService block for each wanted service. Optionally,
assign a security class to all interfaces in each zone. There
are two services stated in the example requirements, HTTP and FTP.
The traffic is local to this host and, therefore, the routing is designated
as local. No forwarding of these services is allowed.
Because the entire internal network is defined in one zone, you can define a unique security class for the interface with address 9.1.1.1. For this example, the SECCLASS parameter of all internal network interfaces is assigned the arbitrary value of 1, which can be interpreted to mean a trusted network. If you specify the SecurityClass parameter in the IpService block, the related interface must be assigned the same value on the SECCLASS parameter of the LINK or INTERFACE statement in the TCP/IP profile. In this example, the traffic is allowed only over an interface with a SECCLASS parameter value of 1, presumed to be the interface connected to the internal network.
IpService { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 }Because normal FTP uses two well-known ports, two services are required, one for the control connection and one for the data connection:
IpService { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 1 }The InboundConnect keyword is used for services that are not allowed to initiate a TCP connection. The OutboundConnect keyword is used for services that are not allowed to receive a TCP connection request. If neither keyword is specified, either side can initiate a TCP connection.
- Determine the data endpoints to be protected. There
are two sets of data endpoints to be protected in this example, representing
the connection from the administrative machine, and all the other
hosts on the subnetwork:
Local Address of secure server: 9.1.1.1 Remote Address of administrative machine: 9.1.1.2 Local Address of secure server: 9.1.1.1 Remote Address of all hosts on internal network: 9.1.1.0/24 - Determine what level of security is needed between each set of data endpoints. In this example, only permit is required. Therefore, no IPSec information is needed. Because z/OS® IP security policy implicitly provides a default-deny policy, all other traffic is denied.
- Configure an IpGenericFilterAction statement for the level
of security (permit, deny, ipsec) that is required, including whether
the connection is logged. Because the example requirement
is to permit two types of traffic with different logging requirements,
two actions are needed as follows:
IpGenericFilterAction permit-log { IpFilterAction permit IpFilterLogging yes } IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no } - If IPSec is required between any two endpoints, configure a KeyExchangePolicy statement that defines the parameters of the phase 1 negotiation, configure an IpDynVpnAction statement that defines the control of the phase 2 negotiation, and decide how the Security Association is to be activated. IPSec is not required in this example. If there was sensitive data flowing through the internal network that needed to be confidential, IPSec could be specified to encrypt some IP packets, thereby effectively securing information that travels between two hosts on the internal network.
- Define an IpFilterRule block for each set of data endpoints. Each rule should include the services that are allowed (one
IpService statement for each allowed service), and the level of security
that is required (a reference to the IpGenericFilterAction statement).
If IPSec is required, create an IpFilterRule statement that allows
IKE traffic (UDP, port 500). If NAT traversal is allowed, create an
IpFilterRule statement that allows IKE UDP traffic on port 4500.
In this example, the source address refers to an address on the secure host. The destination address refers to remote hosts. The IpService statements are the ones defined in step 2. Note that the IpGenericFilterAction statement must reference a previously defined action.
IpFilterRule AdminFTP { IpSourceAddr 9.1.1.1 IpDestAddr 9.1.1.2 IpService { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 1 } IpGenericFilterActionRef permit-log } IpFilterRule InternalNetWeb { IpSourceAddr 9.1.1.1 IpDestAddrSet 9.1.1.0/24 IpService { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpGenericFilterActionRef permit-nolog } IpGenericFilterAction permit-log { IpFilterAction permit IpFilterLogging yes } IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no }Because IPSec is not required in this example, no filters for IKE traffic are needed.
- Include the IpFilterRule statements in the IpFilterPolicy
block. The IP filter rules and their relative placement
within the IpFilterPolicy block should be from most specific to least
specific. Because the AdminFTP rule controls traffic from a specific
host, it should be placed before the InternalNetWeb rule. Note that
to enable logging of the individual rules, filter logging must be
enabled at the global level of the IP filter policy with the FilterLogging
parameter.
IpFilterPolicy { FilterLogging on IpFilterRule AdminFTP { IpSourceAddr 9.1.1.1 IpDestAddr 9.1.1.2 IpService { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 1 } IpGenericFilterActionRef permit-log } IpFilterRule InternalNetWeb { IpSourceAddr 9.1.1.1 IpDestAddrSet 9.1.1.0/24 IpService WebServer { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpGenericFilterActionRef permit-nolog } } - Include all configured statements in the stack-specific
IP security configuration file. The IpFilterPolicy statement
and the IpGenericFilterAction statements are placed in the file in
no particular order, although the file is easier to read if logically
related items are placed close together. For further ease of reading
and maintenance, document the file with comments, which begin with
the number sign (#).
The completed stack-specific IP security configuration file for the internal network with two filter rules follows:
# IP Security policy for Secure Server ########################## # IpFilterPolicy block # ########################## IpFilterPolicy { FilterLogging on #Allow admin FTP; log traffic IpFilterRule AdminFTP { IpSourceAddr 9.1.1.1 IpDestAddr 9.1.1.2 IpService { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Routing local SecurityClass 1 Direction bidirectional OutboundConnect } IpGenericFilterActionRef permit-log } #Allow LAN Web traffic; don't log IpFilterRule InternalNetWeb { IpSourceAddr 9.1.1.1 IpDestAddrSet 9.1.1.0/24 IpService { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpGenericFilterActionRef permit-nolog } ############################ # Generic Filter Actions # ############################ IpGenericFilterAction permit-log { IpFilterAction permit IpFilterLogging yes } IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no } - Define an IP filter group for each zone, and include the
IP filter rules that belong to that zone. In step 9, both IpFilterRule statements include
a reference to statements defined outside of the IpFilterRule block,
the IpGenericFilterAction statements. Some other information, such
as IP addresses and services, is undoubtedly to be needed more than
once. Changing these occurrences to reference objects eliminates repeated
typing of the same information and adds clarity to the configuration
file. To take advantage of references, the reusable statements must
be given a name.
- Single IP addresses are defined by the IpAddr statement, which
contains one parameter, Addr:
IpAddr InternalNetServerAddress { Addr 9.1.1.1 { IpAddr InternalNetAdminAddress { Addr 9.1.1.2 } - Ranges or subnetworks are defined by the IpAddrSet statement,
which contains either a Range or Prefix attribute:
IpAddrSet InternalNet { Prefix 9.1.1.0/24 } - To be referenced, each IpService statement needs a name:
IpService WebServer { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService FTPServer-Control { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService FTPServer-Data { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 1 } - FTP is composed of two individual services, and both can be condensed
into an IpServiceGroup that references the two FTP services:
IpServiceGroup FTPServer { IpServiceRef FTPServer-Control IpServiceRef FTPServer-Data } - The IP filter rules can be grouped as well. Because the filter
rules that apply to the internal network naturally relate to each
other in the sense that they apply to the same security zone, they
can be combined into an IpFilterGroup statement:
IpFilterGroup InternalNetZoneA { IpFilterRef AdminFTP IpFilterRef InternalNetWeb }Notice that just as the list of IpFilterRule statements in the IpFilterPolicy block is ordered, the list of IpFilterRef statements in the IpFilterGroup block is also ordered. The InternalNetWeb rule applies to all of the IP addresses in the network, including the administrative machine. However, the AdminFTP rule is more specific because it applies only to a specific address within that network. The more specific rule is placed first in the list.
Now that all reusable statements have been identified and separately defined, they can be incorporated into any statement that requires that reusable statement type. The modified stack-specific IP security configuration file using references follows. Note that by adding names and organizing related statements, the purpose of the IpFilterPolicy statement is clarified.
# IP Security policy for Secure Server ########################## # IpFilterPolicy block # ########################## IpFilterPolicy { FilterLogging on IpFilterGroupRef InternalNetZoneA } ########################## # Security Zones # ########################## IpFilterGroup InternalNetZoneA { IpFilterRuleRef AdminFTP IpFilterRuleRef InternalNetWeb } ########################## # Filter rules # ########################## #Allow admin FTP; log traffic IpFilterRule AdminFTP { IpSourceAddrRef InternalNetServerAddress IpDestAddrRef InternalNetAdminAddress IpServiceGroupRef FTPServer IpGenericFilterActionRef permit-log } #Allow LAN Web traffic; don't log IpFilterRule InternalNetWeb { IpSourceAddrRef InternalNetServerAddress IpDestAddrSetRef InternalNet IpServiceRef WebServer IpGenericFilterActionRef permit-nolog } ######## All reusable reference statements defined below ######## ############################ # Generic Filter Actions # ############################ IpGenericFilterAction permit-log { IpFilterAction permit IpFilterLogging yes } IpGenericFilterAction permit-nolog { IpFilterAction permit IpFilterLogging no } ########################## # Reusable Services # ########################## IpService WebServer { SourcePortRange 80 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService FTPServer-Control { SourcePortRange 21 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional InboundConnect Routing local SecurityClass 1 } IpService FTPServer-Data { SourcePortRange 20 DestinationPortRange 1024 65535 Protocol tcp Direction bidirectional OutboundConnect Routing local SecurityClass 1 } ############################ # Reusable Service Groups # ############################ IpServiceGroup FTPServer { IpServiceRef FTPServer-Control IpServiceRef FTPServer-Data } ############################ # Reusable IP Addresses # ############################ IpAddr InternalNetServerAddress { Addr 9.1.1.1 } IpAddr InternalNetAdminAddress { Addr 9.1.1.2 } IpAddrSet InternalNet { Prefix 9.1.1.0/24 }This stack-specific IP security configuration file gives FTP access to the administrator and web access to everyone in the internal network. By relying heavily on the abstracted use of references, the policy is not only more self-explanatory, but changes to any referenced object are propagated to any statement that references it. So, if the IP address of the administrative machine or internal subnetwork changes, you merely have to make one change to an IpAddr or IpAddrSet statement, rather than modify a large number of instances in multiple rules.
- Single IP addresses are defined by the IpAddr statement, which
contains one parameter, Addr: