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.
"On the Firewall" is a online journal on the subject of network Firewalls and all things Internet security.
November 26, 2004
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.
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.
November 24, 2004
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.
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.
November 20, 2004
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:
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.
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?
"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?
November 15, 2004
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.
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.
Subscribe to:
Posts (Atom)