Firewall
Overview
The VNS3 Firewall adds a layer of security and control for cloud-based deployments.
VNS3 Firewall features are controlled using IPTables syntax. For more information see the official IPtables documentation and look for the PARAMETERS section. Another useful guide is available here from some geeks.
In general, you write a specification of a packet to match and then specify what to do with this packet. These are referred to as “customer” rules and are applied as appropriate in the overall firewall rule structure on the Controller. This means 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.
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. Important note: 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.
NOTE: Firewall rules added to a specific controller are not automatically synced to other controllers in the peered mesh.
Firewall Syntax
VNS3 creates a firewall table for your rules which is implicitly used by any firewall commands you enter. As a result, the firewall syntax varies from standard iptables in that you don’t specify an “append” or “-A”. The chain names for your commands use restricted chain names of INPUT_CUST, OUTPUT_CUST, FORWARD_CUST, PREROUTING_CUST, and POSTROUTING_CUST.
These tables go into the top of the corresponding VNS3 internal firewall chains. The INPUT_CUST, OUTPUT_CUST, and FORWARD_CUST go into the iptables Filter table, and the PREROUTING_CUST and POSTROUTING_CUST go into the Nat table.
Cohesive also offers a chain MACRO_CUST which is a type of rule that combines some more complicated rule combinations spanning multiple chains and tables into a single rule. For example the full IPTable syntax would be something like:
iptables -A INPUT_CUST -p tcp -s 172.31.1.1/32 --dport 8000 -m state --state NEW,ESTABLISHED -j DROP
In VNS3 enter the same elements without the “iptables” command and the “-A”:
INPUT_CUST -p tcp -s 172.31.1.1/32 --dport 8000 -m state --state NEW,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 any rules of the following forms:
INPUT_CUST --dport 8000 -j REJECT
INPUT_CUST -j REJECT
INPUT_CUST -j ACCEPT
Firewall Examples
-j ACCEPT allows a packet. -j DROP drops a packet. -j REJECT sends an appropriate notification to sender saying such and such packet was rejected (depends on protocol).
Some Basic examples:
- 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
NAT (Network Address Translation)
It is now common for clouds to provide VLAN isolation. This provides a critical element of your overall security approach but creates the need for additional capabilities not needed in “plain old EC2”.
One of these is “NATing” which allows the machines in the 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. This is 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.
Port Forwarding
With a VPC, your cloud servers are not visible or accessible from the Internet unless you assign a public or Elastic IP, “putting” 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
PREROUTING_CUST -i eth0 -p tcp -s 61.61.70.70/32 --dport 3389 -j DNAT --to 10.199.130:3389
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:
- Enable NAT (required 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 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 parameters:
- Remote subnet: 10.10.10.0/24
- VNS3 Overlay (clientpack network): 172.31.10.0/24
- Local Server the Remote wants to access: 172.31.10.50
- Customer LAN: 10.10.10.0/24
- Allocate an EIP to your account but DON’T associate: 23.23.23.23.
Goal: 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 -s 172.31.10.0/24 -d 10.10.10.0/24 -j ACCEPT
FORWARD_CUST -s 10.10.10.0/24 -d 172.31.10.0/24 -j ACCEPT
Firewall - Copy Traffic to a Device
With the addition of the 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 <Container Network IP> --inbound # Copying incoming traffic to tun0 to container
MACRO_CUST -j COPY --from tun0 --to <Container Network IP> --outbound # Copying outgoing traffic to tun0 to container
NOTE: At this time analyze inbound OR outbound at any given time in order to prevent accidental traffic loops. It IS POSSIBLE to create a traffic cycle which could “brick” your controller if you create simultaneous inbound AND outbound rules with improper parameters.