In the previous part, we have started working with SmartConsole, which is the main administrative tool for creating and managing security policies.
In this session, we will be using SmartConsole to perform the following tasks:
- Set Anti-Spoofing and Security Zone parameters for Security Gateway network interfaces;
- Create various objects;
- Create and apply an Access Control policy on our Security Gateway.
Security Policies
There are four types of Security policies:
- Access Control: With the R80.x Unified Policy concept, such policy can use Firewall, Application Control & URL Filtering, Content Awareness, and Mobile Access Software Blades;
- Threat Prevention: This includes IPS, Anti-Virus, Threat Emulation, and Threat Extraction Software Blades
- Desktop Security: This is not enabled by default and only relevant for Remote Access VPN clients.
- QoS: Only relevant if the QoS blade is enabled.
In this lecture, we will cover Access Control only.
Access Control
The Access Control policy is the primary security policy you must install on your Security gateway. It must be installed before applying other Security Policy, such as Threat Prevention and/or Desktop Security. With R80.x, the Access Policy in Unified mode can include multiple Software Blades: Firewall, Application Control, Identity Awareness, and Content Awareness.
In this part, we will talk about the Firewall blade only.
Before installing Access Control security policy, we need to perform some actions:
- Set up Anti-Spoofing and Security Zones for Network Interfaces of the Security Gateway,
- Create network objects describing your IT infrastructure: Networks, Hosts, Servers, Groups, etc.,
- Create Access Control Security Policy rulebase.
Anti-Spoofing and Security Zone settings
Double-click on your Security Gateway object in SmartConsole and choose Network Management tab. There are three interfaces listed there: eth0, eth1, and eth2.
Double-click on eth0 and the following screen appears:
Three parameters needs to be adjusted:
- Leads To
- Security Zone
- Anti-Spoofing
Click on Modify and set up those as shown below:
Click on OK twice and set up eth1 interface topology, as shown below:
Note that we have changed the default settings for this interface by choosing Override option. In addition, we have marked “Interface leads to DMZ” checkbox.
Click on OK twice and move to eth2 settings:
Click on OK three times to finish setting up the Security gateway.
Network objects
Before building Access Security policies, we need to create Network Objects we will be using there. A network object is not an IP (which can be IPv4, IPv6, or both), but it may also contain many other important details.
Objects are managed through Objects Panel on the upper right part of SmartConsole screen or with Object Explorer:
Let us start by creating a new network object called LanNetwork. To do so, in the Object Panel, press New > Network
In the new pop-up, set up the object name (LanNetwork), IP address and Mask:
Leave NAT (Network Address Translation) settings untouched. They are a subject of our next lecture. Press OK to finish.
Similarly, create a Host object DMZ-Srv (172.16.20.100). To start, choose New > Host. For better representation, change the color of the object (upper left corner):
Our objects are ready, now we can start building Access Control Policy rulebase.
Creating Access Control Policy
Go to Security Policies > Access Control > Policy. We have there a single pre-defined policy called Standard with just one rule of Any > Any > Drop:
This rule is called Cleanup rule. It is best practice to put this rule at the bottom of your policy package, to make sure all previously unmatched connections are dropped by your security policy. For better visibility on a Cleanup rule, change Track settings to Log. To do so, right-click on the Track field in the rule and chose Log:
Add a new access rule by clicking on Add Rule above icon:
The purpose of this rule is to allow HTTPS and SSH access from our LAN to Security Gateway and SMS.
Put “Mgmt” in the Name field. Chose LanNetwork object as Source, add SMS and SG to Destination, finally, HTTPS and SSH to Services & Applications:
You can use text search when looking up any of the mentioned objects by name:
Change Action to Accept and put Track to Log. Your new policy rules should look as below:
To protect our Security System elements from unauthorized access, we need to create so-called Stealth rule. Right-click on Mgmt Rule and choose New Rule > Below:
Put the following parameters:
- Name: Stealth
- Source: Any
- Destination: SMS, GW
- Services & Applications: Any
- Action: Drop
- Track: Log
Our new rules should look as below:
To avoid excessive logging of dropped “noisy” services, we need a Trash rule. Add a new rule below Stealth one, with Any for both Source and Destination. Add udp-high-ports, bootp, NBT, and rip services to Services & Application. To avoid logging, leave Track option default (None😞
Below Trash rule, add rule named Internet for Local Network. Put http, https, ftp, and dns to Services and Applications. The rule will look as below:
Finally, add another policy rule allowing access from LanNetwork to DMZ-Srv with Any service. Your rulebase should now be as shown:
Note: R80.x Security Management Server allows multiple administrators to make parallel changes. To make your changes available to other administrators, you need to publish them by pressing on Publish button at the top of SmartConsole screen.
In our case, all changes will be published during policy installation process.
Installing Security Policy
We need to apply our Security Policy. Click on Install Policy button at the upper left corner of your SmartConsole screen:
The pop-up message reminds us we did not publish changes. Note that amount of changes and the admin account are mentioned in the Description field. Press Publish& Install:
When changes are published, we will see Install Policy window. De-select Threat Prevention checkbox and press Install:
Once done, you will see Policy installation progress notification at the left bottom corner of your SmartConsole screen.
When installation process is finished, you will see a notification about success:
If your policy is configured and applied properly, Lab User PC should be able to ping and access via http your DMZ-Srv lab machine.
Note that DMZ-Srv should have IIS enabled for HTTP to work.
Select DMZ Access rule in SmartConsole and then chose Logs tab. You should see access logs for this rule:
While DMZ access should work, do not try accessing Internet from your lab environment. To do so, we need to configure Network Address Translation (NAT), which is a subject of our next lecture.
----------------------------
Authors and contributors
Author - Evgeniy Olkov, CTO at TS Solution.
Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.
Translation and editing - Valeri Loukine
Review and editing - Dameon Welch-Abernathy