Setting Up Your Firewall Rules – Best Practices

The first thing a user should do after completing the on-boarding process, is setup their fire wall rules.  The first oder of business is to configure an implicit deny all rule on the firewall to deny all traffic from their announced prefix or public IP end point where their GRE tunnel is terminated. In effect this rule will deny all traffic that is not expressly whitelisted by the client. Then the client should first identify their publicly accessible services, determine the ports and IPs that require white listing and then allow traffic to those ports.  This is an ideal configuration that can prevent a multitude of attacks and unwanted traffic from affecting the client’s resources.

Creating an “Implicit Deny All Rule”

1. Log into your portal at https://coretech.path.net
2. Navigate to the option “Firewall Rules”
3. Click the “NEW RULE” button at the top right side of the page
4. Destination should be your network prefix that you use over BGP or lease from us. Source should be all 0.0.0.0/0.  Leave protocol blank in order to specify all protocols.  Action should be set to “block.”  You can label the rule in the comment section as “Implicit Deny All Rule.”
5. Now all traffic is blocked to your server or prefix and you must create rules in order to whitelist the traffic you want to allow.

Hole Punching Explained:

You may hear our staff mention “Hole Punching” this simply means that even with an implicit deny all rule, we allow sessions through the fire wall that are initially established by the server behind it.

Creating a Whitelist Rule:

1. Determine your services that need to be publicly exposed, their  accessible IP or IP Prefix and associated service ports
2. Navigate to the option “Firewall Rules”
3. Click the “NEW RULE” button at the top right side of the page
4. Set the Rule Destination either a single IP/32 or a IP/24 Prefix
5. Set the source:
   1. 0.0.0.0/0 = any (this is OK if it’s your clients for a  hosted service such as a Minecraft or other game server)
   2. For some common ports/services you will want to make sure you have a very specific range such as the IP or IP prefix of the specific people who need access to these services.  Some of these include SSH, RDP, and other remote connection management software used for administration.  If you allow any source to connect to sensitive services you are creating a security risk as this opens your administration service up to the entire internet.
6. Set the Protocol and it’s source and destination port.  Do to the nature of XDP you will need to set a rule for each needed port and protocol. For instance we do not support port ranges, so you will need individual rules for each port.  This also applies to protocol, so if you have an application that supports both TCP/UDP you need to create a rule for each protocol.
7. Choose Action “whitelist
8. Label your rule in the comments section to that you can identify it.

Configuring Your Filters

Now that you have your firewall rules setup you need to configure your associated filters that further protect your applications.   Our filter rules utilize XDP (Express Data Path), our engineers have studied the RFC’s of multiple common applications and common TCP/UDP traffic and have built these filters to check the data portion of the incoming packet and make sure it is legitimate.

Applying filters to your services is rather easy:

• Locate the service such as OpenVPN, choose the IP and Port you are running the service on and click save.
• For Generic Services such as SSH and RDP you can use TCP Service Filters, make sure you choose TCP Service (Symetric) if you have always on Symetric services to ensure that return traffic is routed through CoreTech Network.