Total FUD: Zonelabs Teams up with...

[treat2]

What is posted from here onward by the member treat2 is totally inaccurate and deliberately false and misleading information. Inspite of being shown proof that he was wrong, he continued to claim that there was some sort of untoward conspiracy going on.

Wilders Security will not support such false and defaming postings, therefore, the member has been banned and this thread closed. - LowWaterMark




Eye Opener: Zonelabs Teams up with Big Brother (Zedo.com)

Yes... just when you thought you've seen Firewall Vendors pulling all sorts of s***.... take a REAL CLOSE look AT Zonelabs, and you'll find it is THE SAME THING AS Zedo.com

Unless EVERY DNS Server on the Net is "poisoned", check this out...

do an nslookup on upd.zonelabs.com.
(ie. nslookup upd.zonelabs.com in the Command Prompt), ...

NOW, do an nslookup on www.zedo.com AND also c4.zedo.com

Notice anything?

Yep. ZONE ALARM'S DAILY UPDATE WEBSITE IS ZEDO.COM!!!

Can you believe that sh**???!!!!!!

If you are totally clueless as to WTF I'm talking about, just Google on Zedo.com, and checkout what everyone on the Net has to say about those A-Ho**!

Folks, it seems that Checkpoint (ZA's vendor) needs to be "checked out", as they're definitely knee deep in s***, and that's an understatement.

Is ZA "THE BEST" firewall EVER!" ????

Think again! ----> Big Brother's Watching!

BTW. Please spread the word. It's clear that nobody knows what really going on with "The Best Firewall EVER!"

Regards, - T2 -

[gerardwil]

What's wrong?

canonical name a288.g.akamai.net.
aliases upd.zonelabs.com
upd.zonelabs.com.edgesuite.net
addresses 204.0.5.11 204.0.5.25


canonical name a1979.g.akamai.net.
aliases c4.zedo.com
c4.zedo.com.edgesuite.net
addresses 204.0.5.19 204.0.5.33

Gerard

[Mem]

-{ Quote: "Yep. ZONE ALARM'S DAILY UPDATE WEBSITE IS ZEDO.COM!!!
" }-
No it isn't...seems someone needs to understand the role of global hosting/mirror companies....

http://en.wikipedia.org/wiki/Akamai_Technologies

[gerardwil]

-{ Quote: "
BTW. Please spread the word. It's clear that nobody knows what really going on with "The Best Firewall EVER!"

Regards, - T2 -" }-

It's best to leave this job for you. ;D

Gerard

[treat2]

-{ Quote: "What's wrong?

canonical name a288.g.akamai.net.
aliases upd.zonelabs.com
upd.zonelabs.com.edgesuite.net
addresses 204.0.5.11 204.0.5.25


canonical name a1979.g.akamai.net.
aliases c4.zedo.com
c4.zedo.com.edgesuite.net
addresses 204.0.5.19 204.0.5.33

Gerard" }-


Pardon me. Try c5.zedo.com

nslookup upd.zonelabs.com.edgesuite.net
Name: a288.g.akamai.net
Addresses: 72.246.52.7, 72.246.52.14
Aliases: upd.zonelabs.com.edgesuite.net


nslookup c5.zedo.com.edgesuite.net
Name: a426.g.akamai.net
Addresses: 72.246.52.14, 72.246.52.8
Aliases: c5.zedo.com.edgesuite.net


And you were saying? Ahem...

[Mem]

-{ Quote: "And you were saying? Ahem..." }-
We are saying that Akamai is a mirror company that takes information from separate individual companies and distributes it to the web in a quicker fashion than they could do themselves. Zonelabs and Zedo are not the same company or 'in' with each other, they just use the same distribution company for the web which has thousands of customers just like them.

[Baz_kasp]

Almost every major company uses Akamai....apple and MS included.

[treat2]

-{ Quote: "We are saying that Akamai is a mirror company that takes information from separate individual companies and distributes it to the web in a quicker fashion than they could do themselves. Zonelabs and Zedo are not the same company or 'in' with each other, they just use the same distribution company for the web which has thousands of customers just like them." }-


I don't mean to sound silly, but you're saying that both "different companies" (just happen to) "share" THE SAME IP Address (72.246.52.14), as shown in the nslookup of c5.zedo.com.edgesuite.net above, eh???

BTW. That "akami" is a monster is not news to anyone.

Anything else?

Sorry, I'm not "buying the line", as a fully qualified URL name shows the two of them are sharing the same bed.

Please correct the nslookup above, or add anything else you have to shed further light on what appears rather obvious (using C5, instead of C4, WITH the fully qualified URL.) - I do thank you folks for pointing out that initial problem. However, it appears that a correction reveals nothing substantially new with regard to what is pointed out in the initial "thread post."
- Regards, - T2 -

[Mem]

-{ Quote: "I don't mean to sound silly, but you're saying that both "different companies" (just happen to) "share" THE SAME IP Address (72.246.52.14), as shown in the nslookup of c5.zedo.com.edgesuite.net above, eh???" }-

Yes, I do. They both use Akamai and the Akamai server uses that IP so it appears to come from the same IP to you even though it is a redistribution from the companys' servers. There are multiple global server centers for Akamai which allows more localized streaming of information from thier servers, improving throughput for the enduser. The Edgesuite is a platform that Akami uses on the server to interact with the client ompany.

http://www.internetretailer.com/internet/marketing-conference/39368-akamai-unveils-edgesuite-business-continuity.html


No offense, but you need to learn more of how this works before spreading FUD around. You may not 'buy the line' but it is the reality of the situation.

Edit: since you may not have seen this from the wikipedia link I supplied above, I thought I would include it...

"Akamai transparently mirrors content (usually media objects such as audio, graphics, animation, video) stored on customer servers. Though the domain name is the same, the IP address points to an Akamai server rather than the customer's server. The Akamai server is automatically picked depending on the type of content and the user's network location."

[Mrkvonic]

-{ Quote: "I don't mean to sound silly, but you're saying that both "different companies" (just happen to) "share" THE SAME IP Address (72.246.52.14), as shown in the nslookup of c5.zedo.com.edgesuite.net above, eh???

BTW. That "akami" is a monster is not news to anyone.

Anything else?

Sorry, I'm not "buying the line", as a fully qualified URL name shows the two of them are sharing the same bed.

Please correct the nslookup above, or add anything else you have to shed further light on what appears rather obvious (using C5, instead of C4, WITH the fully qualified URL.) - I do thank you folks for pointing out that initial problem. However, it appears that a correction reveals nothing substantially new with regard to what is pointed out in the initial "thread post."
- Regards, - T2 -" }-

Hello,

The IP address means nothing.

DNS wise - the zone records simply exist on the same server.

Web server wise - For example, in Apache, you can use VirtualHost blocks to serve different web sites on the same IP address, without the having anything to with one another or being related in any way.

IP addresses are a precious commodity. No reason to squander one IP per site when you can host several.

Mrk

[treat2]

-{ Quote: "Yes, I do. They both use Akamai and the Akamai server uses that IP so it appears to come from the same IP to you even though it is a redistribution from the companys' servers. There are multiple global server centers for Akamai which allows more localized streaming of information from thier servers, improving throughput for the enduser. The Edgesuite is a platform that Akami uses on the server to interact with the client ompany.

http://www.internetretailer.com/internet/marketing-conference/39368-akamai-unveils-edgesuite-business-continuity.html


No offense, but you need to learn more of how this works before spreading FUD around. You may not 'buy the line' but it is the reality of the situation.

Edit: since you may not have seen this from the wikipedia link I supplied above, I thought I would include it...

"Akamai transparently mirrors content (usually media objects such as audio, graphics, animation, video) stored on customer servers. Though the domain name is the same, the IP address points to an Akamai server rather than the customer's server. The Akamai server is automatically picked depending on the type of content and the user's network location."" }-

Sorry for my "tone".

Perhaps we can agree that "c5.zedo.com.edgesuite.net" simply is a URL belonging to CheckPoint, and one of its IPs (72.246.52.14) as shown below...

nslookup upd.zonelabs.com.edgesuite.net
Name: a288.g.akamai.net
Addresses: 72.246.52.7, 72.246.52.14
Aliases: upd.zonelabs.com.edgesuite.net


nslookup c5.zedo.com.edgesuite.net
Name: a426.g.akamai.net
Addresses: 72.246.52.14, 72.246.52.8
Aliases: c5.zedo.com.edgesuite.net

Well.... we'll just forget about that. Obviously, there's no relationship whatsoever between the IP (.14) used by Zedo and Checkpoint.

I think we understand you ENTIRELY now. No offence taken. Many thanks!

Cheers! - T2 -

[treat2]

-{ Quote: "Hello,

The IP address means nothing.

DNS wise - the zone records simply exist on the same server.

Web server wise - For example, in Apache, you can use VirtualHost blocks to serve different web sites on the same IP address, without the having anything to with one another or being related in any way.

IP addresses are a precious commodity. No reason to squander one IP per site when you can host several.

Mrk" }-


Thanks for the laugh! That was really a gem!


BTW. What's an IP???

- Regards, - T2 -

[steve161]

Mrk:

Your sense of humor is getting way too subtle for my tastes. I missed that joke completely.

[treat2]

-{ Quote: "Mrk:

Your sense of humor is getting way too subtle for my tastes. I missed that joke completely." }-

Yeah. LOL. This PC stuff is so "dry". Wait a sec...

Ya think Zedo could be kinda peeved that Checkpoint is using their IP???

I'll bet Zedo would be kinda displeased that everyone using Zone Alarm's Firewall Update is knocking at their door.

Geez!!! Given Zedo's "rep", I'm SURE they've just totally discontinued using that IP for ANY REASON whatsoever.

Ohhhhhh.....

Wait a minute! "The IP means nothing!" Ah yes. So, in "DNSland" Zedo and Checkpoint just SHARE the SAME IP SIMULTANEOUSLY!

Ain't DNS wonderful! WOW! Nothing gets mixed up. It's kinda like magic. Every IP Packet knows just where it's supposed to end up, just by the URL!

Got it. The IP address is simply meaningless, 'cause the IP packet has a URL!

OPPPPs! Geeez.... wonder what happens if the sender of the packet doesn't use "no" URL and uses an IP instead?

AH! I know. They (Zedo and Checkpoint) BOTH get the IP packet, and the "listener" program (at Zedo and Checkpoint) simply decides to discard or accept IP packets in an arbitrary fashion.

Now THAT really makes sense. Thanks a bunch. Obviously, these guys just got "smushed" together by akami, cause akami is probably using every friggin IP address on the Net for itself! (lol) - T2 - (this is too much. lmao)

[LowWaterMark]

Two companies that happen to use akamai content mirroring does not make those companies related at all. Yes, even if the content happens to overlap by IP address, they are still not related. As Mrk wrote, an IP address just brings you to a specific server location, however, the virtual hosting there can easily provide the correct content based upon whichever name the request is using.

akamai is just a third-party bandwidth provider in this case. If a company requests akamai to mirror content, akamai provides them with that content on a specified hostname, then varies its DNS to load balance the content between servers and often geographically dispersed, so that closer servers may provide the content quicker.

-{ Quote: "AH! I know. They (Zedo and Checkpoint) BOTH get the IP packet, and the "listener" program (at Zedo and Checkpoint) simply decides to discard or accept IP packets in an arbitrary fashion." }-No, neither Zedo nor Checkpoint are getting that packet. akamai is getting it. Take a look at who actually owns the shared IP addresses you've noted... Don't just look at the result you get looking up the hostnames, look up based on the IP addreses you are seeing. For example, you show 72.246.52.14 as a shared IP address. Looking that up shows neither Zedo not Checkpoint, instead it shows clearly that akamai owns the IP address:

200069

akamai is the owner of those "shared" IP addresses, not either company. And akamaai provides content based upon the host name in the request header, providing either updates for zonealarm or whatever zedo has hosted there. The key to this is virtual hosting...

http://en.wikipedia.org/wiki/Virtual_hosting

Read the part about how different content is provided on a server using the same IP address but different hosts.

[treat2]

-{ Quote: "Two companies that happen to use akamai content mirroring does not make those companies related at all. Yes, even if the content happens to overlap by IP address, they are still not related. As Mrk wrote, an IP address just brings you to a specific server location, however, the virtual hosting there can easily provide the correct content based upon whichever name the request is using.

akamai is just a third-party bandwidth provider in this case. If a company requests akamai to mirror content, akamai provides them with that content on a specified hostname, then varies its DNS to load balance the content between servers and often geographically dispersed, so that closer servers may provide the content quicker.

No, neither Zedo nor Checkpoint are getting that packet. akamai is getting it. Take a look at who actually owns the shared IP addresses you've noted... Don't just look at the result you get looking up the hostnames, look up based on the IP addreses you are seeing. For example, you show 72.246.52.14 as a shared IP address. Looking that up shows neither Zedo not Checkpoint, instead it shows clearly that akamai owns the IP address:

200069

akamai is the owner of those "shared" IP addresses, not either company. And akamaai provides content based upon the host name in the request header, providing either updates for zonealarm or whatever zedo has hosted there. The key to this is virtual hosting...

http://en.wikipedia.org/wiki/Virtual_hosting

Read the part about how different content is provided on a server using the same IP address but different hosts." }-


OMG!!!

You mean if I send a packet with JUST the IP, then ONLY akmi gets it, and nobody else?????

GEE! All this time, I thought ya could send a packet with just an IP, and it would go to the place I wanted it to, but alas.... akami would simply DISCARD the sh** because I didn't use a friggin fully qualified URL!

OK! Thanks. BTW.... Could you PLEASE tell someone at Checkpoint to rewrite their firewall, cause its got this entry for an IP address, and I REALLY would HATE to think that IP packets MUST have a fully qualified URL just to get to ANYONE (of a few trillion servers) that just HAPPENS to be ON Server Farm!

Thanks for clearing the entire matter up. I'll just attribute the entire thing to the complete ignorance of DNS's ability to resolve an IP to a URL, and then send a packet to the right place, since as you say..... akami gets it, but neither ZEDO nor Checkpoint get squat. Right.

BTW. akami's got too many addresses. Don't ya think they outta join some Web Hosting firm to cut down on their IP consumption?

Oye! LOL I'm having entirely too much fun with this unforseen loss of IP packets just using IP Addresses that are simultaneously shared by a billion points of light.

Thanks for the enjoyable chat. I'll google that reading material under:
"TCP and its irrelevant IP's on millions of Web Servers".

BTW. I kinda figure that Checkpoint and Zedo are pretty liberal minded about sharing a firewall update distribution server address with another company infamous for spreading doggy pooh all over the Net. Go figure, eh?

- Cheers, - T2 -

[Mrkvonic]

-{ Quote: "Yeah. LOL. This PC stuff is so "dry". Wait a sec...

Ya think Zedo could be kinda peeved that Checkpoint is using their IP???

I'll bet Zedo would be kinda displeased that everyone using Zone Alarm's Firewall Update is knocking at their door.

Geez!!! Given Zedo's "rep", I'm SURE they've just totally discontinued using that IP for ANY REASON whatsoever.

Ohhhhhh.....

Wait a minute! "The IP means nothing!" Ah yes. So, in "DNSland" Zedo and Checkpoint just SHARE the SAME IP SIMULTANEOUSLY!

Ain't DNS wonderful! WOW! Nothing gets mixed up. It's kinda like magic. Every IP Packet knows just where it's supposed to end up, just by the URL!

Got it. The IP address is simply meaningless, 'cause the IP packet has a URL!

OPPPPs! Geeez.... wonder what happens if the sender of the packet doesn't use "no" URL and uses an IP instead?

AH! I know. They (Zedo and Checkpoint) BOTH get the IP packet, and the "listener" program (at Zedo and Checkpoint) simply decides to discard or accept IP packets in an arbitrary fashion.

Now THAT really makes sense. Thanks a bunch. Obviously, these guys just got "smushed" together by akami, cause akami is probably using every friggin IP address on the Net for itself! (lol) - T2 - (this is too much. lmao)" }-

Hi,

I was not joking.

Here's how you do it:

<VirtualHost site1.com:80>
ServerName site1.com
DocumentRoot /var/www/html/site1/
</VirtualHost>

<VirtualHost site2.com:80>
ServerName site2.com
DocumentRoot /var/www/html/site2/
</VirtualHost>

Thusly, you serve two completely different sites, with no relation to one another, whatsoever. Even if both sites are used on the same server, served from the same IP address. You have the DNS server handling the queries.

Thanks, LWM for the extra link, was too lazy to add it...

Mrk

[LowWaterMark]

Here's a treat for treat2 showing virtual hosting in action. Yes, I used exactly what Mrk is showing as for virtual hosting in my webserver here.

------------------------

Here's a demo of virtual hosting for you, to show how the host name included in the header will actually provide different content even though the exact same server is being accessed on the same IP address.

If you do an nslookup on wilderssecurity.com you'll see our IP address is 65.175.38.194

Now, I'm not about to set up and propagate DNS for this demo, so, you'll have to use your hosts file to make it resolve the hostname for you.

Add these lines to the top of your Hosts file:


#
# Treat2 demo
#
65.175.38.194 treat2.org
65.175.38.194 www.treat2.org


Now browse to http://www.treat2.org

Check your firewall logs or do a "netstat -an" to show that you are indeed connecting to IP address 65.175.38.194 and even though that is the IP address of wilderssecurity.com it is providing the demo page for the fictitious treat2.org, as well.

Akamai does this same thing except they have massive server farms spread all over the world and they use DNS load balancing to get the connections to various available servers in their server farms and use host names to determine what content to provide back.

[treat2]

-{ Quote: "Hi,

I was not joking.

Here's how you do it:

<VirtualHost site1.com:80>
ServerName site1.com
DocumentRoot /var/www/html/site1/
</VirtualHost>

<VirtualHost site2.com:80>
ServerName site2.com
DocumentRoot /var/www/html/site2/
</VirtualHost>

Thusly, you serve two completely different sites, with no relation to one another, whatsoever. Even if both sites are used on the same server, served from the same IP address. You have the DNS server handling the queries.

Thanks, LWM for the extra link, was too lazy to add it...

Mrk" }-

I figure that Checkpoint and Zedo are pretty liberal minded about sharing a firewall update distribution server address with another company infamous for spreading doggy pooh all over the Net. Go figure, eh? - T2

[treat2]

-{ Quote: "Here's a treat for treat2 showing virtual hosting in action. Yes, I used exactly what Mrk is showing as for virtual hosting in my webserver here.

------------------------

Here's a demo of virtual hosting for you, to show how the host name included in the header will actually provide different content even though the exact same server is being accessed on the same IP address.

If you do an nslookup on wilderssecurity.com you'll see our IP address is 65.175.38.194

Now, I'm not about to set up and propagate DNS for this demo, so, you'll have to use your hosts **** to make it resolve the hostname for you.

Add these lines to the top of your Hosts ****:


#
# Treat2 demo
#
65.175.38.194 treat2.org
65.175.38.194 www.treat2.org


Now browse to http://www.treat2.org

Check your firewall logs or do a "netstat -an" to show that you are indeed connecting to IP address 65.175.38.194 and even though that is the IP address of wilderssecurity.com it is providing the demo page for the fictitious treat2.org, as well.

Akamai does this same thing except they have massive server farms spread all over the world and they use DNS load balancing to get the connections to various available servers in their server farms and use host names to determine what content to provide back." }-


I "hear" ya.

Does it occur to you that doing this using DIFFERENT businesses, NOT A SINGLE BUSINESS WITH MULTIPLE SERVERS SERVING A SIMILAR AND OVERLAPPING FUNCTION.

One of the businesses USING THE SAME IP is a renouned dog-sh**tter that spreads spyware, and the other USING THE SAME IP is for the supposed purpose of Updating their Firewall, VIA THEIR OWN SERVER, not akami's, nor Zedo's.

Is it not just a bit "too much" to take this SAME IP FOR THOSE TOTALLY DIAMETRICALLY OPPOSED BUSINESSES as simply a coincidence?

(I hope I'm not seeming not a conspiracy theorist, but REALLY... this IS, too much to be expected to be cooincidental, when BOTH of these companies are using that same IP, and the "simple" URL is being used by some USERS on the Net, as a "trusted" site!!! Consider the consequences for the USER'S EXPOSURE, given that they are ASKING for a DOWNLOAD of an update to their firewall.)

BTW. The IP packets are NOT TRASHED, regardless of whether or not they have no URL. (That point should clearly be made AND ACCORDINGLY, THE CONSEQUENCES OF WHERE THOSE IP REQUESTS FOR DOWNLOADS ARE GOING, is also of relevance.)

I hear ya. However, I'm not buying the idea that just because it is technically possible to share an IP, that what's going on in this case it is a sheer cooincidence. THAT was and STILL REMAINS my ENTIRE POINT.
I leave it to YOU to decide if you figure its just nonsense, or their is something insidious about what's being done.

- Regards, - T2 -

[Mrkvonic]

Hello,

In that regard, the entire Internet is run by 13 servers.

So ... one way or another, good servers are on the same grid with the bad servers, so to speak.

What you're saying is that ZA could have called Akamai and said: oh noes, you have assigned us an IP that company X also uses. Now, in our kindergarden, we used to fight, so we can't have the same IP ...

And since you can create virtual network adapters, IP means little. The two sites could still physically sit on the same server and use different IPs and you'd be none the wiser.

Again, VirtualHost with 2 IPs, when you use eth0 and eth0:1 (virtual adapter entirely) to assign two different addresses to two different sites, both on your server.

Mrk

[treat2]

-{ Quote: "Hello,

In that regard, the entire Internet is run by 13 servers.

So ... one way or another, good servers are on the same grid with the bad servers, so to speak.

What you're saying is that ZA could have called Akamai and said: oh noes, you have assigned us an IP that company X also uses. Now, in our kindergarden, we used to fight, so we can't have the same IP ...

And since you can create virtual network adapters, IP means little. The two sites could still physically sit on the same server and use different IPs and you'd be none the wiser.

Again, VirtualHost with 2 IPs, when you use eth0 and eth0:1 (virtual adapter entirely) to assign two different addresses to two different sites, both on your server.

Mrk" }-

(Mrk. Just read you're note, and want to acknowledge having done so. I've made a final post, to wrap up my last word within this thread. So, feel free to respond as you please. Thanks for you feedback throughout. - T2)

[LowWaterMark]

-{ Quote: "I leave it to YOU to decide if you figure its just nonsense, or their is something insidious about what's being done." }-Well I'm sorry then treat, but, I have to decide that what you've brought up is indeed nonsense. We've all been trying to explain it to you, but you just don't seem to want to understand. You prefer to think its some sort of consipiracy, and that you've somehow found the smoking gun that no one else in the world has yet found - proof positive of some insidious deal between these companies. But, the fact is, you are simply wrong in the conclusion you've drawn from the data you've seen. And while no one wants to embarrass you, we can't allow a conclusion like that to go unrefuted when it contains such misinformation.

[treat2]

-{ Quote: "Well I'm sorry then treat, but, I have to decide that what you've brought up is indeed nonsense. We've all been trying to explain it to you, but you just don't seem to want to understand. You prefer to think its some sort of consipiracy, and that you've somehow found the smoking gun that no one else in the world has yet found - proof positive of some insidious deal between these companies. But, the fact is, you are simply wrong in the conclusion you've drawn from the data you've seen. And while no one wants to embarrass you, we can't allow a conclusion like that to go unrefuted when it contains such misinformation." }-

OK. Just a last, last post....

What you represented is entirely technically feasible, and done within many a Server Farm. However, what we have been discussing is NOT just a few thousand Web Servers that all are setup for scalability's sake for everyone to simple use a single function, such as for everyone to just "google".

THAT would be an appropriate use of a shared IP by ANY standard of System and Web Farm design, as ALL Servers perform the SAME function, and provide scalability, and redundancy.

On the other hand, what you propose as being an entirely legitimate use of a shared IP, SIMULTANEOUSLY TO PERFORM TWO ENTIRELY DIFFERENT FUNCTIONS is by no means, or in any fashion, a design for a scalable System requiring scalability of Web Servers, as in a Farm, which share the same purpose.

Even if you consider what you propose as being the sole purpose of the shared IP, you clearly do no understand what the purpose of a shared IP address is for, when speaking of the design of Scalable Web Applications and Systems. Instead, you conclude that the SAME IP CAN, COULD, AND IS legitimately used by entirely different Servers for different purposes. Thus, ignoring the treatment of IP packets which hold entirely dissimilar content, which originate with ONLY an IP being given, AND NO URL! - Forgetting this
is convenient, but it is not logical, nor is it how anyone designs Scalable Web Farms.

Akami, albiet a Web Farm can NOT stick 2 totally different businesses' Web Server's which themselves process and serve up totally different kinds of messages, for the simple reason that their is absolutely NO assurance that an IP packet will be sent given a fully qualified URL, as opposed to being specified with simply a shared IP, which IS totally legitimate, and NO System on THIS PLANET, would EVER be setup to REQUIRE 1 FROM "THE PUBLIC AT LARGE", but NOT the other!

Hence, you argument falls flat on its face from even the aspect of a Web and System Design point of view.

Sorry, but you've not at all proved anything, JUST BECAUSE it is TECHNICALLY feasible, as THAT IS TECHNICALLY NEVER DONE for the reasons previously stated. ONLY, another purpose could be served by having that same IP! THAT is exactly my point.

- Regards - T2 -

[fax]

-{ Quote: "OK. Just a last, last post....- Regards - T2 -" }-

Hi!
I am afraid to say but your discover show a good share of lack of understanding of how virtual hosting works.

Just go to ZA forum and search for 'akamai'. Every month or so, there is a new user coming up with this alerts/cryout/frantic discovery... it has been going on for years now (unfortunately) ::)

Errare humanum est perseverare diabolicum!

Cheers,
Fax
EDIT: For example, this message is dated back to 2006:
http://forum.zonelabs.org/zonelabs/board/message?board.id=security&message.id=16279

[LowWaterMark]

-{ Quote: "Sorry, but you've not at all proved anything, JUST BECAUSE it is TECHNICALLY feasible, as THAT IS TECHNICALLY NEVER DONE for the reasons previously stated. ONLY, another purpose could be served by having that same IP! THAT is exactly my point.

- Regards - T2 -" }-You seem to know a fair amount and yet you've still drawn the wrong conclusions.

In fact, you've even misstated my position. Where exactly did I say "...you conclude that the SAME IP CAN, COULD, AND IS legitimately used by entirely different Servers for different purposes." I never said in this case that the same IP was split across different servers. My position is that the same physical server can provide totally different content based upon how it is being accessed. The header information in the request is one way to totally vary served content. Also, they could be using different ports for all I know as another way to differentiate the content to serve.

You also said this: "Thus, ignoring the treatment of IP packets which hold entirely dissimilar content, which originate with ONLY an IP being given, AND NO URL!" Where are you getting that assumption from?

You start by running an nslookup using the name upd.zonelabs.com and yet you then assume that the updates are not being accessed using the name upd.zonelabs.com at all, just by the IP address. What's that based on? Have you run a sniffer on the programs to see exactly how they are connecting and whether they are passing distinctive head or access information?

In any case, my point is that you've taken a few facts and some knowledge of how things work, and then drawn an erroneous conclusion. Then when challenged you've thrown a lot of LOL, OMG and semi-sarcastic replies as if they somehow make your argument sound more credible while dismissing ours. Well, it doesn't work. It simply makes you look like you've got a gap in key knowledge that would explain how and why this can happen, and probably does across a lot more than just these few domains. Akamai mirrors content for countless thousands of companies, and I bet if someone took the time, the nslookups would find all kinds of overlaps in server IP addresses for sites and companies that likewise have nothing to do with each other.

[treat2]

-{ Quote: "...

In any case, my point is that you've taken a few facts and some knowledge of how things work, and then drawn an erroneous conclusion. Then when challenged you've thrown a lot of LOL, OMG and semi-sarcastic replies as if they somehow make your argument sound more credible while dismissing ours. Well, it doesn't work. It simply makes you look like you've got a gap in key knowledge that would explain how and why this can happen, and probably does across a lot more than just these few domains. Akamai mirrors content for countless thousands of companies, and I bet if someone took the time, the nslookups would find all kinds of overlaps in server IP addresses for sites and companies that likewise have nothing to do with each other." }-

Unless I've misunderstood your position, it has been that 2 companies within a Server Farm hosted by akami can share the same IP with no problem whatsoever.

That is entirely false, as I just stated above, So, I won't restate the reasons why that position is entirely false.

As far as my own position, it has remained effectively unchanged from the beginning, aside from the change from "c4" to "c5".

Zedo's Web Servers do NOT do what Checkpoint's Servers do. That is obvious to everyone.

Stating that Zedo and Checkpoint's Servers can share the same IP with NO PROBLEM whatsoever, is technically correct, but obviously a completely silly response regarding the essential fact that the Servers of these companies are NOT running similar systems, nor can an IP msg destined for ONLY the IP Address WITHOUT specification of the URL be dismissed as being irrelevant, because, as you or someone said, in effect, it's handled by akami's Server's.

Hogwash. The response to the point being made is dismissive of the most basic practices and purposes for scaling a specific system.

No.... Just because akami's hosts 10 billion servers does NOT mean that they can randomly assign IPs to ANY Server they please, because "it will work".
BS. It won't work, and you full well totally understand exactly what I mean, and the reasons why it won't work.

Perhaps it may sound as if I might know a little bit about this stuff as I've been in this field since '81, and have focused on communications programming in not only Mini's and Mainframes, but on PC's, as well, since 1993, before Microsoft even put a TCP Stack into Windows. It might also have a little bit to do with having worked on the programming, design (and more) of numerous systems well before and well after the words "2-tier" (etc.) and "scalable" systems became part of our lingo.

My friend.... if you own ZA, as I do. I would ask that you attempt to find a way to tell ZA to block out all of Zedo. C1 thru C7, as well as, www. with a .com and .biz suffix. If you can do so, AND AT THE SAME TIME, NOT BLOCK ZONE ALARM'S OWN WEB SERVER FOR UPDATES of the "Programs", I'm not even speaking of the anti-virus and anti-spyware downloads, .... THEN and only then, could you possibly ACTUALLY PROVE that this SHARED IP is entirely irrelevent. (BTW. Using the hosts **** is the normal method, rather than creating a half-million "Zone Rules" in a firewall), but be my guest and feel free to take that challenge using both ZA and the Hosts ****, or simply one of them.

Only then will YOU understand that what you claim can NOT be put into practice, or you will have entirely disproved everything I clarified in my previous post.

Take the challenge, and prove me wrong!

Cheers, - T2 -

[LowWaterMark]

-{ Quote: "Take the challenge, and prove me wrong!

Cheers, - T2 -" }-You're the one making the claim that "Zonelabs has teamed up with Big Brother." The burden of proof rests upon you.

What content exactly do you think ZA is pulling down from what you are calling a Zedo server? (And again, none of those servers belong to Zedo or Checkpoint - they belong solely to Akamai. Check the ownership of those IP addresses.) Are people not getting their ZA updates? Are they connecting to the akamai server for firewall, whitelist, anti-virus or whatever updates, and instead pulling down some nefarious content and yet ZA says: Update successful?

You've got an interesting history in the industry, but, you are still wrong on the conclusion you draw from basic content mirroring being provided by a third-party webserver farm.

[LowWaterMark]

As an aside, the main IP address used for Wilders Security Forums (65.175.38.194) also serves other domains, and it does it without ever getting mixed up as to what to serve to which request. We use virtual hosting here in our daily operations.

This one is just a placeholder, but is otherwise unused: http://www.securityhelpers.org/

And we've also got it set up to redirect to wilderssecurity.com, if someone browses by IP address:

http://65.175.38.194

I do that as a convenience, but, it isn't necessary. I could provide an error page instead, or default to a different domain.

[wat0114]

This is an interesting thread mainly because I'm learning (well, trying :) ) something. I'm often using Wireshark as a learning tool just to see what contents are contained in various packets. It is interesting to see that my MAC address is contained in outgoing packets. So I ask based on LWM's quote:

-{ Quote: " My position is that the same physical server can provide totally different content based upon how it is being accessed. The header information in the request is one way to totally vary served content." }-

... could this info be used by the hosting server to distinguish who is who when inspecting the header/packet information?

BTW, no offense treat2, but I tend to agree with LWM and others.

[LowWaterMark]

-{ Quote: "I'm often using Wireshark as a learning tool just to see what contents are contained in various packets. It is interesting to see that my MAC address is contained in outgoing packets. So I ask based on LWM's quote:

... could this info be used by the hosting server to distinguish who is who when inspecting the header/packet information?" }-Your MAC address does go out in the packets leaving your computer, however, it is striped out if that packet leaves the local subnet. As a router forwards a packet on to the next subnet, it replaces the original MAC address it had with the one of the next hops router. If it takes many hops to get from the source to the destination, the MAC address gets changed each time until the last router hands the packet to the destination using its MAC address. On the trip back, the same thing happens until the local router uses your MAC address again to get the reply back to you.

[wat0114]

Thank you LowWaterMark!

[treat2]

-{ Quote: "Your MAC address does go out in the packets leaving your computer, however, it is striped out if that packet leaves the local subnet. As a router forwards a packet on to the next subnet, it replaces the original MAC address it had with the one of the next hops router. If it takes many hops to get from the source to the destination, the MAC address gets changed each time until the last router hands the packet to the destination using its MAC address. On the trip back, the same thing happens until the local router uses your MAC address again to get the reply back to you." }-


The bottom line is this:

The IP address DOES (in fact) "matter". (Unlike what someone wrote earlier, that "it doesn't matter!").

The fact is that the Web Servers of both Zedo and Checkpoint are resloved to the SAME IP, and in doing so, ZEDO has a backdoor into the ignorant users of the Internet whom assign "trusted" Web Sites.

The fact is that EVEN 127.0.0.1 can not and NEVER should be "trusted", as THAT would permit Joe Blow to run whatever the hell he wants on your PC, as YOU have elevated the priviledge of that IP address, to trick your PC into thinking IT is "talking" to itself, WHEN IN FACT IT IS NOT! It is simply executing a Web Page that has within it "127.0.0.1" and the various malicious code to do whatever the hell it wants on 127.0.0.1, i.e. YOUR PC.
Unfortunately, virtually nobody on the Net is made aware of this fact, and not surprisingly, they end up with Web Pages executing and "planting" all sorts of crap on their PC, which the user themself gave that Web Page permssion to do, just because it is referencing 127.0.0.1

However, this little known fact is something Firewall Vendors don't mention, nor do any Web Sites make it well known, as IT IS COMMON PRACTICE for Web Pages to refer to "127.0.0.1" for a variety of purposes, mostly having to do with Javascript, which people FOOLISHLY permit to run in the "Local Zone", which they foolishly assign a very high degree of "trust" to within the settings of their Web Browser.


In any case, I'm straying from the point of this thread, which is rather simple:

The Web Servers of two different companies as in the case of Zedo and Checkpoint's ZA Firewall Download/Update Web Site have been assigned the SAME IP address, and THAT means that UNLESS THE WEB SERVERS PERFORM THE EXACT SAME "MISSION" (ie. that the Servers have the EXACT SAME functionality of disbursing ZA Firewall Updates) , which they CLEARLY DO NOT have, when the USER of Zone Alarm that attemps to download an update from upd.zonelabs.com, they will in fact be "talking to" which ever Web Server happens to "grab" the IP message that the user sends to it which requests a download for the ZA Firewall. (Naturally, as Zedo occupies the exact same IP, AND the http request is CLEARLY indicated by ZA's OWN FIREWALL as a failure to connect to http://upt.zonelabs.com because any Net-wise user should be blocking out all of ZEDO's Web Sites (for entirely obvious reasons), the DOWNLOAD FROM ZA WILL FAIL.

Not is there NO getting around that problem since the IP's match, and are passed in the IP Packet, but simply letting Zedo's download of some "free screen trial" which you can find in your Registration Database, as the Program they are intending to launch on your PC is totally foolhardy.

While it is common knowlegdge that IP's can be shared, what you state as being technically feasible and therefore totally irrelevant shows a considerable lack of understanding of Web Design, despite the fact that even a child could execute the same commands which you've shown are easily found on the Net.

Technical feasibility does NOT address the fact that the technical feasibility of these companies sharing the same IP simultaneously, is being used for insidious and malicious purposes by Zedo OR Zone Alarm. Whom is responsible is anyone's guess. However, either way. What remains is that ZA Users are NOT downloading the firewall "progarm update" they assume they are downloading, but are downloading garbage from Zedo.

Check your entire registration database for all occurances of "trial", if you attemted a download without blocking any of Zedo, you will find an entry
(which I deleted yesterday), that is makes reference to something like "trailscreens", except that is NOT the exact string, so simply search for trail, and you will find the http reference to the named site from where your PC assumes it came from, which CLEARLY is the same Web Site as Zedos
c5.zedo.com (modified with a few more qualifiers, when using a fully qualified Web Site Name.)

Beware of those whom want to sweep these facts under the rug, and attibute it to their claims of "my ignorance". Make up your own minds and DO BLOCK OUT Zedo.Com, as they CLEARLY distribute "crap" (a nice word for spyware) as thousands of Web Users reported and can be found via googling Zedo.com, as mentioned earlier.


BTW. This thread is NOT about NAT. Moreover, the origination of the request
is from the USER'S PC, NOT the Server, and THAT is why NAT can tell where to RETURN R E S P O N S E S TO. This is NOT about responses. This is ABOUT the ORINATING OF REQUESTS FOR DOWNLOADS FROM A SINGLE IP!

Do you even have ZA??? I suggest you attempt to block all of Zedo, and THEN look at the Error Message that is displayed. (Sorry, to find that out, you'll have do do the work yourself. -- I already know.)

BTW. THIS thread and my POINTS are not judged on "popularity" polls, of whom tends to agree with whom! As a rule, the Marjority is VERY Frequently, if not ALWAYS, entirely wrong.

The merits of the thread require some thought beyond the mere fact the more than to Servers or Web Sites can technically be assigned the same IP.
Sure they can. The fact is, that the dissimmilarity of what those servers deliver in response to users requests, not to mention the requests, and the responses, would be totally different, as the Servers do NOT Server the SAME s***.

Have you ever heard of DSN Poisoning? Do you know what it means, and WHY it is done?

Clearly, this is NOT DNS Poisoning. Rather, this is an INTENTIONAL MISUSE of Checkpoint's ZA Download Web Site. WHOM PERPETRATED the misuse is unclear, as their are SEVERAL entirely different motives that could be at play, not to mention the unlikely ignorance of the administrator at akami, which I personally believe is NOT the reason these two companies Servers have been in effect "joined together", unbenknownst to 99.999% of ZA Firewall Users whom do NOT bother to ever check their firewall logs, NOR even write "Expert Rules", and assume that ZA, and all the other garbage Firewalls out there ACTUALLY protect them after they slap it on their hard drive and walk away!

Ignorance is bliss, until they find out in a few days after picking up some "nasty garbage" (during their surfing) that their PC can be manipulated by any child that can read.

Best Regards, - T2 -

(EDITTED BY T2 AT 1:54AM EST)

[Mrkvonic]

Hello,

-{ Quote: "
The fact is that EVEN 127.0.0.1 can not and NEVER should be "trusted", as THAT would permit Joe Blow to run whatever the hell he wants on your PC, as YOU have elevated the priviledge of that IP address, to trick your PC into thinking IT is "talking" to itself, WHEN IN FACT IT IS NOT! It is simply executing a Web Page that has within it "127.0.0.1" and the various malicious code to do whatever the hell it wants on 127.0.0.1, i.e. YOUR PC.
Unfortunately, virtually nobody on the Net is made aware of this fact, and not surprisingly, they end up with Web Pages executing and "planting" all sorts of crap on their PC, which the user themself gave that Web Page permssion to do, just because it is referencing 127.0.0.1

However, this little known fact is something Firewall Vendors don't mention, nor do any Web Sites make it well known, as IT IS COMMON PRACTICE for Web Pages to refer to "127.0.0.1" for a variety of purposes, mostly having to do with Javascript, which people FOOLISHLY permit to run in the "Local Zone", which they foolishly assign a very high degree of "trust" to within the settings of their Web Browser." }-

What??

-{ Quote: "While it is common knowlegdge that IP's can be shared, what you state as being technically feasible and therefore totally irrelevant shows a considerable lack of understanding of Web Design, despite the fact that even a child could execute the same commands which you've shown are easily found on the Net.
" }-

Shows the considerable lack of understanding, indeed.

You see, Zedo, Kemo or whatever do not have access to the server logs. This is because these are not their logs. They belong to akamai and only akamai administrators can review them.

Thus, packets and going belong to no one, especially not to what you refer.

IP addresses are irrelevant in the context of your post, not in general. Do not turn my words around. In the context of your conspiracy - oh woes, they both share the same IP - yes in this case, the IP IS irrelevant.

And blacklisting IPs is a waste of time.

Mrk

[LowWaterMark]

-{ Quote: "You see, Zedo, Kemo or whatever do not have access to the server logs. This is because these are not their logs. They belong to akamai and only akamai administrators can review them." }-Indeed Mrk, that is the entire key to why treat2 is wrong. He thinks these IP addresses belong to zedo and/or zonelabs, and that some in-depth dialog is occurring between the customer's PC and these servers, passing data somehow to Zedo while doing ZA updates. He doesn't understand that all that is on the akamai servers in this case are static files that are accessed via simple HTTP for downloading.

And yes, it is definitely virtual hosting using Apache on the akamai servers, and the ZA users are only pulling static ZIP files down using the host name in the header, as we've mentioned above. I decided to use a sniffer and monitor an update process ZAF and see just what it is doing.

Here's a screen shot of the sniffer output...

200081

It starts as expected with a DNS lookup of upd.zonelabs.com. Number 1 is the DNS request and 2 the DNS servers reply. As expected, the DNS reply includes akamai mirrors for upd.zonelabs.com. The highlighted record (number 6) is the HTTP request from my PC by ZoneAlarm to the akamai server - yes, using the host name in the header as is the standard for Virtual Hosting. (That's shown in the lower highlighted section where it has "Host: upd.zonelabs.com")

All that ZoneAlarm is doing when it connects to the akamai servers during the update process is simply pulling down specific .ZIP files by host and filename. It starts with...

http://upd.zonelabs.com/zonealarm/online//Catalog.zip

That is the exact link accessed via HTTP protocol by ZoneAlarm and responded to by Apache running in a virtual hosting configuration on the akamai server. It's all shown in the sniffer log. (Attached at the bottom is a ZIP file (za-upd-session.zip) of the full sniffer log (a text file you can view in noptepad once unzipped) showing the update execution done by a new install of ZAF doing its first update download a few hours ago.)

The Catalog.zip contains a single XML file which simply lists all the latest versions of everything that ZoneAlarm might need to download - a list of the latest program modules, by version number, the anti-virus and anti-spyware definitions and so on. Anyone can download Catalog.zip from the akamai server, unzip it and view the XML file in notepad to see that.

Checking the versions listed in the Catalog.zip file, the one file that ZoneAlarm determined that it needed to update is indeed "update_TrialScreens.zip" So, the only other thing ZA downloaded, again by host and filename via virtual hosting from the akamai server, was the file update_TrialScreens.zip...

http://upd.zonelabs.com/zonealarm/online///TrialScreens/update_TrialScreens.zip

If you look inside that ZIP, you see it's a typical installer file containing the updates needed by ZoneAlarm.

ZoneAlarm downloads these by placing the host name in the header of its HTTP requests to the akamai servers. That is shown clearly in the sniffer log. You can use the links provided above to these two files and download them yourselves. But, you can not download them by using just the akamai server IP addresses. Virtual hosting is clearly in use on the akamai servers, and that is how it differentiates what files to download to which users.

This link fails...

http://72.246.52.14/zonealarm/online//Catalog.zip

200084

So does this one because zedo links don't access the same virtual host area or webroot on the akamia servers.

http://c5.zedo.com/zonealarm/online//Catalog.zip

This next link works because your HTTP request will include the host name upd.zonelabs.com in the header...

http://upd.zonelabs.com/zonealarm/online//Catalog.zip

So, as expected and stated above, the akamai servers are indeed using virtual hosting and require host name in the HTTP header in order to complete the requested file downloads. And all that ZoneAlarm is downloading is static ZIP files, accessed by specific filename and directory path, from the akamai mirror servers. No Zedo spyware. No secret communication dialogs between your PC and Zedo when you run a download. Just completely normal, static file content from an HTTP server that happens to be mirrored by Akamai for Zone Labs.

It is no different than my example using http://www.securityhelpers.org/ - try as you like, the only way to get to that page is to include the host name in the HTTP header because virtual hosting is inuse here on this server. You can not craft an IP address based access alone that will get you to the Security Helpers webpage.

-{ Quote: "Technical feasibility does NOT address the fact that the technical feasibility of these companies sharing the same IP simultaneously, is being used for insidious and malicious purposes by Zedo OR Zone Alarm. Whom is responsible is anyone's guess. However, either way. What remains is that ZA Users are NOT downloading the firewall "progarm update" they assume they are downloading, but are downloading garbage from Zedo." }-You are spreading unfounded and totally irrelevant FUD (fear, uncertainty and doubt) by implying anything untoward is happening in this process, and you show your lack of understanding when you make most of the claims you've posted above. No access to "Zedo" occurs - only properly formatted access to an akamai.net HTTP mirror that provides content on behalf of Zone Labs for ZoneAlarm users. Anyone can download any of these files any time they want and see exactly what is inside of them.

[treat2]

-{ Quote: "Indeed Mrk, that is the entire key to why treat2 is wrong. He thinks these IP addresses belong to zedo and/or zonelabs, and that some in-depth dialog is occurring between the customer's PC and these servers, passing data somehow to Zedo while doing ZA updates. He doesn't understand that all that is on the akamai servers in this case are static ****s that are accessed via simple HTTP for downloading.

And yes, it is definitely virtual hosting using Apache on the akamai servers, and the ZA users are only pulling static ZIP ****s down using the host name in the header, as we've mentioned above. I decided to use a sniffer and monitor an update process ZAF and see just what it is doing.

Here's a screen shot of the sniffer output...

200081

It starts as expected with a DNS lookup of upd.zonelabs.com. Number 1 is the DNS request and 2 the DNS servers reply. As expected, the DNS reply includes akamai mirrors for upd.zonelabs.com. The highlighted record (number 6) is the HTTP request from my PC by ZoneAlarm to the akamai server - yes, using the host name in the header as is the standard for Virtual Hosting. (That's shown in the lower highlighted section where it has "Host: upd.zonelabs.com")

All that ZoneAlarm is doing when it connects to the akamai servers during the update process is simply pulling down specific .ZIP ****s by host and ****name. It starts with...

http://upd.zonelabs.com/zonealarm/online//Catalog.zip

That is the exact link accessed via HTTP protocol by ZoneAlarm and responded to by Apache running in a virtual hosting configuration on the akamai server. It's all shown in the sniffer log. (Attached at the bottom is a ZIP **** (za-upd-session.zip) of the full sniffer log (a text **** you can view in noptepad once unzipped) showing the update execution done by a new install of ZAF doing its first update download a few hours ago.)

The Catalog.zip contains a single XML **** which simply lists all the latest versions of everything that ZoneAlarm might need to download - a list of the latest program modules, by version number, the anti-virus and anti-spyware definitions and so on. Anyone can download Catalog.zip from the akamai server, unzip it and view the XML **** in notepad to see that.

Checking the versions listed in the Catalog.zip ****, the one **** that ZoneAlarm determined that it needed to update is indeed "update_TrialScreens.zip" So, the only other thing ZA downloaded, again by host and ****name via virtual hosting from the akamai server, was the **** update_TrialScreens.zip...

http://upd.zonelabs.com/zonealarm/online///TrialScreens/update_TrialScreens.zip

If you look inside that ZIP, you see it's a typical installer **** containing the updates needed by ZoneAlarm.

ZoneAlarm downloads these by placing the host name in the header of its HTTP requests to the akamai servers. That is shown clearly in the sniffer log. You can use the links provided above to these two ****s and download them yourselves. But, you can not download them by using just the akamai server IP addresses. Virtual hosting is clearly in use on the akamai servers, and that is how it differentiates what ****s to download to which users.

This link fails...

http://72.246.52.14/zonealarm/online//Catalog.zip

200084

So does this one because zedo links don't access the same virtual host area or webroot on the akamia servers.

http://c5.zedo.com/zonealarm/online//Catalog.zip

This next link works because your HTTP request will include the host name upd.zonelabs.com in the header...

http://upd.zonelabs.com/zonealarm/online//Catalog.zip

So, as expected and stated above, the akamai servers are indeed using virtual hosting and require host name in the HTTP header in order to complete the requested **** downloads. And all that ZoneAlarm is downloading is static ZIP ****s, accessed by specific ****name and directory path, from the akamai mirror servers. No Zedo spyware. No secret communication dialogs between your PC and Zedo when you run a download. Just completely normal, static **** content from an HTTP server that happens to be mirrored by Akamai for Zone Labs.

It is no different than my example using http://www.securityhelpers.org/ - try as you like, the only way to get to that page is to include the host name in the HTTP header because virtual hosting is inuse here on this server. You can not craft an IP address based access alone that will get you to the Security Helpers webpage.

You are spreading unfounded and totally irrelevant FUD (fear, uncertainty and doubt) by implying anything untoward is happening in this process, and you show your lack of understanding when you make most of the claims you've posted above. No access to "Zedo" occurs - only properly formatted access to an akamai.net HTTP mirror that provides content on behalf of Zone Labs for ZoneAlarm users. Anyone can download any of these ****s any time they want and see exactly what is inside of them." }-

Yep! The link fails because the IP matters, the Web Site reference matters, and as I said. c5.zedo.com IS upd.zonelabs.com.

No mystery there.

Thanks for proving my point!

BTW. You didn't checkout the intended download, eh? Check that out, too!

Best Regards, - T2 -

[LowWaterMark]

Give it up, you're wrong and have been proven so. Saying my refuting of your points somehow proves your point is simply rhetoric for you trying to save face. And I did download exactly what ZoneAlarm tries to download when it runs an update.

[arran]

if in any doubt solution is simple, don't use zone alarm.

[fax]

-{ Quote: "if in any doubt solution is simple, don't use zone alarm." }-

Oh, yes.. he should also bin windows XP and VISTA.
Probably better to bin the entire PC ;D

Fax

[fax]

-{ Quote: "Thanks for proving my point!
Best Regards, - T2 -" }-

Proves what? That ZA teamed up with ZEDO?
It proves you completely missed the point. The point in virtual hosting is the data been transfered not the IP or http addresses been used. Data is unique and originating from the respective sources.

If this was not the case, I would end up installing the latest fancy screen saver instead of a critical MS KB patch or wakeup in the morning with with a nice spyware pop-up instead of the latest virus definitions.

Have you ever used a download manager? it is very roughly the same principle, data is retrieved from different sources to improve the process and speed of the download this is regardless of the IP or addresses used.

Probably you should rectify your misleading title from "Zonelabs Teams up with Big Brother" into "Virtual Hosting learning thread".... :)

Cheers,
Fax

[treat2]

First, I'd like to thanK the Administrator of Wilders for not having shut
down this thread, and having PERSONALLY taken the time to investigate and
confirm that what I've posted is true. Namely, that (more than one of)
Zedo.com's IP Addresses (hosted by akami) and upd.zonelabs.com (also hosted by akami) are in fact resolving to the same IP, resulting in DNS Servers around the globe resolving Updates to Zone Alarm to the several of the IP's shared by Zedo and the Zone Alarm Programs Update Web Site for their ALL of the users of the Zone Alarm products which go to "their" Zone Alarm Firewall "update Site".

Although it took 24 hours to reach a conclusion, and plenty of debating
various board members and the Administrator here (as well), my findings were
finally confirmed, as my "challenge" (posted in one of my posts above) was
finally taken, and proved out to be true.

For the everyday users of ZA the implications are enormous, as the average
ZA users do not know enough to not "trust" their own Firewall Vendor's Site,
(nor even 127.0.0.1, as I mentioned in an earlier post, and explained why
that should NEVER be done - even if localhost is assigned elevated
privileges. Again, the reasons for not doing so are also explained in one of
my posts in this thread in which I took the occasion to go off on a tangent,
for the benefit of the readers of this thread.)

It is my sincere hope that the Administrator of Wilders will be kind enough
to personally contact Checkpoint and possibly Akami, to explain to them the
effective DNS poisoning which may or may not have been done intentionally.
Personally, I hardly think that an akami Admin to be so dumb as to allocate the same IP to two different companies, as it would be akin to equating
www.bankofamerica.com to www.hackersRus.com, and not giving it a second
thought.

Naturally, we all know the reason that the legitimate allocation of IP's and
Web Site names is done in a controlled manner, as complete chaos would occur if anyone was permitted to allocate their own IP to match the IP of a Bank (for example).

Not surprisingly, the argument was made that assigning IP's to multiple Web
Servers is viable and legitimate.

Indeed that is so.

However, what the "posters" of such statements did not, and probably still
do not understand is the fact that this "device" was NOT intended for two
companies with entirely different "missions" and therefore having different
purposes in terms of whomever makes requests of their Servers, and what
responses those companies deliver MUST NOT share the same IP address, as
that would be totally incompatible with the PURPOSE of those different
Servers of those different companies.

Moreover, the proposal that IPs do not matter was also disproved in terms of
the context and intent of this thread which fully explains that not only do
the IP's matter, but the Web Site names, whether they are or not fully
qualified matter, and that in the case of Zedo and ZoneLabs Update Site, at
the present time, it doesn't matter if you use a "fully qualified Web Site
name, or not, as I initially explained that C4.Zedo.com (and www.zedo.com)
are both equating to the 2 different IPs being used by Zonelabs as their
Firewall Program Update Web Site a.k.a. upd.zonelabs.com.

Only a few seconds of research showed that Zedo's fully qualified Web Site
name for it's c5.zedo.com (not specified in this post, but which is given
above in numerous posts), ALSO equates to upd.zonelabs.com, and I have NO DOUBT that OTHER Zedo.com Web Sites fully qualified Web Site name ALSO equate to the 2 IPs that akami allocated to upd.zonelabs.com.

Perhaps the equivalence in the resolving of the Web Site names (fully
qualified or not) was done at the behest of an ignorant Administrator at
akami (which hosts the Servers of both companies). However, the rather
insidous nature of Zedo's "practices" on the Web can be confirmed by anyone
whom googles on Zedo.com, and looks through only a fraction of the 10's of
thousands of posts by folks on the Net whom were "infected" with a range of
"garbage" originating from Zedo.

Lastly, what leads one to further suspect "foul play" by Zedo and/or by Zone
Alarm's own Vendor is the fact that when one does NOT protect their own PC
by blocking out all of Zedo's sites, what one will find being downloaded
onto their own PC is some sort of "trialware" which can be easily found by
doing a search on your registration database (if you're a Windows user),
using the string "trial" (w/o the quotations). What one will find is an
entry for some sort of "trail screens" which a Command Prompt window will
attempt to install onto the unfortunate user's own PC. And there is little
doubt in my own mind that THAT attempt at installing some "trialware" was
originating from ZEDO.com, as it is a rather unlikely **** name to be used
for the temporary or permanent storage of any kind of legitimate Firewall
Update.

That Checkpoint (ZA's vendor) is involved is rather LIKELY, because despite
the shared IP address, that SOFTWARE is always downloaded. Thus, which ever company's Web Server happens to grab the assembled IP packets from ZA users which are asking for their ZA Firewall to be updated WILL ALWAYS GET THE SAME **** DOWNLOADED!

That would indeed suggest that both ZEDO and Checkpoint's Web Servers are BOTH delivering a **** to ZA Users in an insidious manner, and logically, it
can be concluded that the assignment of the SAME IP by an AKAMI Admin was NOT done out of the Admin's ignorance, but instead was done at the behest of Checkpoint AND Zedo, as BOTH Servers of these companies are delivering the SAME GARBAGE to ZA unfortunate users whom mistakenly are under the assumption that they are getting a legitimate Firewall Update.

Hopefully, Wilders own Admin will Contact Checkpoint, as well as, point out
to the user's of Zone Alarm as to what is currently going on with Zedo and
CheckPoint "sleeping in the same bed", to the unfortunate users of ZA's
Firewall, so as to alert the Public at large, Checkpoint, Zedo, and Akami,
the WE ARE ONTO THEIR SH**. And we KNOW what they are doing, and how they are abusing the trust that consumers of Zone Alarm have placed in their
Firewall, and in CheckPoint to deliver LEGITIMATE FIREWALL UPDATES, RATHER THAN GARBAGE WHICH CHECKPOINT AND ZEDO ARE DELIVERING INSTEAD.

Many thanks again to the Admin of Wilders for confirming for him/herself the
facts pointed out, and not loosing site of the fact that while an IP can
legitimately be shared, THAT is ONLY done in SPECIFIC CASES where it makes
sense for a Single Company's Web Servers to do so, RATHER THAN use a Static or Paid for Assigned IP or Ranges of IP's, as SHOULD BE DONE BY CHECKPOINT, but which they appear not to be doing for ILLEGITIMATE REASONS.

Despite it having taken 24 hours to have proved my point and for the Wilder
Admin to have confirmed the facts I stated as being true, I appreciate the
Admin having ultimately taken the time to do so, and engage in a sometimes
somewhat slightly "heated" debate over what is going on, and trust that
"face-saving measures" will not prevent the Admin from assisting the
community of ZA Users whom frequent Wilders for insights and advice.

Again, I consider Wilders to be one of the most reputable Security related
sites, and as the ZA Forum would have required my taking measures to lower
my security substancially, in order to post my finding to ZA, my first
thought was to reach a wide community of ZA and other users at this
reputable site, which does NOT require anyone take the extraodinary measures of lowering their Internet Security to a level that no one should do in ANY Forum on the Net.

Many thanks again to the Wilders Admin.

Best Regards, - T2 -

[LowWaterMark]

You are truly amazing! You have spread the LAST of your FUD here at Wilders Security.

You are completely wrong in your assumptions and your conclusions, and you are totally wrong about it somehow being DNS poisoning. That in fact is so absurd as to show you do not know what you are talking about. If you only had the slightest understanding of virtual hosting, you'd realize every conclusion you drew above was completely offbase.

And, regarding your statement about "trialware", sigh, Zone Alarm Free has the option to run a trial of the full ZA package for a limited time. The ZIP file "update_TrialScreens.zip" (which I provided a link to above, so that anyone can download and examine what's in it) is simply an update to what shows on the ZA trial screens. It is not some "trialware originating from Zedo". Another wrong statement on your part. (Just download the file and check it!)

Thread closed and member banned for spreading "false, defamatory and inaccurate" information on purpose in violation of forum TOS. (It's alright for a member to be mistaken in something they post, but, we will not tolerate the deliberate posting of false and defaming information of this magnitude.)