J Wolfgang Goerlich's thoughts on Information Security
Browsing in public with PuTTY 0.61, Firefox 5.0, and Amazon EC2

By wolfgang. 13 July 2011 14:45

PuTTY 0.61 released today with a handful of performance enhancements for OpenSSH. This makes the following trick even more attractive, as can it effectively double the performance in some cases.

What trick? Create an encrypted tunnel for browsing the Internet in public. Otherwise people who are sharing that cafe Wi-Fi can see your traffic. Depending on where you are going, these people can even see your usernames and passwords. You start out drinking a latte and end up with some random posts on your Twitter feed and your email box sending out spam. Not good. Not good at all.

To prevent this, setup a remote computer that you can connect to when you are on the go. Then when you find yourself relying on free Wi-Fi -- like at a hotel, at a airport, or where ever -- you can connect back to this safe computer. All your traffic in public is secured between your notebook and that remote computer. Just for fun, I like to use the cloud (e.g., Amazon EC2) for my remote end.

At a high-level, the procedure is:

1) Sign up for Amazon Web Services and provision a free server instance
2) Download and configure PuTTY 0.61 to proxy SOCKS over SSH
3) Download and configure Mozilla Firefox 5.0 to use the SOCKS proxy for Web traffic (HTTP, HTTPS, DNS, and IRC chat)

Instructions with screenshots are available on my Papers page.

Tags:

Encryption | Security

Dropbox - risks and remediation

By wolfgang. 24 April 2011 08:08

Dropbox is a cloud service that presents storage as a local computer drive. Michael Galligan introduced me to the service about a year ago, when he redid the SimWitty branding. You install the Dropbox app, the folder appears, you copy files to the folder, and they synchronize with anyone else who has access to your Dropbox folders.

There are some real risks with transferring files using someone else’s system, of course. There is the chance of local attacks on your Dropbox (see: Dropbox authentication: insecure by design). More likely, there is a chance of a security incident at Dropbox’s systems, thus allowing a malicious insider or attacker to gain access to the documents. A big collection of documents presents an attractive target.

What to do? Dropbox released some guidance this week. Using the tried-and-true Truecrypt software, you can encrypt your Dropbox folder. This restricts access to only those who have access to your decryption key. It is a good option for those who want the ease of the cloud with some assurances as to the safety of the data.

Tags:

Encryption | Security | Storage

Cord Blood Registry breach - encryption controls and media controls

By wolfgang. 11 March 2011 17:45

Backup Files Put Database Information At Risk
Cord Blood Registry breach a cautionary tale in the need for encryption, key management, and secure physical transport of database back-up media.

Kelly explains that step No. 1 to keep this database information secure is implementing strong encryption practices and key management. J. Wolfgang Goerlich, a network security manager at a financial services firm, concurs. He says the risk of misplaced backup information is at the top of his list of worries.

"Encryption is the No. 1 control to prevent scenarios such as the Cord Blood Registry breach. Encryption does require time for configuration and ongoing maintenance, but it has a very low fixed cost," Goerlich says. "In the Cord Blood Registry scenario, three areas that should have been encrypted: the laptop hard drive, the database backup file, and the LTO4 backup tapes. If encrypted, the stolen media would be all but useless. The personal information of 300,000 people would be unreadable and unrecognizable."

He also believes organizations need to do a better job instituting tape media procedural controls as well. "These ensure that the storage tapes are transported in a manner that is physically secure. From the initial reports, it looks like Cord Blood Registry did not have these in place," he says. "A solid procedure would prevent transporting sensitive backup tapes using an employee's vehicle and prevent leaving those tapes unattended in a parking lot."

Tags:

Encryption | Operations Security | Physical Security | Security

Miss the basics, miss the boat - Core Blood Registry

By wolfgang. 4 March 2011 19:30

"The Cord Blood Registry earlier this week began notifying some 300,000 registrants that their personal data might be at risk. (...) a report on the Office of Inadequate Security website indicates that the breach was the result of the theft of data backup tapes from an employee's car."

