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