Saturday, December 05, 2015

Synergy, Screen Savers and Security

My employer requires me to use a password-locked screen saver on my Windows 7 laptop, so I was surprised and confused last week when I unlocked my system to see a 'security violation' notification; my confusion became acute when I check my Windows configuration and found that I had configured the screensaver properly.

After a few minutes of experimentation, I discovered that Synergy was to blame. (For those unfamiliar with Synergy, it's a software-based KVM (non-video) system to share keyboard/mouse/clipboard across multiple platforms. While it was originally open-source, it has become a paid-download product - one of the VERY few such packages I use.)  As it happens, Synergy's default behavior is to synchronize screen savers across all participating systems; since my Synergy server (running Linux) did NOT have a screensaver enabled, the Synergy client on my Windows 7 system silently disabled its screensaver as soon as it made the initial Synergy connection.

Well, now that I know this, how do I fix it?  Well, there's some tweaking to be done on both sides.

On the Synergy server, I added the following section to /etc/synergy.conf:
section: options
    screenSaverSync = false
This disabled the synchronization of screensavers across my Synergy systems; however, I immediately found that I couldn't send a control-alt-delete signal to Windows 7 via Synergy.  Well, it turns out that, by default, Windows 7 doesn't allow the Secure Attention Sequence (SAS - the fancy name for control-alt-delete) to be generated by anything other than the system keyboard...but there's a fix for that. Head over to the Start menu and run gpedit.msc (the Local Group Policy editor). Navigate through Computer Configuration,  Administrative Templates, Windows Components, and Windows Logon Options. At this point, double click on "Disable or enable software Secure Attention Sequence" and configure the policy like this:

Once this policy was enabled and applied, everything worked as expected; my Windows screensaver kicked in when it should AND was password-locked, and I could send Control-Alt-Delete via Synergy with Control-Alt-Pause/Break. A quick security scan confirmed that my employer's requirements were met, and all is now well.

I'm not running Windows 8 or Windows 10 in my environment; if you ran into similar problems with Synergy, let us know in the comments.

Android-x86 and VirtualBox - A Potent Combination

For a "network guy", mobile devices can be really frustrating for one simple reason - unless you jailbreak the device, it can be rather difficult (if not impossible) to dive under the hood and get an idea of how the devices behave at the network layer.  Unless you just happen to have a spare device or two laying around and are willing to jailbreak them, you might be wondering if there's any way to observe network behavior in a fairly straightforward fashion. When it comes to Android, however, there IS a solution.

Now, it's certainly true that you can install the Android SDK and use its included emulator to run various versions of the OS, but that's a LOT of overhead; I don't need to dive THAT deeply into Android internals, and--to be honest--the performance of the emulator isn't all that great. I recently discovered the Android-x86 project, which has been going strong since 2009 to bring Android to the x86 platform. I installed Android-x86 on an old netbook and started playing with it, and then I realized...why not run it in a VM?

Enter Oracle VirtualBox.

This free virtualization package is available for Windows, OS X, Linux and Solaris; I'm currently using it on my Windows 7 laptop and several of my Ubuntu Linux machines, so I tossed an Android-x86 ISO into a new VM and went to work. Ten minutes later, I had this:
Android-x86 5.1RC1 running under VirtualBox on Windows 7
Now, it isn't perfect; since my laptop isn't a touchscreen, I can't work with gestures or multitouch, and (obviously) telephony functions aren't available. However, one can certainly exercise basic functions of just about any Android app within Android-x86...and, thanks to VirtualBox's extensive network support, it's a trivial matter to capture the network traffic of your Android VM with Wireshark. In no time at all, I was profiling the network usage/performance of various Android apps.

If you need to work with several versions of Android, Android-x86 can help you there as well; you can download ISOs of Lollipop, KitKat, Jellybean and Ice Cream Sandwich and install them to their own VMs. You can also share/copy VirtualBox VMs across multiple platforms (for example, I moved an Android-x86 VM from one of my Linux systems to my Windows 7 system with no problems). While I haven't done it myself, I'm told that some enterprise admins have registered their Android-x86 VM with their mobile device management (MDM) products of choice for use in testing/prototyping...

(NOTE: You can install Android-x86 to a bootable USB stick, if you so desire; here are the details.)

(NOTE #2: If you have a touchscreen laptop sitting around, give it a shot! Here's a video of Android-x86 4.4.2 (KitKat) running on a Lenovo Y50.)

So, whether you're testing, developing, or just want to play around with Android without buying a device or jailbreaking your personal stuff, take a look at Android-x86 and VirtualBox; they make a good pair.

Friday, December 04, 2015

New Linux installs - What Are YOUR "Must Have" Apps?

I think that every Linux user has their own list of "favorite" apps which, for whatever reason, aren't included in the default distribution. Some of our choices may be driven by work responsibilities, while others make the list for usability...and it seems that most of us have at least one or two "just messing around" applications as well.

While I'm an 'occasional user' of several Linux distributions (Red Hat, SUSE, Linux Mint, and Fedora), I'm currently running Ubuntu 14.04 and 14.10; I make no guarantee that the applications I list are available for every distribution, or that the release offered in your distribution is the most recent; I've provided links to the home pages of the various projects, in case you want to run the latest-and-greatest stuff. Having said that, and in no particular order, here are a few of the apps I automatically install on any new Linux box:

Shutter: As a software support engineer and networking geek, I use screenshots on a near-daily basis - lots and lots of screenshots, particularly in chat sessions with my colleagues. Shutter is a comprehensive screenshot tool which includes the ability to save images in all major formats, export to sites like Imgur and Dropbox, annotate/edit images, and more.

Wireshark: The opening screen of Wireshark reads, "The World's Most Popular Network Protocol Analyzer"...and, well, they aren't talking trash. If you're doing anything interesting at the network layer, you NEED Wireshark. It not only does network captures, but also reads/writes the file formats of every major network analysis device out there. (If you're running Ubuntu 12.04, 14.04, 15.04 or 15.10, there's an official wireshark-dev PPA you can use to install the latest build (Wireshark 2.0-stable) instead of building from source code!)

Docky: OK, I'll admit it - I don't like the Unity Launcher provided by Ubuntu. Docky is a nice, clean application dock/launcher that includes a selection of useful docklets/helpers; it's almost trivial to customize Docky to your taste.

GIMP: (GNU Image Manipulation Program) This is my "just messing around" app; I like playing around with images, even though I'm not very good at it (just yet). GIMP has tons of features, including many into which I have not yet delved, but it certainly does everything I need to do as far as image maniuplation is concerned.

BOINC: I very much like the idea of digital philanthropy; if my box has idle time, why not donate it to a good cause? Well, the Berkeley Open Initiative for Network Computing (BOINC) client is a good way to go; there are dozens, if not hundreds, of scientific research projects to which you can donate your system's idle time via the BOINC client. My personal preference is World Community Grid, which has my systems currently working on genome sequencing and attacking the Ebola virus. Since I keep several of my systems running 24x7, there's lots of idle time while I'm sleeping - 'nuff said. (Personal request - if you decide to participate in WCG, use this link to register...and that widget on the right sidebar of this blog will pick up a "recruitment" badge. **grin**)

That isn't my complete list of "must have" apps, but it's a good start - feel free to add your favorites in the comments!

Friday, May 02, 2014

Wireshark, GeoIP and Checking Up on Mobile/Home Carriers

As enterprises move an ever-growing list of services into the mobile space, it becomes essential to understand the limitations of the mobile network infrastructure.  No longer can we perform true end-to-end capture or analysis of network data; what was the "last mile" is now an indeterminate path through any number of relatively impenetrable mobile networks.  In this respect, troubleshooting issues involving mobile devices can be quite the challenge. At the same time, we're dealing with an increasing number of telecommuters, those "work from home" people who are at the mercy of their ISP.  What, then, is the enterprise network analyst to do?

The answer (or, at least, a good start toward an answer) lies in geolocation - the association of IP address spaces with their geographic and/or corporate assignments. Geolocation can be been integrated with DNS (or, at least, BIND implementations of DNS), the Apache web server, and any number of other applications, including (as of version 1.1.2) our favorite network tool - Wireshark. The marraige of Wireshark's analysis and GeoIP's provider identification produces some powerful analysis capabilities.

You can download free GeoLite versions of current GeoIP databases from MaxMind.  MaxMind provides free GeoLite databases for IPv4 and IPv6 city, country and autonomous system numbers (ASNs); you'll want to download the binary versions, not the CSV editions.  The MaxMind databases are updated on a monthly basis; if you like the results of this exercise, you'll need to set up a process to handle monthly updates.

Now it's time to make Wireshark GeoIP-aware:

1) Once you've downloaded the GeoIP databases, unzip them to a permanent home. On my Linux systems, I created the /usr/local/geoip directory for this purpose; on Windows systems, I use a \geoip subdirectory under the Wireshark installation directory.  The databases can be (and should be) read-only; you won't be adding any data. Now, we're ready to pull them into Wireshark.

2) Open Edit->Preferences in Wireshark, select Name Resolution, and click the "Edit" button next to GeoIP database directories; click New in the resulting dialog and add the directory you created in step 1. Using my Linux example above, you should have something like this (click to enlarge):
3) Close Wireshark and reopen.  You're ready to go!

