So, SOPA is the news of the day, in terms of the Internet and security; it has been for well over a month now.
In case you’re not familiar, SOPA is the Stop Online Piracy Act. It will “authorize the U.S. Department of Justice to seek court orders against websites outside U.S. jurisdiction accused of infringing on copyrights, or of enabling or facilitating copyright infringement.”

I won’t bore you with the typical arguments about how it’ll infringe on free speech, or weakens safe harbor, etc. These arguments have been made, and they may have some validity, but let’s talk technology.

SOPA is the most recent in a long line of legislation intended to regulate the internet. Such legislation is doomed to failure. The internet was designed to be impossible to regulate. SOPA focuses on preventing search engines from directing users to sites, and ordering domain name registrars to delist sites. While there are other provisions, these are the primary tools for stopping piracy outside of US jurisdiction. They’re supremely ineffective tools, because neither search engines nor DNSes are necessary for the function of the Internet.

To understand this, let’s step back and look at what the Internet really is.

The Internet, or rather its precursors, were created in the 1960s as a result of an initiative by DARPA – the Defense Advanced Research Projects Agency. DARPA is notable for investing in all sorts of interesting projects that might have military applications – many are successful, and result in some of the most powerful technologies of our time. Granted, many are pretty off-the-wall and don’t look like they’ll ever amount to anything, but that’s the risk you take.
The Internet was created to enable communications even against attempts to disrupt the network – even against the loss of most metropolitan areas, such as might happen during a nuclear war. This is actually very hard to do: you have to come up with a design that works even if all of your central nodes are gone.
The Internet as we know it today has a number of elegant solutions which make it the most robust communications network ever known.
The first is in the data packet. All data sent on the Internet is broken up into packets – even when it’s called “streaming”, it actually consists of content that has been broken up into separate packets which are then reassembled at the destination. Each packet, in turn, has a portion that says to where the information is going (the address) and a portion which contains the actual data (payload). This means that any given packet can be lost or corrupted, and the entire rest of the message will still get through. Granted, with encryption or compression this might be a moot point, but on the other hand with error correction it can actually be made even more robust.
Beyond that, there are the routing protocols. Various routing protocols work somewhat differently in ways that are hard to describe, but they all serve roughly the same function. When a router receives a packet, it looks at the destination address and tries to find a route to that address. What’s especially clever is that if a given route fails, the router can then select an alternate route. In this way, the Internet can be self-healing. Bandwidth might drop as alternate routes are used, but so long as a path exists the message can still get through. And that path isn’t limited to even the same medium as was used in the past: Internet data can be sent over copper, satellite, radio, laser, physical media, even carrier pigeon!

Now, I haven’t mentioned DNS or search engines so far. That’s because we don’t need either.

DNS – Domain Name Service – is a technology that renders IP addresses into human-readable names. The addresses to which I alluded earlier are numerical. In IPv4 they’re a 32-bit binary number; in the newer IPv6 they’re a whopping 128 bits. Rendered into decimal, they’re a bit more manageable, but not by all that much – would you like to memorize strings of numbers like “192.168.15.106” for every website you visit? DNS is a service that your computer accesses which translates the much easier to recall names, like www.google.com into 74.125.227.147. It’s a nice convenience, but you don’t actually need it. And you’re not locked in to any one DNS server – you can set up your own, or you can actually use one that’s based outside of US jurisdiction.

And search engines?
Same thing – they’re a convenience. There isn’t even a specification on what a search engine is. And as you doubtless know, you can use whatever search engine you like, again including ones that are based outside of US jurisdiction.

There are technical solutions to these oversights, of course. But, thanks to the structure of the Internet, there are workarounds for those as well. The Internet was designed to be hard to disrupt. From a technical standpoint, attempts to regulate the Internet are basically the same as trying to disrupt it; it’s simply not a technology which was designed to be regulated.

While I did my thesis on this topic back in 2001, I haven’t used the knowledge or skills I gained from it much – or really at all. But I think it’s an interesting topic, and one that security folks and system administrators should at least be passingly familiar with. The technology has certainly changed since I did my thesis.

When you look at an IP address or even domain name in your logs – where is that person coming from? You might need to know for forensics purposes, or even “cyberwarfare” purposes. Keep in mind that spoofing an IP address isn’t rocket science, and just knowing if the IP address in your logs is the one doing the activity isn’t guaranteed. However… TCP traffic has a handshake, and in order for the replies to get somewhere, there has to be a valid “other end” of the connection. That IP address has to be a part of the connection for anything that needs replies (UDP traffic and DDoS? you’re on your own). The attacker may be using a bot net or another compromised machine, so just knowing the location of the IP address doesn’t give you the attacker (or file downloader….)

Used to be you could make a really good guess at the location of an IP address based on a traceroute and noticing the routers that the traceroute went through. You *might* get that information now – depends on if the backbone routers have ICMP turned off (most don’t) and how many hops you go through. If you’re going to an IP on the same backbone provider (or a very well connected provider like Google), you won’t get much information from traceroute. However, it’s a good first start.

WHOIS may also be another helpful tool. whois IPaddress will return different information than whois domainname. The returned information will show who owns that IP address according to the RIRs (ARIN/RIPE). Now, still not going to get you a jackpot every time, but it might. If the IP address belongs to a large organization who has its own IP address space assigned, you’ll have at least the company (and maybe the location, depending on how the company assigns IP addresses). You may also run into another wall if the whois search returns an ISP or hosting provider.

At this point, you’re slowly running out of free options. There are several companies who specialize in geolocation and are happy to sell you the information, which is how most web sites and services find that out (except mobile devices, which are a whole ‘nother ballgame). One service does provide a free database with less accuracy: http://ipinfodb.com/ It reliably figured out most of the IP addresses I tossed at it.

The big databases are put together in several ways: negotiating with ISPs and hosting providers to get the internal information (what dynamic IP space is assigned to the DC area vs the NY area), and just plain old brute work. Anyone remember several of the web sites that’d ask you where you were located??? Guess who ran those, and where that data is now.

The current “hot word” in security is SCADA (Supervisory Control And Data Acquisition) systems. The rumors of Russia attacking a water pump system in Illinois and the actual attack of a water treatment plant in Houston have all been in the news in the last few months.

SCADA systems are used in many industrial applications – water treatment, chemical manufacturing, product manufacturing, etc. More and more industries are becoming automated with robots and all kinds of other neat technologies replacing humans (and theoretically human error). Something has to control these systems, otherwise, you’re just replacing the labor force with folks who know how to control these automation tools. But something important to take away is that SCADA systems can literally control life and death situations – water treatment, medical device manufacture, chemical creation. If something goes wrong with these systems, the resulting device/product may kill someone.

The life and death situation is relatively new in the “hacker” community. Generally, the goal is money, and while it would really suck to not have money in your bank account, it’s very rare that that situation would directly kill you. What’s also new is that the makers of these automation tools have decided that having these tools connected to a network would be useful – without considering the security implications.

These devices have not historically been connected to a network. A computer sat on the manufacturing floor that controlled the device(s), and humans walked up to the computer and programmed it, or read data from it, or whatever needed to be done. Now, this computer is networked and takes commands from and sends data to other systems on the network. Computers are fundamentally dumb things – they do what they’re told, and in the case of SCADA systems, don’t necessarily check to see who told them to do something. So, if an attacker gets onto the same network that these automation devices are on and can figure out how to send commands (trivial for most attackers), they can make the device do what they want.

So, how do you protect against this? Until the automation device makers come up with better security – you want to keep these devices in an “inner sanctum”, protected from the rest of your network. Use a firewall with very specific rulesets – based on IP address or use sneakernet to transfer data from the systems on USB/hard drive. At the same time, ask your vendors for timelines on when they expect to have security built into their systems. You may not be able to replace all of your systems, but you can not buy from vendors who don’t take security seriously when you need new/replacement systems.

Around this time of year, many people receive new devices and gadgets as gifts, and some of those gadgets turn out to be smart phones. But smart phone security is very tricky to pin down, as there are multiple vendors and platforms to take into consideration, not to mention the speed at which smart phone technology is evolving. So when I came across this Top 10 iPhone Security Tips whitepaper (pdf), I knew that it was probably a good thing that it attempts to target a specific platform. However, after reading through it, I think that many of the things McAfee points out can also apply to a Droid or BlackBerry. And so, by stripping away the platform-specific details, we arrive at a pretty decent list of things a new smart phone owner can do to achieve some basic smartphone security:

• Enable passcode/lock

Mobile phones have had passcode capabilities for a long time. Make sure you’re using it, since a passcode lock is often the first line of defense.

• Erase all data before a return, repair, or resale

If you will no longer be the owner in possession of the device, it’s best to erase everything you can first. Everything. If you can do a factory reset, do so, because your phone constantly records information and there is always some data that isn’t easily found, let alone purged.

• Regularly update firmware

I’m guilty of not doing this– sometimes the update notification will sit around for a week before I finally give it permission to run. But this is one of the easier things to do, since it’s mostly automatic.

• Don’t run shady apps

Just like with a personal computer, if you run unknown or untrusted applications, you substantially increase your chances of getting got. So if you don’t want to get got, be prudent about what apps you run on your device.

• Take advantage of the web browser’s security

For smartphones with native web browser apps, be sure to use the security features to clear caches and stored passwords when it’s necessary. Just because a web browser is on a mobile device doesn’t mean it’s a security lightweight. Check out the “settings” or “options” to see just how much your mobile phone web browser can do to help you out.

• If you’re not using it, disable it

I’m also guilty of leaving stuff running unnecessarily. Be careful about leaving debug mode enabled, Bluetooth and wifi on, etc. Generally speaking, the more doors you leave unlocked, the lighter you sleep at night. Turning off unused services when they aren’t needed is a good habit to form, even outside the realm of security.

• Secure that email

In addition to providing native web browser apps, many smartphones also come bundled with a native email app. Check the settings for these apps to take advantage of any security features they’re offering (such as SSL/TLS).

• Use a phone tracker

The GPS can be bad for privacy if you are reckless with it. However, it can also be a powerful tool to help you recover a lost/stolen device. I believe the iPhone 4 has a built in device-finding service (complete with a remote wipe). But even if you have a different smartphone, there is almost certainly an app that provides some remote tracking for lost devices (i.e. Where’s My Droid app for Android).

This certainly isn’t a comprehensive list, but it should be enough to get both new and old smartphone users thinking about general mobile device security in a healthy way.

I’m not too ashamed of myself to whore out a few select email addresses for personal gain, or even promote a certain company by liking or retweeting something if it will benefit me more than the actions required, but I always keep a hesitant nature towards most of these promotions. I mean who doesn’t like free money?

I received an email the other day supposedly sponsored by a reputable programmer-related site. What it entailed was signing up for a big vendor’s developer program. If I did so, they would send me a $15 gift certificate to one of the major online retailers. I’m trying to keep all parties in this matter anonymous simply because I do not want to promote anything involved in this so-called promotion, and the actual parties involved are irrelevant. The email went something like this:

 

Happy Holidays Developers!

Get a $15 [online retailer] Gift Certificate by joining the [vendor] Developer Program (no charge!)

Thanks to your [programmer site] participation, here’s all you have to do!

1. Visit The [hyperlink to vendor site] and register at no cost!

2. [vendor] will send you a validation email: confirm your registration following the URL provided in the email which will prompt you to choose a password

3. Once you have chosen a password, [vendor] will then send you a password reset email: forward the password reset email and the sign up email address used to [promotional site email]

4. Once verified on our end, a gift certificate will be sent to you promptly after the program ends!

Hurry! This is limited to the first 600 respondents, one per person.

For full terms and conditions please visit [marketing link to promotional site]

Step 3 is the one that caught my eye here. You want me to forward you an email sent to me that allows me to reset my password? By doing this I would essentially be sending the promoter an email that contained a link with an embedded token allowing them to authenticate as myself and then change my password, essentially gaining access to my account at this vendor site. Mind you, this isn’t exactly a critical account. But still these are very poor security practices.

So, what’s to be learned from this? Pay attention to what’s being asked of you. If it seems slightly out of the ordinary, it probably is. Inboxes are being filled with more and more spam these days, some make it through, and some even seem legitimate. It’s up to the users to educate themselves on how to detect and avoid these types of situations. In closing, I’ll leave you with a list of things you can do to help protect yourself.

• If it seems too good to be true, it probably is. So use common sense people!
• Do not click on links in emails – period! Just because it says it’s a link to SiteA doesn’t mean it’s actually going there.
• Enable spam controls on your email client – if you’re using Outlook, Thunderbird, or even Gmail’s web interface – they are all pretty good at detecting what may or may not be spam.
• Use multiple emails or use gmail’s ‘+’ email features or mailnull to help sort out those mailing list emails and let you know which emails are being distributed to others.
• Do not load images by default or at all.
• Do not enable scripting at all!

These are just the tip of the iceberg, but you get the idea. Help protect yourself and you’ll be helping to protect all of us.

I’ve mentioned Whole Disk Encryption in the past. There are a number of products, both free and paid, which will allow you to encrypt your entire hard disk, or the hard disks on your servers.

In a recent study whole disk encryption (referred to as FDE in the study) has been shown to significantly hamper investigation. Basically, the encryption is too good. Even with techniques like cryogenic RAM freezing it’s often unlikely that the encryption can be bypassed.

But there’s a huge, gaping hole in such protection: you can’t USE encrypted data. For it to be accessible and usable, it has to be decrypted. (In other news, it is not possible to open properly locked doors, nor to pass through walls.)

And for the last few years, there has been a product out there which makes it possible to remove a computer without powering it down. This product is called HotPlug and it can be used, in conjunction with a portable power source, to remove a machine without disrupting its functioning. Be sure to watch the video.

Of course, lawful search and seizures aren’t the problem per se. But this does show that WDE isn’t a panacea. As with any security, it needs to be backed up by other defenses as well. Physical control trumps software security anyway. Which means, unremarkably, that even the newest technology doesn’t necessarily provide more security than a good padlock.

