dslreports logo
Search similar:


uniqs
13590

NetWatchMan
Premium Member
join:2001-03-13
Alpharetta, GA

NetWatchMan

Premium Member

Common Firewall False Positives

I recently posted this in another newsgroup and thought y'all would find it interesting as well:

I'm tired of hearing that the most logged firewall events are: "normal", "background noise", "random probes", "people typing in wrong IP addresses",
etc...

These are all vague assertions to explain away something this is admittedly difficult to analyze and explain. When you hear words like "random" and "noise" those are really synonyms for "I don't know!".

We'll I DO know as I've spent the last 18 months processing and analyzing 100,000 firewall events/day. (I'm the operator of myNetWatchman.com). So if you really want to understand this stuff, read on...

Here are some REAL causes for false positives, including links to examples of real incidents captured by mNW:

Some of the sources of false positives are:

a) Slow server responses

Most firewalls block (and log) any inbound traffic for which there wasn't an associated and RECENT outbound request. This means that if you make a request, but the server responds too slowly (e.g. > 1 or 2 seconds), your firewall will consider that response as unsolicited and log it as a probe.

The destination port of all server responses will be in the range of 1025-65535. If you see your firewall log "probes" against these ports AND the source is a server you are communicating with, the are probably just slow server responses.

To complicate matters, your attempt to surf to ONE web site, can actually result in communication with dozens of different hosts--often hosts that would appear to be unaffiliated with the site in question. However, consider cnn.com...some of there content is distributed onto Akamai caching servers....so probes coming from XXXX.akamai.net while surfing to cnn.com are probably just due to a slow cache server.

Example: »www.mynetwatchman.com/LI ··· =2518142
(note: this is a case of an Akamai server providing Real audio content)

If you see UDP probes in these port ranges AND the source is your DNS server...then these are probably slow DNS responses.

b) Proximity probes

Larger web sites maintain mirrored content on many distributed web servers, often in multiple countries. When you first do a DNS lookup of a web site (e.g. www.windowsupdate.com ) the site's load-balancing servers will send "proximity probes" from every location to your IP address. PC's that don't have a firewall will send back a reject packet (ICMP port unreachable) in response to these probes...info in these packets allow the load balancers to
determine which one is "closest" to the user, allowing it to provide the user the IP address of the nearest web server.

Users running firewalls will log these proximity packets as probes (often on tcp/53) because they come from IP addresses that they did not make any outbound request to. This even one content hosting company that provides this capability as part of it's hosting services (mirror-image.com)...when you surf to ANY website hosted by this company, you will be immediately "probed" by over 10 load-balancing servers in 6 countries!

Example: »www.mynetwatchman.com/LI ··· D=305387
Note: This incident is generated by the 3DNS product sold by F5 Networks.

c) Open proxy tests

If you are an IRC user you will likely be probed on several ports everytime you atempt to connect to an IRC server. This to prevent anonomous IRC access through other user's PC's that are unknowning configured to allow proxying.

Example: »www.mynetwatchman.com/LI ··· =2466138

d) Stale IP caches

If you have a dynamic IP address, you will often find that you receive a lot of unsolicted probes when you first obtain a new IP address. This often because the previous user of that IP address was running some applicatio which has cached their IP address somewhere and it's aware that the owner of that IP has changed.

Often the involved applications are Internet game servers, peer-to-peer file/music software (e.g. Gnutella, Napster, Kazaa, audiogalaxy, etc..).

Some of these applications are poorly written to handle this situation and will incessantly pound an IP address thousands of times for many hours. As much as this may seem like an targetted attack, it is really just a function
of poorly written code that gives no considerationation to how many firewall false positives it generates.

Example: »www.mynetwatchman.com/LI ··· =2529363

e) Search-engine bots

Similarly, people often post web content with URLs that contain dynamic IP addresses (e.g. »123.123.123.123/blah/blah ). Days, weeks, or months
later web search bots may encounter this reference and then attempt to index that site. If you are the unfortunate person to have IP address 123.123.123.123 you now get a few dozen probes from abc.googlebot.com.

Example: »www.mynetwatchman.com/LI ··· =2482968

f) Netbios name lookup from IIS servers

If an IIS server is also has Netbios over TCP/IP enabled, the server will often send Netbios name lookups directly at the users that surf to that site. This is due to IIS's attempt to associate a host name with every IP address that accesses it.

Although this is technically not hostile, it's probably not advisable for webmastsers to enable Netbios on their Internet facing network adapter...nevertheless, this is a common scenario

Example: »www.mynetwatchman.com/LI ··· =2470765

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK

Mod

Thanks, this is a good summary. Typically, the firewall timeout is much longer that a few seconds (e.g. on the ZyWALL 10 it is a minute, but adjustable). I have encountered late DNS responses up to three minutes after the outgoing request.
(people with NAT router and NO ports forwarded will still see those with the LAN IP as destination. The NAT timeout is much longer than the firewall timeout and NAT still treats them as return traffic.)

