Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 8

14 Using Firewall as a Service (FWaaS) Edit source

The Firewall as a Service (FWaaS) provides the ability to assign network-level, port security for all traffic entering and existing a tenant network. More information on this service can be found via the public OpenStack documentation located at http://specs.openstack.org/openstack/neutron-specs/specs/api/firewall_as_a_service__fwaas_.html. The following documentation provides command-line interface example instructions for configuring and testing a firewall. The Firewall as a Service can also be configured and managed by the Horizon web interface.

FWaaS is implemented directly in the L3 agent (neutron-l3-agent), however if VPNaaS is enabled, FWaaS is implemented in the VPNaaS agent (neutron-vpn-agent). Because FWaaS does not use a separate agent process or start a specific service, there currently are no Monasca alarms for it.

If DVR is enabled, the firewall service currently does not filter traffic between OpenStack private networks, also known as east-west traffic and will only filter traffic from external networks, also known as north-south traffic.

14.1 Prerequisites Edit source

SUSE OpenStack Cloud must be installed.

14.2 SUSE OpenStack Cloud 8 FWaaS Configuration Edit source

Check for an enabled firewall.

  1. You should check to determine if the firewall is enabled. The output of the neutron ext-list should contain a firewall entry.

    neutron ext-list
  2. Assuming the external network is already created by the admin, this command will show the external network.

    neutron net-list

Create required assets.

Before creating firewalls, you will need to create a network, subnet, router, security group rules, start an instance and assign it a floating IP address.

  1. Create the network, subnet and router.

    neutron net-create private
    neutron subnet-create --name sub private 10.0.0.0/24 --gateway 10.0.0.1
    neutron router-create router
    neutron router-interface-add router sub
    neutron router-gateway-set router ext-net
  2. Create security group rules. Security group rules filter traffic at VM level.

    neutron security-group-rule-create default --protocol icmp
    neutron security-group-rule-create default --protocol tcp --port-range-min 22 --port-range-max 22
    neutron security-group-rule-create default --protocol tcp --port-range-min 80 --port-range-max 80
  3. Boot a VM.

    NET=$(neutron net-list | awk '/private/ {print $2}')
    nova boot --flavor 1 --image <image> --nic net-id=$NET vm1 --poll
  4. Verify if the instance is ACTIVE and is assigned an IP address.

    nova list
  5. Get the port id of the vm1 instance.

    fixedip=$(nova list | awk '/vm1/ {print $12}' | awk -F '=' '{print $2}' | awk -F ',' '{print $1}')
    vmportuuid=$(neutron port-list | grep $fixedip | awk '{print $2}')
  6. Create and associate a floating IP address to the vm1 instance.

    neutron floatingip-create ext-net --port-id $vmportuuid
  7. Verify if the floating IP is assigned to the instance. The following command should show an assigned floating IP address from the external network range.

    nova show vm1
  8. Verify if the instance is reachable from the external network. SSH into the instance from a node in (or has route to) the external network.

    ssh cirros@FIP-VM1
    password: <password>

Create and attach the firewall.

Note
Note

By default, an internal "drop all" rule is enabled in IP tables if none of the defined rules match the real-time data packets.

  1. Create new firewall rules using firewall-rule-create command and providing the protocol, action (allow, deny, reject) and name for the new rule.

    Firewall actions provide rules in which data traffic can be handled. An allow rule will allow traffic to pass through the firewall, deny will stop and prevent data traffic from passing through the firewall and reject will reject the data traffic and return a destination-unreachable response. Using reject will speed up failure detection time dramatically for legitimate users, since they will not be required to wait for retransmission timeouts or submit retries. Some customers should stick with deny where prevention of port scanners and similar methods may be attempted by hostile attackers. Using deny will drop all of the packets, making it more difficult for malicious intent. The firewall action, deny is the default behavior.

    The example below demonstrates how to allow icmp and ssh while denying access to http. See the neutron command-line reference at http://docs.openstack.org/cli-reference/content/neutronclient_commands.html on additional options such as source IP, destination IP, source port and destination port.

    Note
    Note

    You can create a firewall rule with an identical name and each instance will have a unique id associated with the created rule, however for clarity purposes this is not recommended.

    neutron firewall-rule-create --protocol icmp --action allow --name allow-icmp
    neutron firewall-rule-create --protocol tcp --destination-port 80 --action deny --name deny-http
    neutron firewall-rule-create --protocol tcp --destination-port 22 --action allow --name allow-ssh
  2. Once the rules are created, create the firewall policy by using the firewall-policy-create command with the --firewall-rules option and rules to include in quotes, followed by the name of the new policy. The order of the rules is important.

    neutron firewall-policy-create --firewall-rules "allow-icmp deny-http allow-ssh" policy-fw
  3. Finish the firewall creation by using the firewall-create command, the policy name and the new name you want to give to your new firewall.

    neutron firewall-create policy-fw --name user-fw
  4. You can view the details of your new firewall by using the firewall-show command and the name of your firewall. This will verify that the status of the firewall is ACTIVE.

    neutron firewall-show user-fw

Verify the FWaaS is functional.

  1. Since allow-icmp firewall rule is set you can ping the floating IP address of the instance from the external network.

    ping <FIP-VM1>
  2. Similarly, you can connect via ssh to the instance due to the allow-ssh firewall rule.

    ssh cirros@<FIP-VM1>
    password: <password>
  3. Run a web server on vm1 instance that listens over port 80, accepts requests and sends a WELCOME response.

    $ vi webserv.sh
    
    #!/bin/bash
    
    MYIP=$(/sbin/ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print $1}');
    while true; do
      echo -e "HTTP/1.0 200 OK
    
    Welcome to $MYIP" | sudo nc -l -p 80
    done
    
    # Give it Exec rights
    $ chmod 755 webserv.sh
    
    # Execute the script
    $ ./webserv.sh
  4. You should expect to see curl fail over port 80 because of the deny-http firewall rule. If curl succeeds, the firewall is not blocking incoming http requests.

    curl -vvv <FIP-VM1>
Warning
Warning

When using reference implementation, new networks, FIPs and routers created after the Firewall creation will not be automatically updated with firewall rules. Thus, execute the firewall-update command by passing the current and new router Ids such that the rules are reconfigured across all the routers (both current and new).

For example if router-1 is created before and router-2 is created after the firewall creation

$ neutron firewall-update —router <router-1-id> —router <router-2-id> <firewall-name>

14.3 More Information Edit source

Firewalls are based in IPtable settings.

Each firewall that is created is known as an instance.

A firewall instance can be deployed on selected project routers. If no specific project router is selected, a firewall instance is automatically applied to all project routers.

Only 1 firewall instance can be applied to a project router.

Only 1 firewall policy can be applied to a firewall instance.

Multiple firewall rules can be added and applied to a firewall policy.

Firewall rules can be shared across different projects via the Share API flag.

Firewall rules supersede the Security Group rules that are applied at the Instance level for all traffic entering or leaving a private, project network.

For more information on the neutron command-line interface (CLI) and firewalls, see the OpenStack networking command-line client reference: http://docs.openstack.org/cli-reference/content/neutronclient_commands.html