Tracy's blog

Federal Linux Security Resources/checklists

Tracy R Reed — Fri, 02 Mar 2012 15:35:00 -0800

I often say that most successful attacks and vulnerabilities are failures of imagination (when they aren't outright laziness/penny pinching). The authors of these documents have seen a lot of attacks and know something about how things should be configured to give your servers a fighting chance. These guides and checklists are great to look over for inspiration and ideas on how to better lock down your systems. Look over each item and think to yourself: "What on earth happened such that they had to put this on a security checklist?"

http://www.nsa.gov/ia/_files/os/redhat/rhel5-pamphlet-i731.pdf

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf (not Federal but good to review all the same)

http://benchmarks.cisecurity.org/tools2/linux/CIS_RHEL_5.0-5.1_Benchmark_v1.1.2.pdf (also not Fed but good)

http://web.nvd.nist.gov/view/ncp/repository

Use something like puppet to automate implementation of this stuff network-wide. That last NIST link even has an awesome puppet config for all of this! I've been reading through the code for the puppet modules and learned some neat things, including stuff I had no clue about previously such as how augeas works and what it is good for.

NIST, HIPPA, PCI, CIS, NSA, IQOQ, another day another security audit and industry-specific acronym!

Verisign intrusion

Tracy R Reed — Thu, 02 Feb 2012 14:24:46 -0800

Verisign has had some sort of intrusion, apparently: Key Internet operator VeriSign hit by hackers

Note that the Verisign CA business was sold to Symantec a couple of years ago (about when the attack happened) but it still operates under the Verisign brand. So who knows if the compromise is related to the CA in any way. You can bet Symantec is upset with Verisign over this because now their purchase of Verisign's CA business may have just lost value due to the branding. What if it was the CA network that was compromised and then sold to Symantec? That would really lead to some legal fireworks!

So far we have DigiNotar, Comodo, Realtek, JMicron on the list of compromised certificate authorities and each of them has been used to create bogus certificates. Hundreds of fraudulent yet CA-signed certificates happily accepted by browsers have been found in the wild impersonating websites/intercepting traffic and nobody knows how many more exist. Iran was successfully using bogus certificates signed for Google.com to intercept gmail and google chat traffic which has likely lead to deaths, given the nature of that regime and their attitude towards dissenters: http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html

The web browser you are using trusts hundreds of different certificate authorities (any one of which could generate a certificate to impersonate any website they want or be compromise and used to do so) including CNNIC from China. I don't trust CNNIC any further than I could throw Mao Tse Tung's corpulent carcass.

Verisign is a big company which provides many services and no doubt extensively subnets and divides up their networks as required by PCI among many other security standards. One would hope, for example, that the corporate office network (a very common way to infiltrate a network) is in no way connected to the DNS or CA infrastructure (now with Symantec but there could still be links) so that an intrusion in one of these areas would not affect the rest. I find these two paragraphs the most disturbing:

  The VeriSign attacks were revealed in a quarterly U.S. Securities and Exchange
  Commission filing in October that followed new guidelines on reporting
  security breaches to investors. It was the most striking disclosure to emerge
  in a review by Reuters of more than 2,000 documents mentioning breach risks
  since the SEC guidance was published.
  ...
  Ken Silva, who was VeriSign's chief technology officer for three years until
  November 2010, said he had not learned of the intrusion until contacted by
  Reuters. Given the time elapsed since the attack and the vague language in
  the SEC filing, he said VeriSign "probably can't draw an accurate assessment"
  of the damage.

The attacks were revealed only to the degree legally required by the SEC and buried in a quarterly 10-Q filing in the hope everyone would overlook it. The CTO wasn't informed (or isn't admitting to having been informed) and the whole thing was brushed under the rug for two years. That's way sleazy.

What does it mean for us? Probably not much, at least at first. If people understood how the CA system worked Verisign's brand would be affected and people would put less trust in their certificates and be less likely to input their credit card number. While it is the part of the system most people focus on, we don't pay a CA to encrypt our traffic. We can do that without them. We pay them to certify that our server is who it says it is. If the media were to run with the idea that the CA system is broken and untrustworthy (which it is) and that man-in-the-middle attacks are rampant (they happen but aren't common, relatively speaking) it could really hurt the e-commerce industry in general which would be bad for us.

PA-23 Piper Aztec checkout

Tracy R Reed — Sat, 27 Aug 2011 12:55:00 -0700

You can check it out here.

Comments on "Views regarding PCI compliance are mostly positive"

Tracy R Reed — Wed, 12 Jan 2011 18:00:42 -0800

A few comments and observations regarding Views regarding PCI compliance are mostly positive

Most IT security practitioners believe...

Sure, they are the ones for whom work is being generated by PCI! :) A survey of business owners/CEOs would be much more interesting.

A majority of survey respondents were "very confident" they could
pass an assessment today.

Hmm....these respondents need to read the Verizon 2010 Payment Card Industry Compliance Report: http://www.verizonbusiness.com/go/pcireport where 78% were non-compliant at IROC. My experience also is that organizations are not nearly as compliant as they think they are. They tend to make assumptions without actually reading the requirements.

The card brand, however, reports only "moderate" compliance for smaller retailers.

I bet that is putting it mildly!

"The people and education is a big issue that maybe is more
challenging to address than just putting a technology in place,” Kost
said.

Definitely! We were just discussing this very issue on here...attitudes are hard to change.

Needing to upgrade antiquated systems to bring them into
compliance is the second greatest pain point...

Ditto again. I have a client running Fedora Core 3 systems (not necessarily in the CDE) with so much stuff all on one system (against best practice and a violation of PCI if in scope) that it has been nearly two years and we still have not been able to move/upgrade it!

Dan Langin, a Kansas lawyer who advises clients on PCI
compliance, told SCMagazineUS.com on Wednesday that organizations
commonly have challenges with the step that requires they maintain a
policy that addresses information security.

I'll have to remember that name. Never before ran into a lawyer who specializes in PCI.

This requirement is somewhat objective and it can be difficult to
determine whether the organization is actually in compliance, he
said.

And I think he means subjective, not objective... And this is the point where one of my clients is currently stuck. They have most of the technical requirements met but need to do some documentation and education of policies.

The cost to achieve PCI compliance is often tied to an
organization's size, with larger companies spending more than their
smaller counterparts, Kost said. Sixty-two percent of all respondents
said they have spent at least $100,000 on compliance over the past
five years.

It is also tied to "technical debt". If you have a very messy environment with interdependencies all over the place running on systems which have been EOL for ages it is going to cost a whole lot more. Such is the case with the Fedora Core 3 client above.

Most organizations plan to increase PCI compliance spending in
2011, with some organizations planning to invest in technologies that
allow them to comply in virtualized environments, according to the
survey.

What sort of technologies would they need to allow themt o comply in virtualized environments? The virtualization container is to be secured to at least that of the highest level virtual machine running in it.

Meanwhile, 60 percent of respondents said they are using another
emerging technology – point-to-point encryption (P2PE), sometimes
referred to as end-to-end encryption

I would hardly call P2PE an merging technology. VPN, SSL, etc. which we have had for many years now are P2PE. I think the innovation here is in having it built into a PED.

SIP brute force attacks

Tracy R Reed — Sun, 26 Dec 2010 23:36:06 -0800

If you run a VOIP system accessible to the Internet you need to keep up on your system security. Over the last year I have seen an ever increasing amount of brute force attacks on SIP servers. Many systems have poorly chosen passwords which are being discovered via brute force guessing. The bad guys then route international phone calls to their phone company or calling card service through your phone system leaving you stuck with a huge bill. I personally knew someone who ended up with a $100k+ phone bill on his DS-3 line. VOIP providers are now making people sign contracts accepting all responsibility for charges incurred if the customer's VOIP system is breached.

Checking my own system logs I see 137,507 failed SIP REGISTER attempts over just the last 4 days.

