Under attack Linux Lives Longer?

Just a few days after the release of the USA Today / Avantgarde study about how long an unprotected PC might survive on a network before experiencing a variety of un-targeted attacks; the folks at the Honeynet Project released the results of a similar study that looks at the "time to live" for various Linux distributions. The study finds that Most Linux PCs are much less vulnerable to attack than PCs running Microsoft operating system products. The study suggests that a Linux PC could last up to 3 months on the Internet without being compromised.

I don't think there is any "me too" factor here. The folks over at the Honeynet Project have been doing their work and producing good results for several years. Even though these latest results were published a couple of days after the USA Today study there are clear differences in the work.

The title of the Honeynet Project report is "Know Your Enemy - Trend Analysis". The Honeynet folks did a much more thoughtful job of looking at the various Linux distributions that were out there and talking about where the problems are. The reality seems to be that the older Linux distributions that #1 turned on more services by default, and #2 have more documented vulnerabilities simply because they have been around longer are more vulnerable to un-targeted attacks.

An interesting note (#2) in the section of the "Know Your Enemy" or KYE study titled 'Reasons" was the rise in network based phishing (social engineering) attacks where the target isn't the asset (the PC) but the personal data on the PC or the personal information of the user.

How long can a PC survive on the Net?

USA Today recently sponsored some testing to determine how long various types of unprotected PCs could survive on the Internet. In at l;east one instance an unprotected PC running Windows XP was broken in to within 4 minutes of being started and attached to the Internet. It should be clear to all that this type of research is valuable in a couple of ways.

First off for USA Today it sells lots of papers and results in many, many hits at their web site. When a news outlet like USA Today gets behind a study like this many, many people will be able to get to the results.

Avantgarde, the Marketing and Design company that published the results of the "Time to Live on the Network" study did a first rate job. The published results of the joint study that were published at the Avantgarde website show that they did a very reasonable tests and they didn't suffer from any predetermined Windows bias. A Linux distribution (OK, but not one that I'm familiar with or would have suggested) was also used as part of this study. With that said the folks over at Avantgarde should also see much more traffic at their web site and probably more business.

Lost in the noise about the study results is the fact that Kevin Mitnick is credited as having participated in this study as one of the principal investigators. Many folks in the computer security business take issue with hackers who have been convicted of a crime later making there way back into the security business. I'm glad to see that Kevin put his skills to good work here and produced good solid work without making it all about a former hacker.

It should be noted that the PCs that did the best in this study had some sort of Firewall installed.

So where is the beef here? Hopefully the most important result of this study will be all the folks who see the headline and read the article in USA Today who are going to learn something about how bad the security of an unprotected PC really is. This work is another data point that highlights the problems of untargeted attacks over the Internet. It's up to users of PCs and developers of PC operating systems and security products to put the data together to realize the size and scope of the problem and work harder to it's resolution.

Scoble on Firefox and Security

Robert Scoble of Microsoft writes a great blog that I read regularly. I was catching up this evening and noticed an entry titled "Sticking it to the man Firefox style". One of the things that Rob has learned from Firefox was: "3) Security -- or the perception of having security -- is now a driver. It's why Microsoft is spending so much time on security now.". I can't help wonder if in the marketplace the perception of security is actually more important than actually be able to provide security in a product.

Worthless freeware?: Linksys Log Viewer

I'm looking at a number of the log tools available for a couple of different Firewall products. I'm trying to determine how useful these tools are in determining what the Firewall is providing in the way of protection. I'm currently using the Linksys BEFSX41 Firewall / router.

The first log tool I decided to look at was included on the Linksys products install CD. Linksys bundles a program called Logviewer and also makes the program available for download from the support section of their website. The program installs in seconds on a Windows PC and on execution shows up in the task bar.

When you run this program it displays a window on the screen with tabs to separate the view of incoming and outgoing traffic. The program doesn't seem to allow incoming and outgoing traffic to be viewed on the screen at the same time.