http://mobile.darkreading.com/9288/show/5e4cf4d9fde37597b6410715a1daba64&t=adff34649992599d6213734b9fd03797

The breach is a good reminder of the basics. If it moves, encrypt it. If it rests, encrypt it. If you are moving tapes, have basic media controls in place to keep unsecured tapes from sitting in someone's car. Miss the basics, miss the boat.

Tags:

Encryption | Physical Security | Security | Storage

Microsoft embraces and extends IPSec NULL

By wolfgang. 8 January 2010 06:53

IPsec provides authentication, integrity, and confidentiality. In IPv4, IPsec generates an AH (Authentication Header) that provides packet header integrity using a cryptographic hash. ESP (Encapsulating Security Payload) provides integrity using a hash and confidentiality using encryption. Both AH and ESP provide authentication thru key exchange (IKE).

The hashing is typically done with MD5 or SHA and the encrypting is done with 3DES or AES. As known attacks exist for MD5 and 3DES that renders them only slightly better than nothing. SHA-1 and SHA-2 are in a similar state. NIST is currently working on SHA-3. For now, the best is SHA-2 with a long key length and AES.

Interestingly, ESP can also be encrypted using NULL. (See RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec). "NULL does nothing to alter plaintext data.  In fact, NULL, by itself, does nothing.  NULL provides the means for ESP to provide authentication and integrity without confidentiality." Put differently, ESP performs the key exchange and hashing only.

Microsoft's version of IPsec NULL does not quite conform to the RFC. Rather than using a hashing algorithm in conjunction with a NULL encryption, Windows 7 and Windows 2008 skips it altogether. According to Microsoft's IPsec setup guide, the NULL encapsulation "option specifies that no integrity protection is provided to each network packet in the connection. No AH or ESP header is used to encapsulate the data." Embraced? Yes. Extended? Not so much.

Tags:

Cryptography | Encryption | Systems Engineering

Load balance SSH without "Potential Security Breach" or "Someone Is Doing Something Nasty"

By wolfgang. 29 June 2005 07:30

You setup a couple servers with SSH and load balance these. Then, Linux users start reporting they are seeing "It is possible that someone is doing something nasty!" Windows users say that PuTTY is complaining "Warning - potential security breach!" Why?

SSH uses a RSA private/public key pair. The public key is saved on the client as the SSH server fingerprint. Linux users can find these keys under ~/.ssh/known_hosts and ~/.ssh/known_hosts2. Windows users can find the keys in the registry under [HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHo stKeys]. The errors occur when two (or more) SSH servers use the same FQDN but use different private keys.

This is the same thing we see when we load balance Web servers. The workaround there is to export the private/public certificate from one computer, and apply it to all computers in the load balanced set. The clients then receive the same certificate regardless of which computer they connect their Web browser to.

The same workaround applies to load balanced SSH servers. Take the certificate from one, and apply it to all other SSH servers in the set.The files are /etc/ssh/ssh_host_rsa_key (private) and /etc/ssh/ssh_host_rsa_key.pub (public). You may also want to copy /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_dsa_key.pub if you are supporting DSA encrypted sessions.

A word of caution in regards to the security and validity of the private keys. We had the same discussion with Web servers. The idea behind private/public encryption is that one (and only one) entity has the private keys. This guarantees to the end-user the identification of the remote end-point. Copying the keys reduces that guarantee. Given it is one entity (your organization) that controls the keys, and given you are applying them only to a single DNS hostname backed by a single load balanced set, you should rest easy. Just take care not to copy the SSH keys to anything other than these servers.


OpenSSH client (4.1) error message:


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@        WARNING: HOST IDENTIFICATION HAS CHANGED!        @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this message.
Offending key in /home/me/.ssh/known_hosts:xx
RSA host key for hostname has changed and you have requested strict checking.
Host key verification failed.




PuTTY (0.54) error message:


WARNING - POTENTIAL SECURITY BREACH!