So, what exactly does this give you? Well, to start with, you'll find that Wireshark's Statistics->Endpoints includes sortable columns for City, Country and AS Number, like so (click to enlarge):
You'll also find GeoIP information in the Details pane of the packet view, under Internet Protocol:
Finally, you can now use GeoIP information in your Wireshark display filters. For instance, I'll take the ASN definition from the previous example (British Sky Broadcasting) and use it in a display filter to show me ALL traffic from that provider:
ip.geoip.src_asnum == "AS5607 British Sky Broadcasting Limited"
Other GeoIP display filters allow you to select/view traffic based on country (e.g."Egypt"), city (e.g. ip.geoip.src_city == "Birmingham, AL") or even longitude or latitude (e.g. ip.geoip.src_lat == 33.520699).

From here, you can isolate, analyze and/or export data for specific providers, whether they serve mobile or home users; you could even develop "country profiles" if you're serving an international clientele.  While the GeoIP data isn't perfect, it's more than adequate to help you create a profile of your mobile userbase.

Have fun!

Thursday, May 01, 2014

Network Troubleshooting - Sometimes It's What You DON'T See...

I spend a healthy chunk of my typical work day analyzing network packet captures.  My primary tool is Wireshark, which humbly presents itself as "The World's Most Popular Network Protocol Analyzer."  (Seriously - if you aren't using Wireshark, go download it NOW.)  Protocol analyzers are great for identifying typical "red flags" in packet data, but they're all limited to what the raw data might indicate; customer network environments are so broad (and so varied) that the network engineer--especially one "on the outside looking in" with only a small data set--relies heavily on experience and intuition.

One recent case was presented as "many failed connections," and a 6-minute packet capture soon landed in my lap.  Now, every Wireshark user has their own approach; I usually take advantage of Wireshark's display filters to get a general "feel" for the incidence of Layer 3/4 problems. With a typical capture file, I'll start with tcp.analysis.flags,which simply tells Wireshark, "hey, show me what YOU think are TCP problems." Now, as I said, none of these tools are perfect, so take these results with a grain of salt; they're only as good as are the underlying data, and it's very easy to collect inaccurate or incomplete data. After taking a look at the results of this display filter, I noticed what seemed an high number of TCP retransmissions, so I decided to see exactly which packets were being retransmitted with a different display filter, tcp.analysis.retransmission, which will show me only those packets Wireshark believes to be TCP retransmissions. The resulting numbers were somewhat high, but I've seen worse. Now, the complaint was very specific that new connections were failing; no mention was made of existing connections being interrupted/terminated; so, I went to Wireshark's Statistics->Conversations dialog and sorted on the "Packets" column to look for very short conversations and found HUNDREDS of conversations that only lasted for a few packets, like these:
Well, now, wait just a minute - the TCP handshake requires 3 packets (SYN, SYN/ACK, ACK) to establish a conversation, and I'm seeing hundreds of conversations that are only exchanging 3 to 6 packets. After checking a few suspect conversations, I found a pattern, namely this:

So, the remote endpoint starts a conversation with a SYN packet and the local endpoint responds immediately, but we see the remote endpoint retransmitting its SYN packet within 10ms. The local endpoint retransmits its SYN/ACK, but neither the original nor the retransmitted SYN/ACK seem to reach the remote endpoint, and the conversation attempt is ultimately terminated with a TCP reset (RST) packet. Back I go to Wireshark's display, this time to ask about a very specific type of TCP retransmission:
tcp.analysis.retransmission && tcp.flags.syn==1 && !tcp.flags.ack==1
With this display filter, I'm asking Wireshark to show me all retransmitted SYN packets; the "!tcp.flags.ack==1" eliminates SYN/ACK packets from the display. The results were startling; within a 6-minute period, more than 110 endpoints had retransmitted more than 170 SYN packets...and all of them had failed to complete the TCP handshake.

Well, if conditions are this bad to START conversations, then there must be thousands of cases in which existing connections die before completing successfully, right?  Let's go back to Wireshark's Statistics->Conversations dialog and sort on Duration to look at long-lived conversations:
Hmm...I have hundreds of conversations that last longer than 2 minutes...but I can't find one that suffers from retransmissions sufficient to terminate the conversation.

If I were looking at a general network congestion issue on the local network, I'd expect conversations to suffer equally--packets are packets, right?--but this is something different. That seeming conflict in the data prompted what proved to be the key question:
If I'm seeing HUNDREDS of new conversations fail the TCP handshake due to excessive retransmissions, why DON'T I see established conversations suffering excessive retransmissions as well?
Well, after few moments' thought, it occurred to me that the only network devices that usually make specific distinctions between new and existing connections are those involved in network security. A brief conversation with the customer revealed that an intrusion protection system (IPS) was in place and "inspecting" conversations. When we conducted a test that bypassed the IPS, the incidence of failed TCP handshakes decreased by roughly 98%; our troubleshooting attention is now properly directed.

So, the moral of this story: Pay attention to the data, but pay equal attention to what isn't there.

Wednesday, March 05, 2014

SxSW = Tons of Free Music!

SXSW Music: South By Southwest 2014 | Lineup | Rumors | Tickets | Film Festival | Dates | Mobile App | Video | Austin | TexasAustin, Texas is cranking up South by SouthWest 2014, and that means music - LOTS of music. SxSW gets most of its mainstream press for its technical and creative content these days, but the festival's roots are musical; hundreds of bands will be playing in dozens of venues. (Can you tell that I REALLY wish I were attending?) As you might expect from a festival that features so much indie music, there are more free samplers and promotional releases than anyone could possibly want to download...unless, of course, they're a total music geek. So, since I'm already downloading these (grin), I thought I'd share the links with you. In the interest of brevity, I won't go into lengthy descriptions of each collection; the only thing I'll say is that I inevitably find REALLY good music, across a range of genres, in every year's samplers. Having said that, let's get to the list: 

NPR's Austin 100 - A massive (839 MB) collection of NPR's picks. 
Arts & Crafts Records - This Canadian label will have a healthy presence in Austin. 
Bar/None Records - Always an interesting selection.  
SxSWBaby! - Another large (80 tracks, 314MB) collection from the thoroughly UNofficial SxSW blog. 
Rubberneck/Burger City - Truth be told, this one is brand-new to me; I'm downloading the tunes as I write this...  
Dine Alone Records 
OK! Records 

Some of these are straight downloads, while others require your email address. Enjoy!

Wednesday, January 15, 2014

#SpeakerU - Speaker Coaching: It's Worth The Time

OK, so, you've been selected to speak at a conference.  You've spent hours building your slides, you've gone through your outline a dozen times, and you've even jotted down particular words (or turns of phrase) you want to use.  There's only one problem - you've never really given this presentation to an audience.

Enter the speaker coach. 

Now, everyone seems to have their own idea of what a speaker coach should be; as far as I'm concerned, a good technical speaker coach should be able to do two things:
  • Critique the mechanics of your presentation style, and
  • Evaluate the technical content of the presentation itself.
The former category can be tricky for technical folks.  It seems that we're used to people speaking fast, using run-on sentences, and throwing jargon about with reckless abandon.  Most of us have to take a breath and slow things down a bit when speaking to an audience that isn't as familiar with the subject matter as we might be.

The latter focus--the technical content--should be evaluated in the context of the intended audience.  If you're targeting your presentation to beginners, the question is, "Did they get from [nothing] to [basic understanding]?"; presentations to folks with intermediate skills should result in the listener "getting to the next level," and speaking to advanced audiences...well, at that point it's usually about bringing something new to the table, since they (by definition) already know the beginning and intermediate stuff, right? So, you want to find someone who fits the "typical attendee" model, NOT someone who already knows the material.

Long story short, folks - find a person (or persons) who can do these two things for you.  Take them through your presentation.  Don't stop, don't pay any attention to the fact that there are only one or two people in the room, and don't hold anything back: give the presentation as you expect to deliver it on stage.  If you can get a projector, do so; make this as realistic a "dry run" as possible.  After you're done, sit down with them and ask two questions:

  1. "Could you hear and understand my words and how I spoke?"
  2. "What can you tell me about [subject of presentation]?"
Their answers will tell you what (if anything) you need to change.

I can't say this strongly enough: DO THIS.  DO THIS SEVERAL TIMES.  Every runthrough you can make before hitting the stage will improve your performance.

Now, go practice!