There is always an underlying assumption that system administrators know what is passing through their networks. While this may be true most of the time, there are always the old truisms about what happens when you make assumptions. Sometimes it’s the system administrators themselves making this assumption. To help correct any differences between assumptions and reality, the feature “Policy Learning” was introduced in FortiOS 5.4. Its purpose is to help inform sysadmins what is actually moving through their networks.
Policy Learning is very simple to set up. All it takes is a simple mouse click to choose the new option and enable the feature on an individual firewall policy. It is however, worth going over how to use the feature and to know what is going on in the background. And just as important, is going over why you should be using this feature.
To keep things simple and generic, we will use the fictional working environment of an existing network that has just installed a brand new FortiGate. To make it more fun we’ll say it’s your first day on the job at a brand new company. This way we can be sure you haven’t developed any bad habits yet.
When installing a new FortiGate, the first policy set up is usually one that goes from the inside to the Internet with fairly little in the way of restrictions. After all, first you want to make sure that you can connect to things before the access is limited for policy reasons. Once you have verified that you have that first connection and that everyone can access the Internet it is time to start locking things down. Wouldn’t it be nice to know which traffic you should be locking down, which you should be letting through and which should be managed instead of prevented?
To make life easy for the purposes of this example, we will work on the premise that you have a little bit of time before you have to complete and finalize all of your policies. Take that first policy, the one that most outbound traffic will be going through. When it was first set up, the Action field was set to ACCEPT.
The options for this field are ACCEPT, DENY, LEARN, and IPsec.
- ACCEPT allows all match traffic to go through the policy.
- DENY drops all of the matching packets.
- IPsec is for setting up IPsec VPN policies.
The option that interests us now is LEARN.
As cool as it would be for the FortiGate to be the one doing the learning, the purpose of this particular option is to make it easier for the system administrator to learn what sort of traffic is occurring on the network.
When the LEARN option is selected, a few things will be going on in the background.
The profiles
The first thing you are likely to notice is that all of the Security Profile options that you would normally see in the configuration window will no longer be displayed. You don’t need them because a number of predefined, hard coded profiles have been assigned to the policy for you.
These profiles:
- Are all flow-based
- Are static and cannot be changed
- Have SSL inspection disabled
- Are configured to monitor all the traffic that goes through the policy
Profiles not included are:
- DNS Filter – There is no Flow mode for this profile
- Web Application Firewall – There is no Flow mode for this profile
- CASI – (Almost all signatures in CASI require SSL deep inspection. Without SSL inspection, turning on CASI serves little purpose.)
Logging and Reporting
Monitoring the traffic is of little use unless the system administrator can make use of it. Once the learning policy has been active sufficiently long enough to collect some useful information, reports built from the analyzed logs can be viewed in an area of the Log and Reporting session set aside specifically for these reports.
To get to the Learning Report Window, go to Log & Report and select Learning Report.
Here you can select whether you want a Full Report which includes all of the details or a Report Summary. You also choose from the different time frames of
- the past 5 minutes
- the past hour
- the past 24 hours
Both the Full Report and the Report Summary will include, but with different levels of granularity, these topic headings:
- Deployment Methodology
- Test Details
- Start time
- End time
- Model
- Firmware
- Policy List
- Executive Summary
- Total Attacks Detected
- Top Application Category
- Top Web Category
- Top Web Domain
- Top Host by Bandwidth
- Host with Highest Session Count
- Security and Threat Prevention
- High Risk Applications
- Application Vulnerability Exploits
- Malware, botnets and Spyware/Adware
- At-Risk Devices and Hosts
- User Productivity
- Application Usage
- Top Application Categories
- Top Social Media Applications
- Top Video/Audio Streaming Applications
- Top Peer to Peer Applications
- Top Gaming Applications
- Web Usage
- Top Web Categories
- Top Web Applications
- Top Web Domains
- Application Usage
Why do you want to know this information?
Once you have this information you can perform the most important aspect of a system administrators role; make informed decisions. It makes no sense to be configuring policies based upon what you think is happening on your network. You may have a policy that locks down the usage of peer to peer traffic because you’re worried about people using the company bandwidth to download their torrents, because that’s what happened at the last place you were at. Trouble is at this new place nobody cares about torrents because there spending all of their time playing Facebook games.
This is the scenario for one policy, going in one direction. Every time a new policy is set up it is worth spending an hour or a day to find out what is going through that policy before determining what restrictions are necessary to put on it. Not only is it a good idea to discover the different ways in which policies are being used for unintended purposes, but it is also good to verify that policies are being used for the intended purpose. If you set up a policy specifically to manage the traffic between some internal servers and a third party service on the Internet, it’s worth your time to verify that the intended traffic is going through that policy and not another one.
In order to be an effective system administrator it helps to have current and actual data to base decisions on.
Once you have a realistic idea what is going through your network you can start to make plans on how to manage that traffic. The intended traffic should go through, but do you just allow it and forget about it or do you monitor it? As for the less desirable traffic, do you block it, schedule it for specific time periods or do you set up quotas for it? Some choices will be easier than others. For malicious traffic or traffic that is against organizational policy, the decision has already been made. For traffic that isn’t dangerous, other than to productivity, there may need to be some discussions with stake holders and those with appropriate levels of authority.
Maintenance
This feature doesn’t have to be only for new policy configurations. Like any other complex system, network environments evolve over time. The traffic that was captured when you were first setting up the policy may have also changed over time. It could be because new people are now on the network, the network configuration has changed or there are new roles for people and devices on your network. As part of your maintenance plan set aside some time for relearning what traffic is going through your policies so that you can update your policies accordingly.
The obligatory warning
Because the profiles that are used in the learning mode only monitor and do not block anything, it is only recommended that they be used on outbound policies or policies between segments of the internal network. The time an unsecured system is available to the Internet without an attempt by someone trying to compromise it is measured in seconds. If you are going to set up learning on an incoming policy make sure that your danger of being compromised is as limited as possible.
The post Make it a policy to learn before configuring policies appeared first on Fortinet Cookbook.