Alex Scoble's IT Notes - An Information Technology Blog

To run scheduled scans or not

Is it still necessary to do weekly scheduled antimalware scans these days in addition to real-time scans?

It just seems like more and more that antimalware software is used to meet compliance obligations and not as a real security layer. I say this because as we see in breach after breach reported in the news that antimalware software effectively offers little in the way of real protection against modern malware threats these days.

Some people might say that you leave an enterprise appreciably open to infection by not running scheduled scans along with real-time scans, but is this true? By some reports, antimalware software can only detect about 60-70% of all known infectuous software, regardless of scan type.

So the question is, if something is only 60-70% effective today against malware, how is performing a scheduled scan going to help you? Once a box is infected despite real-time scanning protections, the malware is very likely to hide itself from the antimalware or disable the antimalware software altogether.

In my mind, it just seems like best practice is to use either real-time scanning or scheduled scans, but not both. Use real-time scanning on systems where performance isn't a critical issue and use scheduled scans on systems that require every bit of computing power.

What do you think?

Forget about the bomb, the real danger is cyber warfare

One of the most dangerous things that our government is doing right now is the collection of unknown open computer vulnerabilities. Cyber weapons can be launched from anywhere in the world with very low cost, are difficult to determine who constructed or launched them and can do significant damage to our infrastructure.

When we opened the gates to their use as a weapon of war with STUXNET and Operation Olympic Games, we in effect sent all of our troops out to battle without leaving anyone to defend the homeland.

A much more effective strategy would have been to work with software developers to get those vulnerabilities closed and to make sure that our sensitive and critical computer systems were well defended against these types of attacks.

We denied Iran from getting the bomb for a while and instead gave them a brand new weapon that is far riskier to us because of the ease of which it can be used and the inability to attribute attacks to the real aggressors that launch them.

Patching is killing Windows (AKA the problem that Microsoft MUST solve in order to remain competitive)

I wrote a blog post back in 2005 on my Computerworld blog detailing 4 things that I thought that Microsoft needed to fix in Windows in order to remain competitive. Unfortunately, the biggest thing on that list, the land of a thousand reboots, hasn't gotten much better.

Right now, one of my main functions at my job is to manage patches for nearly a thousand Windows systems. "Pain in the ass" doesn't even begin to describe the difficulties of patching that many Windows servers and workstations.

First off, you can't do it without an enterprise tool like LANDesk, Secunia, GFI LANGuard, Microsoft SCCM, etc. These tools are big, complex, hard to manage and typically require agents which often have their own issues.

Second, the number of third party apps that you have to track and patch is significant and growing. Because of compliance requirements, some organizations have to assess every single "security patch" for applicability. To do this, you have to know every piece of software that you have installed in areas requiring compliance and you have to regularly search for security updates to all of those applications. Yes, it is as laborious and mind numbing as it sounds. I have a lot of fun at my job, but this area is totally not intellectually stimulating at all.

Third, because of the fact that Windows patches require a reboot, scheduling downtime of critical production systems can be a total nightmare.

