To see all my blog posts on IP filtering see here.
I have not configured the rules for a z/OS system, but from my experience of TCP/IP I can see some of the challenges, I hope this section gives you some help in planning your configuration
High level view
There are two approaches to locking down.
- Default: allow everything, deny access to specific sites
- Default: deny access. Specifically grant access to sites.
The second approach is better. If you “allow everything” by default and deny access to one IP address, the bad guys could use a different address not covered by your rules. If you deny access by default, and only allow the sites you want to use, it makes it harder for the bad guys.
What do I need to think about when planning rules?
From a planning perspective you need to consider several areas
- The IP addresses of z/OS
- The ports used by applications on z/OS
- The IP addresses of client applications connecting to z/OS
- The ports of used by the clients.
- Whether to allow or deny access to the resource.
The configuration hierarchy
Information to help you plan your configuration.
A request allowed to pass into z/OS, will usually need a rule to allow the response to return to the requester, flowing out of z/OS. When planning my configuration, in my (paper) notebook, I had a page for requesters to z/OS, and another page for responses, and made sure they tied up.
- Filter actions: deny|approve
- Which server IP addresses? Can you create groups of IP addresses which can be reused by different filter rules, for example all LPARS, and all TCP Home addresses for each LPAR
- Which client IP addresses? Can you create groups of IP addresses which can be reused by different filter rules? For example by country.
- Within these,
- Which ports , protocols (TCP/IP,icmp) and direction (inbound or outbound).
What actions should I configure?
There will be some events that will occur, business as usual traffic, which are not interesting, so you would define these so they are not logged.
Other events, such as from new client addresses, are interesting, and you should log these. Once you have put the new rules in place, you can then make them so they are not logged.
I think there are only four actions you should configure when starting to configure IP filtering.
- IpGenericFilterActionRef permitlog
- IpGenericFilterActionRef permitnolog
- IpGenericFilterActionRef denylog
- IpGenericFilterActionRef denynolog
Where the permitlog entry is defined as
IpGenericFilterAction permitlog
{
IpFilterAction permit
IpFilterLogging yes
}
and the other filter actions are similar.
I tend to define a rule with permitlog, deploy it, then once it works, change it to permitnolog, and redeploy it, and check the event is not logged -if it is still logged; fix the rule!
You can have “deny” send back an icmp response saying “not allowed due to administrator”. See use of DiscardAction to send an icmp response back.
Background to z/OS IP Addresses
My laptop has a wireless connection, and an Ethernet connection to my server. Each of these interfaces has multiple IP address assigned to it (one IP V4 and multiple IPV6). In a similar way on z/OS each interface (think cable connected into z/OS) has an IP address. For example the TSO NETSTAT HOME command on my system gives me
IntfName: ETH1
Address: 10.1.1.2
Flags: Primary
IntfName: ETH2
Address: 192.168.1.74
Flags:
To the outside world my z/OS has two interfaces ETH1 with IP address 10.1.1.2, and ETH2 with IP address 192.168.1.74.
You might have one interface which is for external facing connections, and another interface for your internal traffic.
For availability and capacity reasons you may have multiple interfaces per LPAR for internal traffic, and similarly for external traffic.
You may have multiple z/OS images and traffic can be routed to any of them. If you want to use global definitions (available to all systems) you need to include all home IP addresses across all interfaces across all z/OS images.
You also have IP V4, and IPV6.
z/OS addresses
You need to identify the IP addresses for those connections coming into z/OS, and the IP addresses of the z/OS systems. The number of z/OS systems should be limited, so you could define a group with the IP addresses of all your z/OS home addresses, across all LPARs.
z/OS ports
For applications running on z/OS, they will typically use one, or a few ports. For example a web server may have a port for TLS connections, and another port for unprotected connections.
If you wanted to gradually remove non TLS connections to your web server, you could create a rule, and say these IP addresses (from this office/area) can no longer use the unprotected port, and so gradually migrate every one to use the TLS connection.
You have to configure the ports inline – you cannot define them once, and refer to them, as you can with IP addresses
Client IP Addresses
Often the client will only have one address, think of wireless connected laptops. It may have a static address, the value of which is always the same, or it may get a dynamic IP address, which is “leased” the duration of the session. For example a DHCP address.
Dynamic addresses may be within a subnet, so for a particular DHCP server, the addresses may be within the range 10.4.5.0-10.4.5.255.
With my Wireless and Ethernet connections, most of the time my system uses the Ethernet connection. If I unplug this, then the wireless connection is used. With this, a client could have multiple addresses into z/OS, and you may need to cover all of them. You could configure it to accept data over my (ultra secure) direct wired Ethernet, but not over the wireless connection, or allow traffic only from a work location, and not from elsewhere.
Client IP port
A server usually has an allocated (well known) IP port. A client application typically uses bind() with port=0) and will then be assigned an unused port from the dynamic range. It can be given a reserved port.
With some products such as MQ Clients you can specify a port range which the application can use. This sort of application typically loops trying ports in the specified range until it finds a free port. You could use this to predefine a range of ports which you can then use IP Filtering to restrict the allowable range.
Baby steps for ICMP
Put your specific rules in front of your generic rules.
You could (I would not) configure rules
IpFilterRule icmpall
{
IpSourceAddr all
IpDestAddr all
IpGenericFilterActionRef permitnolog
IpService
{
Protocol icmp
Direction inbound
Routing local
}
}
IpFilterRule icmpspecific
{
IpSourceAddr 10.1.0.2
IpDestAddr all
IpGenericFilterActionRef permitlog
IpService
{
Protocol icmp
Direction inbound
Routing local
}
}
IpGenericFilterAction permitlog
{
IpFilterAction permit
IpFilterLogging yes
}
IpGenericFilterAction permitnolog
{
IpFilterAction permit
IpFilterLogging no
}
If IpFilterRule icmpall is before IpFilterRule icmpspecific the action for all is taken from icmpall; is permit and no log for all traffic – which maybe not what you want.
If these rules are swapped round, so the specific rule is first; traffic for 10.1.0.2 would get permit+log, and other traffic would get permit and no log.
You can then look in the logs to see the traffic, for example
EZD0814I Packet permitted: 12/04/2023 17:18:41.17 filter
rule= icmpinspecific ext= sipaddr= 10.1.0.2 dipaddr=10.1.1.2
proto= icmp(1) type= 8 code= 0 -= Interface=10.1.1.2 (I) secclass= 255 dest= local len= 84 vpnaction= N/A tunnelID= N/A ifcname= ETH1 fragment= N
From the information in the logs, you can refine your rules.
Testing the definitions
You can test your definitions (once you have deployed them) to see what rule is used for source and target IP addresses. See Testing the rules.
ColinPaice 