I really don’t get Verizon FIOS sometimes…

So here I am, once again, looking to upgrade FIOS service for my client and the one thing holding me back is Verizon itself. After a series of calls where I was simultaneously told static IP addresses would not change, would change and would not change, a technician who actually understands these things confirmed that yes, all 13 IP addresses would in fact change with the upgrade from the BPON ONT to the GPON ONT.

So once again, I’m on hold scratching my head as to why Verizon a) can’t change the name on an account without first deleting it (losing all IP assignments) and b) can’t seem to upgrade an ONT without throwing away the IP addresses associated with it and providing new ones.

One would think with the technology at our fingertips today, Verizon would have figured this one out.

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.

To the developers of Visual Studio, common sense time…

While I don’t usually rant (yeah right) about developers on my blog I feel I have to on this occasion. Since yesterday, Visual Studio locked up while trying to load a project in that had, until then, loaded just fine. It was stalling at project 10/12 and initially drove me a little nuts thinking I had a corrupted extension, GhostDoc had gone nuts or node.js/Git had gone off the deep end.

Now, I know what your saying right now (let’s face it nobody reads this thing so I can say that) why didn’t you just look at the .SUO file and see what project 10 was and why it was failing to load. Well, I did. Turns out project 10/12 was a node.js link to a server that had been shutdown on my vmware server by flying spider monkeys.

All good right? Wrong. My rant is that Visual Studio in all of its glory simply stalled on 10/12, eventually faded to white and crashed. No error, no warning, nothing like “Hey, your project is pointing to ap4njs.uclnj.com and that server can’t be detected anymore..” which is what these days we should expect our software to be able to do.

I removed the entry from the .SUO file and now the project loads just fine.

Me: 1 – Visual Studio: 0

Calling a web service (.net) from node.js

Took me a little experimentation (given the number of bad examples posted online) to figure this one out but I needed to authenticate a users token through the socket.io listener running in node (5.0.0).

I setup the token.js file to use socket.io with the following

 var app = require('express')(),
     http = require('http').Server(app),
     io = require('socket.io')(http),
     tokens = [];

Inside of the socket.io connection method I created a listener for the ‘register’ message that called the .NET web service to verify the authentication token. This code will be shifted to use the tedious framework in the near future. I included lodash to quickly check to see if the token is in the local array or if not, add it.

  socket.on('register', function (token) {
    var request = require('request');
    request.post({
      url: 'http://xxx/authentication.asmx/VerifyToken',
      method: 'POST',
      headers: { 'Content-Type': 'application/json; charset=utf-8' },
      body: JSON.stringify({ token: token })
    },
    function (err, resp, msg) {
      var body = JSON.parse(resp.body), t = JSON.parse(body.d);
      if (1 == t.flag) {
        var _ = require('lodash'), l = _.indexOf(tokens, token);
        if (l == -1) { tokens.push({ token: token, id: socket.id }); }
        socket.broadcast.emit('token', true);
      }
      else {
        console.log('Invalid Token/Socket ID ' + socket.id + ' Token ' + token.substring(0, 15));
        socket.broadcast.emit('token', false);
      }
    });
  }); // register

Client side, once logged in, it’s as simple as passing:

 socket.on('connect', function () { socket.emit('register', user.token() });

And providing a callback listener that will check for ‘token’ coming back with a true/false. This way the administrator can void the authentication tickets server side and the client will automatically be notified their tokens are no longer valid and sent back to the login screen.

Testing Backups…

When the call comes in that there was an explosion in the building is not the time to ask “is all of our data backed up?” This just happened and reinforces my methodology of testing backups on a routine basis.

If you are backing up your data but not testing the backups by restoring data, volumes or virtual machines, then no, you cannot say you have a working backup. It’s the same as having batteries in the flashlight only to find a pool of acid in the handle when you open it after the lights have gone out from the batteries leaking.

Depending on your volume, at a minimum of once a month, you should restore from multiple points to test your backups. If your backup system supports multiple delta-points, pick the oldest you can find and restore those.

  • Restore entire virtual machines into your lab and fire them up to make sure they work.
  • Restore Exchange databases to your lab and make sure Exchange Server can mount them.
  • Restore SQL databases to make sure the account credentials were also stored so you don’t have to reassign logins.

In short, backup, backup, backup and then restore or don’t be surprised if you get a pool of acid in the flashlight handle when the lights go out.