Part 2 of firewall rules with VNS3 

Check out part 1 for all the overview parts.

Quick review:

VNS3 Firewall features are controlled using IPTables syntax. For more information see http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http:// www.thegeekstuff.com/2011/06/iptables-rules-examples/

The order of rules matter.

If your customer rules don’t reject a packet, it will be allowed by default. However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.

NATing:

Network address translator (NAT) can act as an intermediary agent on behalf of clients. The real originating IP address might be masked from the server receiving a request. A common practice is to have a NAT mask a large number of devices in a private network. Only the “outside” interface(s) of the NAT needs to have an Internet-routable address.

Firewall Rules – NAT

Most public clouds now provide VLAN isolation, a critical element of the defense in depth security approach. VLAN isolation also creates the need for additional capabilities beyond the basic compute and networking functions for application owners.

“NATing” allows the machines in a VLAN to use the VNS3 Controller as a gateway to services on the Internet, with all VLAN machines sharing the Controller’s public IP address.

NATing in public cloud uses the same behavior used in your home or office, where many devices can access the Internet via one shared public IP address. When a VLAN device accesses the Internet, its return traffic is routed to it.

Basically, VNS3 lets you use your cloud VLAN just like you treat your home or office network, isolated from inbound requests for service, but allowing most outbound service requests.

Simple Syntax

MACRO_CUST -o eth0 -s 172.31.1.0/24 -j MASQUERADE

In this example your VNS3 Controller is in a VLAN subnet with a network from 172.31.1.0-172.31.1.255. Many clouds with VLAN capabilities map a public IP to the private IP on eth0 via DNS.

Here we are telling the VNS3 Controller to “masquerade” for traffic coming from that subnet out to the Internet and then return the response packets to the requesting machine.

Firewall Rules – Port Forwarding

With AWS VPC, your can configure your cloud servers to not be visible and accessible from the Internet. AWS assigns a standard, automatically-assigned public IP , but we do not recommend relying on the automatic IP because you will not retain the same IP address if you shut down the instance. Rather, you should assign an Elastic IP to put the server on the Internet.

What if you want to be able to access one of the machines (for example like you might do on your home network) from the Internet? This is where port forwarding comes in.

A common use case would be using a Windows Remote Desktop on one of your cloud servers, as the “jump” box for then remoting to all the other cloud servers in your VPC. VNS3 lets you do this with your VPC, just like you could for your home or office network, allowing specific traffic, from a specific source, on a specific port to be “forwarded” on to another machine.

Simple Syntax

MACRO_CUST -o eth0 -s 10.199.1.0/24 -j MASQUERADE

Using the same example network, assuming a source network public IP of 69.69.70.70 from which the RDP client is running, do the following:

• NATing needs to be enabled for port forwarding to work
• Specify the port to be forwarded, in this case “RDP” or 3389
• Specify the source network address, here 69.69.70.70/32
• Specify the machine for port 3389 traffic, here 10.199.1.130 using the “–to” syntax
• Use the “-j DNAT” syntax to specify destination network address translation.

Firewall Rules – Netmapping

Netmapping allows you to create IPsec tunnels to imaginary IPs on the VNS3 side of the connection and use the VNS3 firewall to map all traffic to/from the imaginary IP, to the actual host on your cloud side. This is extremely useful in situations where a connecting party has an address overlap with your Overlay or VLAN subnet.

Example

Remote subnet 10.10.10.0/24
Local Server the Remote wants to access: 172.31.10.50
Customer will not connect their LAN (10.10.10.0/24) to a private network Allocate an EIP to your account but DON’T associate: 23.23.23.23.
Build an IPsec the tunnel from 23.23.23.23/32 to 10.10.10.0/24

Simple Syntax:

PREROUTING_CUST -i eth0 -s 10.10.10.0/24 -d 23.23.23.23/32 -j NETMAP –to 172.31.10.50/32
POSTROUTING_CUST -o eth0 -s 172.31.10.50/32 -d 10.10.10.0/24 -j NETMAP –to 23.23.23.23/32

If the Local Subnet is a VLAN and not the Overlay Subnet add the following forward rule:

FORWARD_CUST -j ACCEPT

Copy Traffic to a Device

With the addition of the Docker-powered application container system there are scenarios where you might want to push a copy of the traffic from the eth0 or tun0 VNS3 interface to a particular IP. The obvious use-case is copying traffic to the Cohesive Utilities Container where you can do things like run tcpdump or iftop.

Example:
I want to copy all tun0 (Overlay Network) traffic to my Network Utils Container running on the VNS3 Controller on the Docker network at 172.0.10.2.

Simple Syntax:

MACRO_CUST -j COPY —from tun0 —to 172.0.10.2 —bidirectional

SNMP Support

VNS3 now supports a number of industry standard MIBs for use from monitoring system doing SNMP polling. We do not currently support any SNMP traps.

VNS3 SNMP support is enabled through the firewall. In the future we will provide API calls and user interface to provide more control of the SNMP experience.

To enable access to the SNMP information add the following rule to firewall using a source address from your network (either your public IP, or an internal IP available to the Controller via IPsec or Clientpack). There is no SNMP authentication in this beta. An example rule would be

INPUT_CUST -p udp -s 69.69.70.70/32 –dport snmp -j ACCEPT

(where 69.69.70.70 is your network’s public IP address).

On your SNMP monitoring system:

• Use SNMP v1c or v2
• Community string of “vns3public”
• The access to the SNMP information is “read only”

You should then be able to use a utility like “snmpwalk” to test:

