Thursday, March 28, 2013

Cisco Flexible Packet Matching (FPM) in 15.x

Cisco FPM on ISR router is about detecting a certain pattern (e.g. regular expression) in the payload packets before deciding whether to forward or drop it. One good example is to drop malicious packets and even Skype login that attempt to change its communicating methods over time. Your IPS signatures may not even be updated quick enough.

There is an easy-to-follow FPM guide on Getting Started with Cisco IOS Flexible Packet Matching. It even stated that almost all Cisco ISR platforms support this feature. I've learnt that only certain trains and versions can support FPM commands and they may not even be the latest versions. Use "Cisco Software Advisor" on "Feature/Software" tab to determine which IOS trains and versions support FPM. Of course, you'll need a CCO account to login.

In 15.x, there is also a change in loading FPM PHDF files. Not only you don't have to download the phdf files, there is a slight change in loading FPM PHDF files:

Router(config)#load protocol system:fpm
%Complete file name to be loaded is required

Instead, you'll have to do this
Router(config)# load fpm
Try to load bundle PHDF files ...

Then do a "show protocols phdf all" to see loaded phdf files. It should include all standard PHDFs: ether.phdf, ip.phdf, tcp.phdf, and udp.phdf. These PHDFs provide Layer 2-4 protocol definition according to Flexible Packet Matching Deployment Guide.

Nested Access Control
Cisco FPM supports nested access control policy i.e. enforce a child policy on parent policy. You can define a "class-map type stack" to check on the protocol fields and use another "class-map type access-control" to check on the payload contents. For example, you want to check for a password on the payload on protocol number 17 (UDP) on port 1234. The example config would be:

!--- Define the values to be checked on UDP header port 1234
class-map type stack match-all UDP-CHECK
 match field IP protocol eq 0x11 next UDP
 match field UDP dest-port eq 1234 next UDP

!---- Ensure the payload to contain the password string. You can also use regular expression
class-map type access-control match-all PASSWORD-CHECK
 match start UDP payload-start offset 0 size 100 string "password"

!---- Define the child policy and just log the packets if payload contains the password
policy-map type access-control CHILD-POLICY
 class PASSWORD-CHECK
   log

!---- Nested policy on Parent. Check on UDP header then the payload. Otherwise, drop the packet.
policy-map type access-control PARENT-POLICY
 class UDP-CHECK
   service-policy CHILD-POLICY
 class class-default
   log
   drop

!--- Enforce the FPM policy on the router interface
interface GigabitEthernet0/0
  service-policy type access-control output PARENT-POLICY


Thursday, February 28, 2013

Cloning Virtual Domain Controllers

A new feature of Windows Server 2012 is the cloning of Domain Controllers. This is a rapid way to deploy new Domain Controllers in virtual machine forms. The detailed step-by-step is outlined in Virtual Domain Controller Cloning in Windows Server 2012. I won't attempt to repeat all the details. Hence, I would summarize the steps for easy reference later.

Prerequisite Check:
  1. The hypervisor must support VM-GenerationID. Hyper-V running on Windows Server 2012/Windows 8 supports this feature and so do VMWare vSphere 5.x.  
  2. The source virtual DC must be running Windows Server 2012. 
  3. The PDC emulator role holder must be online and available to the cloned DC and must be running Windows Server 2012.
Step 1: Add source DC VM into "Clonable Domain Controllers" Security Group

Step 2: Check for applications and determine whether they should be cloned by running "Get-ADDCCloningExcludedApplicationList" cmdlet. If application is not supported for cloning, uninstall it. Otherwise, add the application to the inclusion list (CustomDCCloneAllowList.xml). The list can be generated with the same cmdlet with "-GenerateXML" option.

Step 3: Run "New-ADDCCloneConfigFile" cmdlet on source VM to run a list of prerequisite checks as mentioned above. It would also generate "DCCloneConfig.xml" file that contains a list of settings to be applied to the cloned DC, including network settings, DNS, WINS, AD site name, new DC name etc. The xml file is contained at the "%Systemroot%\NTDS" folder. These new settings can be specified with the same cmdlet input with the necessary options. For example:
New-ADDCCloneConfigFile -IPv4Address 10.2.1.10 -IPv4DefaultGateway 10.2.1.1 -IPv4SubnetMask 255.255.255.0 -IPv4DNSResolver 10.1.1.10,10.1.1.11 -Static -SiteName CORPDR

Step 4: Shut down the source VM and export it out using "Export-VM" cmdlet e.g. Export-VM -name sourceDC -Path D:\ClonedDC.

Step 5: Import the VM by running "Import-VM" cmdlet e.g. Import-VM –Path {VM XML Path} –Copy –GenerateNewId –VhdDestinationPath D:\ClonedDC. You can also rename the new VM using Hyper-V manager. Start the newly cloned VM.

Tuesday, February 12, 2013

New MS2012 Dynamic Access Control (DAC) for BYOD?

One major new feature in Windows Server 2012 is the introduction of Dynamic Access Control (DAC). At the first glance, it seems to be replacing or enhancing the traditional NTFS ACL. In fact, it's neither. In traditional file shares, the access control is typically controlled by both share permissions and NTFS ACL. DAC is an add-on feature on top of these existing access control mechanisms. For example, you may allow a group of finance executives to access a sensitive finance file share from their managed workstations. But what if the corporate policy forbid them for doing so when they are accessing from mobile or personal devices? This is where DAC comes in.

In DAC, you can create access rule that is expressed in "if-then" statement. Using the same example, you may express the policy as "If the user clearance is high and the user department is finance; and accessed from a managed finance device, then the user can access finance files and folders classified as having high business impact". See below illustration:


I won't attempt to go through the detailed step-by-step in implementing DAC, as there is already a dedicated blog for DAC at http://www.dynamic-access-control.com/. I would just summarise the steps as follows:

On a Windows Server 2012 domain controller:
  1. First, ensure that the domain functional level is Windows Server 2012, as expanded Kerberos with claim-based information is required. Enable "KDC support for claims, compound authentication and Kerberos armoring" using Group Policy on Domain Controllers OU.
  2. Define the user and device claims types using the new "Active Directory Administrative Center (ADAC)" under "DAC - New Claim Types". For example, you may like to define the new User.Department and Device.Managed attributes. You may even provide a list of values such as "Engineering", "Finance", "IT" for User.Department. 
  3. Define the new Resource Properties for the files and folders using the same ADAC console. In this case, you may want to define Resource.Department and Resource.Impact. Add the resource properties to the pre-defined "Global Resource Property List".
  4. Create a new central access rule e.g. using earlier expression as example.
  5. Create a new central access policy and add the central access rule into it. This new central access policy has to be enforced by the file servers mentioned later.
  6. Tag the user account objects using attribute editor in "AD Computers and Users" console e.g. department etc.
  7. You may also want to tag the computer attributes. Do note that Windows 8 is required for claim-based devices.

On a file server running Windows Server 2012:
  • The earlier steps have created Central Access Policy on AD. However, the enforcement has to be performed on individual file server.
  • Add new Windows Feature "File Share Resource Manager" using Server Manager or Powershell
  • Run PS cmdlet "Update-FSRMClassificationPropertyDefinition" to  synchronizes the classification property definitions on the file server with the Resource property definitions on AD
  • You may perform Manual Classification by setting the resource property (Classification tab) on the file and folder properties directly.

  • Alternatively, you may perform "Automatic Classification" by creating Classification Rules on "File Server Resource Manager". You may set the rules to be run at fixed interval.
  • After file tagging and classification, deploy and enforce the earlier created central access policy on the file server. You can find a new "Central Policy" tab on the "Advanced Security Settings" of the share folder
  • You may also test-run the deployment using the "Effective Access" tab (left of Central Policy tab as above)
As for rolling out DAC incrementally, this is what Microsoft would recommend in summary:

Monday, February 4, 2013

Moving WSUS Content Store

The content of WSUS is growing exponentially and the storage is nearly full. To move the existing content to a bigger LUN, Wsusutil.exe is the program. To execute the move, prepare the new destination folder and use this command:
Wsusutil.exe movecontent {new location} {log file}  [-skipcopy]

Use the -skipcopy option, if you do not wish to copy existing content over. For example, if the new location is at D:\content, the command should be:
Wsusutil.exe movecontent D:\Content D:\move.log

For Windows Server 2008, the location of Wsusutil should be at "C:\Program Files\Microsoft Windows Server Update Services\Tools". For Windows Server 2012, you should be able to find the executable at "C:\Program Files\Update Services\Tools".

Tuesday, January 29, 2013

SQL 2012 Installation: Missing NetFx3

When I installed MS SQL Server 2012, there was an error "Error while enabling Windows feature: NetFx3". NetFx3 refers to the .NET framework 3.5. 

However, .NET framework 3.5 is no longer installed as part of the new WS2012. To install this older feature, you would have to perform side-by-side (SxS) installation. Mount the WS2012 DVD or the ISO image on the same host. Do note that you can now mount ISO image directly without third-party software by right-clicking the image and choose "Mount". 

Open an elevated Powershell console. To install the Windows feature:
Add-WindowsFeature NET-Framework-Core -source D:\sources\sxs

Once .NET 3.5 is installed, re-run the MS SQL installation. If you are also looking for the missing "Start" button to search for the SQL Server Management Studio, install the "Desktop Experience" feature as well:
Add-WindowsFeature Desktop-Experience

Wednesday, January 9, 2013

Prevent Users from joining Computers to AD

From a security standpoint, it would be pretty hard to control if normal domain users can join their machines to AD without authorization. By default, a user may join up-to 10 computers to AD.

Depending on your organizational security policy, users should only self-help themselves (or restricted to help-desk personnel) with proper authorization. To enforce such policy:

1) Limit the number of computers that a user can join domain from ten (10) to zero (0) by performing the following procedure. 
  • Run Adsiedit.msc on a domain controller as Domain Admin. Expand the Domain NC node. This node contains an object that begins with "DC=" and reflects the correct domain name. Right-click this object, and then click Properties.
  • In the Select which properties to view box, click Both. In the Select a property to view box, click ms-DS-MachineAccountQuota.
  • In the Edit Attribute box, change the number from 10 to 0.
  • Click Set, and then click OK.
2) Before joining any new computers to AD, enforce a pre-staging procedure. It means pre-creating the computer objects on AD before joining the computers to domain. Do note that the computer name of pre-created object should match the local computer name of the new machine.
  • To conduct pre-staging, fire-up "AD Users and Computers Console", go to the OU that the pre-staging computer objects should reside.
  • Click "New" and "Computer". Name the object. Click on the "Change" button as follows to the delegated AD group for help-desk personnel or to the individual self-help user account.

  • Inform the delegated users to join the new computer according to the object name. Upon successful joining, you should be able to view the computer properties, such as the Operating System versions.

Tuesday, January 8, 2013

Updating Powershell Help Files

When needing help in some Powershell cmdlets, the Get-Help cmdlet is the equivalent "man" command for *nix systems. The Powershell cmdlets are updated so frequently that it is worthwhile updating the help files as well. If the Windows host is connected directly to Internet, the help file would be updated automatically. What about for systems on closed network? There is a "Save-Help" cmdlet to download the help files and "Update-Help" cmdlet for systems not connected to Internet.

For example, run "Save-Help" from a Windows system with Internet connection to download help files for all modules to a file share.

PS > Save-Help -DestinationPath \\Fileserver\PSHelp

Run "Update-Help" on a Windows system without Internet connection.

PS > Update-Help -SourcePath \\Fileserver\PSHelp

Both cmdlets are available to Powershell 3.0. To verify the current version of Powershell of your system, run "$PSVersionTable" and look at the "PSVersion" property. For example: