DNS Filtering for Security & Productivity

DNS filteringAny Human Resources department manager will attest to the need for an Acceptable Use Policy as part of the Employee Handbook. It should clearly state the proper use of business-owned workstations and what traffic is allowed on the company network. Monitoring this policy is next to impossible for small businesses, yet ignoring it leads to infections, security breaches, and huge losses to the bottom line by wasted employee productivity. How does a company stay safe from the big, bad Internet?

Policy Creation

This may sound boring, but before any monitoring and enforcement can take place legally, there must be a clearly defined policy in place with consequences for violations. This policy must be signed by each employee. Only when signed policies are in each employee’s file, can measures can be taken to monitor and enforce the new written policy.

No Administrator Access

There is no reason for the average employee to need Administrator access to a workstation once it is setup properly for business use. Most employees do not need to install any software or make any major setting changes without first consulting management and/or network support personnel. Software and operating system updates should also be handled by network support personnel or by an automated process. Installation of additional hardware should be cleared with management and implemented by network support personnel. Workstations are a company-owned tool to be used by the employee only for the best interests of the company, not for personal file storage or entertainment purposes.

DNS Filtering

The Internet is an invaluable tool for business purposes. There are, however, many threats out there, and the common user has no idea how to avoid them. There are also innumerable distractions ranging from time wasters to those that are downright illegal. DNS Filtering inspects every internet request against a database of known sites and blocks bad traffic before it goes anywhere on the internet. This keeps your internal network assets safe from malicious sites and content that is inappropriate for business or bad for productivity. This is accomplished without interrupting or slowing down the normal flow of good traffic around the Internet.

If your company is looking to add layers of security to your network or increase productivity by limiting Internet time wasters, then contact us for assistance.

CIA hacking home routers with Cherry Blossom since 2007

CIA Cherry Blossom

In the latest dump of purportedly top secret CIA cyber exploits from WikiLeaks, dubbed “Vault 7”, there is evidence of a home router firmware modification called Cherry Blossom. (The CIA has never publicly acknowledged the programs nor the leaked Vault 7 documents.)

What is Cherry Blossom?

“The Cherry Blossom (CB) system provides a means of monitoring the Internet activity of and performing software exploits on targets of interest,” the WikiLeaks documents state. “In particular, CB is focused on compromising wireless networking devices, such as wireless (802.11) routers and access points…to achieve these goals.”

Among the companies whose wireless routers have reportedly been compromised are Motorola, Linksys, Dell, Netgear, US Robotics, Belkin, Asus, Buffalo, DLink and Senao. Cherry Blossom relies on implanting altered versions of the products’ firmware remotely posing as wireless upgrades. An implanted device is known as a “FlyTrap” and communicates via beacon with a CIA-controlled server known as CherryTree (CT).

If your company is a consumer grade home router instead of a business grade router, then contact us for assistance.

Powershell One Liner: Disable User Protocols

Here is a quick powershell one liner that I came up with when I got a request from Microsoft Support to disable user protocols. I did some research and found out that they meant the protocols or services used to access Office 365 Exchange Online.

Connect to Microsoft Office365 via Powershell

Open Windows Azure Active Directory Module for Windows Powershell as Domain Administrator and type in the following to connect to Exchange Online via Powershell:

Set-ExecutionPolicy RemoteSigned
$creds = Get-Credential
(Enter the Office 365 Administrator credentials then click “OK” button.)
Import-Module MsOnline
Connect-MsolService -Credential $creds
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $creds -Authentication Basic -AllowRedirection
Import-PSSession $Session

Disable User Protocols

Once connected to Office 365 via Powershell, here is the one liner to disable user protocols:

Set-CASMailbox user@company.com -ImapEnabled $False -PopEnabled $False -OWAEnabled $False -ActiveSyncEnabled $False -MAPIEnabled $False

Enable User Protocols

Here is the one liner to enable user protocols:

Set-CASMailbox user@company.com -ImapEnabled $True -PopEnabled $True -OWAEnabled $True -ActiveSyncEnabled $True -MAPIEnabled $True

If your company is currently using Office 365 and needs help translating commands given by Microsoft Support, then contact us for assistance.

Nagios Core SNMP Monitoring APC UPS

God has recently lead me to do some charity volunteer work for a worldwide organization and their IT department. My first project was to untangle their Nagios Core system and then take over the administration of that server and the monitoring of the rest of the network. Part of this volunteer work took place yesterday with deep dive into the Nagios framework, Linux and SNMP to allow monitoring APC UPS devices.