The biggest problem I had was getting this program to actually display all the information that it captured in its window. I could not re-size the Logviewer window and there was no option of going full screen. The program doesn't have a command bar. I could change the size of each of the columns. I wound up making the date and time columns really small and unreadable in order to be able to read the destination port column (that includes what was done to the packets).

I thought that maybe the version of this program that I retrieved from the CD was old. Just in case I downloaded and installed the utility from the Linksys support pages. Alas, there was no version number listed for Logviewer at the web site or in the filename.

About all I can say is that using Logviewer you will be able to figure out if the Linksys device is sending data to the log host. Since Logviewer can't get the most basic data fields up on to the screen at the same time it's not really very useful for trying to visually analyze what's going on at the Firewall.

Linksys and the blinking LED

If anyone else out there in the world is using a Linksys BEFW11S4 router (4 ports 10/100 with a 802.11B wireless access point) to connect to the Internet and you notice that it's not working properly take a look at the "power" LED on the front of the device. Apparently this can happen to just about any Linksys router. If that LED is blinking it means that the router was not able to load the firmware that the device needs to operate. The remedy is to reset the router by turning it on and holding the reset button down for 30 seconds. Then you connect to the Linksys from a PC with a fixed IP address in the 192.168.1.2 to 192.168.1.10 range. From that PC you should be able to ping the router at 192.168.1.1 and get a response. If not the unit is probably toast. If the ping succeeds then use the Linksys firmware installation (TFTP) utility with the default password of "admin" to load new a firmware image. Linksys support covers the issue here.

Be careful of a couple of things here. When we first noticed the problem one computer was able to connect to the Internet. The Linksys router had given that PC the ISP DHCP provided IP address. As far as I could tell that PC was on the Internet totally unprotected by the Linksys device.

I also noted that the Linksys support site points out that you can connect your PC directly to the Internet in order to retrieve the firmware image and firmware update utility. Be careful in that directly connected configuration to either disconnect or power off when you are not using the Internet to minimize the risk of attack.

Application Firewalls Vendors Challenge, Part 2

After my previous blog post I received an email from one of the firms that I had described based on reading several articles as developing this new application Firewall test criteria. The message pointed out that there were two factual errors in my previous post.

The claimed first error was that this group has posted their criteria. I checked the InfoWorld article that I had based much of my entry on and there was no pointer to the criteria file there. I also looked at articles on the topic that appeared in both eWeek and SC Magazine and could not find any reference to where I might find the criteria in those articles either.

The second claimed error was that these vendors don't call themselves a consortium. I took a quick look at the InfoWorld article and it said:

"At the Computer Security Institute’s Annual Security Conference, F5 Networks, Imperva, NetContinuum, and Teros announced the Application Security Consortium, saying the group wanted to establish minimum standards for application security software through independent testing."

If you're not calling yourself a consortium I'm sorry but it would seem InfoWorld got it wrong.

In was provided with a link to the proposed criteria document. The criteria that the group has published was reported to be "a baseline standard for application security firewalls", again according to reporting in InfoWorld. The actual title of the document is "Web Application Security Minimum Protection Criteria". The document has no author, no date, and no copyright mark and I couldn't find a link to it from anywhere else on ICSA Labs site. Given the lack of any of this info I chose not to link this entry to that document.

My suggestion is that if you want to stop application layer attacks you need to develop a good security policy that can be implemented on your network that meets your objectives given a reasonable risk of operation. There is no silver bullet.

Microsoft says Firewalls failing to keep out hackers

This is possibly a future classic... It seems that a Microsoft security technology architect named Fred Baumhardt was ripping "Firewalls" at a technology briefing on the need for next generation Firewalls.

"We are all bloody lucky that something hasn't obliterated IT on earth," said Baumhardt. "Firewalls are like retarded routers. They just look at the ports, sources and destinations they like. If a train comes from Gare du Nord [Paris] to Waterloo [London] via Eurostar you allow it to enter the country because you trust it. That's what firewalls currently do. They don't check to see if al-Quaeda is riding inside."