One of the biggest complaints I’ve had with VMWare vSphere and VMWare ESX/ESXi over the last few years is that managing my virtual machines from my Mac computer was a hassle. The VMWare management utilities are all Windows-only, and even the few web-based tools either do not work or are extremely limited from a Mac. While it isn’t perfect yet, VMWare vSphere 5 has made it so you can actually do just about anything you need to using a Macintosh computer; you just need to go through a few hurdles.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

I am currently experimenting with my smartphone, to see if its Mobile Access Point Functionality allows it to function as a wireless router independent of Internet connection. In theory, it should – it is capable of providing internet access to four attached devices, and that suggests that it should have router functionality, meaning that the attached devices should be able to talk with each other, rather than simply to the Internet. In practice, I know that sometimes seemingly important parts of networking implementations are, well, not implemented. The most egregious example, in my experience, was a commercial-grade firewall which was unable to pass UDP traffic under certain circumstances.

The lesson I learned then was that just because the hardware and software claim to be able to perform a function, it isn’t enough to assume that they actually work. Never assume – always test. Sometimes ports will be blocked; traffic won’t be passed, or there will be an absurd traffic shaping scheme that makes your particular application untenable. Sometimes these problems are resolvable, and sometimes they aren’t. This can be terribly vexing when trying to, for example, set up a VoIP connection.

But from a security standpoint, sometimes the reverse is even worse. What if the connection works, but the security doesn’t? This isn’t hypothetical. There have already been many cases of firewalls which implemented an IPv6 stack but didn’t apply the firewall rules to that stack – or expected a separate set of rules which had never been set up. And, of course, there’s always the risk of a lazy predecessor who, in the rush to Make Things Work set allow *.* in the rules – would you notice? After all, nothing would stop working. Well, until your systems got infected.

Fortunately, there’s a host of tools to save you from this problem. Your first is simple Defense In Depth – relying not just on one company-wide firewall but also on an IDS, software firewalls, and anti-malware software, so one foolish implementation doesn’t leave you wide open. Second, there are scanning and simulation tools – mostly port mapping, but a few others besides – which will tell you what ports are open and what services are actually available. And if that’s not enough, a proper 3rd-party penetration test will probably find anything. But your best line of defense is in your own head – knowing how your network setup should work, being able to read the configurations you have, and knowing if the actual results match up.

There’s a new GPGMail app – installed with GPGTools – that works on Lion: http://www.gpgtools.org/installer/index.html
Unless you’ve got S/MIME set up. If you do have S/MIME set up, the bundle won’t display the settings, nor will it “work”. You’ll have a GPGMail preferences pane in Mail.app, but the only options you get are enabling OpenPGP under Composing and Reading. You’re supposed to have the choice of keys, etc.

The previous GPGMail (a *long* time ago), allowed both S/MIME and OpenPGP, so this is a bit disappointing. Their bug tracker has that functionality scheduled for (possibly) version 2.1, and I’ll be trying it again at that point.

There are definitely challenges to having S/MIME and OpenPGP running the same mail client. If you (accidentally) try to do both at the same time, you get garbage that most mail clients can’t understand – because each mail client/plugin applies the encryption in a different order, and the recipient’s mail client would have to know that order. Now, if a person only has a PGP key or only has an S/MIME certificate, then it’s not that difficult – the mail client should select the appropriate encryption.

It is very nice to see that GPGMail is being developed actively again.

I recently acquired a new iMac at work to replace the 4yr old one I was using. The new iMac came with Lion on it, and since I had upgraded to Lion on my work machine, I went ahead and upgraded all of my home machines as well. My Macbook Air is my primary “workstation away from work”, and keeps client data. Because it does, I use FileVault on it. Under Snow Leopard, that only encrypted my home directory. Under Lion, FileVault now encrypts the entire drive, not just $HOME. However, if you upgrade, you have to explicitly convert your machine to use the new FileVault. And you need a lot of disk space to do it…

I have a 250 GB SSD drive – not exactly the biggest drive – and I have 11GB of that left. I wasn’t able to upgrade my machine to the new FileVault – until I moved the majority of my data to another computer and practically wiped my drive. I’m sure I’m not the only one in this situation – and generally, backups are not encrypted – Time Machine under Snow Leopard wasn’t, and most other backup options for home use are not either. So you have sensitive data backed up off an encrypted drive, just to “upgrade” to a different disk encryption technology. If I hadn’t upgraded, it wouldn’t have been a problem. If I was content to just leave $HOME encrypted, it wouldn’t have been a problem. But I wanted “bleeding edge”. Luckily, I have an iMac at work to off-load all of the files to – encrypted with Lion’s FileVault from the start.