09/04/13

Configuring Cisco ISE 1.2 and StealthWatch Integration

Due to changes in the integration of Cisco Identity Services Engine (ISE) and StealthWatch the following must be completed to reliably receive user and device information.  The key change is that StealthWatch now receives data via Syslog instead of solely through the ISE API.  This allows the system to scale and greatly improves the reliability of the user and device information.

Configuring ISE Services:

It is necessary to configure the Cisco Identity Services Engine to send specific syslog messages to the StealthWatch system, specifically to the SMC.  The following procedures are required on the ISE server.

  • Target Type:  UDP Syslog
  • Status: Enabled
  • Name: Required
  • IP Address:  IP Address of SMC
  • Port:  Specific port (Recommended is 3514)
  • Max Length:  I usally do 4096 due to profile and additional information.  This may not be required but it does not hurt anything.

 

 

 

 

 

Next setup the following logging categories to send information to StealthWatch:

  • Radius Accounting
  • Administrative and Operational Audit
  • Profiler

 

 

 

 

 

 

 

 

Configuring StealthWatch Services:

The configuration of StealthWatch it is very straightforward for configuring ISE. The following procedures are required to complete the integration of ISE:

  • Name:  <pick a name>
  • Collection Port:  The same you used above, 3514 is the default
  • User Name:  Admin or another user on ISE.  Suggest a dedicated account.
  • Password:  The very complex password configured for the user above.

Now you need to add the different nodes in the deployment to the cluster.  It is recommended that you add ALL nodes to the cluster:

Name:  Name of the node
IP Address:  IP Address of the node

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This completes the required configuration of ISE. Now the user and device identity will be sent via syslog and can be seen in the Identity and Device Table within StealthWatch. (As seen below)

 

Caveats:

The certificate for ISE must be trusted by StealthWatch. You may need to import the certificates into the two systems for the trust to exist. Better yet all ISE and StealthWatch servers should be part of the internal PKI infrastructure to inherently allow this trust.

01/17/13

Permalink 08:34:50 am, by Brandon Culler Email , 307 words
Categories: Cisco ASA, Cisco AnyConnect

AnyConnect Secure Mobility Client version 3.1 - Untrusted VPN Server blocked

With the increase of targeted attacks against mobile users on untrusted networks, Cisco has improved the security protections in the AnyConnect Secure Mobility client version 3.1 to help prevent serious security breaches. The default client behavior has been changed to provide an extra layer of defense against man-in-the-middle attacks.

When the user tries to connect to a secure gateway, and there is a certificate error (due to expired, invalid date, wrong key usage, or CN mismatch), the user sees a red-colored dialog with Change Settings and Keep Me Safe buttons.

Untrusted-Server

Clicking Keep Me Safe cancels the connection (Recommended – See Recommendations below).

Clicking Change Settings opens AnyConnect's Advanced > VPN >Preferences dialog, where the user can enable connections to untrusted servers.

AnyConnect-Block-Server

If the user un-checks Block connections to untrusted servers, then the next time the user attempts to connect to this secure gateway, the user will not see the Certificate Blocked Error Dialog dialog; they only see the following dialog:

AnyConnect-Untrusted-Server-Accept

If the user checks Always trust this VPN server and import the certificate, then future connections to this secure gateway will not prompt the user to continue. (Not Recommended)

Recommendations:

You do not want your end users in the habit of ignoring these types of warnings, we strongly encourage following best practices.  You should generate a Certificate signing request to be signed by a trusted 3rd Party Certificate Authority.  Import the signed certificate onto your VPN appliance to avoid your end users changing the default setting, which is designed to keep them safe.

There is no administrative override to make the end user more secure automatically. To completely remove the preceding security decisions from your end users, enable Strict Certificate Trust in the user's local policy file. When Strict Certificate Trust is enabled, the user sees an error message, and the connection fails; there is no user prompt.

11/08/12

Permalink 03:38:21 pm, by Brandon Culler Email , 552 words
Categories: Cisco Security, Cisco ACS

Cisco ACS v5 should be able to query only desired Domain Controllers – Active Directory/DNS Workaround

Background:
Currently in ACS 5.x, ACS queries DNS in order to get a list of all the Domain Controllers in the domain

 

In a typical Enterprise deployment, it would be common to have a Domain Controller at each local site. More than likely, ACS will be located in datacenters geographically distributed around the globe. The goal is to have ACS authenticate against the local Domain Controller in the same Datacenter.


Issues:

ACS uses DNS to determine which Domain Controller to authenticate each attempt. This default behavior will result in ACS authenticating against every Domain Controller in your environment. See Cisco Bug ID CSCte92062 for additional details.

 

Example Config

(Ex.) Sample ACS configuration: Sample Site: Charlotte, NC

ACS located in Charlotte, NC CLT0 Servers CLT0DC01

Hostname = CLT0-ACS01

IP Address = 192.168.1.10 Sample Site: Redditch, UK

Subnet Mask = 255.255.255.0 BHX0 Server: BHX0DC01

Default Gateway = 192.168.1.1


Validation: Pre-Change

To perform the next set of test, you must be running a minimum code release of 5.4.0.46. From CLI, issue the following command: acs troubleshoot adinfo -a

 

CLT0-ACS01/admin# acs troubleshoot adinfo -a

This command is only for advanced troubleshooting and may incur a lot of network traffic

Do you want to continue?  (yes/no) yes

Local host name:   CLT0-ACS01

Joined to domain: demo.local

Joined as:         CLT0-ACS01.demo.local

Pre-win2K name:    CLT0-ACS01

Current DC:        BHX0DC01.demo.local(this Domain Controller was in Europe, this ACS is in Charlotte, NC)

Preferred site:    <unavailable>

Subnet site:

Warning! Unable to locate computer's subnet site in Active Directory.

Please advise your system administrator.

Zone:              NULL

Last password set: 2012-10-17 10:58:48 EDT

CentrifyDC mode:   connected

Licensed Features: Enabled

 

Workaround:


Step 1:

In Active Directory: Sites & Services à Subnets: You will need to create a “subnet” in which each ACS resides


Step 2:

In Active Directory: Sites & Services à Sites: You will need to map that same subnet to the appropriate “site”. This should be the site in which you want ACS to authenticate against the desired/local Domain Controllers.


Step 3:

After you have allowed enough time for replication, Disjoin & Rejoin ACS to the Domain. This step will rejoin ACS to the appropriate Domain Controller

· Create a subnet: 192.168.1.0/24

· Edit the CLT0 Site & Add the Subnet: 192.168.1.0/24


Validation Post Change:

From CLI, issue the following command: acs troubleshoot adinfo -a

CLT0-ACS01/admin# acs troubleshoot adinfo -a

This command is only for advanced troubleshooting and may incur a lot of network traffic

Do you want to continue?  (yes/no) yes

Local host name:   CLT0-ACS01

Joined to domain: demo.local

Joined as:         CLT0-ACS01.demo.local

Pre-win2K name:    CLT0-ACS01

Current DC:        CLT0DC01.demo.local(this Domain Controller is in the Charlotte Datacenter)

Preferred site:    CLT0 (the correct server this is mapped to in AD Sites & Services)

Zone:              NULL

Last password set: 2012-10-17 10:58:48 EDT

CentrifyDC mode:   connected

Licensed Features: Enabled


Conclusion:

By utilizing AD Sites & Services, we are able to have ACS authenticate against the desired Domain Controller(s).

Please note – Cisco ISE uses DNS in order to get a list of all the Domain Controllers in the domain and then authenticates against all of them. This same concept of utilizing AD Sites & Services will ensure Cisco ISE authenticates against the desired Domain Controller vs. any random Domain Controller in the environment.

01/12/12

Permalink 10:59:41 am, by Fred Parks, 904 words
Categories: Tivoli Endpoint Manager/BigFix, Cisco NAC

Changing Tivoli Endpoint Manager service startup from Automatic (Delayed Start) to Automatic

Background

While working in an environment with TEM (IBM's Tivoli Endpoint Manager - formerly BigFix) and Cisco's NAC (Network Admission Control) technology, I ran into an issue with Windows 7 machines not being allowed to pass through NAC after a TEM client upgrade. In this environment NAC is configured to not allow a workstation access to the network unless the TEM client is installed and running. After upgrading to the latest version of TEM and pushing out the client upgrade, several Windows 7 users reported that they were failing a NAC check. After further investigation I found that the service startup for the "BESClient" (The service name is still BESClient as of version 8.2.1093.0 even though the product has been renamed from BigFix to Tivoli Endpoint Manager) service was set to "Automatic (Delayed Start)" instead of "Automatic." The service would eventually start and work fine but the NAC check was occurring before the machine got around to starting the BESClient service.

Delayed Automatic Start Info

Delayed Automatic Start is a feature that has been around for a while (since Vista) that allows non-critical services to load later in the boot process thereby allowing the computer to spend CPU cycles on critical services and improve the speed which the computer is available to be logged on. For more information on this feature, check out the following link from Microsoft's Performance Team blog - WS2008: Startup Processes and Delayed Automatic Start

In most environments there probably wouldn't be an issue with the TEM client service starting up a little later but in this case we need to make some changes so that users can go through NAC successfully.

Changing the Startup Type of the BESClient Service

The BESClient service is set to delayed start by the presence of a DWORD registry value named "DelayedAutoStart" with a decimal value of 1 in the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" of the registry. To disable Delayed Automatic Start and just have the service start type as Automatic the value of "DelayedAutoStart" should be set to 0.  You can test this out by opening up the services management console on a machine and changing the startup type between Automatic and Automatic (Delayed Start) and seeing the registry value change.

If you change the value through the registry, the services management console will not update the startup type until after a reboot (at least from my experience). The machine will use the new value on the next boot and since the value really doesn't come into play until boot time I didn't see the services console not updating as a big issue.

Deploying the Change Through a Fixlet

I created a fixlet to make the change across the environment as a whole and have posted the sample relevance and action scripts below. You can modify this for your environment or to improve the relevance as you wish.

Relevance

The relevance below will check for a machine running Windows Server 2008, Windows Server 2008 R2, or Windows 7 (If you have Vista in your environment then just add that in). Then it will check to see if the machine has the registry value named DelayedAutoStart with a value of 0. The relevance will evaluate to TRUE if the machine either does not have the value at all or it does not equal 0 (and the machine is one of the OS's listed).

(it = "Win2008" OR it = "Win2008R2" OR it = "Win7" ) of name of operating system AND (not exists key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" whose (value "DelayedAutoStart" of it = 0) of registry)

Action

The action script is very simple and just makes the change in the registry to set the DelayedAutoStart value to 0. It does not matter if the value exists or not, the action script will set it to 0. You could put in "action requires restart" at the end but there's no reason to have the machine reboot since the change won't be processed until the machine boots anyway.

regset "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient]" "DelayedAutoStart"=dword:00000000

Conclusion

You can use this information to build a fixlet to work with any service, not just the BESClient service. This also applies to any type of NAC, Network Admission Control or Network Access Control technology that checks for running processes/services before allowing access to the network. If you are using a different systems management application than TEM then the same methodology applies - you'll just have some different implementation steps.

When you deploy the action for the fixlet shown above I recommend that you make it a "policy" (no start or ending constraints, action reapplies when relevant again, no reboot, no messages) and target all hosts. That way when you perform the next TEM upgrade you won't have to go through all this again.

 

Further Resources

Link to the Fixlet Debugger that you can use to test out your relevance and action scripts before rolling them out. Also has other resources for writing fixlets.

Release notes from BigFix on version 8.1 that mention changing the default startup behavior of the client. There is also mention of a command line parameter for the initial installation of the client that can change the default behavior but it does not change the behavior on upgrades.

Microsoft's Performance Team blog

04/18/11

Permalink 09:52:36 am, by Fred Parks, 154 words
Categories: Security Advisories, General Security

Security Patch Breaks Printing in Outlook 2007 - Recalled by Microsoft

Anybody who installed Kb2509470 last week and happened to have Outlook 2007 may have run into a rather bizarre issue trying to print from Outlook. When attempting to print or generate a print preview from within Outlook, the user would get the error message "There is a problem with the selected printer.  You might need to reinstall this printer.  Try again, or use a different printer." No doubt that countless hours have been spent attempting to resolve the problem from the printer/print driver side of things but the resolution is to remove the update and the problems will immediately cease.

There are several posts on the TechNet forums about this issue, where critical mass from the user community seemed to build up over the weekend. Microsoft has pulled the update and as of this morning has updated the KB article page stating they will re-release a corrected security update (http://support.microsoft.com/kb/2509470).

1 2 3 4 5 6 7 8 9 10 11 ... 41 >>

Priveon, Inc.

Today's complex security and networking solutions require a great deal of knowledge to successfully support and operate. Priveon uses the field experience of its expert staff to develop and maintain a positive reinforcement loop between business practices and to provide the latest information to our customers. The information posted here is supported by Priveon subject-matter experts.

Search

XML Feeds

Archives