Results 1 to 7 of 7


  1. #1
    thoz Guest


    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 at 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, 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: Dest: SrcPort: 1032 DstPort: 80
    10111499 Packet DROPPED: Proto: IP_TCP Flags: 0x0000000a Src: Dest: 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, 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, (and a few others).
    I followed this with a rule (Verisign 1) to block all Traffic to the Verisign IP range to
    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 (, 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 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, 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: Dest: SrcPort: 1488 DstPort: 80
    44899492 Packet DROPPED: Proto: IP_TCP Flags: 0x0000000a Src: Dest: 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
    Software Version:8.0
    Product Name:ZoneAlarm Internet Security Suite

  2. #2
    prof_fate Guest


    Maybe you should Report your Findings Directly to ZA Tech Support..
    ZoneAlarm Tech Support and Customer Service do not
    Monitor this Forum..

    ZA Tech Support (Requires Valid ZA License Key)

    ZoneAlarm Security Suite version:
    TrueVector version:
    Driver version:
    Anti-virus engine version:
    Anti-virus signature DAT file version:965879481
    Anti-spyware engine version:
    Anti-spyware signature DAT file version:01.200812.5045
    AntiSpam version:

  3. #3
    Join Date
    Nov 2004


    Hi!on top of the suggestion to contact ZA support that are the only one knowing the internal functioning of ZA,I would also recommend to remove ZA. As soon as you start questioning connections from your security tool you are loosing confidence in it and you risk to fall in paranoia.Nothing worst than feeling unsecure or under threat with your primary defense line.Better to choose a tool you feel confortable with rather than spending time to block its connections.To avoid connection to ZA servers you will need to turn OFF most features that connect to ZA databases. These includes: Check for products updates, check for AV/AS updates, program control, SmartAdvisor, Privacy control, OS firewall, parental control, AV monitoring (in version 7), http spysite blocking, smartdefense community. Basically, not much of the security tool is left after this....Cheers,Fax

    Message Edited by fax on 12-20-2008 03:01 PM

    Click here for ZA Support
    Monday-Saturday 24x6 Pacific time
    Closed Sundays and Holidays

  4. #4
    Join Date
    Dec 2005


    The ZA updater for the firewall, antivirus and antispyware, spy sites, etc is written into the ZA's .xml files. It requires manually editing - but then do not expect the suite to do any further upgrades or updates.
    Kind of hard to avoid the updates if using a full security suite.
    Just my opinion, but not allowing the updates/upgbrades would be self defeating if wishing to keep the ZAISS fully updated. Unless you use another antiviral and antispyware/antimalware solution and disable the security scanners and other features which do need constant updating.

    If the expert rule is only for blocking the outgoing connections, then either switch the block rule to the Zones and not the Firewall Expert, or add an incoming block rule to the Firewall's expert. Also make sure not just the http is blocked but also any https, as the secure http is often used by the ZA for contacting it's own servers.

    " assists in the functioning of various services including the AlertAdvisor, antivirus updates, and antivirus monitoring. helps your client keep its services up to date. manages information relating to program configuration. manages the Program Advisor functionality. helps with updates to services and client functionality. supports the "Check for Update" functionality. handles product registration." helps your client keep its services up to date- this would include verifing the antiviral/spysite/antispyware is up to date, not just the ZA firewall version itself. (versions and exact dat/engine files should be second-checked by the ZA client/updater to ensure full and maximum coverage).
    Also note this is a very limited listing of the ZA web servers, but this is the most commonly seen by any ZA user in the logs (or a packet sniffer for that matter).

    You could try adding the to the Windows Host file. This should prevent any connections.

    Seeing just "TCP ACKs coming in from" and seeing not any SYN packets logged from or ACK-SYN sent from your windows/zone alarm? Got the ZA logging adjusted properly to log or log/and alert everything? (OT.. I do all of this except alert for the RST, instead just log, as this drives me crazy)
    Or did you mean TCP ack sent to

    Verisign has many IP/IP ranges on the internet besides the range you show.
    Verisign still does some ARNIC duties (originally the first or one of the first for ARNIC) and is a massive cached server system (like akamai and others), besides doing the browser certificates (there are many other companies doing browser/root certificates, not just verisign).
    What probably happen or why the site gets through?
    The visited site did the certificate/authentication from it's own IP into the browser - even though the verisign site is the original issuer. Basically verisign is then seen as a third party site easily obtaining direct access similar to that of a proxy ....not an actual proxy in the true sense, but what a proxy does by avoiding the filters and IP blocks of any software firewall, like using Google translator for a site blocked in the ZA, but google is in a sense is "proxying" the connection - since the google site is allowed, what google translate can go to will be accessed, regardless if the sites are blocked in the firewall (any firewall including the ZA. Basically to block verisign site off you instead need to block off the site web involved that initiated the verisign connection into your browser.

    You want the best way to block off the verisign for the certificate's connections? Then adjust your browser's settings to not use certificates (which I would not advise as this is a serious security risk) or set the browser to ask for installing downloading certificates (this way you still have manual control instead of allowing the browser to automatically update it's certificates). Or set the browser not to use verisign and then use another site for the browser. This should put a stop to the verisign connections.
    Again the issue of the regular http and secure http come into play for the verisign. As any fitering on the secure http level is very difficult for almost all web filtering applications (software firewalls or web scanners of the antivirus or localhost proxies for filtering, etc), as opposed to the regular http. If the traffic is encrypted (it can not be read by any stately packet inspection firewall - ZA or any other brand of firewall) by https and there are third party connections involved with the https, then these are not filtered by the software firewalls or web scanners of the antivirus or localhost proxies for filtering, etc (this includes the Privacy of the ZA or any other brand of firewall with content filtering).
    (this does help explain why google and others are using trackers/cookies/etc for the https, besides getting more coverage, it does pose a small security issue).

    NOTE: HTTPS (http secure) can be completely filtered by DPI (deep packet inspection) type of firewalls, but these are mainly commercial/enterprise applications which are neither cheap or really needed for a home use. (and some proxy firewall)
    But the internet connections become extremely slow as a result of the DPI, as DPI is best applied towards hardware firewalls where it is done more efficently, and with much higher speed connections; and not the home user's desktop software firewall.


    Message Edited by Oldsod on 12-21-2008 01:40 AM
    Best regards.

  5. #5
    Join Date
    Dec 2005


    Silly me.
    I signed out of the forum and then saw the nslookup command windows still sitting in my windows task bar. Suddenly I remembered why I signed in tonight at this time and hour in the very first place.

    Okay the shows as:



    There is a difference between the two IPs.
    There is the "virtual host server" factor to take into account - any given IP can be hosting numerous domains.
    And there is the cached servers factor - these could be hosting other domains and reverse lookups for other IPs.
    Plus the internal system of the verisign is not neccessarily static either - the files could be changing/switching from internal domains and IPs even though the external or the internet IPs remain the same/constant.
    Plus these IPs could be changing anyways as decided by verisign and by the domain registry offices. Static IPs for web servers do change from time to time. This makesg blocking by the user/admin difficult at times - yeah I know this is very much going off on a tangent, but it does factor in on some occassions.

    (0r also known as

    Just to add more to the confusion.

    Sometimes the IP that is supposed to be really involved isn't. Instead the domain name is still used best as it's IP maybe not static after all in the end - when it changes from the IANA or the territorially registry assigned IP to a different IP from another server. <hr>

    Also recently IANA re-allocated or changed the "IPv4 Global Unicast Address Assignments".
    Like this:

    110/8 APNIC 2008-11 ALLOCATED
    111/8 APNIC 2008-11 ALLOCATED

    This means the previous owners of those IPs have been moved around or allocated new addresses and some new owners moved instead. The internet IPs for web servers and domains is usually assumed to be static, but this is not true in many cases. The internet addresses are in a constant state of slow flux.

    (to confuse the matter even more and go further off tangent from the subject, there are also "Bogons" see and "Domain parking" see issues. Not really directly involved in this thread, just decided to really mix up this particular reply.)


    Message Edited by Oldsod on 12-21-2008 02:59 AM
    Best regards.

  6. #6
    thoz Guest


    OldSod : Thank you for the response.

    You said: The visited site did the certificate/authentication from it's own IP into the browser - even though the verisign site is the original issuer. ....... Basically to block verisign site off you instead need to block off the site web involved that initiated the verisign connection into your browser. That is exactly my problem. I don't want a site I visit to establish any secure connection, until I can see what they are trying to connect me to and research the site if I choose. I think you are telling me that it is not possible to control this with the firewall. Is this correct? And why do you think the log lies about it?

    I will contact Opera tech support about certificate downloading options and take a look at some of the referenced Wikipedia sites. I also am using a slightly dated version (9.27) which doesn't have Extended Validation. I tried Opera 9.5 with EV for a while, which really made me feel insecure, so I removed it.

    I had already updated the host file, and it seems to work OK, although the expert firewall won't log the connections to, which is annoying. I also have copied all the expert firewall rules back into winlogon.exe, UserInit.exe and Explorer.exe rules. It appears from the forum that many other ZA Users have resorted to this. Of course, now every time I want to go to a new web site, I have to add four firewall rules to allow it. As a result, I have reduced my internet usage to a handful of trusted sites.

    Fax: You are quite right, but unfortunately my paranoia extends well beyond ZoneAlarm. The firewall is only as good as the operating system and the web domain name system. I suspect that there is no Windows firewall that will really give me control over my internet connections. And as far as I know, ALL the Windows firewalls require download from an Akamai website. If you know of one that doesn't, please let me know.

    I already tried Symantec. Their firewall also lies about HTTPS connections. I asked them about it. They requested all kinds of data, which I duly sent. No response. I sent more e-mail. They asked me to copy the info to some outside &quot;consultant&quot;. I did. Still no response. I sent them a couple more e-mails. They finally answered Just Allow all HTTPS.

    Functionally, ZA is a huge step up from Symantec. I don't want to stop all communication with ZA, I just want control over it. Updates are fine. Automatic updates are not. Controlled TCP Outbound is fine. Open TCP inbound is not. E-mail is fine. Messenger is not. Fixed IPs are fine. Akamai is not. I called ZA Tech Support, told them I didn't want to use an Akamai website or Messenger, but that I would be happy to send them a detailed e-mail with kudos, questions and complaints about ZA. They declined to give me an e-mail address. This is a deliberate Catch-22 for users. To lodge a compaint about web practices, you have to log on to the very web sites you wish to avoid.

    I am convinced that Microsoft and the ISPs like Akamai have deliberately restructured the Web and Windows to make sure users can't determine where they are being connected, can't control their internet connections, and can't stop their marketeers from collecting and selling user data. I think Microsoft is deliberately undermining all the Windows firewalls. I also think the NIO and NSA and Homeland Security have (at the least) encouraged this lack of transparency so that users can't block redirections to their sites. Web 2.0 has become a public/private partnership to monitor and control the end-users - a Faustian bargain between the spies and the marketeers.

  7. #7
    Join Date
    Dec 2005


    Opera can be set to Ask for the site certificates instead of the default allow action for the server certificates.
    In the Tools | Prefereneces | Advanced | Security | Manage Certificates | Authorities | then make your selection and then click the View, uncheck the "allow connections to sites using this certificate" and check 'warn me before using this certificate".
    Very simple and problem is solved. Just ensure you do this for all of the certificates stored in the Opera.
    Opera 9.63 is out and this is a good release (for me anyways but I am anticipating the new improved final Version 10).

    Firewalls do not control the certificates nor the server's connection for the certificate once that server is allowed to be connected by your browser. The certificates belong to the realm of the browser, not the firewall.
    Firewalls are still using basic Allow or Deny actions and the closest thing there is to using an Ask is the Ask setting in the ZA.
    Plus the connections are logged so the title of thread is incorrect - I always see the crl sites involved in the ZA logs, I can not see why do not see the sites involved.
    These are crl sites are very blockable, but you would have to include all of the sites used for the crl involved sites (not an easy feat - not meaning the actual akamai servers and the virtual servers but all of the IPs involved for the crl sites and any other IPs used by the certificate server, as they more than likely balance the load between their own network and their sub network, making the actual blocking a hard task. But not impossible to do with a firewall).

    Loopback can be logged - if it is set for logging in the expert for the program and the default trust zone for the loopback is removed. And every program using or needing the loopback is then setup with log using the expert rule. Basically it involveds removing the default "globally" allow the loopback in the Zones and then entering an expert rule for all of the involved programs. And at this point you might as well finish the job and then go further and create the rest of the program expert rules and expert rules for the Firewall.
    (I do this and basically got it finished all in the same night, and worked out a few of the bugs and quirks a little later on - but I now undersand as a result the quirks of the ZA.
    But the actual connections to the host file will still not be seen.

    " As a result, I have reduced my internet usage to a handful of trusted sites"

    I do not understand what you mean by this.
    And also there is no need to log and alert every windows file involved - just the browser alerts and logs should be sufficent to see what is involved with the connections. (usually the final block all rule at the end of the program's expert rule set is needed for debugging connections and issues).

    PLUS there are more than just four windows files involved that are "parent" programs with the "child" programs actually involved with the connections.

    Firewalls and update servers (or cached servers such as akamai)?
    My ZA does not do anything unless I tell it to - I neutered it.
    A few reg hacks and a little file editing is what is needed.
    (which I will not get into discussing any further)
    That also includes specific expert rules for the particular za files.

    "They finally answered Just Allow all HTTPS. "
    HTTPS is encrypted and the body of the those packets can not be read or deciphered by a firewall. Just the header packets and the end packets can be read by a firewall.
    So yes it is basically allow or not allow type of situation.

    Akamai Technologies is not an evil entity.
    It is a cached server system or properly named delivery content (but is actually a mirror server) which also is providing load balancing for the web.
    Still do not really understand why you avoiding the akamai servers (whose servers are also often used by MS to update all windows systems).
    And akamai is not the only such service - there are many other cached and virtual servers on the web (not to mention the numerous sub domains readily available for any internet IP to have internet access).

    The email address for the Customer and Technical Supports are seen in my signature below.
    No secret there.

    "NIO and NSA and Homeland Security".... I will tell you right now probably would never use akamai servers. Or even there own servers to perform any sort of external spy adventures or spy deeds.
    It would not make any sense to be that easily traced back to their own servers and even let their secrets or information be stolen by others (this could be accomplished) at the ame time.
    These particular divisions of society would instead use unassuming and relatively unknown servers for such work the work.
    Even though you are afraid of akamai, understand the entire internet is made up of data.
    Every server and internet router has logs and records - of all kinds of data from almost every one. This is the age of information granted to us by computers.
    All servers whether it is your provider's servers, the route servers or the backbone servers of the internet, the dns servers, the ad/tracker/counter servers or the server to which are connected to at the final destination - all have logs and records the connected computers (and to a degree the user themselves).
    As far as any tracking or recording by the "NIO and NSA and Homeland Security" goes - they would not need to use any server. Instead they would probably use an invisible hardware device (no MAC) to get the wanted IPs routed directly into their devices and out back to the route tables and then they could record all the packets they want to. This would be all unseen by anyone.
    This would be very silent and known only to themselves.

    As far as tracking and selling the data about users goes - you use firefox?
    You do know every search made in the browser already has a browser referer included in the search url - and this would include your IP, browser version, windows versions, etc? This first track made before the search engines tracked and logged the search. Every web server you connect to makes a log of the incoming connections - and the IP, browser version, windows versions, etc is included.
    Ditto for the site trackers and counters, which could be in the form of a javascript file from google urchin, or a web bug, or an iframe, or even the a gif/swf images seen in the ads/banners/etc or even using invisible gifs.
    I filter a lot of things out to help protect my own privacy on the web, but a lot still gets by anyways - it can not be avoided.


    Message Edited by Oldsod on 12-31-2008 05:22 AM
    Best regards.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts