Saturday, October 20, 2018

Data Leak Prevention (DLP) on Fortigate

Today I would like to present one interesting feature you may find on your Fortigate - Data Leak Prevention. I know there are much better, dedicated solutions on the market but in certain situations the DLP feature available on FortiOS is good enough.

Why you should use it?

This is very important to say: the DLP in such deployment (on Fortigate) can't protect your data against every data leak. Users in your network with his/her mobile can easily take a photo of any document. Why we should still consider it? It is a good (and easy to deploy) method to prevent users' mistakes. It happened hundreds of time when a user attached a wrong file. Sound familiar? Using the DLP you can create policies which stop such leak. Let me show you how you can configure it.

Step #1

First, you have to check if DLP is enabled in a "Feature Visibility" and "Security Features" section:






When you do not see the feature, make sure your Fortigate works in a proxy-based inspection mode:


I know it may be a problem for some of you as a default inspection mode in 5.6 is flow-based (Fortinet introduced NGFW mode in the flow-based inspection mode):



I know in many cases you are not fully aware about such limitation. One of the solution I can recommend is using VDOMs. Your main VDOM can work in flow-based inspection mode, where you can fully use ASIC's capabilities, and second VDOM can work in proxy-based inspection mode where DLP feature is supported.


Step #2

Edit a DLP sensor (profile):



and add a new filter (click +):


In my example I would like to stop files which contain 11 digits,  like this one:




The best method is using a regular expression (PCRE). As you can see my is a quite short: "\d{11}". I set an action to 'block':

What also generate a log entry once it matches string like in my test file. You may notice that only non-encrypted services are on the filter list. You can add SSL full inspection profile to monitor encrypted communication too.


Step #3

In last step you need to attach the new profile (sensor) to a firewall policy:






 Now it's time for test when I try to upload my test file using HTTP. This is the warning message I got:


And what I see in my logs:









You can also test it using CLI:




Summary

As you can see the feature is very easy to deploy. You can start doing small steps, monitor logs and device performance. Remember your Fortigate has to work in the proxy-based inspection mode.

PCRE resources you can find here:


You can test your regex before using here:

https://www.debuggex.com/?flavor=pcre




Wednesday, March 28, 2018

How to increase network resiliency?

Network design is not fixed process. Every time when we add or change something in the network, we should analyze if the network is still resilient, as it was in the original design. Let's analyze below scenario:

Firewall - Fortigate 5.x
Core switch - Nexus 5k NX-OS 7.X 
Routing between core and firewalls - static




With direct connection between FW01-Core01 and FW02-Core02 we can detect link failure easily. Firewalls here are in HA Active-Passive mode, what means the secondary box doesn't process any traffic. In case of Port1, Port2 or device failure - the secondary takes its role and sends ARP updates to the core switch. The same situation when Core01 or Core02 fails, FW01/02 can notice it and triggers failover.

Let's imagine your are tasked to put IDS between core switches and perimeter firewalls, like on the diagram below:




What is wrong with this scenario? Let's think if following failure scenarios are backed up:

1) FW01/Port1/Port2 failure - with port failure FW01 triggers failover, with device failure FW02 detects lack of heartbeats, triggers failover and updates MAC table on the core switch. In case of FW01 malfunction, FW02 will not see heartbeats, so we are covered too.




Status: PASS

2) IDS01 failure or external interface. FW01 can detect such incident and triggers failover.





Status: PASS

3) IDS01 can't process traffic (device malfunction) but its physical interfaces are up. In such case there is nothing what could trigger failover. Traffic will be dropped between FW01-IDS01 (ingress) and Core01-IDS01 (egress):



Status: FAIL

4) Core01 has physical interfaces failure. There is no mechanism in place to trigger FW01 failover. Traffic will be dropped by Core01:



Status:FAIL

5) Core01 can't process traffic (device malfunction). There is no mechanism in place to trigger FW01 failover. Traffic will be dropped by Core01:  



Status:FAIL



In above 5 failure scenarios, 3 of them are not resilient. The problem is the devices are not directly connected and they can't detect link or device failure (scenarios 3,4 and 5).

One of the method to fix the problem could be following change. We have to implement SLA monitor feature on core switches (available on Nexus 5k from version 7) to monitor interface on firewall (Port2) and use it with a static route. On the firewall we can use Link Health Monitor to track state of remote interface (on the core switch).

http://help.fortinet.com/fgt/handbook/cli52_html/index.html#page/FortiOS%25205.2%2520CLI/config_system.23.040.html

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/unicast/7_x/cisco_n5500_layer3_ucast_cfg_rel_6x/l3_object.html#92401


With above improvement there is no possibility to trigger failover based on status from these above features (object tracking on Nexus and Link Health Monitor on Fortigate). They can help you to remove static route only and use alternate path. It means we need backup links:




There are four possible paths:

a) FW01 (port2) -> IDS01 -> Core01   -> preferred
b) FW01 (port3) -> IDS02 -> Core02
c) FW02 (port3) -> IDS01 -> Core01
d) FW02 (port2) -> IDS02 -> Core02

