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?

How best to tell users that their systems are part of a botnet

This article is pretty interesting http://www.darkreading.com/insider-threat/167801100/security/attacks-breaches/240149075/how-best-to-break-the-news-to-users-that-they-re-a-bot.html Talks about the most effective methods ISPs used to notify customers that their computers were part of a botnet.

One takeaway is that both Windows AND Mac computers became part of the botnet, so that should dispel the myth that Macs do not get infected with malware.

Related articles

Microsoft and Symantec Take Down Bamital Botnet That Hijacks Online Searches

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.

A few months ago Microsoft released security patch MS12-034 Because of this patch and the way that it installs, I ran into problems installing it on Win XP and 2003 systems.

Specifically, the patch does a check of a system's keyboard layout registry keys and makes sure that each layout key has a resulting dll file. If no file is found, it adds the missing dll to a file named C:\Windows\faultykeyboard.log and stops the install until either the registry keys are removed, or the missing dll is readded to the file system.

In my case, I found that all of the systems having problems installing the patch were failing because kbdsf.dll and kbdcr.dll were missing from C:\Windows\System32. The offending registry objects are:

Value: HKLM\System\CurrentControlSet\Control\Keyboard Layout\DoskeybCodes, value 0000100c
Key: HKLM\System\CurrentControlSet\Control\Keyboard Layouts\0000046e
Key: HKLM\System\CurrentControlSet\Control\Keyboard Layouts\0000141a

The two files, incidentally are for the "Luxembourgish" and Slovakian keyboard layouts.

Since we use neither layout here, the simple fix was to remove the registry keys before running the patch.

Because we use a patch management system and because that system is able to run VB scripts in order to do things like remove registry keys, it was a fairly simple matter of researching the VBScript code required to delete the keys.

I made a custom patch in the system that first checks to make sure that the offending registry objects are not in the registry, and if they are then proceeds to run the following VBScript to remove the keys:

Const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objRegistry=GetObject("winmgmts:\\" & _
 strComputer & "\root\default:StdRegProv")

strKeyPath1 = "System\CurrentControlSet\Control\Keyboard Layout\DoskeybCodes"
strKeyPath2 = "System\CurrentControlSet\Control\Keyboard Layouts\0000046e"
strKeyPath3 = "System\CurrentControlSet\Control\Keyboard Layouts\0000141a"
strValueName = "0000100c"

objRegistry.DeleteValue HKEY_LOCAL_MACHINE, strKeyPath1, strValueName
objRegistry.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath2
objRegistry.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath3
ReportRepairResult True,"nice job!"

Here's a quick rundown of what the script does... It sets up a constant &H80000002 as HKEY_LOCAL_MACHINE (go here to find out what constants apply to which registry hive)
It then sets up a number of variables to be used later, including the registry keys and value to be deleted. It then deletes the registry objects one at a time using the previously defined variables to complete the function. Lastly we echo True and nice job! out so that the system running the script knows that the script completed successfully. Without that last bit, our patch management system would keep reporting that the custom patch failed.

We then set up a custom patch cloned from the patch management system's own definition for MS12-034 and add our registry fix as a dependency so that it runs before MS12-034 is installed.

And there you have it. The things we go through to fix Microsoft's messes, eh?

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!

Enterprise Linux tools need packaging

With few exceptions (Puppet being one of them, because it just rocks) open source enterprise tools need to be packaged and available in one of the mainstream repositories (even EPEL is good enough! The bar isn't that high!) or your tool just isn't ready for primetime.

Looking at you Plone, LogAnalyzer, nxLog and LogStash! OSSEC gets a pass, but just barely because they are using the funky Atomic repo.

This is where tools like Zabbix and OSSIM come out ahead. The last thing you want to be doing when managing an enterprise, particularly in the industrial control space because of the funky requirements, is worrying about manually updating ANYTHING.

Really, the only reason why Puppet gets a pass is because it's so hugely useful in an enterprise.

And no, I don't want a bunch of excuses on why your tool isn't in a repository, whether it's for Debian, Ubuntu or the Red Hat side of things. If it's not available as a managed package, chances are your tool isn't going to be deployed by me or other IT people like me...and we tend to be a very stodgy group.

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.