Tag Archives: fortinet dlp

FortiOS 6 – Data leak prevention

Data leak prevention

The FortiGate data leak prevention (DLP) system allows you to prevent sensitive data from leaving your network. When you define sensitive data patterns, data matching these patterns will be blocked, or logged and allowed, when passing through the FortiGate unit. You configure the DLP system by creating individual filters based on file type, file size, a regular expression, an advanced rule, or a compound rule, in a DLP sensor and assign the sensor to a security policy.

Although the primary use of the DLP feature is to stop sensitive data from leaving your network, it can also be used to prevent unwanted data from entering your network and to archive some or all of the content passing through the FortiGate unit.

This section describes how to configure the DLP settings. DLP can only be configured for FortiGate units in proxybased inspection.

The following topics are included:

l Data leak prevention concepts l Enable data leak prevention l Creating or editing a DLP sensor l DLP archiving l DLP examples

Data leak prevention concepts

Data leak prevention examines network traffic for data patterns you define through the use of the GUI and CLI commands. The DLP feature is broken down into a number of parts. Note, DLP is not available in flow-based inspection.

DLP sensor

A DLP sensor is a package of filters. To use DLP, you must enable it in a security policy and select the DLP sensor to use. The traffic controlled by the security policy will be searched for the patterns defined in the filters contained in the DLP sensor. Matching traffic will be passed or blocked according to how you configured the filters.

DLP filter

Each DLP sensor has one or more filters configured within it. Filters can examine traffic for known files using DLP fingerprints, for files of a particular type or name, for files larger than a specified size, for data matching a specified regular expression, or for traffic matching an advanced rule or compound rule.

DLP filter actions

You can configure the action taken when a match is detected. The actions include:

 

l Allow l Log Only l Block l Quarantine IP address

Log Only is enabled by default.

Allow

No action is taken even if the patterns specified in the filter are matched.

Log Only

The FortiGate unit will take no action on network traffic matching a rule with this action. The filter match is logged, however. Other matching filters in the same sensor may still operate on matching traffic.

Block

Traffic matching a filter with the block action will not be delivered. The matching message or download is replaced with the data leak prevention replacement message.

Quarantine IP Address/ Source IP ban

Starting in FortiOS 5.2, the quarantine, as a place where traffic content was held in storage so it couldn’t interact with the network or system, was removed. The term quarantine was kept to describe preventing selected source IPs from interacting with the network and protected systems. This source IP ban is kept in the kernel rather than in any specific application engine and can be queried by APIs. The features that can use the APIs to access and use the banned source IP addresses are antivirus, DLP, DoS and IPS. Both IPv4 and IPv6 version are included in this feature.

If the quarantine-ip action is used, the additional variable of expiry time will become available. This variable determines for how long the source IP address will be blocked. In the GUI it is shown as a field before minutes. In the CLI the option is called expiry and the duration is in the format <###d##h##m>. The maximum days value is 364. The maximum hour value is 23 and the maximum minute value is 59. The default is 5 minutes.

If a DLP sensor has contains a DLP filter with action set to Allow certain files and another DLP filter with action set to Block those same files, then the order of the filters within that sensor will determine which action is taken first.

Configuring using the CLI

To configure the DLP sensor to add the source IP address of the sender of a protected file to the quarantine or list of banned source IP addresses edit the DLP Filter, use these CLI commands:

config dlp sensor edit <sensor name> config filter edit <id number of filter> set action quarantine-ip set expiry 5m end end

Data leak prevention concepts

Preconfigured sensors

A number of preconfigured sensors are provided with your FortiGate unit. These can be edited to more closely match your needs.

Two of the preconfigured sensors with filters ready for you to enable are:

  • Credit-Card – This sensor logs the traffic, both files and messages, that contain credit card numbers in the formats used by American Express, MasterCard and Visa.
  • SSN-Sensor – This sensor logs the traffic, both files and messages, that contain Social Security Numbers with the exception of those that are WebEx invitation emails.

DLP document fingerprinting