I should mention right now that Linux does all of this far better. If you pick your tools right (limit the tools that can't be installed from a repository), you manage all of your patching from one place. Yum for RedHat/CentOS or Aptitude for Debian. If your server is headless (who needs a GUI that takes up all of those resources and adds another 200 packages that need to be updated), patching a brand new server up to current takes minutes and requires ZERO reboots. It's as easy as typing "yum update". Since it can be used to track what security patches are applicable for each system, there's no research that needs to be done on just about anything other than the stuff that you installed from source.

Linux is quite simply light years ahead of Windows in this area. It is probably the main reason that I'm getting into Linux so much of late.

It sometimes takes over an hour to install a service pack on a Windows server. I can build up a new Linux server and fully patch it in less time. In fact, I can build up a new server with the LAMP stack, install an app on top of that (for log management, for instance) AND fully patch it in less time.

It's no wonder that Microsoft's share of datacenter systems has remained weak and will continue to slide. This situation is unacceptable. Even with clustering, which is expensive, hard to maintain and requires a lot more hardware, Microsoft can't maintain the kind of uptime that Linux is able to. Because guess what, patching invariably BREAKS your cluster.

On Windows 7, it can take over an hour to fully patch a new laptop or workstation and thats with SP1 already installed.

Even a shark with a congested nose can smell the blood in the water.

Linux administrators are able to perform patch management on their systems without buying expensive tools, without wasting a lot of time performing CVE and NVD searches for their apps, with a minimal amount of downtime and with significantly lower risk to their systems. Not to mention that it's much easier to deal with patching of systems isolated from the internet because you can build your own repositories.

Microsoft will continue to bleed marketshare and loyal customers like me until they solve this problem.

It will likely take a complete rewrite of Windows to do it, but given that the survival of the company depends on it, at least in my opinion, it would be stupid of them not to do it and soon.

I won't hold my breath though.

A good starting point for researching Security Information and Event Management (SIEM) tools/services

Recently, I've been doing research on tools for log management and SIEM (Security Information and Event Management). As anyone who's ever been part of selecting an enterprise can testify, it's quite the daunting task.

Enterprise tools are BIG, as in they have a footprint larger than a brontasaurus, typically require a lot of work to get them set up to where they are useful and usable and they aren't any good unless someone (sometimes a small team is required) is managing them on a daily basis. Figuring out which tool best meets your needs is just as large of an endeavour.

Sometimes it can be hard to figure out just where to start, so you do some Google searches trying to find what SIEM tools are on the market, and maybe you do some searches for open source products that are up to the task and if you are lucky, you'll hit on one of Dr. Anton Chuvakin's blog posts on the subject.

He is definitely an expert in the field and currently works at Gartner doing analysis for them on the subject.

You'll also notice, if you pay close attention, that he's got a great sense of humor (and apparently likes Cognac).

Some notable blog posts of his that I think are required reading to anyone who is looking to purchase a SIEM tool are:

Top 10 criteria for a SIEM? - He goes against his better instincts and writes an informative blog post on excellent criteria, in my opinion, for beginning your assessments of the various SIEM tools

On choosing a SIEM - Here he provides some questions that a security analyst, business exec or IT manager should ask before they even begin looking for a SIEM...the questions are quite insightful and get to the heart of the matter of "do we really need this functionality?" and, more importantly, "do we have the resources to support it and make it successful?"

The myth of SIEM as "analyst in a box" - A good blog post in his series on how not to choose a SIEM. Basically, it boils down to if you don't have a security analyst or analysis team on staff already, you better get one before deploying a SIEM or your effort will be a complete failure.

Happy reading!

Linux would not have protected the Iranians against Stuxnet

Interesting discussion going on over at Google+ about the ramifications of Stuxnet and Flame. 

One part of the conversation is completely *facepalm*/smh (shaking my head) worthy, though. Someone brought up the extremely ludicrous notion that Linux would have protected the Iranians against Stuxnet and Flame. Linux totally would not have given the Iranians any extra protection.

The Stuxnet attacks are highly sophisticated and targeted and were able to get through every layer of the Iranian infrastructure to get embedded within the centrifuge controls. Flame, at least as far as I can tell, may have been used to provide the reconnaissance needed in order to build Stuxnet. It wouldn't have mattered what types of computers and OSes the Iranians used. The attackers would have just found vulnerabilities in any of them and developed exploits accordingly.

These hacks were very difficult to defend against and would have required a very thorough "defense in depth" strategy with a dedicated staff of security analysts to monitor and analyze network, OS and application logs and health. Even then, given the fact that spies were involved, It would have been an uphill battle to stop these attacks from succeeding.

There are certainly advantages that Linux gives to organizations within datacenters. Protecting them against highly advanced and targeted threats that exploit unknown weaknesses is not one of them, in my opinion.

Use LastPass tool to check if your LinkedIn password was compromised

I've recently become a big fan of LastPass as a "cloud based" password management tool and have been using it to secure my identities on various sites by randomizing the password and storing it within LastPass.

As you may or may not know, LinkedIn recently was the victim of a successful attack which resulted in the compromise in a significant number of accounts. My account was among them and I verified it using this tool that LastPass created.

It's good to know that companies like LastPass are doing valuable things within the consumer security space.

If you haven't changed your LinkedIn password within the last week, please use the tool to see if it was compromised, although you should change your password anyhow.

And if you aren't already a LastPass user, now would be a good time to start. For just $12 a year, you can have it manage your passwords, store them in encrypted and hashed form on their infrastructure and sync up the password vault to your PC, Mac, iPad, iPhone, Android phone, etc. I highly recommend using this or similar services to manage your passwords. Your identity should be protected and you can't do it by using a weakly generated password that you use for multiple sites. Have LastPass generate a strong password (at least 20 characters, 32 where possible) for your sites and manage the passwords for you.

You'll be glad you did.

Configuring iptables to log network traffic

For security as well as debugging purposes, it's a good idea to log the inbound, outbound, invalid and dropped packets that flow through the network interfaces on your linux systems. This is part one of a series with the rest, such as how to configure rsyslog.conf, to come later.

I was having problems getting iptables to log packets like I wanted, so I did some research on Google and found this post by Toast Research that detailed a good method for building your iptables modularly to allow for logging of packets.

Then I modified what they had done and came up with my own file and here it is. It is set up to allow port 80 through as well as ICMP pings, SSH connections, syslog messages and traffic from your Puppet server.

Just do 'nano /etc/sysconfig/iptables' when logged in as root (using 'sudo su -' of course) to modify your file to do what you want it to do.

The three digit numbers are there to allow for automated building of iptables files using DevOps systems like Puppet or Chef. The benefit to that is that you'd manage the iptables file at the enterprise level and these systems keep an audit trail of changes made and also ensure that systems stay properly configured. If someone were to change an iptables file managed by one of the DevOps systems, the DevOps system will revert to the proper file. That's the power of DevOps.

As you can see, the file is broken up into modules with the header defining what those modules are and the various rules either accept, log, drop or send packets further on down the chain.

# 001
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:invaliddrop - [0:0]
:loginaccept - [0:0]
:logoutaccept - [0:0]
:logdrop - [0:0]

# 002
# Accept all loopback connections
-A INPUT -i lo -j ACCEPT

# 003
# Forward all invalid packets to invaliddrop
-A INPUT -m state --state INVALID -j invaliddrop

# 004
# Forward all established connections to loginaccept
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j loginaccept

# 005
# Forward all icmp packets to loginaccept-A INPUT -p icmp -j loginaccept

# 006
# Forward these allowed input rules to loginaccept
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j loginaccept
-I INPUT -p tcp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p udp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p tcp --dport 8140 -s <your puppet server here> -j loginaccept
-I INPUT -p tcp --dport 61613 -s <your puppet server here> -j loginaccept

# 007
# Accept these rules without logging or forwarding them to loginaccept for logging
-I INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 80 -j loginaccept

# 008
# Cleanup rule
-A INPUT -j logdrop

# 009
# Allow outbound loopback traffic
-A OUTPUT -o lo -j ACCEPT

# 010
# Forward all outbound traffic to logoutaccept
-A OUTPUT -j logoutaccept

# 011
# Drop all invalid packets (invaliddrop chain)
-A invaliddrop -j LOG --log-level 4 --log-prefix "IPTablesInvDrop: "
-A invaliddrop -j DROP

# 012
# Log accepted incoming packets at a rate of 2 per minute (loginaccept chain)
-A loginaccept -m limit --limit 2/min -j LOG --log-level 4 --log-prefix "IPTablesInAccept: "
-A loginaccept -j ACCEPT

# 013
# Log accepted outgoing packets at a rate of 6 per hour(logoutaccept chain)
-A logoutaccept -m limit --limit 6/hour -j LOG --log-level 4 --log-prefix "IPTABLESOutAccept: "
-A logoutaccept -j ACCEPT

# 014
# Drop all blocked packets (logdrop chain)
-A logdrop -j LOG --log-level 4 --log-prefix "IPTABLESDropped: "
-A logdrop -j DROP
COMMIT

Customize as needed.

Thoughts on Stuxnet and Operation Olympic Games

The New York Times ran a story yesterday about how President Obama ordered further attacks on Iran's uranium processing infrastructure using the Stuxnet virus. The attacks were part of Operation Olympic Games which was started under the previous George W Bush administration.

These attacks have serious ramifications for world politics in general and for the computer security community. The following are my thoughts on what some of those effects might be.

1. This story officially tells the world that the US has an extremely sophisticated cyber attack capability. The number of exploits and the complexity of the chain they created had not been seen before in the wild. This sets a precedent akin to us dropping the first atomic bomb on Hiroshima. No, not in the scope of the damage done, but in the level of seriousness of the attack. This is likely to set off a new "arms race" between countries and other organizations to create even more advanced cyber attacks.
2. Our government is playing a very dangerous game by performing these attacks. They have given other would be cyber warriors, rogue states, terrorists, etc. a blueprint on how to circumvent all but the most robust defenses (and even then, it would be difficult to defend against something like this). The attack used cannot currently be defended against by most corporations, networks and infrastructure in the US. If someone wanted to do harm to the US and thought that physical damage was the only way to do it, they know now that a similar level of damage can be done using computers. How long will it be before we see a serious terrorist/rogue state cyber attack against vital infrastructure or economic centers?
3. It takes a bite out of the use of Stuxnet by security professionals as an example of what organizations in the US have to defend against because no other cyber attack organization has demonstrated this level of sophistication, however, now that the blueprint is out there, it's only a question of time before others start duplicating what Stuxnet did and raising the bar of what is possible.
4. The deployment of Stuxnet which uses so many vulnerabilities that were previously unknown and thus not patched shows that there are some in the US government who think it's more important to keep dangerous vulnerabilities available to them in the wild versus helping to close these gaps for everyone. This should make security researchers very nervous and anger security professionals.
5. One "good" thing about this attack is that shows everyone involved with cyber security or system administation that we have a long way to go to build more secure systems and that we can't afford to wait on efforts to improve security of our vital infrastructure. The cost to improve might be high, but the costs of not doing so are much higher.
6. I question the wisdom of the New York Times in doing the research and publishing any of this information. In many ways, shedding light on this operation does grave harm to our national interests and greatly increases the risks to US citizens. This operation was obviously highly classified and should have stayed a secret for many years to come. Although it does occur to me that this probably could not have been leaked without some help from the Obama administration. Which raises further questions about why they would jeopardize public safety by releasing the information necessary to write this story.

We certainly live in "interesting" times. I just hope that this doesn't cause an outbreak of cyber war that would be catastrophic to people all over the world.

Ever wanted to know how secure a Linux password file, with hashed passwords using SHA-512 and salt, is? I think this is a good answer: http://security.stackexchange.com/questions/4687/are-salted-sha-256-512-hashes-still-safe-if-the-hashes-and-their-salts-are-expos Pretty damn secure.

Problems sending OSSEC logs to rsyslog

Pulling OSSEC logs into syslog is really a mess. It doesn't format stuff at all how a syslog client would.

For instance, it buries the agent name in the message text instead of reporting it as the system name, which instead gets reported as the OSSEC server name that got the logs in the first place.

Plus it ranks everything as MEDIUM in syslog terms regardless of how they are ranked within the OSSEC logs.

So a priority 1 (very low) OSSEC event gets prioritized the same as a priority 10 (high) event.

This is all making me think that syslog just isn't all that great for use with log analysis tools in a heterogeneous environment.

Although it does seem possible to get rsyslog to change the way it handles certain kinds of logs...I'll have to do some digging to see if I can find instructions for doing this with OSSEC.

**Update: My friend Mike recommends http://www.ossec.net/doc/syntax/head_ossec_config.syslog_output.html?highlight=syslog#syslog_output for a possible solution.