Setting up a Cisco port-channel

Setting up port-channels on a Cisco switch can sometimes be a real PITA due to your interface settings having to match the port-channel settings.  I’ve come up with a way to eliminate the config mismatches, which I’ll describe below.

First we clear the configuration on the interfaces that we’re going to add to our port-channel by doing a “default int gi1/1/1”

Then we add our interfaces to the port-channel and only then do we configure our port-channel, like so:

int gi1/1/1
channel-group <x> mode active
!
int gi2/1/1
channel-group <x> mode active
!
int po<x>
switchport mode trunk
switchport trunk allowed vlan 10,50,...
switchport trunk native vlan 999

This forces your interfaces to join the port-channel before any configuration is added to them. It also reduces the mistake of having mismatched configuration on both interfaces, which could cause independent members in your port-channel.

FortiAP does not broadcast on 5Ghz Radio–shows channel 0

I recently had a problem where a customer’s FortiAP 221C AP’s would intermittently stop broadcasting the SSID’s assigned to the 5Ghz Radio.

I had a look at the FortiAP profiles and saw that all channels were selected, including channels 149, 153, 157, 161 and 165.  I deselected those so that my configuration was as per below:

Once I did that the AP’s started broadcasting on 5Ghz again.  Not sure yet if this is a regulatory limitation due to my country code (ZA) or a bug.

sys diag kill command does not kill processes on a Fortigate

I recently had a Fortigate 1500D become bogged down due to the reporting daemon (reportd) utilizing 100% CPU.  I will not go into a lot of detail about diagnosing performance issues, as that is not the topic of this post.  Suffice to say that you’ll need to run the following commands to determine which process is misbehaving:

#get sys perf status
#diag sys top
#diag hard sys mem

Typically one would kill and respawn the offending process with the following command, where process_id is obtained via the diag sys top command.

#diag sys kill 11 process_id

Unfortunately in this case the kill command did not actually kill the process, and a reboot was not an option.  Fortunately I once had a remote session with Fortinet TAC where I saw them using some hitherto unknown (to me) commands.  So what follows is an unsupported way to absolutely kill processes dead.

The command we use is fnsysctl.  This command allows us access to a subset of Linux utilities, like cat, ls, kill etc.  In this case we’re interested in the kill command:

#fnsysctl kill –9 process_id

I have never had this command fail to kill a process, although I would recommend only using it as a last resort.

Happy Hunting!

Fortigate SSL VPN on multiple interfaces

There is an potential issue when setting up SSL VPN to listen on multiple interfaces on FortiOS 5.2.2 (have not tested on earlier versions).  When you create the first SSL VPN listener the Fortigate will automatically create a policy to allow SSL VPN traffic.  Due to the way the information is presented one can be excused for thinking the unit will do it for additional listeners as well.  The screenshot below shows how it looks when SSL VPN is enabled on multiple interfaces via the GUI:

 

These are the relevant bits taken from the configuration file:

config vpn ssl settings
    set idle-timeout 900
    set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
    set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1"
    set source-interface "MTN" "MTC"
    set source-address "all"
    set source-address6 "all"
    set default-portal "tunnel-access"
        config authentication-rule
            edit 1
                set source-interface "MTN"
                set source-address "all"
                set groups "VPN"
                set portal "full-access"
            next
        end
end

From the above it is clear that the listener has been added, but the authentication rule has not been updated.  The fix is simple, just add an additional authentication rule via the CLI:

config vpn ssl settings
config authentication-rule
            edit 2
                set source-interface "MTC"
                set source-address "all"
                set groups "VPN"
                set portal "full-access"
            next
        end
end

Your SSL VPN clients will now be able to connect on all interfaces specified in the GUI.

Symantec Data Loss Prevention Implementation Strategy

Data Loss Prevention (DLP) is fast becoming an key element in protecting an organization's data.  Access to information is critical to an organizations success, conversely the consequence of a data loss incident has never been higher than now. 

Despite the hefty price tag, a DLP solution often proves to be a relatively easy sell (we protect *all* your data against electronic leakage!).  Whilst a successful implementation can achieve those lofty goals, the devil is in the details. 

The most important requirement is to have complete buy-in from the business, in fact achieving a successful implementation will be absolutely impossible without input from all the stakeholders.  Secondly we need to realize that any DLP solution is an iterative process.  Lastly we need to have a proper implementation plan in place and this will be the focus of this post.

High-Level Process Overview

Identify Confidential Data and Data at Risk (Phase 1)

Create Policies (Phase 2)

Discover Data-at-Rest (Phase 3)

Protect the Endpoints (Phases 4 - 6)

Protect Data-at-Rest and Data-in-Motion (Phases 7 - 8)

Remediation and risk reduction (Phase 9)

Breakdown of Phases

Phase 1 - Identify Confidential Data

During this phase we will train DLP to indentify data that is critical and confidential to the business.

1. Involve relevant relevant stakeholders (compliance and risk officers, Heads of Departments, IT) to assist in identifying confidential data.

2. Obtain sample data based on the above

3. Introduce the sample data into the DLP Solution

   1. Sample data population for Exact Data Matching techniques (EDM) based policies

   2. Sample data population for Described Content Matching (DCM) based policies

   3. Sample data population for Indexed Data Matching techniques (IDM) based policies

   4. Submission of of positive and negative samples for Vector Machine Learning (VML)

Phase 2 - Policy Creation

1. Identify reporting an alerting audience

2. Create policies to alert based on the datasets submitted in Phase 1

