Blog

When installing or making changes to the Symantec Endpoint Protection client, be aware that the SEP firewall policy can cause Windows Firewall to 'reset' or change its configuration.  I've seen several versions of Windows OS change to an active firewall config with no exceptions under the following 2 conditions: [more]

  • SEP client with an enabled, default firewall policy is installed for the first time
  • Existing SEP client has its applied firewall policy withdrawn

This has been seen with several 11.0.6x builds of SEP, although it may be applicable to other builds as well.  This occurs even though the SEP firewall module (Network Threat Protection) is not installed.  When a Windows desktop has its firewall enabled with no exceptions and there is no group-policy in place to re-apply a previous config, it may become unreachable remotely via any protocol, while at the same time the user may notice no change and continue working normally.  If the Windows client happens to be a server, all connectivity to that server may be lost, except via console.

I suggest rolling out new SEP clients after the firewall policy in that group has already been withdrawn.  For existing clients where the firewall policy needs to be withdrawn or disabled (ie overriding Win7 firewall config), test a small subset of clients in a separate group before making the change to normal production groups.


 

I recently ran into a problem with Windows 7 UAC where we had a VBS file that was calling the application SETACL.  In order for SETACL to run properly, it must be “Run as Administrator”.  I could set the option in SETACL to “Run as Administrator” in the applications properties, but when the script called the application, UAC would not prompt the user to elevate privileges.

I wanted to see about right clicking the VBS file to select the “Run as Administrator” option, but Windows does not include that option in the context menu by default.

In order to add the option, you can add it to the registry.  Copy the following into a .reg file and then merge the file into the registry: [more]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VBSFile\Shell\runas\Command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
  00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,57,00,\
  53,00,63,00,72,00,69,00,70,00,74,00,2e,00,65,00,78,00,65,00,22,00,20,00,22,\
  00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00

After merging the key, I was able to select “Run as Administrator” when right clicking the VBS file and the call to SETACL also ran correctly. It's a good idea bo backup your registry before making manual changes.


 
 

A couple months ago, I had a user who was having problems with the RSA SecurID App on the iphone.  For some reason, his PIN was not hidden after he typed it in.  I found out there is a small “i” in the bottom right hand corner of the app, and if you open it up, there is a little slide-bar that you can move to hide/unhide the PIN.


 

I was tasked with upgrading a 2003 Windows Server to 2008 over the weekend recently and ran into a few minor issues trying to get the upgrade started. The main one was that the Server 2008 installer would not continue past the compatibility check as long as Windows PowerShell 1.0 was installed. PowerShell 1.0 was released as a hotfix prior to server 2003 SP2 and was included in the SP2 package. When I went into Add/Remove Programs, I didn’t see the PowerShell update in the list. Even after removing SP2, PowerShell was still present on the server and would not allow the Server 2008 upgrade to even start. [more]

I wanted to try manually uninstalling the hotfix from the $NtUninstallKBXXXXXX$ folders located in C:\Windows, but the folder that housed the PowerShell 1.0 hotfix info was nowhere to be found. Most likely, someone had removed those folders to clean up disk space or they were removed with the installation of SP2. In either case, I was stuck.

Fortunately, we had another Server 2003 32bit machine running out on the network that still had the $NtUninstallKBXXXXXX$ folder that I needed. I copied it over to this original box and tried the uninstaller. It successfully uninstalled PowerShell without any extra registration on my part! After this was removed, the upgrade to Server 2008 ran smoothly.


 

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.


 

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

  • Open Remote Desktop Session Host Configuration.
  • Open th/e properties of the RDP-Tcp protocol underneath Connections.
  • In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
  • On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
  • Run netstat to confirm that the server is listening on port 3389 again.

 

While configuring a new Windows 7 laptop I attempted to setup a new VPN connection.  It kept defaulting to a dial-up connection. I verified the steps I was taking on my own Windows 7 laptop and then repeated it again, but it had the same results. I tried copying the VPN connection to the system and it still would try to use dial up. I tried setting up the VPN using the local administrator account, domain administrator account, and domain user account only to find the same results each time.  I even disabled and uninstalled the modem and it still default to dial up.

After some research, I opened the device manager, enabled the “Show hidden devices” option, and under “Non-Plug and Play Drivers” I found NDProxy with a yellow exclamation mark. [more]

NDProxy, according to Microsoft is "a system-provided driver that interfaces NDISWAN and CoNDIS WAN drivers (WAN miniport drivers, call managers, and miniport call managers) to the TAPI services" - see http://msdn.microsoft.com/en-us/library/ff568322.aspx for more details.  NDProxy has been linked to slow boot, BSOD and other issues in Vista.

To fix the problem right click on NDProxy and select properties, go to the second tab (Driver) and look at the “Current Status” section, it says it is “Stopped”. Choose the option to start it then reboot. (Do not change the startup type) After the reboot NDProxy will no longer have an exclamation icon (i.e. it started OK) and it shows “Started” in the “Current Status”.


 

I came across an interesting feature of Gmail the other day.  Apparently you can add a little something extra to your e-mail address to better help your mail filters or just track who is selling your e-mail address.  To use this feature, simply add a '+string' to the 'username' portion of your address.  For example, if your e-mail address was bob@gmail.com, you could track your messages from Amazon.com by using bob+amazon@gmail.com in all your Amazon communication.  This would make it really easy to apply mail filters no matter what the sending address is (since some sending addresses can be pretty crazy).  Another nice "feature" is being able to track who is selling your e-mail address… though you still might not have much recourse.  If you'd like another variation that still delivers to your gmail Inbox, you can also use the domain googlemail.com.  Not sure why you'd want to, but to each his own.


 

We had a user recently that was reporting excessive amounts of spam in her inbox. This company uses Postini as their filtering service, so naturally, this didn’t seem quite right. After some research, I determined that it was non-account blocking (a Postini feature) that was causing the problem. In this example, let’s assume the user is Jane Smith. Her email address is jane.smith@company.com. The spam was coming into jsmith@company.com, an alternate SMTP address in Exchange.

Non-account blocking in Postini bounces all email that comes to addresses not registered in the Postini user database. If this feature is not enabled (as was the case here), Postini does not filter the email according to the spam filters and, instead, passes it through untouched. The jsmith@company.com address was not added into the user database as either a user or an alias to a user. When Postini received email on this address, it passed it straight through to their exchange server. The exchange server recognized the recipient as a legitimate user and delivered the mail as expected.

The fix here was to enable non-account blocking and add these secondary SMTP addresses as aliases in Postini. Jane has not received any spam since then.