[Resolved] filtered by ABE: <LOCAL> Deny

[wxman1]

I just update by browser to FF based v48.0.0.1 Comodo IceDragon and got this blockage:

GET "http://"widget.quantcast.com/p-e2qh6t-Out2Ug/10 <<< "http://"widget.quantcast.com/p-e2qh6t-Out2Ug/10, "http://"www.drudgereport.com/ -7) filtered by ABE: <LOCAL> Deny

What's LOCAL 'bout that? Do I need some sorts of SELF rule? Or is this a surrogate issue, i.e., wrt quantcast, so its pointing to the host? I never seen that before. I looked in the browser console, but didn't see anything related to ABE. Of course may not be lookin' at the correct tab output.

[barbaz]

IceDragon is not a supported browser, please test Firefox 48 and let us know if the issue occurs there.

(IIRC those Comodo browsers try to use their own DNS. Glitches in DNS can wreak havoc with ABE..)

[wxman1]

FWIW: I'm not using Comodo Secure DNS; Drudge had been reported as a malicious site preventing navigation to it. Furthermore, I've not had ANY prollems with NoScript / ABE and I've been using IceDragon since FF base v26. Moreove, given that I'm zipped tight as a drum with CIS proactive paranoid HIPS / FW, I've NEVER seen a peep of malicious activity at Drudge.

The page seems to function o.k., just have the blockage message at the top.

[barbaz]

FWIW: I'm not using Comodo Secure DNS;

Not saying that's the only thing that could cause a IceDragon-specific problem, only suggesting one possibility of what might be happening in this case.

I've NEVER seen a peep of malicious activity at Drudge.

Being tightly protected from compromise will *not* always make you unable to see malicious activity trying to happening. Maybe you've just been lucky for a while.. unfortunately every streak of luck runs out at some point. Just sayin.

The page seems to function o.k., just have the blockage message at the top.

The ABE notification showing in this circumstance is a known bug: viewtopic.php?f=23&t=18996
If you reproduce the problem in a supported browser, can you please check the Browser Console (Ctrl-Shift-J) when this issue happens and post here the message(s) from ABE?

[wxman1]

Thanx for the URL to the known prollem discussion; searching is not a function / feature, its an art.

I know that nothing is bulletproof, that's why its call Host Intrusion Protection and not Prevention. But I'd be seriously impressed that anything can penetrate CIS HIPS / FW; nothing can move on the system without appropriate permissions - default block - and an alert and log entry would be generated. To reiterate, I've never seen a clue of any even suspicious activity from Drudge. But then I've been using NoScript which blocks any JavaScript by default. That inherently mitigates the drive-by-download threat vector. Even if something gets onto the system, something has to execute it - unless its self-executing which will require permission to do so - and whatever is doing the downloading has to have permission to the destination, and then not only execute rights but such rights IN the destination, and then whatever it is having been executed has to have permissions to do anything. O.k., enough of that.

Frankly, the issue should be easily enough reproduced in default supported browser platform; you just going to Drudge should reproduce it easily enough with default ABE SYSTEM rule-set. I don't have a second browser intalled and am disinclined to install another. That being said, what am I spoda look at in browser console? Which tab is of interest that will contain a bloody knife if one is to be found; everybody knows that 'smoking gun' is just way over the top too dramatic cliche.

[barbaz]

I know that nothing is bulletproof, that's why its call Host Intrusion Protection and not Prevention. But I'd be seriously impressed that anything can penetrate CIS HIPS / FW;

Right, you'd see it trying and failing.

Frankly, the issue should be easily enough reproduced in default supported browser platform; you just going to Drudge should reproduce it easily enough with default ABE SYSTEM rule-set.

I can't reproduce the problem, something outside my browser is killing Drudge almost completely, turning it into a massive wall of all-caps text It did try to load the quantcast frame alluded to in the OP, but unblocking that didn't trigger ABE for me.

So we need to figure out whether it's because of IceDragon, or what DNS lookup of widget.quantcast.com returns on your machine, or something else.
Is the domain listed in your HOSTS file? If not, please post the full output from using nslookup (or dig, if you have it) to look up the domain.

I don't have a second browser intalled and am disinclined to install another.

Same here. That's part of why I run VMs.

Also, Firefox Portable.

That being said, what am I spoda look at in browser console? Which tab is of interest that will contain a bloody knife if one is to be found; everybody knows that 'smoking gun' is just way over the top too dramatic cliche.

It's a JS message that starts with "[ABE]" and looks like a more detailed version of the notification message.

[wxman1]

Seems as if this is the prollem chil':

iframe frameborder='0' scrolling='no' marginheight='0' marginwidth='0' height='120' width='200' src='http://widget.quantcast.com/p-e2qh6t-Ou ... '></iframe>

After reading the Bug Thread, I toyed around a bit and settled on this solution:

Deny INCLUSION from www.drudgereport.com

Added to the stock SYSTEM ABE rule-set and the The "problem" ABE block notification goes away. My embeddings are:

Forbid Java
block every object from untrusted source

Moreover, I untrusted both QuantServe & QuantCast. That's when I noticed that NS isn't complaining about QuantCast, but its being intercepted by NS ABE deny LOCAL of a redirect. WHY argue with success, and who cares WHY its working now. I LIKE works now. Although always-worked is much better, but, meh, I take what I can get.

Then you said HOST file. I used to update HOST file from http://winhelp2002.mvps.org/hosts.htm supplemented with additional entries per SpyBot Search & Destroy Immunize. Guess what? All the various incarnations of Quant servers are mapped to 127.0.0.1 in HOST.

[barbaz]

Then you said HOST file. I used to update HOST file from http://winhelp2002.mvps.org/hosts.htm supplemented with additional entries per SpyBot Search & Destroy Immunize. Guess what? All the various incarnations of Quant servers are mapped to 127.0.0.1 in HOST.

And there's the prollem chil'.
Firing requests at your local computer is a horrible idea especially for stuff you want blocked for security reasons. ABE is saving you.

The solution is to change all those entries to 0.0.0.0
https://hackademix.net/2009/07/01/abe-w ... where-omg/
(Note: do *not* use 255.255.255.0 as suggested in that article, when I tried that it caused MASSIVE slowdowns)

[wxman1]

0.0.0.0 Huh. That's interesting, considering, per the MVPS web-site hosting the HOST file parasite protector:

Important Note: The HOSTS file now contains a change in the prefix in the HOSTS entries to "0.0.0.0" instead of the usual "127.0.0.1".
This was done to resolve a slowdown issue that occurs with the change Microsoft made in the "TCP loopback interface" in Win8.1.

This change in the prefix should not affect users. I've had some feedback that COMODO antivirus, Homer Webserver and System Mechanic seems to have issues with the "0.0.0.0" prefix ... to resolve this issue:

You can use the "Replace" function in Notepad to convert the entries, or HostsMan (see below) has an option for converting the entries from "0.0.0.0" to "127.0.0.1.

Since I AM using CIS integrated w/ Comodo A/V, I deliberately changed default 0.0.0.0 URI mappings to the 127.0.0.1. The thing is I've thought about scrapping HOST completely given that I've got bullet-proof hair-root frollicals. But, I can just hear my infosec instructor wagging his finger at me, but you KNOW the #1 principle of infosec is defense in depth: backstop your backstop your backstop your backstop your backstop your backstop your backstop and your A/V is your final defense, and if that's the interception, HAIL MARY; its ON and / or IN your system. Failing efficacy of A/V eradication, NADA. So, I don't know, maybe not so much.

[barbaz]

"issues" is a bit vague, did you actually try 0.0.0.0 and have something specific bad happen?

Otherwise, I would suggest you leave the default SYSTEM rule the way it was default, and then add this at the very top of SYSTEM:

Code: Select all

# comodo av hackery - try to work around ABE notification bug
Site 127.0.0.1
Accept from SELF+
Deny INC

This way you shouldn't have to keep tweaking ABE if your goal is only getting rid of the erroneous notification.

Does that work?

[wxman1]

I don't like "issues" waiting in the wings. So I just global replaced 0.0.0.0 to 127.0.0.1 to avoid "issues".

I've been lax in keeping HOSTS updated - its a pain - and it hasn't been updated since 2014; I've been using NoScript. About when I got sick & tired of IE8 being obsolete, tried IceDragon and once I discovered Stylish I was hooked; the lack of any need to maintain a blocked IE downloads CIS HIPS rule-set - to protect against drive-by-downloads - was the clincher. With NoScript JavaScript blockage, that crap just don't happen. I've encountered ransomware web-pages several times. IceDragon just laughs at that crap; it ends up essentially toothless old hag of a static HTML web-page that can be closed with impunity.

The thing with the HOSTS file from MVPS is that its only as good in so far as it goes. Spybot Search & Destroy has the immunize feature - which adds nefarious URI to the Restricted / Untrusted IE zones - which FF based browsers avail themselves of in addition to URI not found in the MVPS base HOSTS file. However, that entails running the MVPS IE Restricted / Untrosted zone INF before S&D immunization; that clears out any blocked URI that are no longer valid. Otherwise its plausible that there can be blocked stuff in the registry that's not in the HOSTS file.

Anyways, I figure I'm still going run with that rigamarole; NoScript will be a good backstop for scripts and ABE for stuff that NOT in HOSTS.

[wxman1]

...I would suggest you leave the default SYSTEM rule the way it was default, and then add this at the very top of SYSTEM:

Code: Select all

# comodo av hackery - try to work around ABE notification bug
Site 127.0.0.1
Accept from SELF+
Deny INC

This way you shouldn't have to keep tweaking ABE if your goal is only getting rid of the erroneous notification.

Does that work?

After updating HOSTS with current MVPS file, updating SpyBot S&D defs, purging IE Untrusted/Restricted zones, running S&D Immunize - all malignant URI in HOSTS now mapped to default 0.0.0.0 - and making NS ABE SYSTEM rule-set look like:

Code: Select all

# comodo IceDragon - try to work around ABE notification bug
Site 0.0.0.0
Accept from SELF+
Deny INC from www.drudgereport.com
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

I no longer have the ABE LOCAL block alert at Drudge. Deny INC w/ out URI doesn't work. However, I've the same problem here, but with c.bing.com:

https://support.microsoft.com/en-us/kb/919746

I checked HOSTS: c.bing.com is in the HOST file mapped to 0.0.0.0 - I wonder why that's in there; who'da thunk bing is a prollem chil' Notwithstanding any of that, the support.MS ABE LOCAL block can't be suppressed; I added c.bing.com URI after www,drudgreport in the Site 0.0.0.0 section, and added stand alone in the default LOCAL section where I originally got DrudgeReport ABE LOCAL block alert to cease. This "error" is a different animal than Drudge "error".

[wxman1]

Dunno, but I can't find c.bing.com in the page source. The other thing is that c.bing.com isn't a URI listed in NoScript icon pop-up. I see it listed in recently blocked sites. But when I allow it, it still doesn't show up as an item to forbid.

Here's the ABE low-down from browser console:

Code: Select all

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=6EDE2F15631544B8AFE330968D601B0E&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111" on a secure page

[ABE] <LOCAL> Deny on {GET http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=6EDE2F15631544B8AFE330968D601B0E&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=DC323283950F4123ACC7F73E7F228DE0&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111" on a secure page

c.microsoft.com : server does not support RFC 5746, see CVE-2009-3555

[ABE] <LOCAL> Deny on {GET http://c.bing.com/c.gif?&ctsa=mr&CtsSyncId=DC323283950F4123ACC7F73E7F228DE0&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

[ABE] <LOCAL> Deny on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&ctsa=mr&CtsSyncId=0A93C901A2F2451982B80340CE1D45E8&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 7}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

[ABE] <LOCAL> Deny on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&ctsa=mr&CtsSyncId=3DDA1B994EB84375ADCB9ED1FD52C71F&RedC=c1.microsoft.com&MXFR=135D9C8F6E5667C926C995E26A566111 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny INCLUSION from c.bing.com
Deny

[barbaz]

Please use code tags for posting messages, rules, & the like, it's easier to read that way, thanks.

Instead of c.bing.com, you want to use .microsoft.com in this case (note the leading dot). c.bing.com is the request destination (like quantcast in the other example) not the source (like drudgereport in the other example).

That being said, IIRC you should not be getting *any* ABE notifications for requests to 0.0.0.0. I can confirm that behavior, maybe a bug in NoScript?

[barbaz]

BTW, I found this entry in my HOSTS file:

Code: Select all

# try to resolve ip 0.0.0.0 to domain 0.0.0.0
0.0.0.0         0.0.0.0

This is the first 0.0.0.0 entry, and I think I added it to fix packet sniffers saying everything was going to and from some weird or blocked site. Don't know if adding that as the very first 0.0.0.0 entry would fix any 0.0.0.0-related issues you might have?