Blog
Archived Posts from this Category
Archived Posts from this Category
Posted by VulcanRidr on 14 Nov 2008 | Tagged as: Blog
Episode 2 is recorded and I am in process of editing. It is probably going to be something around an hour, with 17 pages of show notes. I will be working on it this weekend and hopefully get it out the first part of next week.
Posted by VulcanRidr on 05 Nov 2008 | Tagged as: Blog, Site News
I am in Chicago for the last of my SAP training. I finally got to meet (and had dinner with) Mr. and Mrs. Verbal. They were a great couple…And apparently Mrs. Verbal thinks Verbal and I were twins separated at birth… A big thanks to the Verbals for taking the time to have dinner with me. It was a highlight of the visit to Chicago.
Episode 2 will be released next week. The review (and rewrite) of the information took longer than anticipated because of travel (Lisbon and Chicago this time) and illness.
Posted by VulcanRidr on 30 Sep 2008 | Tagged as: Blog, Linux
VMware has finally released version 2.0.0 of their free server product. Since I am running a total of four VMware servers (one for testing on my laptop, one semi-test on my workstation, which also stores my template images, and two “production” servers), I have been going through the Waltz of the Upgrade. I upgraded defiant, danube and prometheus, but decided that lexington, my backup- and sole remaining 1.0.x vmware server, needed a little extra love. I set this box up almost 3 years ago, before disk encryption was available easily in Linux. I went back and encrypted /var/lib/backuppc directory, so the backups were encrypted, but never got around to encrypting the rest of the system.
Since I am working on getting Reasonably Secure Builds together and will be walking through a Debian build with an encrypted filesystem, and since I needed to upgrade vmware, I decided to do the full upgrade on lexington and get it up to scratch. I actually used the latest Lenny daily build of the Netinst CD, and it was nice. It is basically the same as I have always done, except for the fact that they have replaced the lilo command line prompt on the burst page with a dialog-like menu to give you your options.
I really want to get it running again, so that I can play with Untangle. It looks like a very cool product, and lexington has enough filesystem space for me to evaluate it.
More on my progress with Untangle. In fact, if things work out with it, expect an AP episode on it, somewhere in the firewalling eposodes.
Posted by VulcanRidr on 23 Sep 2008 | Tagged as: Blog
A new project is taking shape, an aggregator for Linux podcasts. Currently there are two sections…One for blog posts and one for podcasts. Check them out at
http://www.linuxplanet.org/casts/
Posted by VulcanRidr on 23 Sep 2008 | Tagged as: Blog, Show Notes
Recently, the Debian project announced the existence of a couple of major vulnerabilities, specifically, DSA-1571 and DSA-1576, which were on openssl and openssh, respectively. These were for a predictable pseudo-random number generator within openssl. The random number generator, due to a patch that was put in place in Sept 2006, severely limited the randomness of the numbers generated. Instead of billions or trillions of combinations, there are thousands. This means an attacker is able to brute force keys in only a few hours instead of thousands or tens of thousands of years. Applications which depend on these random numbers for communication security, including openssl, openssh and openvpn, need to be upgraded . Keys generated with the suspect random number generator must be regenerated. I also want to note that this applies to all Debian-based distros, including Ubuntu/Kubuntu/Xubuntu, Linux Mint, any deb-based installation.
As root, or through sudo:
apt-get update && apt-get upgrade (or dist-upgrade)
This will upgrade openssh and openssl. If the ssh host keys are found to be vulnerable, they are automatically regenerated and the old keys are archived as /etc/ssh/ssh_host_rsa_key.broken and /etc/ssh/ssh_host_dsa_key.broken<c/ode>.
The upgrade also installs three new tools called <code>openssh-blacklist, openssl-blacklist and openvpn-blacklist. These packages contain lists of partial key fingerprints, enough to verify the vulnerability of a key. They will block vulnerable or compromised keys from connecting.
As root or sudo,
ssh-vulnkey -a
This will give you an initial list of vulnerable ssh keys on your system, including ssh keys, known_hosts and authorized_keys. Key fingerprints are compared to /etc/ssh/blacklist.DSA_1024 and /etc/ssh/blacklist.RSA_2048. Note that if you generated non-standard keys, for instance, at an unusual bit size, the keys could still be vulnerable but not be in these lists. In addition, according to an article in the yobi wiki, any DSA key which was exposed to a compromised machine should be considered compromised. My personal recommendation is to regenerate any key which was generated between September 2006 and May 2008,
ssh-vulnkey -a will list all keys on your system, with a status of Not blacklisted, Unknown or COMPRPMISED. I used ssh-vulnkey as a reference to list the keys which I needed to regenerate, and started by regenerating all of my personal keys on all of the machines on the network that were generated during the time window in question. This includes unattended accounts, such as my account for backuppc and my network monitoring system.
Compromised host keys can be in a user’s .ssh/known_hosts, so issue a
find / -name known_hosts
Examine each file for the compromised key. Since I was doing a clean sweep, I simply deleted the entire known_hosts file. It will be repopulated when a logging into a new host. To do this, issue
find / -name known_hosts | xargs rm
Use the same procedure for authorized_keys. When you push your keys to the server, this file will again be created and/or populated.
Continue to run ssh-vulnkey -a until all keys are clean. Repeat the process on each host. To regenerate a user key, issue
ssh-keygen -t dsa
or
ssh-keygen -t rsa
and follow the prompts. Choose a good passphrase for your key. Pauldotcom had a great discussion of good passwords/passphrases on episode 106, if memory serves (the discussion is not listed in their show notes, so you’ll just have to go listen).
Other good passphrase resources include
queen.clara.net unix-ag.uni-kl.de
To regenerate host keys, move the old host keys to another filename or delete them, then run
dpkg-reconfigure openssh-server
The tool for this application is called openssl-blacklist. There is no -a option, so you need to find the ssl certs on your system. Ssl certs are similar to ssh keys, in that they have two parts. In the case of ssl, you have a certificate file (which is generally a .pem or a .crt) and a .key file. Obviously, if you called it something else, you are probably savvy enough to know what it is called. The openssl-vulnkey tool works against the key file, rather than the certificate itself. You should search your system for key files, which is usually called something.key. You should usually be able to find a something.pem or something.crt nearby. A couple of good places to look are in /etc/ssl/private for the key, with the certificate in /etc/ssl/certs, if you run openvpn, /etc/openvpn. Also check beneath /var/www if you run a web server with https. This tool does not have a -a feature, so you must run it against individual keys. However it does accept multiple keys. Run openssl-vulnkey /etc/ssl/private/*.key, the output should be similar to ssh-vulnkey.
OpenVPN works with either ssl certificates or with shared keys. The ssl certificates are handled by openssl-blacklist, while openvpn-blacklist handles shared keys generated by openvpn. Normally, these are used for tls-auth files or if you are using shared-key authentication for your vpn. Keys generated by openvpn look similar to
# # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- b54ea37f29de1988937868e3cdbf7ded 2e720ed9531f68df3fe03f21a4087c0d 74c132f5fb47c3852b3f3d4b29ebe3af cc009cc78af265664f4ec04adc514ad8 58e0e5f9667da0d453f8c8440027bcae c704444177a8de47819063c957f7ac35 3463c2d61deb9406799d0fad448f8941 d484fa04b37d6be97e33acd3d1b8260c 836bdc3bba7814e693b8ee886fab4e2f 3501f1482d1c8d2710e3186f8155d434 95301361b8bf68c4d2c1f15f0eadd526 86cfbcf1659ab9bb0b4decc46c24b471 7164a2824aaa4aef56734c5086f5f571 b0ed86119b14c78a1fc7e38eb3dfab4d 924ae1213179d2401b36604907c005fc 9eb5f0a0f0b4c16833f14f0ebc5240eb -----END OpenVPN Static key V1-----
in the first line. The process for running the tool is the same as openssl-blacklist. Once you have checked all applicable keys, your systems should be in far better shape.
Why is this a critical vulnerability? Because with the ease of brute forcing the keyspace, not only can an attacker eavesdrop on supposedly secure communications, but they can also decrypt any sessions which they may have recorded through, say, tcpdump or wireshark.
Posted by VulcanRidr on 26 Jun 2008 | Tagged as: Blog, Site News
I know, I owe apologies. I tried to re-record the segment while in Geneva, but little did I know that the hotel was downtown, where the Euro Football 2008 fans were driving around honking horns when their teams won, as well as being two blocks from Hopitaux Universitaires de Geneve (Geneva University Hospital). For as calm as the Swiss are, there are ambulances running all the time.
I got back on the 14th, and was fighting jetlag the entire week. Last weekend, the kids came over to celebrate my birthday, and this week have been in SAP training. So I will get that segment re-recorded as soon as possible, and get it out.
Posted by VulcanRidr on 02 Jun 2008 | Tagged as: Blog, Site News
A long time in coming, however, I have all my content collected and most of it recorded. I had a bout of jetlag last week, having jumped forward in time by 6 hours. I recorded last week, but part of the content was irrecoverable. I will re-record tomorrow night after changing hotels. I thank my loyal fans for hanging in there.
Posted by VulcanRidr on 19 May 2008 | Tagged as: Blog, Site News
I spent most of the weekend getting my keys regenerated. On the downside, it took most of the weekend, but on the plus side, tons of content for the podcast. I took the tinfoil had approach.
In essence, any keys or certs that were either compromised or unknown status and were created between Sep 2006 and May 2008 were deleted and recreated. In the immortal words of Ripley in Aliens, “I say we take off and nuke the entire site from orbit. It’s the only way to be sure.”
I will give a step-by-step of the process that I used to update in episode 1, which should be out this week.
Posted by VulcanRidr on 12 May 2008 | Tagged as: Blog, Site News
Episode 1 is in production. I apologize for the delays, but in addition to the new job, computer upgrades, and what not, I just spent 18 hours vacuuming the water out of my basement from the series of storms.
In any case, I will make a real effort to release the episode this week.
Posted by VulcanRidr on 23 Apr 2008 | Tagged as: Blog, Site News
For all that are wondering, I am in pre-production on episode 1. I will hopefully be able to sit down and do some recording this week. Its been very busy on the new job, plus I need to put the upgraded recording machine through her paces. I will hopefully be able to get two episodes cranked out before I have to leave for Geneva.
Entries and comments feeds.
Valid XHTML and CSS. ^Top^
30 queries. 2.434 seconds.
Powered by WordPress with jd-nebula theme design by John Doe.
This site is not associated with Armored Penguin Consulting. Their site can be found here.