I think Fred is trivializing what is perhaps the most common security problem faced by anyone with an Internet connection. Even Microsoft's own Internet Connection Firewall (ICF) does more than this (but in the case of ICF not much). Which begs the question to Fred; what is Microsoft going to do to address this?

Application Firewall Vendors with something to prove?

InfoWorld has an article about the launch of the Application Security Consortium (no link, see note directly below), a group of application Firewall vendors who want to establish minimum requirements for what can be called an application Firewall.

Note: Amazingly the InfoWorld folks linked the Application Security Consortium to a profile for a New York based company, Application Security Incorporated (which seems to be about developing application test tools).

The members of this "consortium" are F5 Networks, Imperva, Netcontinuum, and Teros. In their start up announcment that coincided with this years CSI Conference in Washington D.C. the consortium issued a challenge to a number of other Firewall vendors (Symantec, McAfee, Juniper, Check Point) to submit their products for testing at ICSA Labs.

While this is an interesting idea it falls short of actually being useful. The Application Security Consortium has developed their own test criteria which has not been published. Where is the peer review here? They made the test criteria available to ICSA Labs and pay the Labs (or more accurately have the challenged vendors pay the Labs) to test other vendors products. This consortium should make their criteria freely availble for everyone to look at. They should define a means for other to challenge items in the criteria which don't make sense.

I was also bothered by the fact that this group has taken to calling themselves a "consortium". The ICSA Labs folks have developed a number of really good security industry consortiums (Anti Virus, Firewall, IPSec Interoperability consortiums to name a few) where vendors come to together with ICSA staff and discuss and agree on testing criteria that ICSA Labs later tests against. This isn't what has happened here.

Until this group gets their act(s) together this really isn't helping improve anyone's security.

Filters and VoIP

CNet News reported yesterday that broadband subscribers attached to various cable providers were experiencing problems with some VoIP calls being blocked. The article points out that some "angry customers" atributed the problem to overzealous cable companies trying to bolster their own VoIP offerings. Reading the rest of the article it's clear that this probably relates back to filters these cable providers put in place to mitigate the MSBlaster worm. It seems that several of the affected VoIP services use port 69 (normally TFTP) for call setup rather than port 5060. Filtering (blocking) port 69 through your Internet Firewall is totally normally. I'd suggest keeping track, but not filtering port 5060.

Duelling Firewalls?

Computer Business Review points out that personal Firewall vendors now have a new competitor in Microsoft. Microsoft Windows XP Service pack 2 ships with a more capable version of the Internet Connection Firewall (ICF). In order to deal with new Microsoft software personal Firewall vendors will have to add the capability to detect the running ICF and turn it off before they install their own software. I took a look at the XP Service Pack 2 update page and I didn't notice any tips about checking for or turning off any personal Firewall software that you might have already installed.

Another article from ZDNet on SP 2's new Firewall and the Security Center.

Ten Things to Look for in Firewall Logs

I've been working on a list of the top ten data points to look for in Firewall logs. This is a work in progress. I'm not sure if I've got all the right events listed here or if the order is right.

#1 - Authentication Allowed (user from outside allowed in)

I ranked this event highly since this is the case were someone from the outside has been allowed in. I think these are most important as someone is now inside the Firewall. These sessions should always be audited to make sure that access was legitimate.

#2 - Traffic dropped (from outside addressed to Firewall)

Traffic addressed at the Firewall is a potential problem if someone on the outside can isolate the Firewalls address. If these are just scans of address ranges that include the Firewall they can be ignored.

#3 - Firewall Start / Restart

Another event that when it happens need to be explained. When the Firewall starts isn't as important as the restarts. A Firewall restart is an opportunity to discover important version information and for a new configuration to load.

#4 - Firewall Configuration changed

These events should always be audited and correlated with a change control record.

#5 - Interface up/down

Interface up or down defines when the Firewall may have stopped working. At best this is an inconvience to users behind the Firewall. At worst this is a sign of unstable Firewall software, the exploitation of a flaw that would signal the start of an attack, or worse.

#6 - Admin Access Granted

Someone has their hand in your cookie jar. do you know who and what they were up to?