One of the DLP techniques to detect sensitive data is fingerprinting (also called document fingerprinting). Most DLP techniques rely on you providing a characteristic of the file you want to detect, whether it’s the file type, the file name, or part of the file contents. Fingerprinting is different in that you provide the file itself. The FortiGate unit then generates a checksum fingerprint and stores it. The FortiGate unit generates a fingerprint for all files detected in network traffic, and it is compared to all of the fingerprints stored in its fingerprint database. If a match is found, the configured action is taken.

The document fingerprint feature requires a FortiGate unit with internal storage.

Any type of file can be detected by DLP fingerprinting and fingerprints can be saved for each revision of your files as they are updated. To use fingerprinting you:

l select the documents to be fingerprinted l add fingerprinting filters to DLP sensors l add the sensors to firewall policies that accept the traffic to which to apply fingerprinting.

Fingerprinting

Fingerprint scanning allows you to create a library of files for the FortiGate unit to examine. It will create checksum fingerprints so each file can be easily identified. Then, when files appear in network traffic, the FortiGate will generate a checksum fingerprint and compare it to those in the fingerprint database. A match triggers the configured action.

You must configure a document source or uploaded documents to the FortiGate unit for fingerprint scanning to work.

Fingerprinted documents

The FortiGate unit must have access to the documents for which it generates fingerprints.

Configuring the document source

To configure a DLP fingerprint document source in FortiOS 5.6.0, you must use CLI commands.

config dlp fp-doc-source edit <name_str> set name <string> set server-type {smb} set server <string>

set period {none | daily | weekly | monthly} set vdom {mgmt | current} set scan-subdirectories {enable | disable} set remove-deleted {enable | disable} set keep-modified {enable | disable} set username <string> set password <password> set file-path <string> set file-pattern <string> set sensitivity <string> set tod-hour <integer> set tod-min <integer>

set weekday {sunday | monday | tuesday | wednesday | thursday | friday | saturday} set date <integer>

end

Configuring a DLP fingerprint sensor

To configure a DLP fingerprint sensor in FortiOS 5.6.0, you must use CLI commands.

config dlp sensor edit <sensor name> config filter edit <id number of filter> set proto {smtp | pop3 | imap http-get | http-post | ftp | nntp | mapi} set filter-by fingerprint

set fp-sensitivity { critical | private | warning}

set action {allow | log-only | block | ban | quarantine-ip | quarantineport}

next

end

next

Once you have set the document source and configured the DLP sensor for fingerprinting, add the DLP sensor to the applicable firewall policy. This can be done through the GUI.

File size

This filter-type checks for files exceeding a configured size. All files larger than the specified size are subject to the configured action. The value of the field is measured in kilobytes (KB).

Data leak prevention concepts

DLP filtering by specific file types

File filters use file filter lists to examine network traffic for files that match either file names or file types. For example, you can create a file filter list that will find files called secret.* and also all JPEG graphic files. You can create multiple file filter lists and use them in filters in multiple DLP sensors as required.

Specify File Types is a DLP option that allows you to block files based on their file name or their type.

  • File types are a means of filtering based on examination of the file contents, regardless of the file name. If you block the file type Archive (zip), all zip archives are blocked even if they are renamed with a different file extension. The FortiGate examines the file contents to determine what type of file it is and then acts accordingly.
  • File Name patterns are a means of filtering based purely on the names of files. They may include wildcards (*). For example, blocking *.scr will stop all files with an .scr file extension, which is commonly used for Windows screen saver files. Files trying to pass themselves off as Windows screen saver files by adopting the file-naming convention will also be stopped.
  • Files can specify the full or partial file name, the full or partial file extension, or any combination. File pattern entries are not case sensitive. For example, adding *.exe to the file pattern list also blocks any files ending with .exe. l Files are compared to the enabled file patterns from top to bottom, in list order.

Extended-UTM-Log Enable Error

I received the following question through my consulting form:

Question: when configuring application list, setting the “extended-utm-log” the I got the following error:

burgfg01 (list) $ edit “RogersStandard”
new entry ‘RogersStandard’ added

set extended-utm-log enable
burgfg01 (RogersStandard) $ set extended-utm-log enable