snmpwalk -v 1 -c vns3public -O e <vns3_manager_public_ip>

Want to see something cool? Let’s add 10,000 firewall rules at once!

If you have trouble with the video player below, watch the video on YouTube: https://youtu.be/N-c3GyGP6qk

This is part 1 of an overview of firewall rules and capabilities with VNS3. Stay tuned for more advanced VNS3 firewall scenarios: Network Address Translation (NAT-ing), Port Forwarding, Netmapping, SNMP Support, and Copying Traffic to a Device.

A Super fast Firewall Overview

Firewall = network security system that monitors and controls the incoming and outgoing network traffic based on a set of security rules.

Firewalls act as a barrier between a trusted, secure network and another network, like the public Internet

2 Types of Firewalls:

• network firewalls: protect the perimeter of a network by watching traffic that enters and leaves
• host-based firewalls: protect individual devices regardless of the broader network

IP addresses and firewalls

You can use a firewall to control access to a server or network, or to selectively tailor a client’s response to each request for criteria.

Firewalls examine each packet in TCP/IP traffic. Firewalls determine whether to drop packets or forward packets to the destination. Packets contain 3 key sections: IP header, TCP / UDP header, and data (payload).

NAT Firewalls, IP address translation, and NAT-ing

Network address translator (NAT) can act as an intermediary agent on behalf of clients. The real originating IP address might be masked from the server receiving a request. A common practice is to have a NAT mask a large number of devices in a private network. Only the “outside” interface(s) of the NAT needs to have an Internet-routable address.

Commonly, the NAT device maps TCP / UDP port numbers from public networks to individual private addresses on the masqueraded network. In a typical NAT, only the valid IP address is assigned to the firewall. All other device IP addresses are behind firewall, and their internal IP addresses are only valid on the private network.

Home networks scenario:

NAT functions are usually implemented in a residential gateway device, typically one marketed as a “router”. In this scenario, the computers connected to the router would have private IP addresses and the router would have a public address to communicate on the Internet. This type of router allows several computers to share one public IP address.

When a device on the private network needs to communicate with the outside world, the device sends its request to the firewall. The firewall then places the request on behalf of the device that actually made the request. When the response to the request comes back, the request arrives at the firewall, and then the firewall sends the response to the appropriate computer on the private network.

Firewalls in VNS3

VNS3 acts as an application-layer firewall. It’s a great tool to layer your firewall security on top of lower-level firewalls like AWS Security Groups or Azure Network Security Groups. VNS3 is a layer 4 – 7 firewall for your cloud based application. We like to highlight how it allows you more control over your cloud deployments – Only you can control your VNS3 firewall rules.

Set up that VNS3 Firewall

Once you set up and configure your VNS3 instance, add firewall rules to allow or reject packets.

Navigate to Connections > Firewalls to enter firewall rules. Click Save and Activate.

ta da!

Notes on VNS3 Firewall syntax

VNS3 Firewall features are controlled using IPTables syntax. For more information see http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http:// www.thegeekstuff.com/2011/06/iptables-rules-examples/

The order of rules matter – rules are applied from top to bottom until the first match. If no match is found, the packet is allowed to continue on.

In addition to the standard security and firewall features of VNS3 you can create your own rules to restrict traffic to and through the VNS3 Controller. Write a specification for a packet to match, then specify what to do with the packet.These are “customer” rules and are applied as appropriate in the overall firewall rule structure on the VNS3 Controller.

If your customer rules don’t reject a packet, it will be allowed by default. However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.

VNS3 Firewall examples: the basics

Drop all packets from 1.1.1.1 to 2.2.2.2:

INPUT_CUST -s 1.1.1.1 -d 2.2.2.2 -j DROP

Drop all traffic from 192.168.3.0/24 (entire subnet) except 192.168.3.11:

INPUT_CUST -s 192.168.3.11/32 -j ACCEPT
INPUT_CUST -s 192.168.3.0/24 -j DROP

Drop tcp traffic from 172.31.1.1 on port 8000 (Stop overlay clients from using the overlay IP of 172.31.1.1 with port 8000).

INPUT_CUST -p tcp -s 172.31.1.1/32 –dport 8000 -m state –state NEW,ESTABLISHED -j DROP
INPUT_CUST -p tcp –sport 8000 -m state –state ESTABLISHED -j DROP

VNS3 Firewall Warning

The VNS3 firewall allows customers complete control of the INPUT, OUTPUT, FORWARDING, PREROUTING and POSTROUTING behavior of traffic as it first enters the VNS3 Controller and as it exits the VNS3 Controller.

The VNS3 internal firewall is still there to “protect” the internal mechanisms of VNS3, however, customer rules can be created that have undesirable effects. Essentially rules that ACCEPT or REJECT/DROP all traffic are likely to create a device that is un-reachable or one that is too permissive in accepting traffic.

Customer rules are evaluated and if there is not a match in the _CUST chains, then they flow through into the interior VNS3 chains which are quite restrictive. Accepting all traffic prevents most of the interior rules from being evaluated which might block unsafe traffic. Blocking all traffic prevents most of the interior rules from being evaluated which accept necessary traffic such as the API and WebUI management utilities. (Blocking port 8000 from all traffic will make the VNS3 instance un-manageable.)

Do not have rules of either of the following forms:

INPUT_CUST –dport 8000 -j REJECT

INPUT_CUST -j REJECT

INPUT_CUST -j ACCEPT

Up next, we’ll look at more advanced VNS3 firewall scenarios including: Network Address Translation (NAT-ing), Port Forwarding, Netmapping, SNMP Support, and Copying Traffic to a Device.