Re: Followup: Zone Alarm and Akamai -- not either one. (blush).

[Joe <joe () blarg net>]

On Mon, 16 Oct 2000, j nickson wrote:

> Followup:  Zone Alarm and Akamai.
>
>     Well, this is too long, but it may help someone.

Not bloody likely. Read on McDuff. (My apologies to the list, I tried to
offer some clues to Mr. Nickson via private email yesterday, obviously Mr
Nickson is somewhat resistant to clues, so to impart his misunderstandings
to him I'm going to be a wee bit agressive here)

> DNS spoofing reported from one ISP regularly.

There is absolutely zero evidence of DNS spoofing here. Are you running a
DNS server? No? Then you can't be a victim of "DNS Spoofing" as it's most
commonly defined. If your ISP's server has been spoofed, there's absolutely
no way you would be able to tell (unless you yourself are running your own,
clean DNS server, or have access to one). Please consult:

http://www.the-project.org/admins/0897-1097/0381.html

For an excellent write-up of what DNS spoofing really is. You're probably
visiting load balanced sites and receiving replies from IPs which differ
from the request IP. (ie, you request a document from a.b.c.d:80 and get a
reply from b.c.d.e:80 - this is not a spoof, it's simple load balancing)

> Went to get coffee, sat down again and *then* ZA popped a
> message
>
> ---------------------------------------
> The firewall has blocked Internet access to a388.g.akamai.net
> (63.160.183.233) (HTTP) from your computer.
>
> Time: 10/15/00 8:13:08
> ----------------------------------------
>
> It turns out Akamai is used by CNN, that much is solved.
>
> Why "my computer" was requesting something about two minutes
> after Netscape had been terminated escapes me.

It shouldn't. I tried to explain it to you yesterday, even sent you the TCP
RFC. If you had read it, you would know that long after you close your
browser the TCP/IP stack is still negotiating the connection close sequence.
This is perfectly normal TCP acitivity.

> ---------------------------------------
> blackd tried to connect to the Internet (209.198.87.40), but was denied
> access by the Internet Lock.
>
> User: *********************
> Program: blackd
> Time: 10/15/00 9:19:58
> ------------------------------------------
>
> I Ctrl-Alt-Del to look at the top level running tasks and
> neither blackd or Black Ice was listed.

If blackd is loaded as a service, it won't be listed in your C-A-D list of
applications. That, and it's blocking access to your ISPs name server. If
you don't want to be able to resolve host names that's your business.

> It was pretty clear the system was ill or boggled.

So far I see a perfectly normal system operating as it should, although
hampered by a badly configured firewall.

> The firewall has blocked Internet access to 216.15.66.222
> (HTTP) from your computer.
>
> Time: 10/15/00 12:38:38
>
> -------------------------------------------------
>
> which is a Microsoft site advertising IIS.

No - actually, it's a server in ZoneLabs turf, which still happens to have
the default IIS page up.

Name:    222.zonelabs.com
Address:  216.15.66.222

ZA was trying to talk to ZoneLabs. Please do your research based on the IP
Address, not on what pops up when you try to visit that IP with your web
browser.

> It was pretty clear that the computer was boggled.

Nope.

>      I double check and there is no Java.exe on the system now.
>      Listed in the registry under a compatibility key?  I remove it.
>       - Each of Eudora, Netscape, Opera run separately, the key does
>         not re-appear.
>
>      I am almost certain there was one inside the
>      Inprise/Borland package which is now removed.
>      JAVAxxx's permeate any modern system.

Java.exe - the Java application viewer, installed by JBuilder no doubt. You
can't really develop any java application without it.

> It is now about 19:00 and I reconnect to the internet.
>
> No UDP probes.  No more DNS spoofs.

Good - no more misconfigured firewall.

> The difficulty with this procedure is that repair took roughly
> 11 hours and to have single stepped and checked all the way
> through for determining an exact cause would have
> taken days, which are not available.

There was nothing to repair. Your problem was a PIBKAC: Problem Is Between
Keyboard And Chair.

>   The system is not apparently connecting to Redmond spontaneously.

It never was.

>   The system is no longer asking for things or sending information several
>  minutes after the relevant program has been terminated.

Which means your firewall(s) are probably configured correctly and now
ignore normal TCP traffic.

> UDP probes went from a peak of 44 in ten minutes to 0.33 per hour.

Of everything in this document, the UDP probes are the only part that could
very well have been intrusion attempts or UDP port scans. The nice thing
about a firewall is that once it's configured correctly, you can tell it to
stop alerting you to these. (They're blocked, "who cares". My personal box
at home gets scanned daily, usually several times a day, and far more
agressively than 44 in ten minutes)

> I have not seen a DNS spoof.

You never have. Most likely you were visiting load balanced servers and
getting replies from IPs that didn't match the original request.

> Learnings:
>
> UDP probes and DNS spoofs are not as harmless as some doc indicates.

Especially when you mis-interpret normal TCP/IP traffic as "attacks", don't
bother to do your homework, and trash your system in a futile attempt to
"repair" the problem.

Mr Nickson, please refrain from posting to VULN-DEV unless you've got a real
live vulnerability to discuss, or you're participating in an ongoing
discussion. Your "reports" are riddled with errors and misconceptions, and
the resulting advice you give is horribly inaccurate.

--
Joe                                     Technical Support
General Support:  support () blarg net     Blarg! Online Services, Inc.
Voice:  425/401-9821 or 888/66-BLARG    http://www.blarg.net