The ZONEALARM "Expert Firewall" apparently refuses to block or log certain sites.
I posted this complaint once before but it was removed.
A recent forced Microsoft auto-update (even though Windows Autoupdate is off and the autoupdate service is disabled) appears to have made changes which affect this.
ZA connected to hs2.zonelabs.com at 188.8.131.52 immediately when I went on line (home wireless to COMCAST). I had created an expert firewall rule (ZA HS2 OUT) to block, log and alarm this. This didn't work, so I had created a blocked zone for the ZA IP range. This once seemed like it worked. But now I see TCP ACKs coming in from hs2.zonelabs.com, when no outbound TCP is recorded. The log indicates that blockage of the incoming ACKs is triggered by the rule "ZA HS2 OUT" and the policy is listed as
A subsequent rule to block ZA HS2 incoming was apparently not triggered. There is no record of the outbound TCP and no alarm.
Here is the FWPacketLog info which indicates that even though the outbound packets were supposedly dropped, an ACK was received:
10111499 Packet DROPPED: Proto: IP_TCP Flags: 0x00000005 Src: 192.168.1.101 Dest: 184.108.40.206 SrcPort: 1032 DstPort: 80
10111499 Packet DROPPED: Proto: IP_TCP Flags: 0x0000000a Src: 220.127.116.11 Dest: 192.168.1.101 SrcPort: 80 DstPort: 1032
So a ZONE BLOCK also now fails to function. There appears to be no way to block this site. Also, a zone block on Verisign now fails (contrary to my original posting below.)
Can anyone explain precisely what
is, who owns it, why it would require me to connect with hs2.zonelabs.com, and why the log lies about blocking it? Is the policy posted somewhere?
Also, Is there a list of these unblockable and unlogable sites? Should I blame Microsoft, ZA, the NIO or all of them for inserting these backdoors into my system?
Can anyone recommend a good sniffer?
__________________________________________________ __________________________________________________ _________
Following are details from my original(deleted) post. The failure to block key-delivery sites is particularly serious since it could allow any host site you visit to force a key exchange behind the firewall.
I created a rule to Allow HTTP (80) and HTTPS(443) connections to my bank (two Host sites).
I followed this with a rule (OCSP) to block all traffic to named sites ocsp.verisign.com, ocsp.verisign.net (and a few others).
I followed this with a rule (Verisign 1) to block all Traffic to the Verisign IP range 18.104.22.168 to 22.214.171.124.
I followed this with a rule (BLOCK ALL) to BLOCK all Traffic (ALL Protocols, All Ports, ALL sites.)
All the rules were set to Log and Alarm.
The log reported that the rule "OCSP" blocked a connection to ocsp.verisign.net (126.96.36.199, although it can vary). However, my Opera browser received the keys, showed the certificate information, connected via HTTPS,and I successfully used the keys to log in to my account.
So the firewall failed to block ocsp.verisign.net and the log lied about it. No alarms occurred.
When the rule "OCSP" was disabled, the firewall reported that the rule "Verisign 1" blocked the site, but it did not.
When the rule "Verisign 1" was also disabled, the firewall reported that the rule "BLOCK All" blocked this site, but it did not.
I tried IP and Host based Program rules for Windows Explorer and they also reported blockage, but failed to block.
It appears that connections to other key-delivery sites are treated similarly. I haven't tested many of these, but I had similar results with another site which used a GTE Global Trust root certificate and a CA intermediate site. I also tested www.Pandora.com, which uses Flashplayer to go secure using a Verisign key. Same results.
It appears that the expert rules also fail to block connections to several Akamai Technologies sites. The logs report a number of cases where the outgoing TCP to an Akamai site is supposedly blocked, but a TCP ACK is received (and also supposedly blocked, which somehow I doubt).
Here is one sample from the log:
44899492 Packet DROPPED: Proto: IP_TCP Flags: 0x00000005 Src: 192.168.1.100 Dest: 188.8.131.52 SrcPort: 1488 DstPort: 80
44899492 Packet DROPPED: Proto: IP_TCP Flags: 0x0000000a Src: 184.108.40.206 Dest: 192.168.1.100 SrcPort: 80 DstPort: 1488
Creating a blocked zone to block the Verisign Range does seem to actually block the key exchange. However, absolutely nothing is recorded in the log indicating the blockage (Even when the Program settings are set to show an alert every time program access is denied). So if you use this technique, visit a site, and it fails to connect you via https, there is no way to tell what was blocked.
Operating System:Windows XP Home Edition
Product Name:ZoneAlarm Internet Security Suite