command parse error before ‘extended-utm-log’
Command fail. Return code -61
———

Please advise.
Thanks

Answer: Chances are the user is utilizing FortiOS 5.2 or later which no longer has the extended-utm-log enable feature.

Fortinet Acquires AccelOps

In case you guys didn’t know already Fortinet has bought, or acquired, or whatever we want to call it,AccelOps. Here is an excerpt from their blog post.

One of the biggest security challenges organizations face is being able to see enough of the network to identify today’s most advanced, multi-vector threats. Ideally, you need to be able to see across the distributed network, including cloud deployments and devices from multiple network and security vendors, correlate detected local activity with global threat intelligence and expected behaviors, and coordinate a response across the entire portfolio of installed security solutions.

This becomes increasingly challenging as networks continue to expand beyond the perimeter and embrace increasing numbers of devices and applications. As the network expands, the attack surface naturally expands with it. At the same time, new threats are targeting this distributed network architecture. Mobility, IoT, virtualization, big data, and the cloud aren’t only transforming businesses. They are being specifically targeted, which is a game changer for security as well. For example, it is estimated that by 2020 over 25% of attacks on enterprises will involve IoT.

If you are interested in reading more please CLICK HERE

A Wrap Up Of HITB Amsterdam 2016 Conference

23 May 2016 marked the first day of the annual security conference organized by Hack In the Box. As usual, the event took place in Amsterdam, Netherlands. This year I had the privilege to attend. HITB is one of the top-notch technical conferences, where elite security researchers from around the world gather to share their research. Not to mention that it is also a great place to hang out with these people to exchange ideas offstage. There were so many great talks in this conference. I am pleased to share a couple of talks here that I feel were particularly interesting.

One of my favorite, and most anticipated talks, was Go Speed Tracer: Guided Fuzzing presented by Richard Johnson. Richard is an expert in fuzzing technology, particularly emphasizing on how to optimize the performance of traditional fuzzers to make them scale extensively. Of course, traditional fuzzing methodologies, such as dump fuzzing, which use simple sample-based mutation still work in most cases. However, they are often limited to discovering minor security issues, and eventually lead to bottlenecking, an issue many security researchers come across when writing their own fuzzer. Feedback driven fuzzing is an evolutionary fuzzing methodology, made possible by the introduction of American Fuzzy Lop (AFL), an approach that is able to enhance the coverage of a fuzzer, thereby increasing the chances that the user can discover more security issues, or even uncover severe security vulnerabilities. After thoroughly studying various open source fuzzers like AFL, Richard shed some light in his presentation on how to customize your own, optimal performance guided fuzzer using existing binary instrumentation technologies like Pin, DynamoRIO, and DynInst. He also performed a couple of demos that showed the performance overhead between Pin and DynamoRIO, which showed that DynamoRIO seems to outperform Pin in term of binary code instrumentation. Unfortunately, he wasn’t able to show the demo of AFL with full support for Windows binary, along with hardware tracing using Intel Processor Tracer via Windows driver, as the prototype has not been completed yet. Nevertheless, it was an inspirational talk for researchers who are interested in developing their own fuzzer.

Click Here To Continue Reading

FortiClient Monitoring and Quarantine

FortiClient Monitoring and Quarantine

FortiClient monitoring and quarantine is currently only supported by FortiClient 5.4 for Windows.

FortiSandbox uses a single signature to identify tens of thousands of variations of viral code. A FortiSandbox can send frequent, dynamic signature updates to a FortiGate and FortiClient, which allows files to be blocked before they are sent to the FortiSandbox.

With FortiSandbox, FortiClient, and FortiGate integration, you can configure a FortiGate to send files to FortiSandbox for scanning.

When FortiSandbox determines that a file is infected, it will notify the FortiGate of this event. Then, from

FortiView, the administrator can take action to quarantine the endpoint which downloaded the infected file. FortiGate administrators can quarantine endpoints from FortiView.

To support this, the FortiClient now supports host-level quarantine, which cuts off other network traffic from the endpoint directly, preventing it from infecting or scanning the local network.

