Immutable Security

Here’s a little secret that the sales guys of the million-dollar SIEMs are probably going to gloss over. Most of them do not offer a way to encrypt logs in transit end-to-end. Worse, many of them use downright silly methods to collect logs on common operating systems, such as installing an FTP client on every host and sending them along as a big batch every so often.

For some reason, this is seen as acceptable since it’s usually on the internal network. At the same time, we give mean looks to anyone who even mentions the use of a clear-text protocol like telnet.

Here’s another little secret: many of the big SIEM vendors use syslog-ng as the log daemon on their appliances. It’s reliable and secure and generally works very well.

What if there was a way to add encrypted log transit to the expensive SIEM, or to the other log management solution you already have in place? What if you can’t use or don’t need the full functionality of a log analysis solution like OSSEC, but would like the ability to use encrypted log transport? Read on, my friend, because I’m going to show you exactly how to do that, and it can be done in just a few minutes.

1. Install OSSEC in server mode on the existing syslog server from the vendor. I won’t go into detail here on how to install OSSEC, as it’s well documented elsewhere. These systems are generally just minimal Linux installations, so if you are lacking a compiler then you may need to install it on a like system and move OSSEC over. If your vendor won’t let you do this, ask them why you are paying them gobs of money without even the basic functionality of encrypted log transit!
2. Install OSSEC agents on the hosts you want to collect logs from. Configure the agents to collect the logs you are interested in and add them to the manager. Don’t forget to restart the OSSEC manager after adding the agents.
3. Add the following lines to /opt/syslog-ng/etc/syslog-ng.conf under the “source s_local” section:
   # Read OSSEC queue
   unix-dgram(”/var/ossec/queue/ossec/queue”);
4. Edit /var/ossec/etc/ossec-control and modify the two variables which are responsible for starting the OSSEC daemons. After modification, they should look like this:
   DAEMONS=”ossec-remoted”
   SDAEMONS=”ossec-remoted”
5. Finally, stop both syslog-ng and OSSEC. Start syslog-ng first, then start OSSEC.

The reason this works is due to the way OSSEC is designed. In fine Unix tradition, OSSEC separates the tasks into individual daemons that do only one job and do it well. In this case, ossec-remoted is writing to a Unix socket that syslog-ng is reading from in real-time. OSSEC is simply handing off the message to the local syslog daemon, at which point the message continues on its way as it normally would.

I used to use Snare, Zebedee and OSSEC for secure log delivery and file integrity. Now, it can all be handled with one open-source agent, already designed for secure and reliable log delivery.

There is a downside, which is primarily due to me not taking this to the next level and looking into the issue. In this configuration, you will not receive a notification if the OSSEC agent disconnects, since there is nothing to act on the absence of the heartbeat OSSEC sends. I’m pretty sure that can be solved by taking it up a notch and including one or two more daemons, combined with a stripped down decoder and rules file.

So the next time your expensive SIEM vendor tells you there’s no way to encrypt the logs in transit, tell them you can set it up in under an hour. Then send them a bill for your time.

PhysOrg.com and many others are reporting a new attack against WPA encryption, which is used in wireless networks. While WEP encryption has been proven to be all but worthless, attacks against WPA have mostly been limited to acedemic and brute-force attacks.

The two Japanese scientists apparently have found a method to crack WPA when combined with the TKIP algorithm, however the attack does not apply to WPA2, a more recent version of the standard, when combined with AES.

This might be a good time to verify the settings on your home wireless network. If the option to use AES and WPA2 is present, it makes sense to use it. But I wouldn’t rush home in a panic.

While you’re in there, make sure your admin interface requires a strong passphrase and your WPA2 keys are equally protected. At least for the keys, use a strong, randomly generated password since you generally only have to key them in once per device. Here’s an online generator you can use from grc.com.

For some time now I have had problems with Yahoo! accepting mail from the domains I manage and marking the messages as spam. They continued to blackhole me depite having never been an open relay, having a valid PTR record, having a valid SPF record, not sending any spam or mailing list e-mail, sending to and from only a few select people and having nothing in the message body that could possibly be considered spammy. Only Yahoo! has problems with the server. Everyone else seems to think I’m an OK guy.

Several attempts to resolve the situation fell on deaf ears.  Several times I dutifully filled out the forms and provided all the details requested. I even requested to not receive a scripted response, hoping a human being worked somewhere at Yahoo!. The experience led me to conclude one of two things: either they really don’t care at all about letting you know how your mail server offends them or the place is so (in)efficient that the machines have risen and killed off all the humans, only to run Yahoo! all by themselves.

It seems that I have now appeased the Yahoo! mail gods. Yesterday, I implemeted Domain Keys using the excellent guide over at Brandon Checketts’ site.  Yahoo! now considers me worthy of sending mail to their underlings. I can only hope that I continue to please the Yahoo! gods, for they are all powerful.

VoIP, or Voice Over IP is quickly usurping traditional phone lines. It’s not hard to understand why. VoIP service allows you to do things previously impossible with traditional phone service. You can use physical phones or an application on your computer. You can setup internal company PBX systems previously only available to those with lots of money. You can even use VoIP to answer your front door.

The insecurities of VoIP are being discussed, but few are listening. We already know that VoIP is insecure in many ways. But I have not heard much discussion about the practical implications of VoIP insecurity. The discussion is still a bit too academic.

Let me give you an example. Most providers that I know of do not support transmission over TLS/SSL. The practical implication of this is that whatever you discuss is being transmitted over the Internet in the clear. It is fundamentally no different than putting the same info in an e-mail.

If you have VoIP service or are considering it, consider whether you would be confortable transcribing what you are about to say and sending it in clear-text e-mail. If your conversation contains SSNs, credit card numbers, passwords or your strange affliction for <insert subject of fantasy here>, you may want to reconsider discussing it in a VoIP call.