Tag: #security

Get Ranked to Become More Secure

Lorin Olsen
I’ve been in the business world for a few years. And in the past two decades, the forced ranking of employees has been used by most HR departments. These ranking systems have generated both great advantages and equally great disadvantage. But the motivation for implementing such competitive systems is quite clear: as humans, most of us are driven to compete. So it is theorized that this imperative can be channeled to “inspire” maximum performance while on the job.
 
We want to be the “best” in whatever we do. This includes having the best house (or car), maintaining the best yard, encouraging the best students (or student/athletes), or being the “best” member of a great team. These kinds of systems inspire us to be the best that we can be. Such reward-based systems are nothing new in technology either. For a generation, game designers have built reward systems into their products. It is no longer just about beating the “big bad”. It is also about wearing the best armor or having the coolest spaceship. And social media systems have often devolved into follower counting or “influence” ratings.
 
So how can such comparison and esteem systems result in a stronger security posture?
 
The folks at LastPass (which is owned by LogMeIn) have been using a “security challenge” program to motivate people to be more secure than they have ever been. While such a system does not work for everyone, it has always worked for me. As a result of this system, I remained dissatisfied with being in the top ten percent of LastPass users. The test inspired me to work hard in order to join the top one percent of users. And this week, it inspired me to implement any and all recommended areas of improvement.
 