Initial Trip Off Course

My initial thought was not to re-invent the wheel and head to the Nagios Exchange to find a pre-made project that would elegantly provide monitoring APC UPS devices. I found the check_apcupsd project which looked simple and had a great screenshot. Little did I know what I was getting into. Turns out there are a couple undocumented dependencies for this including apcupsd itself and an undocumented connection to port 3551 which I could not find inside the portal page for the SMART-UPS 1500 network management card. After a couple hours of frustration I abandoned this and removed all linux packages associated with it.

Trip Down SNMP lane

After looking over other projects at the Nagios Exchange, I decided to research using SNMP to provide monitoring APC UPS devices. This lead me to an article by Mihai Radoveanu which provided the detailed steps to create monitoring APC UPS devices in Nagios Core. He details editing the command.cfg file to add the check_snmp and his own check_snmp_inverter to list of commands. (Please note that the check_snmp_inverter.sh file will need to be edited to Change the Home variable to point to the Nagios Core plugins directory) He details creating host templates, host groups, adding a separate configuration file to the main file which includes hosts and services. I prefer the more standards based approach to creating individual host files, adding them to a host group and then creating a service file that points to the host group. Made these changes to the Nagios Core framework and confirmed my configuration before making the changes live.

APC Changes Needed

Finally came the changes to the APC UPS network management card configuration:

Monitoring APC UPS - Main Page

  1. Login to the network management card webpage, click on Configuration > Network > SNMPv1 > Access then check the box next to Enable and click on Apply.Monitoring APC UPS - Configure SNMP
  2. Click on Configuration > Network > SNMPv1 > Access Control then click on a community name then type in the network SNMP community name and the IP address of the Nagios Core server. It will only need Read permissions. Click on Apply.Monitoring APC UPS - Configure SNMP Access

That is all that is needed. This introduction to the Nagios Core framework later allowed me to setup SNMP monitoring for the High Availability link ports between their Sonicwall 4600 devices.

If you are looking for expert monitoring of your network systems by highly trained technicians, then contact us for assistance.

Ubiquiti USG Remote User VPN RADIUS Authentication

The following steps will setup Windows Server 2012 R2 RADIUS authentication via Network Policy Server (NPS) with your Ubiquiti UniFi Security Gateway (USG) for a USG Remote User VPN. This will allow users to use their current Active Directory Domain Services (AD DS) credentials to authenticate to the Virtual Private Network (VPN).

I am using the UniFi controller version 5.4.14 hosted in Microsoft Azure on a Linux Server with PostFix for alerting.

Step 1: Configure Windows NPS Server

  1. From the Server Manager Dashboard, install the Network Policy and Access Server role using Add Roles and Features accepting all defaults.
  2. Once installed,  open the Network Policy Server Administrator Tool. Expand the RADIUS Clients and Servers, then right Click on RADIUS Clients and click New.
    USG Remote User VPN - Create New RADIUS Client
  3. Give the USG router a Friendly Name. Type in the IP Address of the inside interface of the USG on the same network as the Windows Server. (This is the IP that the RADIUS requests will come from.) Click the Generate radio button, then click the generate button. Copy this Shared Secret to be pasted later. Click OK. USG Remote User VPN - Create New RADIUS Client
  4. In the Network Policy Server window, expand Policies, right click on Network Policies, and then click New.
    USG Remote User VPN - Create New Network Policy
  5. Enter a policy name and leave Type of Network Access Server as Unspecified. Click on Next.
    USG Remote User VPN - Create New Network Policy
  6. In Specify Conditions click Add.. and then select Windows Group, and pick the AD Group you want to use to allow VPN access.  (If you have not already then you will need to add all users who will be accessing the VPN into a seperate group.) Click Add… then Add Groups… which brings up the typical AD search box. Type in the name of the VPN Windows Group and click on OK. Click OK again. Click on Next
    USG Remote User VPN - Create New Network Policy
  7. Leave the Specify Access Permissions at the defaults (Access Granted, Dial-in box unchecked). Click Next.
  8. Uncheck all authentication methods other than MS-CHAPv2. Click on Next.
    USG Remote User VPN - Create New Network Policy
  9. Accept the defaults under Configure Constraints. Click Next.
  10. Leave all setting at the default on this page except for under Encryption. Uncheck everything except for MPPE 128-bit. Click Next.USG Remote User VPN - Create New Network Policy
  11. Check your settings on the last page. Click Finish.
    USG Remote User VPN - Create New Network Policy
  12. Finally, move the new policy above the two default policies in the list by right clicking and choosing Move  Up.

Step 2: Configure the USG Remote User VPN

  1. To create the remote access network, in the UniFi controller, go to Settings, then Networks, and click Create New Network, give the network a name and select Remote User VPN.
    USG Remote User VPN - Network Setup
  2. Fill in the appropriate Gateway/Subnet information for your environment. Make sure it is not the same as any of your current networks.
  3. Add Manual DNS servers, if required for your environment.
  4. Click on Create New RADIUS Profile.
  5. Give the Profile a name, enter in the IP address of the Windows Server 2012 R2 server that will be used for RADIUS authentication and paste in the generated shared secret.USG Remote User VPN - Create New RADIUS Profile
  6. Click Save. Click on Save again.

This allows easy access from Windows default VPN connections to network assets behind the USG device.

If your company is currently using a Ubiquiti USG device and need a Remote User VPN setup, then contact us for assistance.

WannaCry Ransomware Spread Halted by Webroot

Webroot & WannaCry Ransomware

WannaCry Ransomware: Webroot protects you.

Ransomware attacks continue to spread around the world this weekend, after the initial damage inflicted on healthcare organizations in Europe on Friday.

The criminals responsible for exploiting the Eternal Blue flaw haven’t yet been identified, but up to 100 countries have hit with WannaCry ransomware, with Russia, Ukraine and Taiwan among the top targets.

The ransomware first appeared in March, and is using the NSA 0-day Eternal Blue and Double Pulsar exploits first made available earlier this year by a group called the Shadow Brokers.  The initial spread of the malware was through email, including fake invoices, job offers and other lures with a .zip file that initiates the WannaCry infection.  The worm-like Eternal Blue can exploit a flaw in the Server Message Block (SMB) in Microsoft Windows, which can allow remote code execution.  This flaw was patched in Microsoft’s March 2017 update cycle, but many organizations had not run the patch or were using unsupported legacy technology like XP.

What’s New

Today, Microsoft has released emergency security patches to defend against the malware for unsupported versions of Windows, including XP and Server 2003.

Overnight and today, it has become clear that a  kill switch was included in the code.  When it detects a specific web domain exists—created earlier today—it halts the spread of malware.  You can learn more at The Register.

As a Webroot customer, are you protected?  YES.

Webroot SecureAnywhere  does currently protect you from WannaCry ransomware.

In simple terms, although this ransomware is currently causing havoc across the globe, the ransomware itself is similar to what we have seen before.  It’s the advanced delivery mechanism that has unfortunately caught many organizations off guard.

In addition to deploying Webroot SecureAnywhere as part of a strong endpoint control strategy, it is essential you continue to keep your systems up-to-date on the latest software versions, and invest in user education on the dangers of phishing, ransomware, social engineering and other common attack vectors.

If you have any questions about your Webroot deployment, reach out to our Support Team now.

And, if you are not a Webroot customer, we encourage you to trial Webroot SecureAnywhere now.

Webroot Incident

Dear Webroot Customers,
You are a critical part of our business. Our Managed Service Providers have asked us to write you to explain why our Webroot SecureAnywhere Business Endpoint Protection experienced performance issues, and what we are doing to resolve those
issues as quickly as possible.
Yesterday, Webroot released a rule that categorized some legitimate files as malware. As a result, multiple legitimate business applications were quarantined and unable to function. This rule change was in effect for 13 minutes on Monday, April 24. To be clear, this rule change was caused by Webroot and not your Managed Service Provider.
Webroot is continuing to work diligently with our partners to restore functionality for our mutual customers. While the false positives that caused the incident have been stopped, we are still working on an automated fix to reverse the files affected. Any
resolution will be released immediately.
Webroot is a trusted partner of many Managed Services Providers and this incident is not representative of our high standards. We always strive to be open and transparent, and we are working tirelessly to fix the issue. Once Webroot has identified the root cause, we will ensure further controls are in place to prevent an
incident like this from happening again.
We apologize for the pain this has caused you. Webroot appreciates your business, and our entire team is dedicated to being your most trusted Partner.
Thank you for your patience as we work through this incident.
Yours sincerely,
Mike Malloy
Executive VP of Product & Strategy

Setup Ubiquiti USG Pro DSL PPPoE Failover Connection

This article will leave out the names of the internet providers to protect against defamation of character issues, but they include a local cable internet provider and a local reseller of DSL connections who also provide T1 lines. Had a client that recently changed from using a bonded T1 line to cable internet in order to get substantially better speeds. During the winter months they experienced the issues that are typical for remote installations of cable – downtime due to issues with the vendors hardware on the poles. After consulting with them, it was decided to go with a DSL PPPoE failover connection as part of some more expansive upgrades. Here is the setup that had to take place on the provided C1100Z modem / router and the Ubiquiti USG Pro.

Setup of C1100Z Modem Router

The modem / router defaults to router mode, which puts all traffic behind a Network Address Translation (NAT) router and allows this DSL vendor their usual practice of monitoring and reselling traffic information. I chose instead to change the settings to make the device into a standard modem in “Transparent Bridge” mode. You will need to contact the DSL vendor in question to get the PPPoE username and password before performing these steps to ensure that you can setup the Ubiquiti USG Pro later. Here are the steps from their website:

1. Open a web browser and go to

2. Login to your modem by doing the following:

3. Select “Advanced Setup”.

4.. Select “WAN Settings”.

5. Select “Transparent Bridging”.

6. Select “Tagged-201” for the transport mode.

7. Select “Apply” to save your changes.

Setup of DSL PPPoE Failover Connection on Ubiquiti USG Pro

The second part of this is to setup the failover portion of the Ubiquiti USG Pro to use the PPPoE Connection.

  1. Login to your Ubiquiti Controller
  2. Choose the correct site from the list at the top right
    Ubiquit Controller Current Site
  3. Click on the Devices icon on the left hand column
    Ubiquit Controller Devices Icon
  4. Click on the Ubiquiti USG Pro device at that site to open up its properties
    Ubiquit Controller USG Pro Properties
  5. Click on Configuration
    Ubiquit Controller USG Pro Configuration
  6. Expand the WAN2 connection and add the username / password acquired from the vendor earlier along with the preferred DNS then make sure to choose the Load Balancing type as Failover then Queue Changes and Apply Changes

This will setup the DSL PPPoE failover connection to be used whenever the primary WAN1 connection goes down. If your company is currently using an unreliable internet provider and need to setup failover, then contact us for assistance.

Setup Azure to Unifi USG IPSec VPN

Had another tech firm that needed some Tier 3 assistance as they were having trouble with their VPN connection. I helped them setup Azure to Unifi USG IPSec VPN to connect their headquarters to the hosted RemoteApps server. This tutorial will go into detail about the creation of this tunnel starting with the Microsoft Azure side first using Resource Manager. It will be using the following parameters:

  • VNet Name: TestNetwork
  • Address Space:
  • Subnets:
    • Primary:
    • GatewaySubnet:
  • Resource Group: TestResourceGroup
  • Location: West US
  • DNS Server: Azure Default
  • Gateway Name: TestVPNGateway
  • Public IP: TestVPNGatewayIP
  • VPN Type: Route-based
  • Connection Type: Site-to-site (IPsec)
  • Gateway Type: VPN
  • Local Network Gateway Name: TestSite
  • Local Subnet:
  • Connection Name: VPNtoTestSite

Configure an Azure VPN gateway

This part takes the longest, so it should be done first:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Virtual Network Gateway” and click on the “Create” button.
    Azure Virtual Network Gateway
  • Give the Virtual Network Gateway a name, leave Gateway & VPN type the defaults, choose or create a local network (not covered here), choose or create a Public IP Address, leave the remaining values as their defaults and then click the “Create” button. (Please note the reminder that this takes 45 minutes to create!)
    Azure Virtual Network Gateway Setup

Configure an Azure Local Network Gateway

This is a reference to your on-premise network so that subnets can pass traffic:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Local Network Gateway” and click on the “Create” button.
    Azure Local Network Gateway
  • Give the Local Network Gateway a name, specify the external IP address of the on-premise site, specify the on-premise address space (subnet), leave the remaining values as their defaults and then click the “Create” button.
    Azure Local Network Gateway Setup

Configure an Azure VPN Connection

This will create the tunnel from Azure to the on-premise site:

  • Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Connection” and click on the “Create” button.
    Azure VPN Connection
  • Choose “Site-to-site (IPSec)” as the connection type, leave the remaining values as their defaults and then click the “OK” button. On the summary screen click on the “OK” button to create the connection.
    Azure VPN Connection Setup #1
  • Choose the newly created Virtual Network Gateway, choose the newly created Local Network Gateway, give the connection a name, specify a shared key and click the “OK” button.
    Azure VPN Connection Setup #2

This completes the setup of the Azure side of the VPN tunnel. Now to work on the Ubiquiti USG side.

Configuring an Ubiquiti USG VPN Network

This is a fairly simple process but it has to be precise:

  • Choose the Current Site from the top right hand side of the portal.
  • Click on the Settings gears down on the bottom left side of the portal.
  • Click on Networks then on the “Create New Network” button.
  • Give the connection a name, choose “Site-to-Site VPN” as the Purpose, choose “IPSec VPN” as the VPN Type, choose to Enable this Site-to-Site VPN, add the Azure subnet under Remote Subnets, get the newly created Virtual Network Gateway IP address from Azure for the Peer IP, enter the on-premise external IP address for Local WAN IP, enter the same shared key as used in the Azure VPN Connection for the Pre-Shared Key, choose “Azure Dynamic Routing” as the IPSec Profile, expand Advanced Options, leave Key Exchange Version, Encryption, Hash & DH Group as default and uncheck the PFS & Dynamic Routing boxes.
    Ubiquiti USG VPN Connection Setup

That is all there is to it. If you have any difficulties with connection then delete and re-create the Ubiquiti USG side first (those two check boxes at the bottom of the Advanced Options will check themselves again, but don’t be fooled by this quirk in the software). If your company is currently using either Microsoft Azure or Ubiquiti USG routers and would like a VPN created, then contact us for assistance.

Using External Certificate for RemoteApps in .Local Domain

Recently did some Tier 3 support work for another technology company that was trying to setup a Windows Server 2016 RemoteApps server in Azure that would allow connectivity to remote users for their on-premise software. The process started with creating a VPN tunnel between on-premise and Azure, but that is a discussion for a future set of blog posts. Once this connection  was in place, the company tried to use an external certificate for RemoteApps setup on the server. This would have been fine if the internal domain had not been a “.local”  address scheme. This tutorial assumes that you have already installed Remote Desktop Services on a server and configured it to use the CA provided external certificate.

Change Remote Computer Name

One of the main sticking points that caused issues with security warnings for clients connecting is they would see the warning – “The remote computer could not be authenticated due to problems with its security certificate.” The fix for this has been graciously scripted in PowerShell by someone with the handle “TP” on Technet. The script is called Set-RDPublihedName.ps1 and is used as follows:

Set-RDPublishedName "remote.domain.com"

Proper Active Directory Group

There were then issues with the login process that caused the following error:

Remote Desktop can’t connect to the remote computer “<End Resource Name>” for one of these reasons:

1) Your user account is not authorized to access the RD Gateway “<RD Gateway Server Name>”
2) Your computer is not authorized to access the RD Gateway “<RD Gateway Server Name>”
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

This was coupled with Security Log messages – “The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.” All this turned out to be the RD Gateway was not in the proper Active Directory Group, so added the server to the RAS and IAS Servers group.

Add URL to IIS

There was then an error about not being able to find the computer name, which turned out to be a setting in IIS. Looking under Sites > Default Web Site > RDWeb > Pages click on Application Settings and change the DefaultTSGateway to the URL of the CA external certificate for RemoteApps.

Fixing RS CAP & RAP

Last error that was received was the following:

Remote Desktop can’t connect to the remote computer “computername” for one of these reasons:

1) Your user account is not listed in the RD Gateway’s permission list
2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example computer1.fabrikam.com or

This turned out to be related to the RD Client Access Policy (CAP) & Remote Access Policy (RAP) under the RD Gateway Manager tool and DNS. For RD CAP, make sure that Domain Users is listed, and that Client Computer Group membership is blank. FTor RD RAP, make sure that Domain Users is listed, and that it is set to allow connection to Any Network Resource (This allows remote access). For DNS, make sure it contains a Forward Lookup Zone that points to the URL of the CA external certificate for RemoteApps and has an A record for the internal IP address of the RD server.

If your company is currently moving some of your resources to the Azure cloud or wanting to properly setup your RemoteApps server, then contact us for assistance.

Client relevant news, commentary & blogging