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