#7 - Connection was torn down

When a connection between a host on the inside and one on the outside of the firewall is torn down the logs can reflect how long that connection lasted and how much infomration was transferred.

#8 - Authentication Failed (user from outside)

Someone just tried to get through the Firewall and the connection was not allowed. In order to even attempt to authenticate this outside user needed to know the protected IP address and port. Where did this attempt come from? Am I seeing multiple attempts from the same address?

#9 - Traffic Dropped (from outside not addressed to Firewall)

#10 - Admin Session Ended

Firewalls at David Piscitello's Blog

I was scanning the web looking for interesting content this morning on Firewalls and noticed David Psicitello's web log. Dave is the President of Core Competence which is a data network consulting firm. I first met Dave years ago at the First "The Intenet Security Conference" or TISC that was held in San Jose in the late 1990's(he met a couple of hundred people at that event so I don't count on him remembering me). I look for Dave's writing because I find that he's very objective in his approach to different products and technologies . I need to think about that all the time since I work for a Firewall product manufacturer. Dave's also from the east coast and as suchI think he's pretty clear at speaking his mind. If somethings broke, he'll point it out and tell you just how broke it is.

One of the neat things about Dave's blog is the list of topics on the left side of the screen. I can choose "Firewalls" and then see only Dave's content on that topic. In the same list he has also included links to some other authors sites (Avolio, Chuvakin, others,..). I found the Firewall references to all be interesting.

Finishing the Book Proposal

Work on the book proposal is nearing completion. The working title will be "Firewall Fundamentals". I've got the scope of the book, the Firewall market and the competitive portions of the proposal completed. The writing outline is looking great to me. I have a lot of detail in there. I've got some work to do in defining the audience, listing key objectives, and defining the format. I hope to get the proposal completed between tonight and tomorrow morning, and then submit it tomorrow afternoon.

Two Firewall FAQs

As I start doing research for my Introduction to Firewalls book I'm looking at some of the information that is out on the Internet that I've always recommended. Two resources that I often suggest are the Firewall FAQ at Interhack and Robert Grahams "What am I seeing" Firewall Forensics FAQ for Firewall logs.

The Firewall FAQ does an excellent job or answering most of questions that someone who is new to network security would ask.

In the description of the Firewall Forensics FAQ the author says it explains what you'll see if Firewall logs and 'especially port numbers". This is a great reference for port to application and specifically hostile port to application mapping.

Both of these are great non product specific resources.

And so it begins...

Based on a conversation I had a couple of weeks ago with one of the acquisition editors at Cisco Press I have decided to pursue a dream and write an introduction to Firewalls book. The funny thing is that about two years ago I contacted Cisco Press (different people then) and asked if they would be interested in a book that introduced readers to Firewall technology. At the time they weren't interested. At all. But they were really nice and did call on me for opinions on other proposals and technologies from time to time. That progressed to reading other peoples manuscripts and later proposals. Last year they asked if I wanted to lead the development of a book about troubleshooting some specific Firewalls. Unfortunately that effort has been bogged down by the development of products.

I'm excited about this new project. I've been very interested in Firewall technology for years. I've worked at the edges of Firewall product development within Cisco Systems for years. I've been explaining Firewalls to Cisco customers and helping them with their issues for years.

I think there are a few challenges to writing an introduction to Firewalls book. I want the reader to be someone who is learning about Firewalls and security. I have to step back and make sure I keep the writing on target to that audience and stay away from "geek speak." How can I make the book relevant to lots of people. I want to write something that talks about a Linux Firewall and the Cisco PIX. I'd like to show readers what both do and let them decide which is best. I think it is important to talk about applications to be Firewalled. When I think about applications I think Network News (NNTP) is yesterday and that VoIP is today. I think that most of the books out there are really dated in that regard.

I think a problem that I may run into is that I tend to favor very closed security policies. It goes back to what I learned in the "old days" from the likes of Marcus Ranum and Joel Synder ("only talk to your friends"). To do this right I need to educate the reader and not preach.

It's not going to be easy. But I think it is going to be fun.