I’m not certain whether the aforementioned example speaks to the power of motivation systems or to a fundamental facet of my personal psyche. But for the sake of this article, I’ll assume the former while considering the latter at some point in the future. After cleaning up (and locking down) all of my credentials, I decided to turn my focus towards household vulnerabilities. And my tool of choice to evaluate vulnerabilities is Nessus (http://www.tenable.com).
 
I’ll probably write a follow-up article about my findings – and my subsequent actions. In the meantime, I will tell you that the very first thing which I started to do after seeing the most recent results was to triage the important vulnerabilities. I looked at the items that Tenable noted as most important. I then researched and worked towards remediation of all of the highlighted vulnerabilities. Bottom line: I was motivated to be better than my nearest neighbors. This “better than the Jones’s” compulsion is driven by my fundamental view that to be a survivor, one cannot be the slowest antelope in the herd. Consequently, I am using an incentive-based system (and some fear-based motivation) to further strengthen my security posture.
 
In the final analysis, I am convinced that harnessing ego rewards and highlighting real risks (i.e., letting people know of the possible punishments for not addressing vulnerabilities) are a winning strategy – if you have a company with employees like myself.
 
http://smallbusiness.chron.com/employee-motivation-reward-systems-15978.html

Trading Privacy for a Little Convenience

Lorin Olsen
Benjamin Franklin once wrote, “Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.” The quote (and its source) is often disputed (see https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century). But it is clear that modern privacy advocates see this quote as a proof text for the shortsightedness of exchanging your privacy for your security. Indeed, I too have used this quote as a rallying cry. But in candor, my use of this quote is more of an “appeal to authority” rhetorical argument rather than a reasoned defense of unfettered freedom.
 
But how should we respond to HART (the Homeland Advanced Recognition Technology project)? DHS is building a massive repository of identity information. This is, ostensibly, for ensuring our security. From the Electronic Freedom Foundation (at https://www.eff.org/deeplinks/2018/06/hart-homeland-securitys-massive-new-database-will-include-face-recognition-dna-and),
 

DHS’s plans for future data collection and use should make us all very worried. For example, despite pushback from EFF, Georgetown, ACLU, and others, DHS believes it’s legally authorized to collect and retain face data from millions of U.S. citizens traveling internationally. However, as Georgetown’s Center on Privacy and Technology notes, Congress has never authorized face scans of American citizens.
 
Despite this, DHS plans to roll out its face recognition program to every international flight in the country within the next four years. DHS has stated “the only way for an individual to ensure he or she is not subject to collection of biometric information when traveling internationally is to refrain from traveling.”

On its face, this is repulsive. And for most Americans, this kind of assault on our freedom and our right to privacy is unthinkable. But the federal government apparently hoped that this effort would gain little public attention.

But while we chafe over such obvious governmental incursions, why do we embrace the same incursions when they come from a private company? Most Apple users applauded the availability of facial recognition as part of the new Face ID feature. And I daresay that Android users would welcome the very same technology, if they knew that it already existed on their phones.

So what’s the problem with a company doing this?

There is little problem if you trust the company and if you read your grant of license. I daresay that miwe do trust companies and we don’t read license agreements. Of course, it should be the other way around. If we read the grant of license, then we would realize that most companies will use whatever they can leverage to increase profits for their owners/shareholders. And if we give away our rights (as well as personally identifiable information), then we are worse than those who gave away freedom for security. We’re doing it to save a few seconds of login time.

Summer of Insecurity

Lorin Olsen

More Paranoia
More Paranoia

First, I need to apologize to many of my faithful readers.  I think I’ve finally succumbed to the Twitter disease.  As many of you know, I’ve been using Twitter for over two years.  Indeed, I’m one of those technology saps that picked it up, set it down, and picked it up again.
And I really love Twitter.  You can connect with others at the same time that you post your thoughts on any subject.  And for me, it has the added value that you only have to edit a 140 character posting.
I state all of this for one reason: I must apologize to my readers as I have forsaken the “long form” for the micro-blog.  It has been almost a month since my last post to this blog.  And that is thoughtless of me.  If I want you to continue to read the things that I write, I must continue to write them.  In the meantime, I’m trying to work out an adequate penance.  Please leave me a comment with your ideas on how I can attone for the sin of neglecting my readers.
Now, on to the meat of today’s missive…
Last month, I started a security voyage.  Much of the reason for being so concerned about security is that Noah has challenged me.  He didn’t even realize that he had challenged me.  But those pesky Starbucks conversations have a way of provoking an immune response reflex. He would tell me about going to Defcon and how thrilled he was to meet with his friends in the hacker community.  His joy at being able to “crack” technology barriers perked my concerns.  So it was time to convert concern into action.
Last month, I knew I needed to address some chronic architectural flaws.  Think of last month as stiffening and strengthening the girders.  I put a VLAN in place to isolate the most insecure aspects of my infrastructure from the most valuable jewels in the collection.  I turned off all but the most necessary of protocols.  I began utilizing a lot of tunneling.  This allowed me to lessen the surface area of my risk. But it just put all of my “risk” into one basket.  In effect, I had one basket of very dense risk.
As I type these words, I think of the last scene in Terry Gilliam’s “Time Bandits” movie.  In the last scene, the totality of evil t be found in the movie is condensed down to a single charred briquette of absolute evil.  That’s what I unintentionally had created last month.
As of yesterday, I started to address some of that evil by working on the doors and the locks that protect my house.  I’ll start by noting that I do have a few web servers that are relatively open.  These are the webcams I referred to last month.  They are older and inherently less secure.  But they are now “isolated” and provide rather limited value to an intruder – unless you want to watch me typing on the computer or loading my new panniers.
But I’m wandering off topic…
Yesterday morning, my biggest “door” was the cable modem connection and the wireless router that I use at home.  I’ve been pretty good about securing the wireless.  And last month, I closed a whole bunch of windows on the facade (i.e., open ports for unneeded services).  But the locks on my front door weren’t very solid.  Yes, I use a custom firmware build.  And yes, I use ssh  for the majority of my access needs.  But it wasn’t a strong enough lock.  So I set to work on replacing the locks on the front door.

  1. I started by using Steve Gibson’s “Shields Up” service.  I quickly noted that while port 22 was open, there was still a remnant of port 80 that was still visible.  After stumbling through some documentation, I realized that there are a couple of “options” in the DD-WRT firmware that I needed to tweak.  In order to really lock down the leakages, I had to set some nvram options as well.
  2. I then improved the locks by switching from a password-based authentication approach to a PKI approach.  Using PuTTYgen, I created a 1024-bit public/private key pair for myself.  [No, I haven’t posted my public key on a keyserver yet.]  I then generated a horribly long passphrase tat I would remember.  Now I had to get the public key onto the router.This proved to be quite a challenge.  After editing the generated keyfile, and using cut/paste operations (from Notepad into the router’s web GUI), all I had to show for it was a series of failures – on many levels.  After what seemed like hours (but was actually just a few hours), I finally noticed that PuTTYgen places the public key component it generates into a portion of its key generation window.  And the output was quite a bit different than the output PuTTYgen places into the keyfile.  Every security wonk reading this must be saying, “Gosh, you’re kinda slow, eh.”  Well, I guess I am.  I took the text (in OpenSSH key format) and pasted it into the DD-WRT ssh public key segment of the DD-WRT -> Services dialog.  And voila, things began to work.
  3. After adding the key through the GUI, I realized that I didn’t even want the management GUI (for DD-WRT) to be generally available – even from the LAN side of the router.  So I set nvram parms so that the web GUI would not start at all.  And if/when I needed it, I could start it via the command-line.At this point, I had locked down ssh in my environment, right?  The answer wasn’t quite that simple.
  4. Since I was still routing port 22 from the WAN interface to the WinSSHd instance on my main system, I still had a problem: ssh needed to be hardened on my Windows 7 device.I use WinSSHd.  It is free for personal use.  And since I’m a person, I felt I can take advantage of their generosity.  From a personal viewpoint, I’ve used a variety of Windows SSH tools (including the full-featured Tunnelier product).  And I think that the personal version of this tool is excellent.I set up the  server to utilize my public key.  I then went to my laptop.  After setting up some additional session profile in PuTTY, I had a serviceable session established for testing.  But for the life of me, I couldn’t get the crazy thing to work.  I started to assume that it was a public key  problem as was the case with DD-WRT.  But after a few hours of fumbling and trying a number of things, I started to get frustrated.
    I finally noticed an inconspicuous link on the main WinSSHd server management page.  It pointed me to the server management log folders.  Well, I had been through the session management logs.  But I figured I’d give this a try.  In a few moments, I was treated with a rich feast of information.  And I casually noted that the key exchange was failing because the client was offering a 2048-bit key while the server was expecting a 1024-bit key.
    It dawned on me that I had trouble copying the public keys to this machine many hours earlier.  Earlier in the day, I couldn’t find my USB key.  So I had used one of the Sandisk Cruzer drives my wife had squirreled away.  And amidst all of the trouble associated with the U3 drivers for the USB device, I had probably copied the wrong version of the key that I had generated many hours earlier.
    The solution was simple: I took the right key and loaded it onto my laptop.  Once corrected, the ssh tunnel sprang into life.  Here’s a reminder.  When doing a multi-step project, write down what you do and when you do it.  It may prove helpful at a later point in time.
  5. Once I got the tunnels working, I realized that I really didn’t want a 1024-bit key.  So I regenerated new keys and deployed the public key component to both ssh servers (Dropbear in DD-WRT and WinSSHd on Windows).  It only took a few minutes – now that I had solved the earlier issues.

So after ten hours of security tinkering, I had installed stronger and more tamper-resistant locks onto the one door I have onto the Internet. I am effectively tunneling all of the valuable protocls through ssh.  So I’m feeling a lot better.
But after doing all of this, am I any safer?
That’s such a tough question to answer.  I am smarter than I was a few hours ago.  I know a lot more about PKI.  And I know that having 2048-bit asymmetric keys is better than a weaker alternative.  And I know that even longer keys may not be worth the effort.  And I remember that if you want to stop casual hacking, you only have to have a stronger door than your neighbor.
But am I safer?
All the windows are shut.  And I’ve got better locks on the door.  But if someone wants to get in, there is precious little that I can do to stop them.  So we need to remind ourselves that multiple layers may be the best defense.  Even though the door is locked, put your valuables in a secure place.  Some of my most sensitive data is not stored on my online systems.  Indeed, that data may be in the form of offline media that I have in my desk or in a filing cabinet.  But such distribution of data is not the only defense.  Make sure that your computers are secured with strong passwords.
And try not to leave the keys near the locks.   Some folks write down their passwords and leave them on a sticky note – just like the idiot office clerk in “Wargames.”  If you must have  a repository for passwords, use a secure password manager tool.
And always remember that security is a perpetual process of improving what you already have in place.
-Roo

Battening Down the Hatches at Home

Lorin Olsen

CamerasHow many times have you heard the phrase “batten down the hatches?”  But do you know what it means?  Well, it’s a nautical term referring to sealing ship hatches with strips of wood and caulk.  This is done to prevent water from penetrating the hatches of the ship.
Well, I’ve been battening down the computing hatches here at Chez Roo.  As most of you know, I’m focused on security – but not obsessed by it.  I have a wireless network that is fairly well protected with WPA2/AES encryption, strong  passkeys and strong credentials/passwords on all of the systems in the network.  I use MAC filtering.  And I try not to broadcast my SSID.
But nothing is totally secure.  And every measure or counter-measure should be periodically reviewed.  So when I added both a Wii and a new LCD TV to the wireless network, I figured that it was time to start doing a network review as sone of the new devices requred that I enable SSID broadcasting on my main access point.
At the same time, I had finally gotten around to addressing some remote access problems.  Specifically, I had finally been able to successfully configure my Windows 7 test system to allow remote mamangement via either VNC or Windows Remote Desktop.  Up until this week, I had tried to open all of the various ports needed for both products.  But I really hate having lots of ports open to the Internet.  So I reconfigured everything to tunnel through SSH.  BTW, I’m using WinSSH in a non-commercial role – and it is working fantastically well.
Of course, nothing is nearly as simple as it would at first appear.  I do use DynDNS to manage/publish the dynamic address that my cable provider doles out to me.  So I installed update to my DynDNS “updater” tool.  I also switched over to OpenDNS in order to improve performance and in order to get some rudimentary namespace management tools.
So once I changed three or four things at the same time, things stopped working – of course.  It turns out that as I cleaned up the router to eliminate the now unnecessary port forwarding, I could no longer connect to the UltraVNC server on my main system.  It was a simple problem.  I had used the FQDN name (in DynDNS) in the tunnel definitions I had put into PuTTY.  So once I established a tunnel, it would try and connect to the external name (i.e., the router) on the real VNC and RDP ports.  Of course, this wouldn’t work once I removed the port forwarding rules.  How did I correct it?  I decided to use the blunt force trauma approach: I updated my hosts file to point the external DynDNS name to localhost.  Once done, things started working again.
And now was the time to call a friend and ask for a favor.  While I trust my skills, I always want a set of unbiased eyes.  So I called @ax0n and had him do a Nessus scan on my network.  So what did he find?  First, he found my wireless IP cameras.  [Note: We put these in so that we could monitor the house while we were away.]  And he also saw the other ports that I expected.
But when he saw the cameras, I decided that these were the weakest link in my security chain.  You see, I run two different wireless networks.  One supports the main systems in the house while the other supports the wireless cameras that we installed.  The camera network is not nearly as secure as the main wireless router.  That’s because the camera network is over five years old.  And when it was first designed, WEP-128 was still the standard encryption model.  But I didn’t want my whole household to be limited to WEP-128.  So I set up an access point just for the cameras.  That network uses WEP.   I ran a separate network cable from the router to the camera AP so I could physically separate the traffic.
But I never took the next logical step.  This weekend, I took that step.  I set up a series of virtual LAN’s in the house.  And the cameras are now on their own VLAN.  Of course, this meant that I needed to reconfigure all of the cameras to provide them with new IP addresses.  And that took quite a while as I had to directly attach them to my laptop in order to reconfigure them.  It’s a simple process, but it does take time.
Then I had to set up the VLAN’s on the router.  The good news is that I use DD-WRT.  So VLAN setup is relatively easy.  But in addition to adding the VLAN, I had to set up new autostart options in order to relate the VLAN to a specific physical port on the router.  Finally, I had to update the builtin firewall to ensure that the VLAN for the cameras couldn’t access the other systems behind the router.  Yeah, this was the whole reason to reconfigure everything; I didn’t want someone to be able to connect to the camera network and then launch an assault against the more secured portions of my network.
So the annual security review is drawing o a close.  Yes, I expect that I may see a few more minor changes.  But the major re-designs and major changes are done.  And I sure am glad for that.  I sure hope that the next minor project is as fun as this one has been!
-Roo