In addition to choosing strong passwords (and why not, it isn't like human beings are going to be using these passwords, you program them into the phone) the only real solution (more of a band-aid, but a really good one) is to use a package like fail2ban (in the rpmforge repository if you use CentOS/Fedora as well as the standard apt-get repo for Debian/Ubuntu) to block too many failed register attempts in a row or to use a set of iptables rules like the following which I cooked up a long time ago and have used to remediate DOS attacks on HTTP, ssh brute forcing, and now SIP brute forcing. This does not detect failed registers but merely checks how many times a remote host sends a UDP packet to 5060 per amount of time. You may have to play with these numbers depending on how chatty your phones are. And be sure to whitelist generously. The chances of you whitelisting someone who will attack you are very small. The chances of locking out a legit client are decent. If someone can't register and you can't see their register attempts on the console check your packet filter. But it is worth it. Also keep an eye on your logs using some sort of log monitoring software (I wrote my own, used to have a website for it but not anymore, need to get it back up there) so you can know about failed/blocked registrations.

# Deal with SIP brute forcing
iptables -N SIP_WHITELIST
# home
iptables -A SIP_WHITELIST -s 1.2.3.0/24 -m recent --remove --name SIP -j ACCEPT
# voip provider
iptables -A SIP_WHITELIST -s 4.5.6.0/24 -m recent --remove --name SIP -j ACCEPT
# remote location
iptables -A SIP_WHITELIST -s 7.8.9.0/24 -m recent --remove --name SIP -j ACCEPT

iptables -N SIP_BRUTEFORCE
iptables -A SIP_BRUTEFORCE -m recent --set --name SIP
iptables -A SIP_BRUTEFORCE -p udp --dport 5060 -m state --state NEW -j SIP_WHITELIST
iptables -A SIP_BRUTEFORCE -m recent --update --seconds 30 --hitcount 3 --name SIP -j LOG
iptables -A SIP_BRUTEFORCE -m recent --update --seconds 30 --hitcount 3 --name SIP -j DROP

iptables -A INPUT -p udp --dport 5060 -m state --state NEW -j SIP_BRUTEFORCE

You cannot rely on antivirus

Tracy R Reed — Fri, 19 Nov 2010 14:29:20 -0800

As the number of viruses/malware to scan for and parts of the system to monitor for infection increases more resources will be required. I bet we already spend the equivalent of one whole CPU of ten years ago just scanning for malware on the typical modern computer. In the last couple of years there has been talk of the end of antivirus as we know it:

http://www.google.com/search?q=the+end+of+antivirus

This is because the increase in resources required to secure the computer cannot continue forever.

What's worse is that antivirus only detects known viruses. There are an increasing number of unknown viruses out there and antivirus vendors are falling further behind. There has always been a large lag between initial release and detection by antivirus software. The virus has to be released, discovered, reverse engineered, signature created, added to antivirus software signature database, then the user has to update. This all takes plenty of time.

There is an increasing number of unknown viruses out there that do not get caught until after they have already caused damage. Google had no clue they were infiltrated until the bad guys tipped their hands by getting caught logging into other people's webmail accounts which prompted investigation. At that point the malware they had been sent was undetected. There have been serious consequences, likely including prison time if not worse, for certain human rights activists in China whose gmail accounts were compromised.

Stuxnet was discovered in June 2010. The widely accepted theory is that it was designed to sabotage the Iranian centrifuges and has probably been successful. According to:

http://www.fas.org/blog/ssp/wp-content/uploads/NumberCentrifuges1.jpg

we see the number of centrifuges online decreasing between May and August of 2009.

On July 17, 2009 WikiLeaks posted a notice saying:

Two weeks ago, a source associated with Iran’s nuclear program
confidentially told WikiLeaks of a serious, recent, nuclear accident at
Natanz. Natanz is the primary location of Iran’s nuclear enrichment
program. WikiLeaks had reason to believe the source was credible however
contact with this source was lost. WikiLeaks would not normally mention
such an incident without additional confirmation, however according to
Iranian media and the BBC, today the head of Iran’s Atomic Energy
Organization, Gholam Reza Aghazadeh, has resigned under mysterious
circumstances. According to these reports, the resignation was tendered
around 20 days ago."

A centrifuge full of uranium hexaflouride turning at 15k RPM failing and spewing its contents widely throughout the facility due to someone messing with the speed controls via the computer which controls the PLCs is indeed a serious nuclear accident which could end the career of whoever is in charge.

All of this implies that it was more than 10 months that Stuxnet was out there completely undetected by antivirus.

What malware is on the computer you read this on that you won't know about for 10 months?

Windows market share

Tracy R Reed — Sun, 10 Oct 2010 20:40:21 -0700

http://www.zdnet.co.uk/blogs/the-open-source-revolution-10014902/microsofts-dwindling-market-share-10020700/

It is debateable whether Linux is increasing in desktop market share or not although it is killing (in the form of Android, for whatever that's worth) in the mobile phone business. I think Linux probably is increasing in desktop market share or perhaps number of installations if not increasing as a percentage because I have come across more and more people in the last few years who are using it. I recently saw someone post on Facebook (who I have not influenced) that they haven't had any computer virus problems since they have been using Linux.

I have been reading this blog of the HeliOS Project for a long time:

http://linuxlock.blogspot.com/

Thanks to Ken Starks there are thousands of Linux computers out there in Texas homes (now doing 300-400 per year and doing it since 2002) helping less fortunate kids get an education. Not only has he endured technical and political challenges but note where he mentions he took a stabbing in the course of trying to deliver a computer to some kids. That's dedication!

And obviously Mac has gained market share in recent years which is surely where most of the Windows share is going.

As markets mature they have historically had a tendency to standardize on open standards and I think we are finally beginning to see that in the computer business. Decades ago the hardware and software were both completely proprietary. Then the hardware became somewhat standard with the introduction of the PC as a platform as IBM hardware went by the wayside. Then networks were standardized on ethernet and TCP/IP and the various proprietary networking protocols and hardware went away. And now we see the beginning of serious change affecting the average user in the software side of things. It's a good day.

Aeronautical charts

Tracy R Reed — Thu, 23 Sep 2010 13:10:00 -0700

The special aeronautical charts (aka maps) used by pilots have expiration dates. Dates vary between every 56 days to every two years depending on the chart. Mountains don't generally change much but antenna towers, roads, and sometimes even airports and towns do. Sometimes the radio frequencies for control towers change or airspace boundaries move. So the charts get updated.

When my charts expire I have to buy new ones. That means at least every couple of months I am having to buy something new. Most pilots just throw away the old charts. But they are so densely packed with cool information that I hate to just throw them in the trash. I recently noticed that I had a stack of expired charts about a foot high and wondered what I should do with them.

When I was a little kid I liked playing with Flight Simulator on the computer. Someone gave me a copy of an aeronautical chart to use with the flight simulator software and as a Junior High School kid I was making simulated cross country flights. By the time I started training to be a "real" pilot I already knew most of what I needed to read a chart and navigate. I think it would be cool to help out some other kids with their interest in aviation (sort of like paying back the good karma that came to me when I was a kid). So I bundled up the charts into useful sets (typically a Los Angeles sectional, Los Angeles Terminal, San Diego Terminal, IFR enroute covering SoCal, and book of instrument approach procedures covering SoCal per set). Then I placed an ad in the Free section of the San Diego Craig's List. I really don't know many kids who play with the flight sims anymore and it isn't generally considered nearly as cool as it once was to be a pilot so I wasn't sure if anyone would be interested.

Over the next few hours my inbox was full of people willing to drive across town to pick up a set. Mostly for their own kids, as well as a couple inactive pilots looking for study materials to get back into it, and one youth pastor looking for something cool to put up on the walls of his classroom.

All of the chart sets are now spoken for and given away. Hopefully there will be a lot of happy kids out there this evening.

PHP

Tracy R Reed — Sat, 22 May 2010 04:25:00 -0700

It has been a while since I did any language trolling so let's talk about a religious issue: PHP. You either love it or you hate it. I have been looking at PHP frameworks lately. Not that I want to but in this particular case there isn't much choice. I am constantly reminded of all of the reasons why I played with PHP for 6 months then moved away from it so many years ago and have since watched the train wreck from a safe distance.

PHP has no language design philosophy.

With Ruby/Java/Python (almost) everything is an object. Perl has its "There's more than one way to do it" swiss army chainsaw. Python has "There's one obviously right way to do it" and zen of python in the "import this" easter egg. Lisp/Haskell/Erlang all have their (purely)functional related philosophies. PHP? Nada.

Not a general purpose language.

Really only meant for webpages. Not a general programming language. While technically you can run php from the command line and automate system tasks with it few people actually use it that way with shell, perl, python preferred instead. I have never downloaded a command line app to find that it is written in PHP. Being able to use the same language for web programming and, say, system automation is a handy way to amortize that learning curve over a number of projects.

Code embedded in HTML is bad

Originally started out as a way to embed basic site counters and such in HTML. It took years but a few people eventually figured out templates were the way to go and started heading towards MVC with templates etc. But far too many people still write PHP intertwined with HTML making a real mess.

Breaks with Apache WebDAV

I set a developer up with WebDAV access to a PHP project so he could edit code, upload files, etc. The very things that WebDAV was designed to do. But whenever he would open up a .php file the editor would come up empty. It turns out that Apache was trying to EXECUTE the PHP file instead of just serving it up for the developer to edit. I found a few references to how to disable the PHP engine when a file is being served up via WebDAV but have so far been unsuccessful in implementing the suggested fix.

Terrible security history

Long a major complaint against PHP and very sensitive subject to PHP programmers. Before flaming me go patch your Wordpress instance. You know it needs it.

The infamous register globals functionality is where people always start when complaining about PHP security. It took years but most people have moved away from using them, especially after it was turned off by default in 4.2. But why did anyone ever think it was a good idea in the first place?

I saw quite a few php apps get owned by the xml-rpc flaw in the 2005-2007 timeframe.

In 2007 it was discovered that you could insert PHP code into a gif name it image.gif.php and get it executed on many sites. Oops. Another instance where parsing your code out of content being served up (instead of separate of logic and presentation via templates) was a big mistake.

I am yet to see anyone religiously use prepared (aka parameterized) statements in PHP to prevent SQL injection which consistently leads to total box ownage. The attackers are generally far more creative than the programmers/admins and find ingenious yet obvious in hindsight ways to pull this off. No, addslashes() is NOT sufficient. mysql_real_escape() is not sufficient either. Take a look at this blog entry from 2007 which sums up some of the more popular options: http://old.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/ Scroll down to where it mentions BIG5 and advanced injection techniques. It is a fact that there is no amount of clever escaping which will suffice. Parameterized queries are the ONLY solution to this problem. Parameterized queries simply makes it impossible to get user input code parsed as part of the SQL statement.

While you can code sql injections in almost any language that speaks SQL to an RDBMS many other languages/frameworks do it differently by default. PHP's default database interface seems to encourage SQL-injections. The magic quotes hack is just an ugly band-aid. Same for addslashes(). Compare that to Java where you have Command and Parameter objects or can abstract away the SQL generation with Hibernate. Or compare it to Python/Django which also has an ORM which uses parameterized queries. Or to Ruby with its Rails ORM and parameterized queries. Or Zope/Plone with its object database and the inherent impossibility of SQL injection no matter what the programmer does.

And who can forget all of the file inclusion vulnerabilities? Remote file inclusion even! There have even been instances of code injection into PHP regexes via null bytes.

PHP wildly mixes code with strings all over the place causing this mess.

PHPs promiscuous mixing executable code with web content causes trouble as well. 1% of sites accidentally reveal their db passwords: http://www.feross.org/cmsploit/

The latest trend is exploitation of memory corruption bugs in the PHP interpreter itself. You might think that because you are using an interpreted language you don't have to worry about pointer mishandling, buffer overflows, etc. But it just isn't so. And PHP has such issues. There are right now undisclosed remote exploits which have not been revealed to the public and have not been patched in the PHP interpreter. There will be a talk on this given at SyScan Singapore 2010.

And then there is the issue demonstrated by this video: http://www.youtube.com/watch?v=6W68u18Bh28&NR=1 PHP apps traditionally mix static content and PHP code in the same filespace. So if you can get your own PHP code uploaded you can get it executed and suddenly you are owned.

You can say that all of this security attention is due to simply being a very popular language for implementing webapps if you like (although popularity leading to exploits is one of my favorite myths to bust) but it doesn't change the fact that there are a lot of problems which either don't exist or are simply less likely to be exploited in other languages/frameworks.

Be sure to keep an eye on http://php-security.org at least to know what you are up against.

PHP is almost everyone's first web programming language

This may hurt the feelings of a lot of PHP programmers whose business cards say "Software Engineer" but it is an important part of the argument.

Far too many people pick up a PHP tutorial, start coding knowing nothing about software development best practices or security issues, and turn loose some code on the net. This has nothing to do with the language necessarily but a lot to do with the community surrounding it. They are typically either newbies or at the very least not nearly as wise as they think they are.

If PHP is the only web programming language you have much experience with you have a problem.

ReST? MVC? Unit tests? What are those? I know that there are a few PHP programmers out there who practice these things but I have never met one personally.

Too many people start with PHP but then never graduate to any of the other languages/frameworks.

The old "because it's the most popular" myth

Tracy R Reed — Fri, 02 Apr 2010 23:47:05 -0700

Linux is a very tempting target for spammers and botnet owners. And there are millions of Linux boxes out there by now. But so far the only way they are really being compromised is through PHP web apps and poorly chosen passwords. Linux machines are being constantly bombarded with ssh brute force attacks and funny url requests. And as I manage my ssh access well and don't run publically accessible PHP apps I don't have problems. Between the MySQL on Windows worm a few years ago:

http://dev.mysql.com/tech-resources/articles/security_alert.html

and the Linux on MIPS router exploit from last year:

http://blogs.zdnet.com/security/?p=2972

and the Apache on FreeBSD worm:

http://news.cnet.com/2100-1001-940585.html?tag=fd_top

and the recent Linux router based botnet:

http://www.computerworld.com/s/article/9159758/Chuck_Norris_botnet_karate_chops_routers_hard

they are clearly trying anything that is exploitable including the very obscure software platforms. I just don't buy the idea that they only go after Windows because it is the most common. That is just where the low hanging fruit is and has the most exploits.

Software design has got to have something to do with it and being forced to maintain decades of backwards compatibility and poor design decisions as part of holding onto their monopoly has got to complicate things for Microsoft.

I actually like reading about Linux based appliances with poor security defaults being attacked. It really shoots down the whole idea that only Windows is targeted and that this is because it is the most popular. Notice that the primary way in which Linux systems are being attacked is misconfiguration or poor choice of password. Both are easily remedied issues. Actual exploitable implementation flaws are more rare than in Windows and actual design flaws rarer still.

Flight to Catalina Island (KAVX)

Tracy R Reed — Fri, 26 Mar 2010 13:00:00 -0700

On March 21st, 2009 (Yes, I'm a little behind in my blog entries!) I flew my wife and three of her friends to Catalina Island in Plus One's Cessna 210 N210BX. Catalina Island is one of the "Channel Islands" about 30nm off the coast of Los Angeles. We departed from Montgomery Field (KMYF) in San Diego which is 76nm away from the island. This is usually about a 40 minute trip since I like to climb up high going out over the ocean. This is a fun place to fly to for various reasons. I have flown out there probably 20 times by now.

From a pilot's point of view the trip out over the ocean is something you don't get to do often unless you fly the international big iron. There's something cool about seeing only water in any direction. Aside from my many Catalina crossings, the only other time I have flown across a long stretch of open water is when I had to fly due west across the Sea of Cortez from Culiacan to La Paz. There was a tropical storm to the north of Culiacan on my way to San Diego from a friend's place south of Puerto Vallarta.

Originally constructed in the late 1930's, the Catalina airport itself is on top of a mountain. Each end of the runway is practically a sheer cliff. The runway has a hump in the middle so that when touching down (or departing) you can't see the other end. Rumour has it that pilots have been known to think the peak in the middle of the runway is actually the end of the runway and slam on the breaks or initiate a go-around. Since it is often impossible to tell if someone is departing the runway going the opposite direction it is very important to use the UNICOM (local airport radio communications frequency) to be aware of what is going on and announce your intentions. The field has no official tower or controller but there is a tower of sorts above the terminal building where you go to pay landing fees and book transportation down to the town. There is usually an employee in there monitoring the UNICOM who will announce winds and help out within their abilities. The winds around the island can be tricky as you can get up and down drafts right around the cliffs on each end of the runway.

And then there is the fact that the airport itself is at 1,600' MSL (Mean Sea Level) elevation. And that is what made this day's trip more interesting.

We got a rather late start due to the low marine layer clouds that often cover the coast. I am a current instrument rated pilot and our 210 is a capable airplane with IFR instrumentation and a Garmin 530 so normally a marine layer is no problem. But if the clouds start at 1,900' MSL as they did on this day and Catalina Airport is already all the way up at 1,600' MSL that means there is only 300' of clearance between the runway and the bottom of the clouds. That is not enough room to safely get there and maneuver to a landing.

The combination of warm landmass and/or a light breeze often produces a bubble of higher ceilings over the island. On this day I met a pilot who had flown at about 1000' MSL the whole way over all that ocean (from LA but I know people have done this from San Diego too) and then quickly climb as they approach the cliff-face at the end of runway 22 at Catalina entering that bubble of higher ceilings immediately over the island just barely clearing the cliff making it up to runway level and then plop it right down on the deck. But that's not for me. Nor do I recommend it for anyone else. If you have a problem at 1000' over the ocean you have little time and even fewer options. Not only does this risky maneuver likely violate VFR (Visual Flight Rules) cloud clearance requirements but it leaves too few options should anything not go exactly as planned. Any go-around is likely to involve going into IMC (Instrument Meteorological Conditions). I insist on a normal, stabilized approach to landing. Lack of pilots choosing to go around has cost the club some bent aircraft in recent years. It is never a good idea to do anything which would preclude the ability to go around. Recall that the number one cause of weather related general aviation accidents is VFR into IMC.

So we waited. Some of us more patiently than others. A pilot must resist get-there-itis, especially when it comes from passengers, even if that passenger is the pilot's wife. Eventually the weather reported that the ceiling was 500' above AVX which put it at 2100' above sea level. Departing Montgomery Field (KMYF) in San Diego with a VFR-on-top instrument clearance to OCN (Oceanside) VOR (Variable Omni-range, a navigation beacon on the ground) we climbed up through the clouds, canceled our IFR clearance upon reaching clear skies, and then on up to 8,500' for the cruise out there. I was hoping that things would begin to clear during the flight to the island. As the surface of the island warms it will often burn a hole through the marine layer and sometimes you will find the island sitting in the clear surrounded by clouds. I knew this was unlikely to happen on this day as the temperature was just too cool. But I had a plan B and plan C.

We agreed before take-off that when we got to Catalina Island if there was no way to get down in clear skies I would attempt the VOR instrument approach to landing. That was plan B. And if that didn't get us down into clear view of the airport we would execute the missed approach procedure, get back on top, and then we would fly about an hour to the east and spend the day in Palm Springs instead of Catalina. This was plan C.

I have always considered the VOR approach to Catalina Island to be a fairly useless approach and never expected it would really get anyone below a marine layer. The airport is at 1,600' MSL. With this instrument approach you can get down to 2,440' MSL over the airport. This means you need at least 840' between the clouds and the runway. The marine layer is usually lower than that. When we departed it was reported that there were 500' ceilings.

Having descended from cruise altitude down to around 4,500' and approaching where my calculations told me the island should be and seeing nothing but clouds I advised SoCal approach that I would need an IFR clearance for the VOR-A approach to Catalina while beginning to slow the airplane from cruise speed to approach speed. They cleared us for the approach and with the missed approach procedure in mind and ready to execute we passed over SXC VOR nearing 90kts and tear-dropped into the holding pattern for a turn for alignment with the approach and started a descent down to 2900' which plunged us down into the clouds. There are only 1.6 nautical miles between the FAF (Final Approach Fix) to the MAP (Missed Approach Point) with an MDA (Minimum Descent Altitude) of 2440'. If you have the airplane slowed down to 90knots for the approach you have one minute and four seconds to descend from 2900' to 2440' which means you have to descend at 431 feet per minute to reach the MDA on time. If you go faster you must descend faster and have a smaller margin for error.

Upon passing the SXC VOR (which marks the FAF) inbound we turned to heading 352 degrees while keeping one eye on the time (counting down 1m and 4s), one eye on DME (Distance Measuring Equipment, to tell us when we are 1.6nm from the Catalina VOR on a mountaintop nearby the airport as a cross-check to the time), one eye on the attitude indicator (to keep us right-side up inside the clouds), one eye on the airspeed indicator (trying to maintain 90knots to make all the math work out correctly) and one eye on the compass trying to maintain 352 degrees. You didn't know instrument pilots have 5 eyes? They do. And at least as many hands.

Just as we passed through 2500' MSL we could see the ground. A few seconds later we were at 2440 and the airport had come into view off to our right. Ideally we would have come out right above it. With only 1.6 miles you don't have much room to get lined up on your outbound radial or established on your compass heading and we actually ended up passing just slightly north of the VOR on our way inbound according to the GPS which I suspect is what did it. We made a right turn into the downwind leg of the pattern while simultaneously calling SoCal to cancel our IFR clearance since landing was assured, announced our presence to any other local traffic on the UNICOM frequency (no control tower at this airport), ran a GUMPS (pre-landing) check one last time (landing gear had already gone down at the FAF), made a couple more turns in the pattern and gently squeaked the wheels onto the pavement. Mission accomplished! Apparently, my wife had been doubting our ability to land when we arrived to find the island cloud covered. She excitedly pointed out the airport when it appeared and upon exiting the aircraft I was promptly declared her “hero”!

Unfortunately, it was now around noon. The airport would close at 5pm after which no more takeoffs would be allowed. While open to the public this is actually a privately owned airport and has somewhat restricted hours. We planned to go back that same day. After landing I paid the $25 landing fee and then bought the five of us $25 round-trip van tickets for a 30 minute van ride down the mountain to the coastal town of Avalon, the only town on the island.

We had three hours to look around. It's a small place and you can walk from one end of the main drag to the other in 15 minutes. But the ladies spent a lot of time in each little gift shop along the way. We walked around town and ate buffalo burgers and oysters at a local burger joint with some sort of tropical island theme whose name I don't recall. I've eaten at nearly every restaurant on the island it seems. Many pictures were taken. By the time we had lunch and made it from the docks on one end to the historic "Casino" (not a place of gambling, simply entertainment) on the other it was time to head home. As usual, we got a pretty good look at some buffalo along the winding road from the airport to town and on the way back up. The island was the greenest I have ever seen it due to the recent rains. I also saw a number of scorched tree trunks from the wildfires they have had there in the last couple years.

At 4pm we met the van for the ride back up the mountain to the airport. The van left a few minutes late and we stopped to look at some buffalo on the way up. So we had around 20 minutes to get off the ground. While the passengers made final bathroom breaks and got themselves situated in the plane I did the pre-flight. Then hop in for the start checklist, start, taxi, final takeoff checks, and we were off the ground with only a couple minutes to spare. It was tight but we made it.

After takeoff we were still underneath the marine layer although it was higher now than when we arrived. A few miles from AVX I called SoCal for an instrument clearance to Montgomery so we could get above the clouds for a safe open-water cruising altitude. This was quickly granted and up we went through the clouds. The rest of the the flight back to Montgomery was uneventful aside from nice scenery. The clouds had mostly cleared by the time we got back although I stayed on the IFR flight plan and flew the ILS (Instrument Landing System) into MYF for a smooth landing and happy conclusion to a successful day-trip to Catalina Island.

Change and HTML emails

Tracy R Reed — Tue, 09 Jun 2009 11:30:00 -0700

I write a lot of lengthy emails, reports, and other documents and all
too often forget to post them here for others to enjoy (or ignore or
despise, whatever). I know IT people who are staunchly against change,
usually old guys. Maybe they are jaded and burned too many times by
change or maybe they just don't want to learn something new and are troubled
by watching their skillset slowly become obsolete. And I also know guys
who are always chasing the latest and greatest but not really getting much
productivity out of it. I am always looking for that optimal middle-ground...

On Tue, Jun 09, 2009 at 01:29:56AM -0700, Raleigh spake thusly:
> In fact, I've always been curious why so many IT pros that I meet
> are anti-change when it comes to software. Aren't we supposed to be
> the technology evangelists within our respective organizations? It
> is the job of our users to be cryin' about change. Not us.

I run into this often. Some people accuse me of always chasing the
shiny and some people accuse me of being an old fart who won't
change. I'm against change simply for the sake of change. Have there
really been any major breakthroughs in UI research in the last 10
years? Not really. So why are the UIs in certain products changing so
much? For the same reason car bodies change every year: Marketing and
change for the sake of change. I'm not into that. It creates
difficulties in training, introduces new bugs, and doesn't really
benefit us, the end users.

Virtualization, on the other hand, is a huge breakthrough on the x86
platform (IBM big-iron has had it for decades) and that is change that
I can definitely get behind and advocate constantly.

> P.S. - speaking of change, when will the list software (whatever
> that is) that this list runs on be upgraded to allow rich text or
> HTML email. I'm subscribed to various lists (IT and non-IT related),
> and this one is the only one that is plain text only. It's 2009, for
> crying out loud. Time to get with the 21st century. Just a
> thought...

This is more change for the sake of change. Plaintext works great for
what this mailing list is intended for. There are many exploits and
browser compatibility issues (in all of HTML, CSS, and Javascript) and
I don't want random strangers mailing active content into my
mailbox. Phishing would be largely impossible if it weren't for HTML
email. I read email on an OS that is definitely not prone to these
problems and I *still* avoid non-plaintext emails. I also don't want
your emails with the kitty backgrounds and yellow on black text and
animated corporate logo gifs in signatures etc. You got something to
say? You can say it just fine in plaintext. Impress me with your
beautiful prose not your idea of beautiful (which I will probably
consider gaudy) artwork.

--
Tracy Reed
http://tracyreed.org

I'm on twitter

Tracy R Reed — Mon, 06 Apr 2009 21:30:00 -0700

By popular demand you can now all know what I'm having for lunch in real time. Isn't technology great?

http://twitter.com/tracyrreed

I was attacked by Spam from Outer Space

Tracy R Reed — Wed, 01 Apr 2009 10:15:00 -0700

So yesterday at around 3:30pm I got a strange email from LOLLERSKATES (system logfile analysis software which I wrote to warn of unusual activity). It said that Yahoo was blocking a whole ton of email from my server. Why would my server suddenly be sending thousands of emails to Yahoo? So I looked into it and the system was processing a massive amount of email. I instantly knew that my computer was being used to send spam.

How could this be? One of two things must have happened:

A web app was compromised - Unlikely, but possible. I don't run any PHP and I don't use anything which isn't very careful about avoiding shell/sql injection exploits etc. A lot of my stuff is protected by SE Linux which should prevent web apps from talking to the mail system but not everything.
Someone compromised a users password - This is possible. People do dumb things with their passwords all the time.

So I fire up tcpdump and see a lot of traffic coming in via an authenticated SMTP session. I check the mail logs and notice that a particular user is authenticating from an IP address behind an Internet satellite link provider ("Spaaaam frooooom spaaaaaaaaace!" Thank you, Muppet Show) which is very unusual. So a quick iptables firewall rule to block off that IP address and a password change for that user and the spam stops. Then I whip up a quick shell script to clear the mail queue of all of the pending spam. Everything is back to normal.

I instant message the user in question and let him know what happened. The conversation went like this:

(05:48:35 PM) Tracy: I had to lock your email account on my server
(05:48:43 PM) Tracy: Someone guessed or stole your password and was using my server to send spam
(05:49:46 PM) Tracy: If you use that password anywhere else you need to change it
(05:51:12 PM) User: Oh really. It was studball. Thanks
(05:51:23 PM) Tracy: hmm...I doubt they would have guessed that.
(05:51:34 PM) Tracy: So I bet your windows computer or somewhere else where you have typed
                     that password in was compromised.
(05:51:38 PM) Tracy: You need to check that out.
(05:52:27 PM) User: Did it just start happening today or yesterday?
(05:52:41 PM) Tracy: Just today at 1:30pm my time which is 4:30pm your time
(05:59:41 PM) User: I checked my email about that time too.
(06:02:57 PM) Tracy: What computer did you check it on?
(06:03:11 PM) Tracy: Did you type in your password on that computer at that time?
(06:04:22 PM) User: windows. Yes I did. And I also choose save password.
                    My computer was acting slow today also. So I think it may be a worm.
(06:06:54 PM) Tracy: Yep. I bet that's it.
(06:07:33 PM) Tracy: You need to unplug that thing from the network asap.
(06:07:38 PM) Tracy: Then wipe and reinstall the operating system.
(06:10:19 PM) User: I will have to do that tonight when I get home.

So once again Windows bites me and I don't even use it myself. My server may be on email blacklists as a spam sender now. Hopefully not since I caught it quickly.

The funny thing about this is that from the user's point of view I have not done him a favor. I have only caused him a problem. Everything worked fine and his world was happy until I contacted him. He was not really inconvenienced in any way that he noticed at the time. What does he care if his computer sent his password to someone else so that they can use it to send spam through someone else's server? And now he has to change his password (I already changed it once for him) and reinstall his computer (although I seriously doubt that will happen and the infection will persist). I am reminded of "Typhoid Mary". The cost of lax computer security is a complete externality for most people which usually costs the insecure person/system nothing noticeable. So goes computer security apathy.

Linux worm/virus on the loose!

Tracy R Reed — Thu, 26 Mar 2009 22:15:00 -0700

Psyb0t Attacks Linux Routers

Why am I saying "Yeay!" about a Linux worm? Read on...

I've been a Linux fan for 15 years. Linux has always had good security and it is constantly improving. Much better than certain OTHER operating systems. We have always been proud of the lack of virus/worm infections in Linux. But there were always those who said that this was only because Linux was so small that nobody bothered to target it.

This hasn't been true for a long time but now they definitely can't say that anymore. Linux is big enough to be worth targeting. Not only that but Linux is big enough that they are targeting the very small and specific niche of Linux running on MIPS cpu devices!

In order to get infected by something like this you really have to open yourself up and let it in. This has always been the case for many years now and nothing new: If you allow root logins from the net and your root password is "root" you are going to be owned. Contrast that with another OS which recently only required that a specially malformed PDF merely get downloaded onto your machine (not even viewed) to become infected. But now there are enough Linux users out there that enough of them set things up with an ssh or telnet running on the WAN interface with a default or very simple guessable password that they are being actively targeted. Linux has hit the big time and this sort of "exploit" is still the best the worm authors can do.

Yeay!