AIX > Administrator > Security

The PowerSC Virtual Networking Firewall

IBM Power Systems servers provide the capability to perform virtual networking between logical partitions (LPARs) running on the same physical server. This design results in faster communications between LPARs, since network traffic isn't required to exit and then route back into the server. However, because inter-LPAR network traffic doesn't pass through traditional firewalls, use of virtual networking also presents a security challenge. To address this challenge, IBM’s PowerSC security and compliance solution provides a trusted firewall module.

PowerSC provides solutions that enhance the security of both the AIX operating system and the Power Systems server virtualized environment. It's available in both Entry and Standard editions, which offer various combinations of these PowerSC modules:

•	security and compliance automation
•	realtime compliance
•	trusted boot
•	trusted firewall
•	trusted logging
•	trusted network connect and patch management
•	trusted surveyor (separate offering)

This article focuses on the trusted firewall module, which is included with the PowerSC Standard Edition offering.

A Look at PowerSC Trusted Firewall

The PowerSC trusted firewall is a layer 3 router. It's installed as a device drive extension to the virtual I/O (VIO) server. This extension is called a secure virtual machine (SVM). Trusted firewall filter rules are maintained in a table and loaded into the SVM driver. The trusted firewall routes virtual traffic that passes through one or more shared Ethernet adapters (SEAs) configured on the same VIO server.

Note that the trusted firewall does not route network traffic that flows either in/out of the physical network connection, or between LPARs on the same VLAN and vSwitch. This traffic flows directly between LPARs via the hypervisor and doesn't even require the presence of a VIO server.

Trusted Firewall Commands

Trusted firewall operation commands and filter rules are managed through the restricted shell execution environment on the VIO server. Operational commands include:

•	$ mksvm				Install SVM on the VIO server.
•	$ rmdev –dev svm		Remove SVM from the VIO server.
•	$ vlantfw –s		Start the SVM.
•	$ vlanfw –t		Stop the SVM.
•	$ vlanfw –q		Query SVM operational status.
•	$ vlanfw –d		Display network interface mapping table.

When the trusted firewall is running, the query command returns TFW=True and capability=4. When it's stopped, the query command returns TFW=False and capability=0. The mapping tables list the VLAN ID, SEA (PVID), IP address and MAC address for each network interface associated with the VIO server. Firewall rules are configured using these commands:

•	$ genvfilt 		Creates a filter rule.
•	$ lsvfilt 		Lists all filter rules.
•	$ chvfilt –n <fid>	Changes a filter rule.
•	$ rmvfilt –n <fid>	Remove a single filter rule.
•	$ rmvfilt –n all	Removes all filter rules.

A suggested best practice is to put all of your filter rules in a data file. This makes it easier to view and maintain the filter rules. To apply these filter rules, you could write a script to do the following:

•	First, remove all filter rules to clear out the SVM using the rmvfilt command.
•	Then, read each filter rule from the data file and apply it to the SVM using the genvfilt command.

This process helps ensure that the operational firewall filter rules in the SVM are accurate and complete. If you need to modify any of the filter rules, you would edit the data file and rerun the script.

Firewall Filter Rules

Each filter rule must specify specific source and destination VLAN IDs. Filter rules can also specify any combination of IP address, port and service type (udp, tcp, etc.). Rules set for VLANs and IP addresses allow bidirectional traffic to flow. Port and service type filter rules allow flow in only one direction: source to destination. If you want traffic to flow in both directions, you’ll need to specify a second rule for the opposite direction. For any options not specified in a filter rule, all traffic will flow for that particular option. For example, if you specific Port=20 but don't specify any IP addresses, Port 20 will be open for all IP addresses between the source and destination VLANs. For each filter rule you must specify:

•	-v_ 	IP version (4 or 6)
•	-a  	action (P=permit, D=deny)
•	-z 	source VLAN
•	-Z 	destination VLAN

And optionally, you can specify:

•	-s	source IP
•	-d	destination IP
•	-p	source port
•	-P	destination port
•	-O	destination operation (udp, tcp, icmp, icmp6, any)

You can also use these range qualifiers: lt, gt, eq, any. A simple IP filter rule might look like:

	$ genvfilt –v4 –a P –z 100 –Z 200 –s –d

This rule sets up a bidirectional traffic flow from a source to destination IP address as follows:

•	-v4			using IPv4
•	-z 100			source VLAN is 100
•	-z 200			destination VLAN is 200
•	-s		source IP address
•	-d		destination IP address

Securing Your Virtual Networks

The PowerSC trusted firewall attaches to the VIO server kernel as a device driver. Only one trusted firewall is permitted per VIO server. Filter rules are only applied to traffic that flows through the virtual side of an SEA. Traffic that flows in/out of the physical network interface is not filtered, nor is traffic that flows on the same VLAN between LPARs. For dual VIO server implementations where adapter failover capabilities are configured (via AIX or SEA failover), the filter rules should be applied to both VIO servers. Also, if you're using live partition mobility (LPM), you’ll need to consider firewall requirements for LPARs that are being migrated. Filter rules aren't specifically associated with LPARs and they won't be passed along to a destination server when using LPM.

For firewall protection without PowerSC, Power Systems administrators must configure inter-LPAR traffic to exit and reenter the server so that it can pass through a physical firewall. Implementation of the PowerSC trusted firewall allows you to continue to make use of high speed inter-LPAR communications with the benefit of firewall protection, eliminating the need for network traffic to exit the server.

Charlie Cler supports customers in a solutions-architect role at Forsythe Technology Inc. He can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Hardening the Cloud

Security considerations to protect your organization

Verify System Integrity

AIX 6.1 and Trusted Execution help ensure secure systems

A Bankable Solution

AIX Cryptographic Services improves security while simplifying administration

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters