Blog

The Dallas Region of the FDIC conducted a conference call today (October 8, 2008) entitled "ID Theft Responsibilities - FACTA Red Flag Guidance."  The call consisted of a presentation including an overview of the regulation and guidelines, exam procedures, and what examiners will be looking for, followed by a question and answer session.  The FDIC presenters were:

  • James Brignac, Regional Office IT Examination Specialist - Risk Management
  • Jeff Kopchik, Technology Supervision Branch Senior Policy Analyst

The call was not recorded, but attached you will find a copy of the PowerPoint slides used during the call in Adobe pdf format.

FACTA ID Theft presentation.pdf (165.52 kb)


 

I recently experience a problem with the RDP client not passing the %clientname% variable when setting up a Thin Client running Win CE 6.0. 

Further investigation shows that the issue of the environment variable %clientname% not being passed through to the Terminal Server does not have anything to do with Win CE 6.0. The issue was caused by the specific build of RDP 6.0 that was included on the image of the new shipment of Thin Clients running Win CE 6.0. The specific build included on this image was RDP 6.0 build 9.  [more]

When I checked, there was a new image available for the HP thin clients from HP’s website. The new image included an updated build (14) of  RDP 6.0. This build does pass through the %clientname% environment variable and allows the scripts to function normally. Build 14 of RDP 6 was not available individually as a download from HP’s site. That means the only option at this time is to reload the entire image on the thin client.

When you download and runn the exe you will be given the option of creating an ISO, copying to a USB drive, or deploying the files to a network. I copied the files to a USB drive and then booted the TC to the USB drive. Note: that the USB copy completely formats your USB flash drive erasing any pre-existing data.


 

I recently ran into a problem on one of our websites where users’ authentication was timing out before the amount of time I had set in the configuration.  I was using ASP.NET forms authentication with the timeout set to 30 minutes and sliding expiration set to true.  After some investigation this turned out to be a two part problem.

This first cause I found was that the sliding expiration functionality for forms authentication isn’t exactly intuitive.  When sliding expiration is turned on, each time a web page is requested, the user’s authentication cookie timeout is supposed to be updated to the expire in X minutes from the time of the page request.  However, even though you set a timeout of X minutes it is perfectly normal for a users authentication ticket to expire before that time limit due to the sliding expiration is implemented in the .NET framework.  From the MSDN .NET Framework Reference:

“If the SlidingExpiration attribute is true, the timeout attribute is a sliding value, expiring at the specified number of minutes after the time the last request was received. To prevent compromised performance, and to avoid multiple browser warnings for users that have cookie warnings turned on, the cookie is updated when more than half the specified time has elapsed. This might result in a loss of precision.”

Basically, if the timeout is set to 30 minutes then the expiration time of the authentication cookie is only updated if 15 minutes have passed when a request is made. [more] If a user signed in at 8:00 and requested a page at 8:14 you would think that their authentication would timeout 30 minutes after their last request at 8:44, but instead it would actually timeout at 8:30.  So if you want the timeout to for sure be at least a certain number of minutes you can increase the timeout to twice the desired time, or write your own code to refresh the cookie after each page request.

The second cause of the problem that I found was that the settings on the Application Pool in IIS was causing the ASP.NET worker process to be recycled after a number of minutes and shutdown after 20 of being idle.  I changed the worker process to recycle at a set time during off peak hours instead of after a number of minutes had passed. I also increased the number of idle minutes before the worker process would shutdown.  I included screen shots of the settings below.

 


 

I recently started reevaluating how we do port security as a result of a recent customer's information security audit.  We normally turn on port security and set the maximum MAC addresses to 1 (the default) or 2 (if there is an IP phone connected).  The default behavior is to disable the port when the MAC changes or if the number of concurrent MAC’s exceeds the maximum.

However during testing I discovered this didn’t work exactly like I expected.  Port security was enforced as long as a device stayed connected to the port.  If the port was disconnected, the switch would remove the pre-existing MAC’s and ANY new device could connect, as long as the maximum was not exceeded.  While this prevents unauthorized hubs and switches, it doesn’t prevent someone from unplugging a device and plugging in a different unauthorized device.

The solution to this is to use the sticky option on the port security interface command: [more]

  • switchport port-security – enables port security, optional “maximum <n>” to set the max greater than 1
  • switchport port-security mac-address sticky – turns on the sticky MAC feature

After enabling, you will notice the currently connected MAC address(es) will appear in the running config:

  • switchport port-security
  • switchport port-security mac-address sticky
  • switchport port-security mac-address sticky 0080.6433.xxxx

This will stay in the config until the switch is rebooted, so it’s important to write the config.

Other related commands:

  • show port-security address – lists all the learned MAC addresses by interface
  • show port-security interface fa0/1 – shows the detailed port security settings for an interface, including enable/disable status
  • clear port-security sticky interface fa0/1 – clears the learned sticky MAC addresses, must be done prior to a shut/no shut to re-enable a port disabled due to port security