The server's host key does not match the one PuTTY has
cached in the registry. This means that either the
server administrator has changed the host key, or you
have actually connected to another computer pretending
to be the server.
The new key fingerprint is:
ssh-rsa 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
If you were expecting this change and trust the new key,
hit Yes to update PuTTY's cache and continue connecting.
If you want to carry on connecting but without updating
the cache, hit No.
If you want to abandon the connection completely, hit
Cancel. Hitting Cancel is the ONLY guaranteed safe
choice.

Tags:

Encryption | Security | Systems Engineering | Troubleshooting

Encrypting private circuits (VPN over Frame Relay and MPLS)

By wolfgang. 8 May 2004 06:55

This is a summary of a debate I recently had with a network engineer. The question is whether or not to run a VPN over a private circuit.

Let’s start with a quick definition of terms.

Private circuits are provided by the telcos to sites that companies own. So say you have a site in Detroit and Chicago. Way back when, the way to connect the two was to run a dedicated line. A dedicated line provides dedicated bandwidth and constant latency at a price. This was rather expensive. For redundancy, you purchased separate lines.

Frame Relay was the telcos solution. You can think of Frame Relay as a virtual dedicated line. The connection relays network frames (layer 2 or data link) over several physical networks to create a logical end-to-end line. The Detroit-Chicago traffic crosses any number of devices and circuits, but the link is presented to your layer 2 switches like a dedicated line. This cuts down the cost. The trade-off is varying bandwidth and latency because Frame Relay is a shared resource. Like dedicated lines, you needed to purchase separate circuits for redundancy.

MPLS (Multi-Protocol Label Switching) aims to provide performance of dedicated circuits at the cost of frame relay. MPLS adds traffic management and in-network redundancy. Detroit-Chicago over MPLS is still a shared resource, but now the link can more effectively shape the traffic and utilize the networks of circuits. Redundancy is baked into the circuit.

In terms of cost, it goes redundant dedicated lines, redundant Frame Relay, and MPLS. All three are rather expensive. Meantime, the Internet reliability has increased and cost has decreased. Strictly from a costing perspective, you might build the Detroit-Chicago link with a VPN (Virtual Private Network) over the Internet. Like MPLS and Frame Relay, VPN is a logical end-to-end line that builds on top of a physical network.

Now to dive into the confusion.

Telcos sell dedicated lines as private circuits. Telcos sell Frame Relay and MPLS as virtual private circuits. The argument you will hear is that security is built-in because these are private circuits. There is also the operations efficiency of not having to deal with routing infrastructure and possibly even IP infrastructure. (Novell administrators love Frame Relay as they can run IPX/SPX over it.) A private circuit is private, right? Not exactly.

First, all the telco equipment between Detroit and Chicago have visibility into the IP traffic. A truism of network security is that a network is only as secure as the people who have access to the equipment. In this case, that could be any number of telco support technicians. They can read your packets.

Second, the privacy of the private circuit depends upon the correct configuration of the equipment. Your packets and some other organization’s packets are streaming down over the same routers. The only difference is the tags in the packets and the how the routers treat those tagged packets. When improperly configured, the circuit fails open. I have seen situations where new IP subnets suddenly appear on the LAN switch, and are traced back to a misconfigured frame relay. Whose packets were they? Did the owner of those packets know he was broadcasting onto our network? Probably not.

My recommendation.

Treat dedicated lines, Frame Relay, and MPLS circuits the same as you would untrusted Internet circuits. Encrypt all internal traffic that travels over these circuits.

Virtual private circuits are not the same as Virtual Private Networks. One is clear text and the other is encrypted. The first ensures availability and integrity. The second ensures confidentiality. For best results, run a VPN over a virtual private circuit.

What about bandwidth and latency? With decent gear, the bump in thru put should be no more than 10%. Look for routers or firewalls that advertise encryption and line speed.

What about packet shaping? Use the QoS preclassify features of your gear. This reads the DSCP/TOS from the unencrypted packets, and writes it to the encrypted packets. The MPLS gear can then handle the encrypted packets properly.

What about complexity and cost? The trade-off is security for operational complexity. You may need to purchase more gear. You will need to implement IP routing. These add to the overall cost of the solution. Given the increases in security of encryption over clear text, the trade-off is worth it.

Tags:

Architecture | Encryption | Security

    Log in