Disabling the Symantec DLP Agent notifications

I’ve been branching out from the normal infrastructure stuff I’ve been doing into more security oriented fields.  Part of what I now do includes Data Loss Prevention, and I’m proud to say that I’ve recently completed my first Symantec DLP deployment.  It also happened to be the first deployment in Africa, outside of South Africa.

By default the Symantec DLP endpoint agent displays a notification when it scans for sensitive content, like so:

In this case the customer did not want to let the end-user see what was going on so we had to disable.  Unfortunately this seemingly simple UI option is not so simple – here is what you have to do

Log into the DLP Console.  Go to System -> Agent Configuration

-> Edit config -> Advanced Agent Settings

Set the UI.NO_SCAN.int to any value other than 0 and the scan dialog will not be displayed.

All Fortigate FSSO users are placed in the FSSO_guest_users group

Getting AD authentication going on a Fortigate is a slightly finicky, but well documented process and once you get it working it works well.  If it’s something you battle with, leave a comment and I’ll do a HowTo.

That said I recently had an issue with a Fortigate unit that absolutely insisted on putting all FSSO users in the FSSO_guest_users group, which means none of my Policies using authentication was working.  This is what the Fortigate saw my logged on users as:

The fix in the end was fairly simple, turns out that on the Fortigate I had the groups configured in Advanced mode, like so: CN=Internet Access,OU=Security Groups,OU=Head Office,DC=corp,DC=root. 

The Collector Agent, however, was configured to use Standard mode.  The fix was to switch the FSSO Collector Agent Directory Access Mode to Advanced Mode.

Once the change was made I refreshed the FSSO groups on the Fortigate via the “execute fsso refresh” command and all was well again.

For those of you keeping notes, the Fortigate was running FortiOS v5 Patch 6 and the FSSO agent was v4.0 MR3 B0151

“Unable to launch RDP native” using Fortigate SSL VPN Portal

Recently we started receiving calls from our Fortigate customers that they cannot launch RDP sessions from within their web portal.  After a bit of troubleshooting I discovered that this was caused by a recent Java update (Java 7 Update 51).  More information can be found here, here and here.

The exact error looks like this:

Workaround

The workaround in this case is very simple, just add your Fortigate Portal address to the Exception Site List in your Java configuration, like so:

More information about the exception list can be found here.

Configuring a 4G USB modem on a Fortigate Firewall

Fortigate is a deserved market leader in the UTM space, but as with all products there is always room for improvement.  Point in case is getting a 3G / LTE connection via a USB dongle up and running.  There is minimal support in the GUI, and they’ve removed a lot of options in FortiOS 5.

Fortunately for an old Cisco hack like myself we’ll always have the CLI to fall back to so below are the steps to get it up and running.  Note that the below is for a device that is on the Fortigate HCL.  If yours is not then you’ll have to configure that first.

config system modem
    set status enable (Enables the modem functionality)
    set pin-init "at+cpin=1111" (If you have PIN security, I tend to disable the SIM PIN check)
    set dial-on-demand enable (self-explanatory)
    set phone1 "*99#" (replace *99# with whatever your dial-up number is)
    set extra-init1 "at+cgdcont=1,\"ip\",\"internet\"" (replace internet with your APN)
    set altmode disable (enable if you're in China, rest of the world disable)
end

VLAN Up, Line Protocol Down

Creating a VLAN and a SVI

Today, not for the first time, I was asked to troubleshoot a issue with an SVI (Switch Virtual Interface) not coming up.  The customer had created a SVI like so:

switch# conf t
switch (config)# int vlan 10
switch (config-if)# ip address 192.168.10.1
switch (config-if)# no shut

The problem was that the SVI stayed down, and the VLAN did not even show up when you do a “sh vlan”.  Why did this happen?  Because the customer created the SVI without first creating the Layer 2 VLAN for it to live in.  Here is what the customer should have done:

switch# conf t
switch (config)# vlan 10 ***this creates the layer 2 VLAN***
switch (config-vlan)# name VLAN_NAME
switch (config-vlan)# exit
switch (config)# int vlan 10 ***this creates the layer 3 SVI for the VLAN***
switch (config-if)# ip address 192.168.10.1 ***assigns the IP and netmask to the SVI***
switch (config-if)# no shut

Now if we do a “show vlan” it should show as active.  Whilst we’re on this topic, let’s have a look at what exactly is required for a SVI to come up and be ping-able on your network.

Requirements to get a SVI to the Up/Up state

An SVI must meet all of the below requirements to transition to the “Up/Up” state

• Its VLAN must exist and show as active in the VLAN database “sh vlan”
• One switched port in the VLAN (can be access or trunk) must be up
• The port must be in a STP forwarding state

Handy WMI GPO filters

I thought I’d document a couple of WMI filters I’ve found handy when deploying software via Group Policy Objects (GPOs).  Windows Management Instrumentation (WMI) filters allow you to dynamically determine the scope of GPO based on attributes of the target computer.

When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running Windows 2000, in which case the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true, the GPO is applied.

Target Windows 7 32-bit machines

select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"

Target Windows 7 64-bit machines:

select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND OSArchitecture = "64-bit"

Target any 32-bit OS:

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='32'

Target any 64-bit OS:

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='64'

Target Windows 7, Vista, Server 2008, Server 2008 R2 

select * from Win32_OperatingSystem where Version like "6.%" '

Target Windows 7, Server 2008 R2

select * from Win32_OperatingSystem where Version like "6.1%" '

Target Windows Server 2003

select * from Win32_OperatingSystem where Version like "5.2%" '

Target Server 2003, but not domain controllers

select * from Win32_OperatingSystem where Version like "5.2%" and ProductType="3" '

Target Server 2008 and 2008 R2, but not domain controllers

select * from Win32_OperatingSystem where Version like "6.%" and ProductType="3" '

Note:  Substitute ProductType="3" ' with ProductType="2" ' to just target domain controllers.

Schedule a Reload on a Cisco Router

Who hasn’t been in the situation where you have to make changes to a Cisco devices that you do not currently have physical access to. Fun and games until you fat finger something and lose access to the device. 

An easy way around this is to schedule a reload of the device before you start making changes.  That way if something does go wrong the device will reload and come up as before.  Of course if the reload is not required you can cancel it.  Below is the steps needed to achieve all that.

Cisco_Switch#copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Cisco_Switch#reload in 015
Reload scheduled in 15 minutes
Proceed with reload? [confirm]
Cisco_Switch#reload cancel
Cisco_Switch#

***
*** --- SHUTDOWN ABORTED ---
***

Cisco_Switch#