Steps for verifying IP security policy or defensive filter enforcement

Verify IP security policy or defensive filter enforcement.

Before you begin

Complete the steps in Steps for verifying IP security and defensive filter operation in order to identify the name of an IpFilterRule or IPSECRULE or IPSEC6RULE for which IP security policy enforcement is to be verified or the name of a defensive filter.

About this task

Figure 1 shows the decisions involved for verifying IP security policy enforcement.

Figure 1. Overview of verifying IP security policy enforcement
Overview of verifying IP security policy enforcement that shows the decisions involved for verifying IP security policy enforcement.

Procedure

Perform the following steps:

  1. Start TRMD for the stack if it is not already active. The Traffic Regulation Management Daemon (TRMD) is required to log IP filter permits and denies. See z/OS Communications Server: IP Configuration Reference for information about starting TRMD.
  2. Display the identified filter rule using the ipsec -f display -n command if it is an IP security filter. Display the identified filter rule using the ipsec -f display -N command if it is a defensive filter. Use the instructions in the following lists to temporarily activate logging for the filter if it is not already active. See z/OS Communications Server: IP Configuration Reference for information about the IpFilterPolicy, IpFilterRule, IpGenericFilterAction, IPSEC, IPSECRULE, and IPSEC6RULE statements.
    • If the ipsec command header output indicates Stack Policy, do the following:
      • If the ipsec command header output indicates Logging NO, temporarily specify FilterLogging On on the IpFilterPolicy statement. If you are using the IBM® Configuration Assistant for z/OS® Communications Server to configure, select Enable filter logging on the IPSec: Stack Level Settings panel.
      • If the displayed filter Logging field is not ALL, specify IpFilterLogging Yes on the IpGenericFilterAction referenced by the IpFilterRule. If you are using the IBM Configuration Assistant for z/OS Communications Server to configure, set filter logging to Yes in each Connectivity Rule.
      • Use the MODIFY command with the Policy Agent to activate your changes, if any. See z/OS Communications Server: IP System Administrator's Commands for more detailed information about the MODIFY command.
    • If the ipsec command header output indicates Stack Profile, do the following:
      • If the ipsec command header output indicates Logging NO, specify LOGENABLE on the IPSEC statement.
      • If the displayed filter Logging field does not indicate ALL, specify LOG on the IPSECRULE or IPSEC6RULE statement.
      • Use the VARY TCPIP,,OBEYFILE command to activate your changes, if any.
  3. After IP filter logging is active, check the syslog to determine whether the IP traffic that is characterized by the filter rule is being permitted or denied. Message EZD0814I is issued when an IP packet is permitted. Message EZD0815I, EZD0821I, EZD0832I, EZD0822I, EZD0833I, or EZD1721I is issued when an IP packet is denied. If the traffic is denied, proceed to step 7. Otherwise, proceed to step 4.
  4. If the IP traffic is being permitted, but you do not want that, correct the filter configuration. See z/OS Communications Server: IP Configuration Guide for information about configuring IP filtering.
  5. Determine whether the IP traffic is subject to IPSec protection by locating the vpnaction field in the EZD0814I message. If the vpnaction field is not N/A then the IP traffic is subject to IPSec protection. If IPSec protection is not applied, then proceed to step 8. Otherwise, proceed to step 6.
  6. Determine the properties of the IPSec tunnel by first locating the tunnelID field in the EZD0814I message. Apply the following criteria to evaluate the tunnelID:
    • If the first character of the tunnelID is M, use the ipsec -m display -a command to display the corresponding manual tunnel. If the displayed manual tunnel does not have the characteristics that you want, correct the IpManVpnAction statement. See z/OS Communications Server: IP Configuration Reference for information about the IpManVpnAction statement.

      If you are using the IBM Configuration Assistant for z/OS Communications Server to configure, the IpManVpnAction corresponds to a Security Level implementing Manual Tunnels. If Security Level does not contain the characteristics that you want, correct the Security Level. See the Configuration Assistant online help for additional information.

    • If the first character of the tunnelID is Y, use the ipsec -y display -a command to display the corresponding dynamic tunnel. If the displayed dynamic tunnel does not have the characteristics that you want, correct the IpDynVpnAction statement. See z/OS Communications Server: IP Configuration Reference for information about the IpDynVpnAction statement.

      If you are using the IBM Configuration Assistant for z/OS Communications Server to configure, the IpDynVpnAction corresponds to a Security Level implementing dynamic tunnels. If Security Level does not contain the characteristics that you want, correct the Security Level. See the Configuration Assistant online help for additional information.

  7. Data traffic cannot be initiated to the remote data endpoint in certain cases when NAT traversal support is being used. Message EZD0832I is issued when an attempt is made to initiate data traffic if either of these conditions is true:
    • The remote security endpoint is acting as a security gateway and a NAT was detected between the local security endpoint and the remote security endpoint.
    • The remote security endpoint is behind a NAT device performing port translation

    If not the "cannot initiate case" message, proceed to 9.

  8. If the IP traffic is not being protected with IPSec, but you want IPSec protection, correct the filter configuration. See z/OS Communications Server: IP Configuration Guide for information about configuring IP filtering.
    Tips:
    • If you defined a filter rule for this traffic but packets are matching a different filter rule, consider whether your filter rules are ordered correctly. The filter table is searched in sequential order, so it is possible that a filter rule earlier in the table is overshadowing a filter rule later in the table.
    • If you defined a filter rule for this traffic and packets are matching your filter rule, consider whether you defined the right policy action for the filter rule. You can choose an action of deny, permit, or IPSec protection, with further options for IPSec protection.
  9. If the IP traffic is being denied, determine what type of filter is denying the traffic.
    If the IP traffic is being denied by a defensive filter, message EZD1721I is issued.
    • Determine the user that added the defensive filter by locating the "EZD1723I Defensive filter added" message that corresponds to the deny message. The userid of the user that added the filter is included in message EZD1723I.
    • Delete the defensive filter if it is denying traffic that should be permitted. Use the ipsec -F delete command to delete a defensive filter. See z/OS Communications Server: IP System Administrator's Commands for information about the ipsec command.

    If the IP traffic is being denied by an IP security filter, correct the filter configuration to change this situation. See z/OS Communications Server: IP Configuration Guide for information about configuring IP filtering.

    Tips:
    • If you defined a filter rule for this traffic but packets are matching a different filter rule, consider whether your filter rules are ordered correctly. The filter table is searched in sequential order, so it is possible that a filter rule earlier in the table is overshadowing a filter rule later in the table.
    • If you change the order of two filter rules that employ dynamic IPSec protection, consider whether a similar change is necessary in your key exchange policy. For more information about the ordering of key exchange policy rules, see z/OS Communications Server: IP Configuration Guide.
    • If you defined a filter rule for this traffic and packets are matching your filter rule, consider whether you defined the right policy action for the filter rule. You can choose an action of deny, permit, or IPSec protection, with further options for IPSec protection.