You’re not safe on the Internet (but you could be)

2 Comments / Misc Computers and Tech, Security

It’s a wonderful Friday evening. You’re out enjoying it with some friends, eating dinner at a classy Italian restaurant, telling stories and laughing together as you share a delicious bottle of wine. It’s the perfect end to the week.

As dinner wraps up, you hand the waitress the first card you grab from your wallet, a debit card, and don’t think twice. Moments later, she returns and asks you, quietly, if you have another card they can try. Looking at the debit card in her hand, you put two and two together, and a sinking feeling creeps in.

You pick up your phone and check. Sure enough, your account has a $0 balance. You just deposited your paycheck last week, and have been careful to keep a reasonable balance in there. And it’s gone. All of it.

You can’t begin to understand what happened, as you frantically call the bank, your night utterly ruined. But someone knows. The one who drained your account. The one who entered just the right username and password. The same password you use on a dozen sites. The same one you used to order flowers three years ago on a local boutique’s site. The same site whose password database was quietly hacked last week.

The Internet is a wild place

Most people on the Internet only see the tip of the iceberg. They’re on Netflix, Google, YouTube. They’re playing mobile games, ordering from Amazon. The Internet is like a giant mall with the best shops and arcades.

There’s more to the Internet than you may see. Darknets, where identities, weapons, drugs, and the darkest of pornography can be bought and sold. Cyberwarfare and espionage between countries of all sizes. Enormous “botnets,” or networks of compromised computers just like yours that are used to attack networks and crack passwords. Teams of hackers who work to find vulnerabilities in sites or in people and exploit them for amusement, financial gain, or just to make a statement.

This isn’t a reason to fear the Internet, to fear shopping online or visiting new places. This is a reason to respect it, and to be safe.

The line of fire

“But nobody will come after me!” you might think. “I’m not important. Who would target me?”

The problem with that line of thought is that it assumes a person is going after you specifically. That’s often not the case. Hackers and botnets go after many, many websites. They’re looking to hit the motherload. For instance, here’s some of the bigger sites hacked lately, and how many people were affected:

Steam – 35 million
Evernote – 50 million
Home Depot – 56 million
Target – 70 million
JP Morgan Chase – 76 million
PlayStation Network – 77 million
Anthem – 80 million
eBay – 145 million

Ever use any of these? Me too.

So what happens next? Well, automated systems will harvest the results and begin trying these combinations of usernames/passwords on all sorts of different sites. Google/gmail, banks, dating sites, anywhere. And how big are these botnets? They can reach up to the 10s of millions of computers.

You are not specifically being targeted, but you’re in the line of fire. And this is going to keep happening, over and over again.

So let’s protect you from this. I’m going to teach you about three things:

Using passwords safely
Two-factor authentication, a second layer of protection and alert system
Identifying and ensuring secure connections to websites

And in case you’re wondering, yes, you are the target of my post. So keep reading.

Passwords: Your first line of defense

Most people on the Internet treat passwords like they’re a cute little passphrase to get into a clubhouse. We’re trained by our computers to pick something memorable to log us into our desktops, a code that “protects” you from others in the house who might want to check your e-mail. Much like a standard lock on your door protects you from your neighbors simply walking in.

Nobody ever really teaches us properly. It’s common to use your dog’s name as a password, or your birthdate, or something equally easy to remember and crack. It’s also common to use the same password or set of passwords on many different sites and services, which is how our fictitious Friday night was ruined.

This is extremely important to get right. Here are the rules for protecting yourself using passwords:

Never use the same password for more than one site.
Pick a long, strong password with uppercase and lowercase letters, numbers, and symbols, without any dictionary words.

That’s basically it. Seems simple enough in theory, but how do you keep track of all those passwords? You’d probably have 50 of them!

Don’t worry, there are tools that make this super easy.

1Password

This is one of my favorite tools for staying secure.

1Password is a tool for keeping track of your accounts and generating new passwords. It works with your browser and remembers any password you enter, and makes it really easy to fill in passwords you’ve already entered.