When a device is under quarantine, FortiClient cannot be shutdown or uninstalled. A user is also unable to unregister from the FortiGate that quarantined them, or register to another FortiGate unit.

Alternately, FortiGate can release the file to the client before receiving the FortiSandbox scan results, and then have FortiClient quarantine the device when the scan results are available if required.

Pushing signatures to AntiVirus

Pushing signatures to AntiVirus

When a FortiSandbox discovers a malicious file, it can create a signature that is sent to the FortiGate, to supplement the AntiVirus signature database. This signature can be used to block that file from entering the network again, and to prevent duplicates of the file being sent to the FortiSandbox in the future. This feature is enabled in an AntiVirus profile.

CLI Syntax

config antivirus profile edit “default”

set ftgd-analytics {everything | suspicious}

set analytics-db {enable | disable}

end

Files blocked by a FortiSandbox signature can be viewed and filtered for in the FortiSandbox dashboard.

In FortiOS 5.4 Beta 2, the URL feature is only available for proxy-based Web Filter profiles.

Information on the current database for both malware signatures and blocked URLs can be found by going to

System > External Security Devices.

 

FortiSandbox Integration

FortiSandbox Integration

The following improvements have been made to how sandboxing, using either a FortiSandbox Appliance or

FortiCloud Sandboxing, integrates with a FortiGate unit.

See the Cookbook recipe Sandboxing with FortiSandbox and FortiClient.

Connecting to a FortiSandbox

1. Go to System > External Security Devices and select Enable Sandbox Inspection.

2. You can either select FortiSandbox Appliance or FortiSandbox Cloud.

3. If you select FortiSandbox Appliance, add the Server IP address.

4. Select Test Connectivity to verify that you can connect to FortiSandbox.

5. Then edit an AntiVirus profile by going to Security Profiles > AntiVirus and selecting Send Filter to

FortiSandbox Appliance for Inspection.

6. You can also select to send Suspicious Files, Executable files or all supported files.

7. Select Use FortiSandbox Database to add signatures for suspicious files found by FortiSandbox to your

FortiGate antivirus signature database.

8. Then select this Antivirus profile in a firewall policy to send files in traffic accepted by the firewall policy to

FortiSandbox.

9. You can also go to Security Profiles > Web Filter and select Block malicious URLs discovered by

FortiSandbox.

Pushing malicious URLs to Web Filtering

The malicious URL database contains all malicious URLs active in the last month. The FortiSandbox can add the URLs where any malicious files originated to a URL filter, to block these files from being downloaded again from that URL.

This feature is enabled in a Web Filter profile under Security Profiles > Web Filter > Block malicious URLs discovered by FortiSandbox.

CLI Syntax

config webfilter profile edit <profile>

config web

set blacklist [enable | disable]

… end

Files blocked by a FortiSandbox signature can be viewed and filtered for in the FortiSandbox dashboard. Information on the current database for both malware signatures and blocked URLs can be found by going to System > External Security Devices.

FortiSandbox Dashboard in FortiView

The FortiSandbox dashboard is available from FortiView > FortiSandbox. The dashboard shows all samples submitted for sandboxing. Information on the dashboard can be filtered by checksum, file name, result, source, status, and user name. Each entry also offers a drilldown view to show more details about a particular sample.

Web Application Firewall

Web Application Firewall

Go to Security Profiles > Web Application Firewall. From here you can customize the default Web Application Firewall profile, or create new profiles, to protect against a variety of web-based threats. Web Application Firewall profiles can be created with a variety of options (Signatures and Constraints), similar to other security profiles.

You can set the Web Application Firewall to use an External Security Device, such as FortiWeb, by setting

Inspection Device to External.

Web Application Firewall

Selecting External in the Web Application Firewall profile adds the following configuration to the CLI:

config waf profile edit default

set external enable end

You must add the Web Application Firewall profile to a firewall policy in order for that traffic to be offloaded to the

External Security Device for processing.

If your FortiGate or VDOM Inspection mode is set to flow-based you must use the CLI to set a Web Application Firewall profile to external mode and add the Web Applic- ation Firewall profile to a firewall policy.