Phase 3 Enable Data-at-Rest / Network Discover

During this phase we will enable the Network Discover component of Symantec DLP.  This allows us to scan data repositories on the LAN (File Servers / NAS's etc.) for policy violations.  We will only alert the DLP team during this phase.

1. Deploy Symantec Data Insight (if purchased as part of the DLP Suite) to assist with identification of data owners, as well as to monitor and log permissions and data accesses by end-users.

2. Configure Data Insight / DLP integration which will enable DLP to infer data owners based on intelligence gained from Symantec Data Insight.

3. Consult with stakeholders to identify all relevant data repositories on the network

4. Initiate a Network Discover scan of all the data repositories based on the previously created EDM, DCM, IDM and VML policies.

5. Re-iterate the process to fine-tune the policies and EDM, DCM, IDM and VML data-sets

6. Enable alerting to the relevant stakeholders and re-iterate based on feedback

Phase 4 - Pilot Deployment - Endpoints

During this phase we will only be monitoring.  Alerts will only be sent to the DLP team - no end user alerting or notification.

1. EDM Policy Implementation for pilot group

2. DCM based Policy Implementation on for pilot group

3. IDM based Policy Implementation for pilot group

4. Re-iterative review of DLP policies, EDM, DCM, IDM and VML data based on alerting and reporting

Phase 5 - Enable Prevent Mode for Pilot Group

During this phase we will actively start blocking and alerting on the endpoints.  Both the end-users and the DLP team will receive alerts and notification.  We will depend heavily on end-user feedback to further streamline our DLP policies.

1. Enable end-user notification

2. Fine tune DLP policies based on end-user feedback as well as alerts

3. Fine tune EDM, DCM, IDM and VML data based on end-user feedback

4. Re-iterate the process to reduce false-positives

5. Enable alerting to relevant stakeholders (Data owners, Heads of Departments etc.)

Phase 6 - Roll out the Endpoint Agent to all users

During this phase we will roll-out the DLP endpoint agent to all users.  Our policies and confidential data has been thoroughly fine-tuned so we can safely enable end-user alerting as well.

1. Ideally we should provide the end-users with DLP / Security awareness training during this phase

2. Deploy the DLP endpoint agent via the organization's preferred deployment mechanism (GPO / SCCM / Altiris etc.)

3. Further fine-tuning of policies and EDM, DCM, IDM and VML data-sets based on alerting and end-user feedback

Phase 7 - Enable Data-at-Rest / Network Prevent

During this phase we will activate the blocking mode of the Network Prevent component.  This will involve quarantining, copying, encrypting and/or applying DRM to sensitive and confidential data existing on your data repositories.  Alerting will be to the DLP team as well as the relevant stakeholders.

1. Verify all Data repositories configured within DLP during Phase 5

2. Create the necessary FlexResponse rules to automatically respond to incidents.

3. Actions include quarantining, copying, encrypting and/or applying DRM

4. Add the FlexResponse rule to your policies

5. Scan your data repositories

Phase 8 - Deploy Network Monitor and Network Prevent for Email and Web

During this phase we deploy the Network Monitor component, which operates via a mirror / SPAN port to capture Data in Transit incidents.  We will also deploy the Web and Email DLP components.  Alerting will be done to the the DLP team as well as the relevant stakeholders.

1. Install the physical DLP Network Monitor Server (This server cannot be virtualised as per Symantec)
2. Integrate the DLP Network Prevent for Email component with your existing MTA (DLP can operate in either Reflecting or Forwarding mode)

3. Integrate the DLP Network Prevent for Web component with your existing proxy server.  (The proxy server needs to act as an ICAP client to DLP.  Symantec DLP supports both the REQMOD and RESPMOD modes of ICAP)

4. Further fine-tuning of policies and EDM, DCM, IDM and VML data-sets based on alerting

Phase 9 - Ongoing remediation and reporting on risk reduction

This phase will be perpetual.  As incidents occur they will be re-mediated, and reporting to the relevant stakeholders will be set up and adjusted as necessary.  Your DLP solution is now fully deployed, and your policies and EDM, DCM, IDM and VML fingerprints will be continuously updated by the DLP team as business data changes over time.

How to enable Windows Server 2008 R2 to issue SAN certificates

The Certificate Authority in Windows 2008 R2 cannot issue Subject Alternative Name certificates in it’s default configuration.  Therefore if you include a SAN entry (like for Exchange) the CA will issue your certificate, but omit all the SAN entries

To allow your CA to issue SAN certificates you need to run the following from an administrative command prompt:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

This is not necessary on a Windows 2012 and above.

 

Symantec Data Insight 4.5 Overview

Symantec recently released version 4.5 of their Data Insight product.  In a nutshell, Symantec Data Insight allows an organization to:

• Identify who works with and owns their data
• Understand what unstructured data they have
• Maintain regulatory compliance for information access, use and retention
• Ensure information is protected from exposure to unauthorized individuals
• Review permissions on data and suggest changes

What’s New?

• Self-service portal allows data owners to remediate incidents directly without necessarily involving IT.
• Reporting enhancements
• Deep integration with Symantec Enterprise Vault and Symantec Data Loss Prevention
• Data Insight can infer ownership of a file and then add that intelligence to Symantec DLP
• Allows you to utilise Symantec EV’s file archiving and retention management capabilities when remediating incidents

To sum it all up, if you need to reduce the effort you spend on securing your data, enhance your data protection levels as well as achieve / prove compliance then Symantec Data Insight will go a long way to assist you in achieving those goals.