When you’re creating a new account or changing passwords, it’ll help you by generating strong, secure, nearly uncrackable passwords. For example, here’s one it just made for me: wXXgVzb8Zp(zwmjG7zBGkg=iT.

It’s available for Mac, Windows, iPhone, iPad, and Android. It’s free for iPhone, iPad, and Android, and costs only $35 for Mac and Windows (which is a bargain for what you’re getting).

Let me show you how it works.

I’m about to log into an account on Facebook.

Instead of typing my login and password, I just click that little keyhole icon next to the address bar, which will pop up any 1Password entries I have for Facebook.

Once I click “Facebook,” it’ll fill in my username and password and log me in. It’s just that simple.

When you’re signing up for a new account, use the Password Generator, like so:

Once you create the account, 1Password will remember the password for later. Look at that thing. Nobody’s cracking that!

This all works for any site, and even works on your iPad/iPhone:

1Password is great for more than passwords. It can keep secure notes, information on your credit cards or bank accounts, or really anything else you have that you want available but locked away.

In order to access your stuff in 1Password, you only need to remember a single password of your choosing. Make sure this is a strong one, and that you don’t forget it! Write it down if you have to.

Buy 1Password and use it. Look, $35 is nothing compared to the potential fallout of being involved in the next several major security breaches.

LastPass

LastPass is an alternative to 1Password, and is great if you’re an Android user. Usage is pretty similar to 1Password.

I don’t personally have a lot of experience with LastPass, but a lot of people love it. You can learn more about it on their site.

Pen-and-paper password journal

I’m sure you’ve been told before that it’s a bad idea to write down your passwords, am I right? Afterall, if you write them down, then gee, anyone can get them!

That’s not entirely true. The fact is, you’re more at risk reusing one or two weak passwords on the Internet than keeping dozens of strong passwords written down on paper in your home.

Let’s be clear, this is not the best option, and if you’re going to do this, keep it secret, keep it safe. Still, it’s better than not having strong passwords. If at all possible, use 1Password or LastPass, but if you absolutely must, write them own on a dedicated journal that you can keep safe somewhere. Don’t lose it, and always use it for every password.

Two-Factor Authentication: Second line of defense

You’re now using stronger passwords, and you have friendly tools to help manage them. Good job! The next step is making sure that only you can log into your most important websites.

Many sites and services (Google, Apple, Dropbox, Evernote, Bank of America, Chase, and many others) offer an extra security layer called “two-factor authentication.” This is a fancy term for “We’ll only log you in if you enter a code we’ll send to your phone.” When enabled, these services will require something you know (your login/password), and something you have (your phone).

Let’s take Google, for example. You can set things up so that after entering your username and your brand-new secure password, Google will send you a text message with a 6-digit code. Once you receive the text (which only takes a second), you’ll enter it on the site, and you’ll be logged in.

Now why would you do that? To prove that you are the one logging in, and not someone who’s figured out your password. The cell network’s going to make sure that text is only going to your phone, and you’re going to prove it’s you logging in. (Some services will require that you use a specialized app, or a hardware device that fits on your keychain, but most will work with text messages.)

Imagine someone did get a hold of your password, and tried logging in. You’re still going to get that text, but that person will not. He/she won’t be able to log in as you. You’re safe! It’s also going to be a dead giveaway that your password was compromised. You’ll want to change it right away.

Basically, this is both your gated community and your alarm system.

This is pretty easy to set up at most places. Here are some guides:

You can find more at twofactorauth.org. Just click the icon under “Docs” for any service you use that’s green.

I’ll be honest with you, this will feel unfamiliar at first, and you might be tempted not to do it. Trust me, though, this is worth turning on for as many services as possible. You’ll be glad you did next time one of these companies announces a security breach.

Identifying and ensuring secure websites

Let me briefly explain how the Internet works.

When you connect to a website, the browser will usually try to access it first over the “HTTP protocol.” This is the language that browsers and web servers speak. This communication is in plain text, which means anybody that listens in can read what’s being posted. This is sort of like handing a piece of paper to someone, and having them pass it along to the next person, and so on, until it reaches its final destination.

That’s very bad if you’re sending anything confidential. Passwords, for instance. It’s important that you learn to identify when you’re on a secure website.

You know the address/search bar on your browser? Look to the left. If you see http://, or you don’t see anything but an icon and a domain name, you’re on an insecure website.

However, if you see https://, or a lock icon, or a green banner, you’re good! This is using HTTPS, an encrypted connection, meaning that nobody in-between can listen in. That’s more like writing your letter in gibberish that only you and the final recipient understand.

For comparison, these are secure:

This is not:

Always look for these before filling out any forms. If it’s not showing a green banner or lock, you don’t want to give the site any sensitive information.

If you see a green banner, it’ll show the name of the company or organization. This is showing that the encrypted channel and website have been verified by a “certificate authority,” an entity that issues certificates for these encrypted channels. It means they’ve checked that, for instance, ally.com is owned by Ally, and not by someone pretending to be Ally.

If you click the banner or the lock icon, you’re going to see some more information about the connection. Most of this will be highly technical, but you should see some blurbs about who verified the authenticity of the site, and some information on the organization owning the site.

Most websites these days are moving to encrypted HTTPS connections, and most will automatically redirect all requests from HTTP to HTTPS. This is good, but you can go a step further and have your browser always start out using the HTTPS connection whenever possible. This takes almost no effort, and is worth doing.

This is done with a browser extension called HTTPS Everywhere.

If you’re running Chrome as your browser, simply install it from the Chrome store.

If you’re running Firefox, install it from the Firefox add-on store.

Did you do it? Great, you’re done! You’re now a little bit safer on the Internet!

Putting it all together

I threw a lot of information at you, but hopefully you’ve learned a lot and will put it into practice.

So let’s summarize. If you follow the above, you’ll:

Be at less risk for identity and financial theft the next time there’s a major security breach, since your passwords won’t be shared.
Be alerted when someone tries to log in as you on any service with two-factor authentication enabled.
Have passwords strong enough to be unguessable and nearly uncrackable, for all sites and services you use.
Know how to identify secure websites, so you don’t leak passwords or other private information to anyone who’s listening in.
Automatically connect to the most secure version of a website whenever possible.

Not bad for a little bit of work. Hopefully by now, you realize that this does matter, because you, I, and everyone else really is a target, simply because we’re all part of something large enough to be a target.

So pass this around. Tell your friends about what you’ve learned. Educate your kids. Stay safe on the Internet.

A better web through spreadsheets

Leave a Comment / Misc Computers and Tech

I’ve spent the past couple of days basically living in spreadsheets, crunching sales data, entering equations, building pivot tables and forecasts, and painstakingly toggling cell borders… Your typical spreadsheety stuff. ^{(And I didn’t go crazy at all.)}

While spreadsheet work is a task an engineer would often dismiss, loathe, and try to pawn off onto an intern or manager, I’ve come to realize the opportunity we as an industry have missed.

A world on a web

The World Wide Web has been a part of most people’s lives for a couple of decades now. It has transformed society, and we take it for granted today. Before the web, communication wasn’t quite so pleasant. We had to visit our friends in person if we wanted to talk or play a game together. The events of a wild party stayed mostly in the minds of the participants, and couldn’t easily be shared with millions of people around the world. We didn’t even know that cats and cheeseburgers went so well together.

That's not what I meant! — That’s not what I meant!

It was the dark ages, and frankly, we should be embarrassed to even talk about it.

Then a wonderful man named Sir Tim Berners-Lee created the Web. There were probably other people involved, but it doesn’t matter really. The point is, he did a pretty great job and we should all buy him a drink if he’s in town.

Let me briefly explain how the web works on a technical level, using a common analogy of computers as tactical submarines. Imagine you’re in a US submarine (your computer) and you want to get some cat pictures from the guy in the Russian submarine (a Russian server). You know where in the sub he is (a “URL”), and know that the only way to get to him is through an unsecured port (we call this a “HTTP port”) or a mostly-secured-but-sometimes-not port (“HTTPS port”).

You’d load a torpedo with a letter asking for cat pictures (these are “packets”) and fire it off through their port (“HTTP/HTTPS”) into the location of the guy with the pictures (“URL”). Being trained to handle this, the torpedo would be intercepted, a new one stuffed with cat pictures, and fired back at your submarine.

This is the primary use of the web. Not so much torpedoes.

That’s… basically how the web works.

Oh and there’s also HTML. This is the universal language of web pages. It comes with a family of other technologies, like CSS, JavaScript, VBScript, Dart, Silverlight, Flash, Adobe Flex, Java, ActiveX, and a myriad of innovative plugins.

Where was I? .. Oh yeah, spreadsheets.

(Spreadsheets are more like Battleship. A5! B12!)

The missed opportunity

We have built the world’s communication, social interaction, and repositories of cat pictures on top of the web, and therefore HTML (and co).

What I’ve realized over the past two days is that building it on top of HTML was a mistake. We should have built it on top of spreadsheets.

Hear me out.

Spreadsheets have been around a long time, and unlike HTML/CSS/JavaScript, people just naturally understand them. They’re simple, intuitive, and fun!

In the dark times before tab-based browsing, a time when browser manufacturers thought window management should most resemble the winning animation of Solitaire, Spreadsheets had multiple tabs. The right technology coud have put us years ahead of where we are now.

As developers, we face religious wars over table-based layouts vs. non-table-based layouts. We waste thousands of man years on this. Spreadsheets, being nothing but table-based, would have saved us all a whole lot of trouble.

It took a long time for the world to realize JavaScript could be used for more than scrolling status bar updates and trailing mouse cursors; it could be used to write useful things, like Facebook and Twitter! All the while, spreadsheet power users were writing complicated macros to do anything they could ever want. I mean, look at this guy who wrote a freaking RPG in Excel!

Spreadsheets are inherently social. You can save them, edit them, pass them out to your friends. You can’t do that with your Facebook wall. Ever try to save or edit someone else’s webpage? Yeah, I bet that worked out great for you.

Developers, how many different third-party APIs are you dealing with in order to generate some meaningful statistics and reports for your app/startup? How much money are you paying to generate those reports? How much code did you have to write to tie any of this together? In the spreadsheet world, you’d just stick some pivot tables and graphs on the page and call it a day, spend some time with your family.

None of this nonsense with disagreements between slow-moving standards bodies that keep going back-and-forth on everything. Instead, I think we’d all feel comforted knowing we could leave this all in the hands of Microsoft.

What can you do…

I know, I know. It seems so obvious in retrospect. I guess all I can say on their behalf is that the web was once a new, experimental project, and such things are rarely perfect. Even my projects have some flaws.

Sir Tim, call me. We’ll get this right next time.

Remembering the Line Ride

3 Comments / Uncategorized

I spent the holidays at Disneyland this year with my girlfriend and my family. We stood in numerous lines for hours on end during the busiest week of the year, waiting to see Disney’s take on classic rides such as the Haunted Mansion and Small World.

Their take was fantastic, but this post is not about that.

Standing in line for the Haunted Mansion, listening to people murmur about how agonizing the lines were, it dawned on me that not everybody understood nor appreciated the true origins of these amazing amusement parks. My sister certainly didn’t know, and neither did my girlfriend.

You may not either, so allow me to share a bit of history.

Back to the middle ages

Much of what we’ve come to enjoy in amusement parks originated from fairs in the Middle Ages [1]. The food, the shows. They were further inspired over time by other events and inventions throughout the centuries that followed. One of the innovations in amusement technology that really sparked the modern era of amusement park rides was a classic mechanical ride, the steam-powered carousel, built by Thomas Bradshaw at the Alysham Fair in 1861 [2].

The problem with technological innovations is that they overshadow the simpler pleasures that came before them.

The Line Ride

Long before the carousel, in 1733, people enjoyed a simpler tradition. The humble fairgrounds in those days were unlike the marvels we have today, but were still full of events for children and adults of all ages.

One of the most beloved traditions in those days was known as the Rope Line Ride, or the Line Ride for short. Long lines of rope, attached to tall stakes in the ground, would be laid out in all sorts of patterns, forming paths for the kids to traverse. Common patterns included the spiral, the back-and-forth, and the weave.

Participating in the Line Ride was simple. A person would start at one end, following the line, seeing where it took them (by a garden, perhaps, or a wall of funny drawings), eventually coming out on the other side.

Remember, these were the days when Kick the Can and Hoop Rolling were the rage. The Line Ride was so popular that it was often nearly full of people, but this gave them time to socialize and join together in the admiration of their surroundings.

Evolution of the Line Ride

Times change, as they often do. While once a fun and common attraction, the younger generations began to grow weary of the Line Ride. In 1861, Thomas Bradshaw, the aforementioned inventor of the steam-powered carousel, forever changed the Line Ride by making it a means to an end. He put the carousel at the very end of the Alysham Fair Line Ride.

Now, instead of simply enjoying the Line Ride for what it was, people were passing through it, with great impatience, just to get to the all-new steam-powered carousel.

A new tradition was born. The Line Ride no longer became an attraction itself, but rather simply the Line, a way to control the flow of people leading up to an attraction. This was seen as a very controversial change in its day — after-all, the Line Ride was a tradition going back over a hundred years — and with it came a distrust of the newer attractions by the older generations. Of course, time passed, and the Line became the norm.

The spirit carries on

While often forgotten as an attraction, the Line Ride’s spirit remains today in our terminology and our parks. We’re all familiar with celebrities walking down the rope line, or hearing about people “working the rope line.”

And, of course, the long, grueling lines leading up to the popular attractions at amusement parks and carnivals around the world.

Using Freshdesk with PagerDuty for Better Customer Support

3 Comments / Uncategorized

At Beanbag, we’ve been using Freshdesk to handle customer support for Review Board, Power Pack, and RBCommons.

We’ve also been using PagerDuty to inform us on any critical events, such as servers going down, memory/CPU load, or security updates we need to apply to our servers.

Our customers’ problems are just as important to us as our servers’ problems, but we were lacking a great way to really get our attention when our customers needed it most. After we started using PagerDuty, the solution became obvious: Integrate PagerDuty with Freshdesk! But how? Neither side had any native integration with the other.

Enter Freshdesk webhooks

Freshdesk’s webhooks support is pretty awesome. Not only can you set them up for any custom condition you like, but payload they send is completely customizable, allowing you to easily construct an API request to another service – like PagerDuty!

This is super useful. It means you won’t need any sort of proxy service or custom script to be set up on your server. All you need are your Freshdesk and PagerDuty accounts.

Deciding on your setup

There are probably many ways you can configure these two to talk, and we played with a couple configurations. Here are the general rules we settled on:

Only integrate PagerDuty for paying customers (with whom we have support contracts). We don’t want alerts from random people e-mailing us.
When a paying customer open new tickets or reply to existing tickets, assign them to a “Premium Support” group, and create an alert in PagerDuty.
When an agent replies or marks a ticket in “Premium Support” as resolved, resolve the alert in PagerDuty.

We always resolve the alert instead of acknowledging it, in order to prevent PagerDuty from auto-unacknowledging a period of time after the agent replies. When the customer replies, it will just reuse the same alert ID, instead of creating new alerts.

Also note that we’re setting things up to alert all of our support staff (all two of us founders) on any important tickets. You may wish to adjust these rules to do something a bit more fine-grained.

Okay, let’s get this set up.

Setting up PagerDuty

We’re going to create a custom Service in PagerDuty. First, log into PagerDuty and click “Escalation Policies” at the top. Then click the New Escalation Policy button.

Name this policy something like “Premium Support Tickets,” and assign your agents.

Next, click “Services” at the top. Then click the Add New Service button and set these fields:

Click Add Service. Make a note of the Service API Key. You’ll need this for later.

Edit your service and Uncheck the Incident Ack Timeout and Incident Auto-Resolution checkboxes. Click Save.

Optionally, configure some webhooks to point to other services you want to notify. For instance, we added Slack, so that we’ll instantly see any support requests in-chat.

Okay, you’re done here. Let’s move on to Freshdesk.

Setting up Freshdesk

Freshdesk is going to require four rules: One Dispatch’r and three Observers.

I’ll provide screenshots on this as a reference, along with some code and URLs you can copy/paste.

Start by logging in and going to the Administration page.

Dispatch’r Rule: Alert PagerDuty for important customer tickets

Click “Dispatch’r” and add a new rule.

Set the Rule name and Description to whatever you like. We added a little reminder in the description saying that this must be updated as we add customers.

For the conditions, we’re matching based on company names we’ve created in Freshdesk for our customers. You may instead want to base this on Product, From E-mail, Contact Name, or whatever you like.

For the Callback URL, use https://events.pagerduty.com/generic/2010-04-15/create_event.json. Keep note of this, because you’ll use it for all the payloads you’ll set.

Now set the Content to be the following.

{
    "service_key": "YOUR SECRET KEY GOES HERE",
    "event_type": "trigger",
    "description": "Ticket ID {{ticket.id}} from {{ticket.requester.company_name}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "client": "Freshdesk",
    "client_url": "{{ticket.url}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Make note of the whole YOUR SERVICE KEY GOES HERE part in line 2. Remember the service key in PagerDuty? You’ll set that here. You’ll also need to do this for all the webhook payloads I show you from here on out.

Go ahead and add any other actions you may want (such as adding watchers, or setting the priority), and click Save.

Click Reorder and place that rule at the top.

Setting up Freshdesk Observer

Now we need to set up a few observers. Go back to the Administration page and click “Observer.” We’ll be adding three new rules.

Observer Rule #1: Resolve PagerDuty alerts on close

Add an event. You’ll set:

Use the same Callback URL as earlier, and set the Content to:

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "resolve",
    "description": "{{ticket.agent.name}} resolved ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Don’t forget that service key!

Observer Rule #2: Resolve PagerDuty alerts on agent reply

Let’s add a new event. This one will resovle your PagerDuty alert when an agent replies to it.

Again, same Callback URL, with this Content (and your service key):

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "resolve",
    "description": "{{ticket.agent.name}} acknowledged ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Observer Rule #3: Alert PagerDuty on customer reply

Here’s your Content:

{
    "service_key": "YOUR SERVICE KEY GOES HERE",
    "event_type": "trigger",
    "description": "{{ticket.agent.name}} acknowledged ticket {{ticket.id}}: {{ticket.subject}}",
    "incident_key": "freshdesk_ticket_{{ticket.id}}",
    "details": {
        "ticket ID": "{{ticket.id}}",
        "status": "{{ticket.status}}",
        "priority": "{{ticket.priority}}",
        "type": "{{ticket.ticket_type}}",
        "due by": "{{ticket.due_by_time}}",
        "requester": "{{ticket.requester.name}}",
        "requester e-mail": "{{ticket.from_email}}"
    }
}

Done!

You should now be set. Any incoming tickets that match the conditions you set in the Dispatch’r rule will be tracked by PagerDuty.

Now you have no excuse for missing those important support tickets! And your customers will thank you for it.

Breaking back into your network with the Synology Web UI

5 Comments / Misc Computers and Tech

Have you ever left town, or even just took a trip to the coffee shop, only to find that you’re locked out of your home network? Maybe you needed a file that you forgot to put in Dropbox, or felt paranoid and wanted to check on your security cameras, or you just wanted to stream music. I have…

The end of a long drive

Last night, I arrived at my hotel after a 4 hour drive only to find my VPN wasn’t working. I always VPN in to home, so that I can access my file server, my VMs, security cameras, what have you. I didn’t understand.. I was sure I had things set up right. You see, I recently had my Xfinity router replaced, and had to set it up to talk to my Asus N66U, but I was absolutely sure it was working. Almost sure. Well, I thought it was working…

So I tried SSHing in. No dice. Hmm.. Any web server ports I exposed? Guess not. Maybe port forwarding was messed up somewhere?

Ah HA! I could reach my wonderful Synology NAS’s web UI. If you haven’t used this thing, it’s like a full-on desktop environment with apps. It’s amazing. Only thing it’s really missing is a web browser for accessing the home network (get on this, guys!). After spending some time thinking about it, I devised a solution to get me back into my home network, with full VPN access (though, see the end of the story for what happened there).

Christian’s step-by-step guide to breaking in with Synology

No more stories for now.

To get started, I’m assuming you have three things:

Remote access (with admin rights) to your Synology NAS’s web console.
A Linux server somewhere both sides can log into remotely (other than your local machine, as I’m assuming yours isn’t publicly connected to the network).
A local Linux or Mac with a web browser and ssh. You can make this work on Windows with Putty as well, but I’m not going into details on that. Just figure out SSH tunneling and replace step 7 below.

All set? Here’s what you do.

Log into your NAS and go to Package Center. Click Settings -> Package Sources and add:
Name: MissileHugger
Location: http://packages.missilehugger.com/
Install the “Web Console” package and run it from the start menu.
Web Console doesn’t support interactive sessions with commands, so you’ll need to have some SSH key set up on your linux server’s authorized_keys, and have that key available to you. There’s also no multi-line paste, so you’ll need to copy this key through Web Console line-by-line:
Locally:
```
$ cat ~/.ssh/id_dsa
```
On Web Console:
```
$ echo "-----BEGIN DSA PRIVATE KEY-----" > id_dsa
$ echo "<first line of private key>" >> id_dsa
$ echo "<second line of private key>" >> id_dsa
$ ...
$ echo "-----END DSA PRIVATE KEY-----" >> id_dsa
$ chmod 600 id_dsa
```
Establish a reverse tunnel to your Linux box, pointing to the web server you’re trying to reach (we’ll say 192.168.1.1 for your router).
Remember that Web Console doesn’t support interactive sessions, or pseudo-terminal allocation, so we’ll need to tweak some stuff when calling ssh:
```
$ ssh -o 'StrictHostKeyChecking no' -t -t -i id_dsa \
      -R 19980:192.168.1.1:80 youruser@yourlinuxserver
```
The ‘StrictHostKeyChecking no’ is to get around not having any way to verify a host key from Web Console, and the two -t parameters (yes, two) forces TTY allocation regardless of the shell.
If all went well, your Linux server should locally have a port 19980 that reaches your web server. Verify this by logging in and typing:
```
$ lynx http://localhost:19980
```
On your local machine, set up a tunnel to connect port 19980 on your machine to port 19980 on your Linux server.
```
$ ssh -L 19980:yourlinuxserver:19980 youruser@yourlinuxserver
```
You should now be able to reach your router. Try it! Open your favorite browser and go to http://localhost:19980
Clean up. Delete your id_dsa you painfully hand-copied over, if you no longer need it, and kill your SSH sessions.

Epilogue

While this worked great, and I was able to get back in and see my router configuration, I wasn’t able to spot any problems.

That’s when I realized my Mac’s VPN configuration was hard-coding my old IP address and not the domain for my home network. Oops 🙁

Hope this helps someone!

A new adventure begins

8 Comments / Life, Uncategorized, VMware

Act 1, Scene 1

August 23rd, 2004. A young kid, not even 21, freshly dropped out of college, passionate about open source and programming. He walks into his new office at his new job at VMware, his first job, ready to start the day, eager to impress and meet his new co-workers.

Nobody was there. Thumbs twiddled.

10AM starts to roll around, and finally, the first sign of life. Over the next couple hours, more people show up.

Over the next week, he’s set up and learning the ropes. Working on his first bug, soon his first feature. Attending his first team get-togethers. Making his first Bay Area friends.

Over the next few months, his first birthday celebration at work. His first glass of champagne. His first real responsibilities.

Over the next few years, bigger roles, leadership roles. He began to get a feel for where he’s truly going in this silly little world.

This, of course, was me, on my first adventure in the tech industry.

I was lucky to be placed in a fantastic team full of smart, hard-working, dedicated, and fun software engineers and managers. We’d discuss architecture, brainstorm ideas, joke around, watch YouTube videos, play poker, watch movies, go to events. The web of awesome people extended throughout the company as well.

Over the past nine years, I worked on a great many things.

Eight releases of VMware Workstation, including a three-year effort to build Workstation 8.0 (a major undertaking).
VMware Server 1.0. I was the primary Linux developer, pulling caffeine-fueled all nighters to meet insane deadlines.
Player and VMRC, which powers the VM console for our enterprise products.
The core foundation used in Fusion and other products.
Icons and artwork for the Linux products.
I introduced Unity to Workstation. (Sorry, guys…)
Helped in the creation of the current generation of the View client for Linux.
More recently, I developed WSX, an experiment in developing a pure web client and console for accessing remote VMs anywhere, from desktops and tablets.

Not a bad run.

This Thursday, August 1st, 2013, I’ll be leaving VMware.

Revision 1: “Add the reviewboard”

Several years ago, I began working with my good friend David Trowbridge on an open source project for keeping track of patches and easing the review process. We spent many years in the open source world looking at raw diffs on bug trackers and in e-mails, and things weren’t that much better at VMware. As Mr. Wonderful says, “There has to be a better way!”

So we slaved away in the late nights and weekends, iterating and iterating until we had something we could use. We named this product “Review Board” (or “the reviewboard,” as our first commit says). We put it out there for people to play with, if anyone was interested.

There was interest. Review Board is now used around the world at companies big and small. We’ve continued to improve and grow the product and turn it into something that developers actually want to use.

We later built a startup around this. Beanbag.

It’s dangerous to go alone. Take this.

Earlier this year, we met a local entrepreneur as part of a program we participate in. We quickly developed a rapport, and he offered to help and advise us in our efforts to grow our business. It wasn’t long after that we started discussing funding, and where that could get us.

We started pitching, and he reached out to his contacts. Before long, we had what we needed to give this a try for a couple years.

Step 3: Profit?

There’s a lot of hard work ahead of us, but we’re up to the challenge. It’s both exciting and terrifying.

Leaving my team behind at VMware is hard, but everyone has been so supportive.

Basically.

In the coming months, Review Board’s going to grow in exciting new ways. We’ll be gearing up for a new 1.8 release, releasing our first commercial extension to Review Board, and improving our SaaS, RBCommons. We have a pretty good idea where we want to go from here, and now we can better focus on making it happen.

It’s going to be an awesome adventure.

WSX 1.1 beta is released, with bookmarkable VMs!

Weird bugs: Django, timezones, and importing from eggs

VMware WSX 1.0.1, and the new Community Page

13 Comments / Uncategorized

Last month, we released WSX 1.0. Those following along with the beta knew what to expect, as it was largely our latest Tech Preview release with some more fixes thrown in.

Unfortunately, we also threw in a regression that we’ve since been working to fix. The console would, at times, stop displaying anything, just appearing black. Clicking the little Refresh button would fix it, but it was annoying and, to me personally, quite embarrassing.

Today I’m happy to announce that we’ve released WSX 1.0.1, which has fixes for the black screen issue, and also support for Windows domains in usernames (indicated by “MYDOMAIN\username”) when logging in.

Along with the release, we’ve also introduced the new WSX Community Page, where you’ll be able to find the latest releases, documentation, and discussions on WSX. I’ll be on there, as will some of our QA, to answer questions.

VMware WSX July Tech Preview Release

45 Comments / VMware

A month ago, I announced the release of the June VMware WSX Tech Preview. In it, I covered our awesome new Retina support for MacOS X and iPad, voice input, Windows support, and more. We had some great feedback and worked to address some of the key issues, while putting in a few new things.

Today I’d like to announce the WSX July Tech Preview, which is chock full of improvements. Let’s go over them, shall we?

Improved Home Page

The Home page on WSX was a bit.. barren. Completely blank and useless, in fact, but no more. Now the Home page serves as a jumping point to get to your servers and to configure your server list. This replaces the Configuration page. In the future, I’d like to further improve this by giving quick access to your most recently used VMs.

Improved Server Page

The Server Page was a jumbled mess of links to VMs. Now it’s a nice, filterable, alphabetical list. Search for your VMs by typing part of their name, or filter them by power state. It’s much easier now to find what you need. Oh, and the VM icons now show the power state as well!

Big Honkin’ Power Button

Much like VMware Player and Fusion, we now show a Power On button on top of the screen when the VM is powered off or suspended. This gives you both a nice visual showing what state your VM is in, and a big, easy to hit target for powering it on. Particularly great for touchscreens.

Better Touch Input

Working with your VMs on an iPad is now much, much nicer. We map a bunch of gestures to mouse events, giving you support for right-click, middle-click, and scrolling.

To right-click, just tap-and-hold part of the screen. Or you can press with one finger and tap with a second. Pressing instead of tapping with the second finger is equivalent to holding down the right mouse button, letting you drag around the screen. The actual click will take place where you pressed the first finger.

Just add a third finger to the mix to work with the middle button. That is, press with one finger and then tap (or press) with two more fingers.

Drag up or down with two fingers to scroll. This works just like the mouse wheel.

Mouse Wheels

If you’re using WSX from a PC or Mac, your mouse wheel should now work! Scroll to your heart’s content.

(Note: Mouse wheels events work a bit differently across different browsers, so depending on which browser you use, the sensitivity may be off. It works pretty well in Chrome and Firefox.)

Better Retina Support

Retina was cool and all, but reconnecting to a VM would put that VM back in non-Retina mode, moving all your windows and icons around. No more! Now if your VM was in Retina mode before, it should be in Retina mode when you connect next.

You can pretty easily live in Windows 7 with high-DPI set in Retina mode on an iPad 3 now.

There’s also new Retina icons on the action bar below the screen.

SSL

WSX can now (optionally) encrypt all the traffic between the WSX server and your computer or mobile device. You only need to generate or purchase an SSL certificate, name the files wsx.crt and wsx.key and place them in your /etc/vmware/wsx/ssl/ directory (on Linux) or Application Data\VMware\VMware WSX\SSL directory (on Windows).

Why isn’t this the default, you may wonder? Of course we’d love to just generate self-signed certs by default and encrypt everything, but it turns out there are some browser compatibility issues with self-signed certs and WebSockets, which we use for all our communication. iOS, in particular, is currently broken in that regard.

There are many places on the web where you can get free or cheap certificates that should work fine for you. We highly recommend installing an SSL certificate to enable HTTPS for WSX. Another option is to require access to WSX through a secure VPN.

Easier Installation

Some Windows and Linux users hit problems with our installation in the previous release.

A few Windows users had a crash at startup. This was due to a naming conflict causing an early failure, which we’ve fixed.

Linux was a bit more of a complicated story. We required a specific version of Python on the system, and while not an uncommon version, it proved to be too hard to get going on many systems. This is no longer a requirement! You don’t even need Python installed. We run completely independently now.

So give it another try!

Smarter Defaults

New installs would come with a “Shared VMs” server pre-configured. The intent was to make it easy to get to your Workstation Shared VMs. Some people, though, had changed the port for their Shared VMs, which confused WSX and caused some problems. We’ve improved the smarts to only add this server if it’s installed on the same system as Workstation, and to grab the port from that configuration.

Performance Tweaks

Connecting to the VM should be a bit faster now.
Resizing the browser window no longer causes the VM to take forever to update its resolution. We were spamming it with resolution change requests.

Bug Fixes

Fixed a crash when accessing some Linux VMs that had Tools but didn’t support switching resolutions.
Fixed the styling of some parts of the UI on some browsers. The Log In page, in particular, looked pretty broken on the iPad.

Known Problems

Connecting to vSphere will still only show VMs in the root VM folder, and not in subdirectories or datacenters. Work is still needed here.

Feedback

As always, please let us know if you hit any problems or have any questions!

Author name: chipx86