Let's analyze last 3 scenario which weren't resilient in the previous design.


1) (former #3) - IDS01 can't process traffic (device malfunction) but its physical interfaces are up.

This is what happens:

- FW01 is still active as it isn't able to detect IDS malfunction
- Static route from FW01 via preferred path is removed as link monitor on Fortigate can't reach Vlan15 on Core01. Next available path from FW01 is via Port3 to IDS02 and then to Vlan25 on Core02
- Core01 detects lack of connectivity to Port2 on Active firewall (FW01) and only one available path is via Core02 and then IDS02 to Port3 on FW01. FW02 is in standby mode that's why path via Vlan25 on Core01 and via Vlan15 on Core02 are not available



2) (former #4) - Core01 has physical interfaces failure.

 This is what happens:

- Core01 can't reach Port2 (via Vlan15) on FW01 and that static route is removed

- Core01 has only one available path via Core02 then IDS02 and FW01 on Port3
- FW01 detects problem with reaching Vlan15 via Port2 and next preferred path is via Port3 to IDS02




3) (former #5) - Core01 can't process traffic (device malfunction).

  This is what happens:

- FW01 detects problem with reaching Vlan15 via Port2 and next preferred path is via Port3 to IDS02
- Core01 is not available and only one possible path is via Core02


  
I think I went through all possible failure scenarios. If not, please let me know. You may think that all this job could be done by dynamic routing protocols. Fortigate and Cisco Nexus support most of them. The problem is many organizations don't accept dynamic routing on firewalls.

Tuesday, March 27, 2018

Nexus and VTP

I would like to work today with Nexus5k in VTP Server mode and see what steps are necessary to recover configuration from the backup.

This is the platform I have in my lab:

N5548A# sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.html
Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.

Software
  BIOS:      version 3.6.0
  loader:    version N/A
  kickstart: version 6.0(2)N2(3)
  system:    version 6.0(2)N2(3)
  Power Sequencer Firmware:
             Module 1: version v3.0
             Module 2: version v1.0
             Module 3: version v5.0
  Microcontroller Firmware:        version v1.2.0.1
  SFP uC:    Module 1: v1.0.0.0
  QSFP uC:   Module not detected
  BIOS compile time:       05/09/2012
  kickstart image file is: bootflash:///n5000-uk9-kickstart.6.0.2.N2.3.bin
  kickstart compile time:  12/17/2013 2:00:00 [12/17/2013 13:52:59]
  system image file is:    bootflash:///n5000-uk9.6.0.2.N2.3.bin
  system compile time:     12/17/2013 2:00:00 [12/17/2013 17:02:31]


Hardware
  cisco Nexus5548 Chassis ("O2 32X10GE/Modular Universal Platform Supervisor")
  Intel(R) Xeon(R) CPU         with 8253856 kB of memory.
  Processor Board ID FOC16454D9A

  Device name: N5548A
  bootflash:    2007040 kB

Kernel uptime is 74 day(s), 9 hour(s), 16 minute(s), 13 second(s)

Last reset at 403970 usecs after  Thu Jan 11 21:01:25 2018

  Reason: Reset Requested by CLI command reload
  System version: 6.0(2)N2(3)
  Service:

plugin
  Core Plugin, Ethernet Plugin
N5548A#



and this is VTP status:


N5548A# sh vtp status
VTP Status Information
----------------------
VTP Version                     : 2 (capable)
Configuration Revision          : 2
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 6
VTP Operating Mode              : Server
VTP Domain Name                 : TEST
VTP Pruning Mode                : Disabled (Operationally Disabled)
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 Digest                      : 0x9D 0xA0 0x8D 0x8D 0x07 0xAC 0x46 0xCB
Configuration last modified by 0.0.0.0 at 3-27-18 07:09:24
Local updater ID is 0.0.0.0
VTP version running             : 2

N5548A#


As you can see the switch works in VTP Server mode version 2. For this test I create two vlans: 120 and 1200:

N5548A# sh vlan

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Eth1/1, Eth1/2, Eth1/5, Eth1/6
                                                Eth1/7, Eth1/8, Eth1/9, Eth1/10
                                                Eth1/11, Eth1/12, Eth1/13
                                                Eth1/14, Eth1/15, Eth1/16
                                                Eth1/17, Eth1/18, Eth1/19
                                                Eth1/20, Eth1/21, Eth1/22
                                                Eth1/23, Eth1/24, Eth1/25
                                                Eth1/26, Eth1/27, Eth1/28
                                                Eth1/29, Eth1/30, Eth1/31
                                                Eth1/32, Eth2/1, Eth2/2, Eth2/3
                                                Eth2/4, Eth2/5, Eth2/6, Eth2/7
                                                Eth2/8, Eth2/9, Eth2/10, Eth2/11
                                                Eth2/12, Eth2/13, Eth2/14
                                                Eth2/15, Eth2/16
120  VLAN120                          active    Eth1/3
1002 fddi-default                     suspended
1003 token-ring-default               suspended
1004 fddinet-default                  suspended
1005 trnet-default                    suspended
1200 VLAN1200                         active    Eth1/4


The most common way to do a backup is taking a copy of your configuration. In most cases it works fine but sometimes it isn't enough.

Now I take a copy of the config and I reset switch configuration to the default one. This is what I see when I restored my backup config:

N5548A# sh vlan

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Eth1/1, Eth1/2, Eth1/5, Eth1/6
                                                Eth1/7, Eth1/8, Eth1/9, Eth1/10
                                                Eth1/11, Eth1/12, Eth1/13
                                                Eth1/14, Eth1/15, Eth1/16
                                                Eth1/17, Eth1/18, Eth1/19
                                                Eth1/20, Eth1/21, Eth1/22
                                                Eth1/23, Eth1/24, Eth1/25
                                                Eth1/26, Eth1/27, Eth1/28
                                                Eth1/29, Eth1/30, Eth1/31
                                                Eth1/32, Eth2/1, Eth2/2, Eth2/3
                                                Eth2/4, Eth2/5, Eth2/6, Eth2/7
                                                Eth2/8, Eth2/9, Eth2/10, Eth2/11
                                                Eth2/12, Eth2/13, Eth2/14
                                                Eth2/15, Eth2/16
1002 fddi-default                     suspended
1003 token-ring-default               suspended
1004 fddinet-default                  suspended
1005 trnet-default                    suspended
1200 VLAN1200                         active    Eth1/4




As you can see there is no Vlan120. Definition of this vlan is not in the backup config:


vrf context default
vrf context management
...

vlan 1200
port-profile default max-ports 512


interface Vlan1

interface Ethernet1/1

interface Ethernet1/2

interface Ethernet1/3
  switchport access vlan 120

interface Ethernet1/4
  switchport access vlan 1200

interface Ethernet1/5


Only Vlan1200 is included. This is how VTP Server mode works. Let's do one test. I paste below config:

N5548A(config)# vlan 999
N5548A(config-vlan)# name vlan999
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1000
N5548A(config-vlan)# name vlan1000
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1001
N5548A(config-vlan)# name vlan1001
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1006
N5548A(config-vlan)# name vlan1006
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1007
N5548A(config-vlan)# name vlan1007
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1008
N5548A(config-vlan)# name vlan1008
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1009
N5548A(config-vlan)# name vlan1009
N5548A(config-vlan)#
N5548A(config-vlan)# vlan 1010
N5548A(config-vlan)# name vlan1010
N5548A(config-vlan)#


and this is what I see in the config:

N5548A(config)# sh run | i vla
feature interface-vlan
vlan 1006
  name vlan1006
vlan 1007
  name vlan1007
vlan 1008
  name vlan1008
vlan 1009
  name vlan1009
vlan 1010
  name vlan1010
vlan 1200
  switchport access vlan 120
  switchport access vlan 1200
N5548A(config)#


Vlan definition from range 1 to 1001 (1005 I should say) is kept in vlan.dat file, not in the configuration file. When you plan your backup make sure you have a copy of these VLANs too.

In my case I have secondary box with the same vlans. Let's try copy vlan.dat file:

N5548b# copy bootflash:///vlan.dat tftp://12.15.3.1/test1
Enter vrf (If no input, current vrf 'default' is considered):
Trying to connect to tftp server......
Using IP address of interface loopback0
TFTP put operation failed:Permission denied


The problem is you can't copy this file when the system is using it. The only one method (I'm aware of) is to change VTP mode from Server to Transparent and copy definition of these vlans from the config:

N5548A(config)# sh run | i vla
feature interface-vlan
vlan 1006
  name vlan1006
vlan 1007
  name vlan1007
vlan 1008
  name vlan1008
vlan 1009
  name vlan1009
vlan 1010
  name vlan1010
vlan 1200
  switchport access vlan 120
  switchport access vlan 1200
N5548A(config)#
N5548A(config)# vtp mode transparent
N5548A(config)#
N5548A(config)#
N5548A(config)# sh run | i vla
feature interface-vlan
vlan 1
vlan 999
  name vlan999
vlan 1000
  name vlan1000
vlan 1001
  name vlan1001

vlan 1006
  name vlan1006
vlan 1007
  name vlan1007
vlan 1008
  name vlan1008
vlan 1009
  name vlan1009
vlan 1010
  name vlan1010
vlan 1200
  switchport access vlan 120
  switchport access vlan 1200
N5548A(config)#


As you can see in above output once we change VTP mode we can see full vlan definition.


Summary

  • VTP v2 server mode - VLANs 1-1005 definition is stored in vlan.dat file, from VLAN 1006 above - in cofiguration file. In version 2 only range 1-1005 can be exchanged between VTP servers/clients (in version 3 all VLANs can be exchanged via VTP)
  • VTP v2 transparent mode - all VLANs are stored in the configuration