InformAction Forums

by **wxman1** » Thu Aug 11, 2016 12:35 am

Major breakthrough! I encountered another website that has similar problem, except having a -6 deal in the blockage. I discovered that the 1st level domain is redirecting to 2nd level sub-doc where both have the same domain name plus that domain is in the HOSTS file.

I discovered that I need to TRACERT the domain after remarking the domain name in HOSTS, and then the web-page displays - and even links are functional - despite the site URL and script associated URI's being forbidden.

So, yeah, NoScript + ABE will be a solid backstop to fundamental parasite protection offered by HOSTS.

by **wxman1** » Wed Aug 10, 2016 7:44 pm

Copy that and roger that; it works.

Here's a thing: I had an issue a while back with Flash being blocked - but never knew it - because there was script blockage; I never seen the Flash blockage notification. Once I implemented a 10 second time out for script blockage, I could enable Flash based on the subsequent Flash blockage notification. Otherwise the site I was on was crippled - not nonfunctional - but major crippled even so I wasn't using Flash for the slideshow I think it was that wanted that. .

What came to my attention with this most recent issue: the ABE blockage message never times out. On the plus side, if but for that "feature" I'd never have drilled into this matter. As it is I learned a bunches.

by **barbaz** » Wed Aug 10, 2016 7:29 pm

That Deny INC is just suppressing the notification, not changing what ABE blocks.

(Sorry, I missed a minor detail earlier. You should remove that Accept line for 0.0.0.0 as 0.0.0.0 should never be able to request anything in a web browser.)

Anyway, glad you got it working for you, marking this Resolved.

by **wxman1** » Wed Aug 10, 2016 6:57 pm

I tried remarking out the HOSTS entry for c.bing.com and voila! The MS Support page rendered w/ out ABE block. I put it back in and the "error" returned. No variation of rule-set would resolve that. TRACERT c.bing.com returned 0.0.0.0 invalid IP address. However, I noticed that its the LOCAL rule that's hitting, not the 0.0.0.0 rule-set.

I pull the c.bing.com URI out of the LOCAL ruleset - back to default - and cut out the www.drudgereport.com from the Deny INC action of the 0.0.0.0 ruleset and discover that Drudge STILL didn't generate an error. I removed the entire 0.0.0.0 ruleset and Drudge once again displayed ABE block. I added it back in again and the ABE block went away on Drudge. I checked the MS Support page and it didn't display ABE block either.

I checked the browser console for the MS Support page:

Code: Select all

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&CtsSyncId=D0712B25DFD04E3589289940C1CCA73D&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5" on a secure page

[ABE] <0.0.0.0> Deny INCLUSION on {GET http://c.bing.com/c.gif?&CtsSyncId=D0712B25DFD04E3589289940C1CCA73D&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site 0.0.0.0
Accept from SELF+
Deny INCLUSION

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

Loading mixed (insecure) display content "http://c.bing.com/c.gif?&CtsSyncId=55BBA3CAA23344089423F1CBA2360A7D&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5" on a secure page

[ABE] <0.0.0.0> Deny INCLUSION on {GET http://c.bing.com/c.gif?&CtsSyncId=55BBA3CAA23344089423F1CBA2360A7D&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5 <<< http://c1.microsoft.com/c.gif?, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site 0.0.0.0
Accept from SELF+
Deny INCLUSION

[ABE] <0.0.0.0> Deny INCLUSION on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&CtsSyncId=A8BB2238121543618489E29AEA68C761&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 7}
SYSTEM rule:
Site 0.0.0.0
Accept from SELF+
Deny INCLUSION

[ABE] <0.0.0.0> Deny INCLUSION on {GET https://c.bing.com/c.gif?DI=4050&did=1&t=&CtsSyncId=10B5C640D24641989FE66CAD6B86A561&RedC=c1.microsoft.com&MXFR=2ACB603D9A6A67E8261769509E6A61A5 <<< https://c1.microsoft.com/c.gif?DI=4050&did=1&t=, https://support.microsoft.com/en-us/kb/919746 - 3}
SYSTEM rule:
Site 0.0.0.0
Accept from SELF+
Deny INCLUSION

Dunno, that would seem to suggest an issue with NoScript parsing the rules, or there was a non-ASCI or wierd unprintable UTF char in the rulesets.

Bottom line it looks like its working now.

by **barbaz** » Wed Aug 10, 2016 1:27 pm

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?

by **barbaz** » Wed Aug 10, 2016 1:20 pm

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?

by **wxman1** » Wed Aug 10, 2016 8:57 am

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

by **wxman1** » Wed Aug 10, 2016 7:50 am

barbaz wrote: ...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".

by **wxman1** » Wed Aug 10, 2016 7:26 am

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.

by **barbaz** » Wed Aug 10, 2016 4:01 am

"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?

by **wxman1** » Wed Aug 10, 2016 3:38 am

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.

by **barbaz** » Wed Aug 10, 2016 3:11 am

wxman1 wrote: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)

by **wxman1** » Wed Aug 10, 2016 2:52 am

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.

by **barbaz** » Wed Aug 10, 2016 12:39 am

wxman1 wrote: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.

wxman1 wrote: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.

wxman1 wrote: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.

wxman1 wrote: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.

by **wxman1** » Tue Aug 09, 2016 11:18 pm

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.

InformAction Forums

[Resolved] filtered by ABE: <LOCAL> Deny

Post a reply

Expand view Topic review: [Resolved] filtered by ABE: <LOCAL> Deny

Re: [Resolved] filtered by ABE: <LOCAL> Deny

Re: [Resolved] filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny

Re: filtered by ABE: <LOCAL> Deny