Another case that often seem to create false positives in personal firewalls are broadcasted DHCP replies (from your-DHCP-server:67 to 255.255.255.255:68).
Quote from RFC 1541:Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit.

Note that personal firewall correctly ignore DHCP requests of other LAN users. Suppressing broadcast replies seems however not implemented in most personal firewalls.

In general, anything that contains a broadcast or multicast address (224.0.0.0-239.255.255.255) as destination should be summarily ignored!

Of course the firewall programmers are reluctant to add a little bit of AI to clean up/limit the logs, because every log generated justifies their existence to the user.

All this also underscores the need to discourage reporting by new users directly to ISPs. Your service is very valuable in this respect, because it can weed out all the meaningless garbage and focus on the rare gems that might require attention.

WizzOzz
join:2001-05-21

WizzOzz to NetWatchMan

Member

to NetWatchMan
Thanks, this is one of the threads which is very valuable but (looking at the responses) no one notices it.
Ill copy/paste, with link to dslreports, it to the Outpost FAQ. If this isnt allowed, let me know it.

Wildcatboy
Invisible
Mod
join:2000-10-30
Toronto, ON

Wildcatboy to NetWatchMan

Mod

to NetWatchMan

Very well done. Thank you.

Rocktagon
Slightly Bent
Premium Member
join:2000-11-04
Chattaroy, WA

Rocktagon to NetWatchMan

Premium Member

to NetWatchMan
One more Lawrence, great job
tenacious0
join:2001-10-16
San Jose, CA

tenacious0 to NetWatchMan

Member

to NetWatchMan

That's a great topic! Very helpful for my continuing Firewall Education.

Thanks for taking the time to post it!

Chekawa
Ema
Premium Member
join:2001-02-02
Nectar Land

Chekawa to NetWatchMan

Premium Member

to NetWatchMan
Great Stuff! Thanks for the information and helping me understand it. Excellent.......

Krispy1
Premium Member
join:2001-12-11
the stix

Krispy1 to NetWatchMan

Premium Member

to NetWatchMan
Nice

Another of my favorites is the false positive DNS spoof successful most often reported by BlackIce users...

»advice.networkice.com/Ad ··· ault.htm

Flippant
So Much For Subtlety

join:2000-06-04
Katy, TX

Flippant to NetWatchMan

to NetWatchMan
Excellent post. I will bookmark this one for future use in explanations.

Thanks!

ITGeekMonkey
Orbis Hirsutis
Premium Member
join:2001-11-06
Wylie, TX

ITGeekMonkey to NetWatchMan

Premium Member

to NetWatchMan
I've gone over this post several times.

Much appreciated. Needs to be added to the must read list for the forum posting rules.;)

NetWatchMan
Premium Member
join:2001-03-13
Alpharetta, GA

NetWatchMan

Premium Member

Here's another great false positive example:

g) Source of probes is *Victim* of Spoofed DoS Attack

One or more attackers Syn-flood a victim web site, sending each TCP connect request with a different randomly spoofed IP address. The victim host sends a response (SYN/ACK) back to each of the spoofed IPs. If the DoS attack is over a long period of time, potentially millions of spoofed IPs may be sent a response packet. Users running firewalls on any of these IPs will log this response packet as a probe.

mNW 2542636 - livejournal.com DoS Attack

I spoke to the owner of the web site above and he confirmed that he indeed was has been under DoS attack in the last day or so.

The link above doesn't show it, but all these "probes" had a *source* TCP port = 80...showing these these were really response packets from the web server. Also notice, that the 4 sensors that picked up this activity all got hit within a VERY short time-frame (2.5 hours). That tells me that whoever was launching this DoS attack must have been generating a boat load of connect attempts at an extremely high rate!

rfhar
The World Sport, Played In Every Country
Premium Member
join:2001-03-26
Buicktown,Mi

rfhar to NetWatchMan

Premium Member

to NetWatchMan
thanks

Luka1
join:2001-10-30
Index, WA

Luka1 to NetWatchMan

Member

to NetWatchMan
Thanks, Lawrence

Slowly but surely, I'm learning.

So now I understand that UDP probes from several different ip's can be the result of checking out a new website. Any reason I should be concerned then, with UDP probes from different ip's and different ports ?

Also, is there any way that UDP probes can be used for other than good reasons ? ie, can I just allow all UDP, and quit being bothered with it, or is there some proven way to set up a good rule for them, etc ?

penguins4evr
Premium Member
join:2002-01-17

penguins4evr to NetWatchMan

Premium Member

to NetWatchMan
Most excellent post. Since I am a novice to ZA the information is quite helpful. Thanks! Peace . . .

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK

Mod

JUst for reference, here is a little summary from the attbi security page about common false positives that get reported to them:

Common misinterpreted Abuse Complaints
HarryBeanBag
join:2002-01-22
USA

HarryBeanBag to NetWatchMan

Member

to NetWatchMan
Thanks, very helpful post.