When you use sticky MAC addresses you'll want to make sure that the MAC addresses are cleared off of a switch when a device is moved.  We had a laptop that was moved from one client location to another and one of the distribution switches was thinking the device was plugged into the old switch and the other distribution switch thought it was plugged ito the new switch.  This created a situation where some network traffic was reaching the laptop and some was going into a black hole.  After clearing the the sticky MAC addresses on the old switch the problem was resolved.

Update:  You might also be interested in a couple stick MAC address tips.


 

Incase you didn't know, there is a command line interface for WMI - wmic.

Some documentation is here http://technet.microsoft.com/en-us/library/bb491034.aspx, and http://technet.microsoft.com/en-us/library/bb742610.aspx.

You can write simple scripts to manage just about anything that your might write a short VB program for – printers, accounts, scheduled jobs, processes, etc. It has a lot of aliases you can use that are documented in the online help, but you can use the actual class commands.  If you just enter wmic on the command line and let it prompt, it sets your command window width to 1500 so output from most commands will not wrap.  You can enter /? At any point for help.  Some examples: [more]

  • wmic process get Caption,Commandline,Processid
  • wmic /node:server1 cpu get description, manufacturer, maxclockspeed, revision
  • wmic process where name='iexplore.exe' call terminate
That last one kills all processes running iexplore.exe.  If you just ran that to see what it would do without reading ahead, then chances are you are not reading this right now.

 

 


 

Microsoft Office uses various types of password protection.  In general, passwords used to limit modification of documents are reasonably weak and can be cracked easily (and immediately) with tools such as Office Key (from www.lostpassword.com).  Passwords required before a file can be opened usually require brute force type cracks but until I did some research, I still didn't know how strong the encryption was for these types of protection. [more]

There is also an online service (www.decryptum.com) that offers document recovery for about $29/document in many cases.  The service will show you part of the decrypted document before you have to pay for the whole document decryption process.  If they can't decrypt it, you don't pay.  However, it seems to work pretty well.  I tested it with a simple Office 2003 document that required a password to open.  Within about 30 seconds, they showed me the first two lines of the document's contents (which, in this case was the whole document).

Note - this does not work with 2007 XML formats - only with previous versions of Office documents.  That is consistent with Microsoft's warning that encryption with older versions of office is not as strong as it is with native mode 2007 documents.

The online document recovery process does not determine what the password is.  It just involves removing the password requirement altogether.

Of course, you would want to be very careful with confidential documents…

This came up in a recent audit where the bank was using password protected Word and Excel files for security measures.  We determined this isn't a suitable method for securing documents they send via e-mail.


 

October is National Cyber Security Awareness Month!

Each year, the National Cyber Security Division (NCSD) of the Department of Homeland Security (DHS) joins with the National Cyber Security Alliance (NCSA), the Multi-State Information Sharing and Analysis Center (MS-ISAC) and other partners to support National Cyber Security Awareness Month, a national campaign focused on educating the American public, businesses, schools and government agencies about ways to secure their part of cyber space, computers and our nation's critical infrastructure.[more]

The goal of National Cyber Security Awareness Month is to educate everyday Internet users on how to "Protect Yourself Before You Connect Yourself", by taking simple and effective steps.  These steps will teach Internet users how to safeguard one's computer from the latest online threats, offer ways to respond to potential cyber-crime incidents, and link how each person's cyber security affects securing our nation's critical infrastructure.

Below are a few links related to National Cyber Security Awareness:


 

One of our customers was having problems reported by their terminal server users last week where their remote core systems were being very slow and having disconnects.  In the past, they have rebooted routers, terminal server, and their domain controler to get it to working much better but eventually it would slow way down again.  After doing a reboot of the equipment last week, the users again reported that it was very, very, very slow a few days later.  There was a Symantec Premium Anti-spam process running last week that I thought to be the culprit, but it looked to be running okay on the DC this time. [more]

I decided that I had better check the Internet connection speed using a speed test from cnet.com.  Their results were an abysmal 53 kbps (this is in the dialup range folks).  I asked them to call their ISP and get them to check the line.  They found problems with the cable modem (one, that it was very ancient) and replaced it.  After the hardware replacement, things are running much smoother.

In summary: It never hurts to perform an Internet speed test when things are running slowly.


 

Sequential processing got me this week when I was configuring a rule in ISA to allow outbound traffic on port TCP 3000. Traffic kept getting blocked, but I didn’t know why. The rule configuration was correct. After putting a monitor in place, I noticed that the traffic was getting blocked by a rule that was higher up in the rules definitions. This rule was configured with same destination IP and port number. The gotcha is that ISA will match traffic to the first access rule that is processed (in order) from top to bottom. If two rules happen to define the same destination IP and port, the first one is the only one that ever gets processed. ISA considers the first a “match” and never proceeds with processing subsequent rules.


 

For those who like to experiment, there is open-source firmware available for many SOHO routers.  Two popular ones are:

Here’s a partial list of extra features you get with these:

  • Improved QoS capabilities
  • Better bandwidth reporting
  • Ability to increase wireless output power
  • Support for wireless clients and wireless bridging
  • Improved access restriction rules