The weird gateway day … this time it wasn’t DNS

This isn’t a story where at the end I will say “yes, it was DNS.”

Two days ago, I started noticing sporadic failures from servers at one client’s office, unable to be pinged for a few seconds, then operating as normal for five to ten minutes. One might start off with checking the switch, physically investigating the servers and cables which, I did. What made the issue stand out was it wasn’t just one server, it was multiple servers on multiple switches.

The investigation jumped to the routers. Nope, they were fine.

At this time, desktops began to lose connectivity to the affected servers. Not all servers, and not even all servers on the same switch! From the servers I found I could ping other machines sporadically but ping working servers constantly.

Magically, it all stopped (well, started working again, the problem stopped) at five o’clock on the dot. So, this was user related, not the servers, not the switches and not the routers.

I decided to setup a sting for the following day. I started watching users as they logged into the domain while running non-stop pings on the servers when suddenly, it began again! I raced across the office to the offending user’s office to find, of all things, an ancient HP printer sitting on the desk. The culprit had been discovered.

It seems he HP printer’s LaserJet card had thrown a wrench. It was auto-assigning the gateway address as is local IP address complete with no net mask and no gateway address (how could it, it was its own gateway.) By statically assigning an IP to the printer pool, all went back to working well.

The end result showed an HP printer, assigned its IP to the default gateway of the system. Servers picked up on this from ARP updates and began, sporadically sending packets destined to the routers to the printer.

I’m not sure how to prevent this from happening again other than to constantly monitor the MAC of the router and alert if the perceived gateway MAC suddenly changes.

It certainly was an entertaining hunt.

Automatic login with the Ubiquiti NVR (tested on 3.7.3)

I was looking for a way for my Raspberry PI to automatically log into my Ubiquiti NVR and having found a few resources online all dealing with VB script launchers figured there has to be an easier way. I was wrong. But here is what I came up with.

I’m going to assume you know how to use SSH, nano (or vi or your favorite editor) and can search/type in a compressed javascript file.

SSH into the NVR and head on over to the /usr/lib/unifi-video/webapps/ROOT/static/js/(version.js) file – this will be a long named javascript file with the latest build. Note – this will change on each patch so get used to editing this until Ubiquiti figures out this is a needed feature. In my case, the file is called uv3.833f7b634e8027fc5fcb19f3b27e440690db4b43.min.js

Search for the /uv3/views/LoginView controller and edit the data to change the lines from:

username: this.$username.val(), password: this.$password.val()
to
username: "(your username)", password: "(your password)"

This will automatically provide a username/password to the controller on form submission. Now to get the controller to automatically log you in, look for the function nearby called didInsertElement and edit it from:
this.$().find("input")[0] && this.$().find("input")[0].focus()
to
this.$().find("input")[0] && this.$().find("input")[0].focus();this.doLogin();

Now when you browse to the login screen it will automatically log you in without the need for a VB script.

Naturally, it will always login with the given username/password so before any admin functions you need to perform you will need to swap out the changes and any patching will undo all of these changes.

Round three of my edit will include the ability to provide a different username/password based on the calling IP address so from my administrator machine or VPN tunnel I can access the admin features while reception will automatically login with a standard user account.

PS. The logout button now will also not do anything unless you redirect it elsewhere.

Phishing these days…

These days it’s not a matter of if you will get phished through email but a matter of when.  This is not the normal doom and gloom reminder but a simple request.  Slow down, just a bit.  When that email arrives asking you to transfer $60,000 to an account in Belize for a summer home purchase, sit back, sip some water and ask yourself, why is the CEO of the company asking me, the marketing manager to setup a wire transfer?

This is what I see almost every day.  Emails beginning with “My Dearest” or “So Kindly” (with many variations on spelling) litter the phishing world to the point that any email starting like that should just be deleted to begin with.

There are simple steps to take to eliminate being tricked (phished) through email.

  1. Does the return address make sense or even belong to you?
    1. Anyone can fake a sending address but the return is where they want to get you. You make think the email is from theceo@yourcompany.com but on replying you will see iam_not_theceo@gmail.com or some other variant. If the reply-to domain is different than yours or to an address you’ve never used, delete the message and pick up the phone.
  2. Does the email have links to click?
    1. Almost all email programs can show HTML which means I can do this (pseudo-html ahead) Good Link – you will see “Good Link” in the email but be directed to bogus link when you click. How you can avoid that?  Put your mouse over the link and wait a second.  Email programs will show you the real link under the HTML link so when you see Click Here to access your account, a mouse over will show http://bad-domain.com as the destination and a good indication that clicking on it is a bad idea.
  3. Make a phone call.
    1. This one is staggeringly simple yet, it’s number three in the list. Every case of phishing I have investigated would have been prevented if you had just picked up the phone and confirmed.  This should be number one in your list so in your mind, move it up to the top spot.

So that’s it in a nutshell.  Check the return domain, moue over any links and pick up the phone and phishing will be a thing of the past.