In the following example, an instance named WEB1 will be created that acts as a web server running Apache on ports 80 and 443. To demonstrate how security group rules are implemented on a compute node, take note of the following WEB_SERVERS security group created with the Neutron security-group-create command:
Figure 6.3
The following screenshot shows two security group rules being added to the WEB_SERVERS security group using the security-group-rule-create command. The rules allow inbound connections on ports 80 and 443 from any remote host:
Figure 6.4
Using the Neutron port-update command, the WEB_SERVERS security group can be applied to the Neutron port of the WEB1 instance, as shown in the following screenshot:
Figure 6.5
Once a security group is applied to the corresponding Neutron port of an instance, a series of iptables rules and chains are implemented on the compute node hosting the instance.
The implementation of security group rules using iptables is similar in both LinuxBridge- and Open vSwitch-based environments. On compute02, which is a compute node running the LinuxBridge agent and hosting the instance, the iptables rules can be observed using the iptables-save command. For readability, only the filter table is shown in the following screenshot and some comments have been removed or truncated to fit the page:
Figure 6.6
Network traffic to or from an instance will first traverse the FORWARD chain, as follows:
-A FORWARD -j neutron-filter-top -A FORWARD -j neutron-linuxbri-FORWARD
The first rule causes iptables to jump to the neutron-filter-top chain for further processing:
-A neutron-filter-top -j neutron-linuxbri-local
From here, iptables jumps to the neutron-linuxbri-local chain for further processing. As there are no rules defined in this chain, iptables returns to the calling chain, neutron-filter-top. Once all rules are processed, iptables returns to the previous calling chain, FORWARD.
The next rule in the FORWARD chain that is processed is as follows:
-A FORWARD -j neutron-linuxbri-FORWARD
The mentioned rule causes iptables to jump to the neutron-linuxbri-FORWARD chain, as follows:
Figure 6.7
The -m flag, followed by physdev, is a directive to iptables to use an extended packet matching a module that supports the devices enslaved to a bridge device.
The packet will match one of the two rules based on the direction that the packet is heading through the interface. In either case, iptables jumps to the neutron-linuxbri-sg-chain chain, as follows:
Figure 6.8
The direction of the packet will again dictate which rule is matched. Traffic entering the instance through the tap6d7340c8-b1 interface will be processed by the neutron-linuxbri-i6d7340c8-b chain, as follows:
Figure 6.9
In the mentioned rule, iptables uses the state module to determine the state of the packet. Combined with connection tracking, iptables is able to track the connection and determine the states of the packet—whether it is INVALID, NEW, RELATED, or ESTABLISHED. The state of the packet results in an appropriate action being taken. The -s flag instructs iptables to match the source address of the packet against the address defined in the rule. The UDP rule allows for inbound DHCP response traffic from the DHCP server at 10.30.0.2/32. Traffic not matched by any rule is dropped by the neutron-linuxbri-sg-fallback chain, as follows:
-A neutron-linuxbri-sg-fallback -j DROP
Traffic exiting the instance through the tap6d7340c8-b1 interface is processed by the neutron-linuxbri-o6d7340c8-b chain, as follows:
Figure 6.10
The first UDP rule allows the instance to send the DHCPDISCOVER and DHCPREQUEST broadcast packets on UDP port 67. All other traffic is then processed by the neutron-linuxbri-s6d7340c8-b chain, as follows:
Figure 6.11
The preceding rule prevents an instance from performing IP and MAC address spoofing. Any traffic exiting the tap6d7340c8-b1 interface must be sourced from 10.30.0.3/32 and the MAC address, FA:16:3E:A4:C3:F9. To permit traffic from additional IP or MAC addresses, use the Neutron allowed-address-pairs extension, as discussed in Chapter 5, Creating Networks with Neutron.
When traffic is returned to the calling chain, the next UDP rule prohibits the instance from acting as a rogue DHCP server, as shown in the following screenshot:
Figure 6.12
Further processing includes verifying the state of the packet and performing the appropriate action. Traffic eventually returns to the neutron-linuxbri-sg-chain calling chain, where it is allowed through, as follows:
-A neutron-linuxbri-sg-chain -j ACCEPT