[RESOLVED] "Accept from" rule not matching

[moggie2002]

With NS 2.3.8, I'm stumped getting "Accept from" to match to allow access to a local server from a remote site, and would be grateful for pointers to where I'm going wrong; it should be trivial which is what's frustrating.

Before the catch all for local, I added a rule similar to:

Site xxx.yyy
Accept ALL from zzz.com
Deny

xxx.yyy is a local server with an entry in the hosts file. zzz.com is a trusted remote site. The site pattern for xxx.yyy matches as expected when zzz.com redirects to it because ABE shows that it's the LOCAL rule that matches if I change the xxx.yyy to something else, and access is allowed if I just have "Accept ALL". However qualify with "from zzz.com", and even though that's the domain with the local link, the rule isn't allowed and the Deny matches. I've tried adding http, using the full path to the target and source URI, wildcards and so on, but no joy. So I'm just doing an "Accept ALL" for now, but would be good not to have to do that.

[Tom T.]

With NS 2.3.8, I'm stumped getting "Accept from" to match to allow access to a local server from a remote site, and would be grateful for pointers to where I'm going wrong; it should be trivial which is what's frustrating.

Before the catch all for local, I added a rule similar to:

Site xxx.yyy
Accept ALL from zzz.com
Deny

xxx.yyy is a local server with an entry in the hosts file. zzz.com is a trusted remote site. The site pattern for xxx.yyy matches as expected when zzz.com redirects to it because ABE shows that it's the LOCAL rule that matches if I change the xxx.yyy to something else, and access is allowed if I just have "Accept ALL". However qualify with "from zzz.com", and even though that's the domain with the local link, the rule isn't allowed and the Deny matches. I've tried adding http, using the full path to the target and source URI, wildcards and so on, but no joy. So I'm just doing an "Accept ALL" for now, but would be good not to have to do that.

See if this thread explains why ABE syntax sometimes looks "backwards" or counter-intuitive. You should then be able to flip the rule on your own; if not, we'll be glad to help.

(Yes, it's frustrating, but not trivial until one understands ABE's "language". )

[moggie2002]

Hi Tom

Thanks for the reply. I tried to switch the rules out of interest but stil no joy.

To recap, in SYSTEM I have something like

# Allow external site foo.com to access local site bar.com
Site bar.com
Accept from *.foo.com
Deny

bar.com is in the local hosts file. A page on www.foo.com links to http://bar.com/sub. The site rule seems to match because that's the rule that ABE shows the Deny belongs to. Is it possible to enable any log of the pattern matching?

[Tom T.]

To recap, in SYSTEM I have something like

# Allow external site foo.com to access local site bar.com
Site bar.com
Accept from *.foo.com
Deny

This is the "looks backwards" part to which I was referring. The resource (site) that you want to control is foo.com. Therefore, foo goes in "Site".

Code: Select all

Site .foo.com

The site which you wish to allow to make HTTP requests to foo.com is bar.com.

Code: Select all

Accept from .bar.com 

You wish for bar.com to be allowed to make requests to foo.com (which foo.com will then return), which is how ABE sees it.

(The leading dot wildcards all sub-domains of foo.com and/or bar.com. If you wish specifically only http//foo.com, omit the leading dot. If you wish specifically only www dot bar.com, use that, which prohibits, say, sports.bar.com) (unintentional pun alert! )

Or to look at it the other way around, (ABE's way), you wish to allow foo.com to ACCEPT REQUESTS FROM bar.com. So the rule is:

Code: Select all

# Allow external site foo.com to access local site bar.com
Site foo.com
Accept from .bar.com (or bar.com, as above)
Deny 
# Prevent *all other* Internet sites from requesting LAN resources. (added the stars for emphasis only)
Site LOCAL
Accept from LOCAL
Deny

It seems that you correctly noted that the specific rule must precede the more general one; when ABE finds a match to foo.com and bar.com, processing stops, and the request passes. All that don't match foo.com continue on, and get caught in the general rule that accepts local-to-local connections, but denies all non-local sites that didn't match foo.com.

Does this work?
Did you perhaps need to add the leading dots in one or both?

As per example at the linked thread, let's say you want to let google-syndication ads run at your fave sites, to support them with ad revenue, but not to bother you elsewhere.

Code: Select all

Site .google-syndication.com
Accept from .favesite1.com .favesite2.com .favesite3.com
Deny

This may "look" backwards, but you are telling NoScript that G-S.com may accept HTTP requests ONLY from your three fave sites, and not from any others.
G-S will return the ad script, the sites run the script, the ads show, and Google pays your fave site webmasters.

The "intuitive way" is the wrong way:

Site fave1, 2, 3 (WRONG)
Accept from google-syndication.com (WRONG)
Deny

i know it seems that we're accepting script FROM G-S, but that doesn't happen unless the site REQUESTS it from G-S.
Using the correct rule in the preceding code tags, we allow G-S to accept requests FROM these three sites only, and no others.
Keeping this HTTP Request model in mind should help.

More info in ABE Rules .pdf, defining resources (the site you wish to restrict/allow), predicates (action words, such as accept, deny), and some more advanced options.

Clear as mud yet?

[Thrawn]

@moggie2002: I'm not entirely clear on which direction you want to allow access. Do you actually want to allow an external site to send requests to a local one? So, at a page on www external com, you could have, say,

Code: Select all

<img src="http://internal.com"/>
<script type="text/javascript" src="http://internal.com/script.js"/>
<iframe src="http://internal.com/frame/"/>

If so, then your original rule ought to be what you want...but it seems like a bizarre thing to do. It means that an external, internet-visible site has knowledge of a site that's only visible on your local network. Presumably this external site, despite being external, is under your control and not publicly visible?

If, on the other hand, you want a page on internal.com to be able to load images/scripts/frames from www external com, then Tom T is right, you need to swap it around.

Can you post the full text of the ABE error?

[Tom T.]

@ Thrawn:

From OP:

With NS 2.3.8, I'm stumped getting "Accept from" to match to allow access to a local server from a remote site, ... xxx.yyy is a local server with an entry in the hosts file. zzz.com is a trusted remote site.

One example might be similar to a VPN-type situation. OP has a remote office in London, and headquarters in Los Angeles. He would like the remote site to be able to access *one specific, HOSTS-listed* address in the LAN at HQ. -- not necessarily the entire LAN, which possibly is why VPN per se isn't used?

Else, as you suggested, the remote site is totally under his control, and not publicly visible -- or he trusts it a *heck* of a lot.

Side note: Per ABE FAQ, note how many large public web sites are using 127.0.0.1 on your own (client) machine, and thus require ABE exceptions. See FAQ 8.3-8.9.
I don't like this, and wouldn't do this myself, but I took OP at his word.

Yes, the ABE message would be of interest. So would the actual sites.

@moggie2002: Do you wish to PM the site addresses to me, in strictest confidence? The answers can still be posted here using generic site IDs. No offense taken should you not wish to do so, of course.

[moggie2002]

Hi Tom

Thanks for the further replies, and yes, it's an external site under our control. The external site is part of a staff admin area, and most links that a staff member sees are links to other pages on external sites, but one link is to an internal site, and it's that link triggers the ABE. I'll PM the details.

[Tom T.]

(in PM)
About this issue, a page within www.xxx.com opens a new tab with a link to http://xxx.yyy/zzz, and that triggers ABE.

So I added:

Code: Select all

Site xxx.yyy
Accept from .xxx.com
Deny

I tried various alternatives, such as the site directive with the full target URL, an allow with the wildcard and so on. As the name servers that our local machines point to aren't in our control, xxx.yyy is an entry in the Windows hosts file.

That's probably the issue, since the address isn't reachable via the public Internet: ABE isn't being told to allow the localhost, which is where your internal address resides - in the HOSTS file.

Least restrictive:

Code: Select all

Site http://127.0.0.1
Accept from .xxx.com
Deny

More restrictive, using regular expressions:

Code: Select all

Site ^http://(?:127\.0\.0\.1|localhost):\xxx\.yyy/zzz
Accept from .xxx.com
Deny 

Please test the first one. If it works, please try the second one.
Let us know, thanks.

[moggie2002]

Hi Tom

Neither of those rules match (added before LOCAL), so the LOCAL rule triggers ABE in both cases. So far only if the site directive has xxxxxxx.yyyy or the same with /zzz does it execute the rule. Note that while xxxxxxx.yyyy is in the local hosts file, the name resolves to the IP for a different machine on the same subnet.

[Tom T.]

Neither of those rules match (added before LOCAL), so the LOCAL rule triggers ABE in both cases. So far only if the site directive has xxxxxxx.yyyy or the same with /zzz does it execute the rule. Note that while xxxxxxx.yyyy is in the local hosts file, the name resolves to the IP for a different machine on the same subnet.

Then let's just use the same LOCAL, modifying the existing (default SYSTEM) rule:

Code: Select all

# Prevent Internet sites from requesting LAN resources, except from xxx.com
Site LOCAL
Accept from LOCAL .xxx.com
Deny

If I've messed up the xxx's and yyy's etc., please adjust accordingly (translating from your PM info).

[moggie2002]

Hi Tom

Thanks for persisting, and the final suggestion led to a fix. Adding .xxx.com for the external site didn't work, but adding BOTH the external and internal sites worked. So I have

Accept LOCAL .xxx.com aaa.bbb/svn

Not sure why both were needed unless it is related to aaa.bbb being an entry in the local hosts file.

Cheers
Nick

[Tom T.]

Thanks for persisting, and the final suggestion led to a fix.

Yes, persistence is often a decent substitute for brains.

(originally followed the pattern in ABE FAQ for local exceptions, and when that didn't work...)

Adding .xxx.com for the external site didn't work, but adding BOTH the external and internal sites worked. So I have

Accept LOCAL .xxx.com aaa.bbb/svn

Not sure why both were needed unless it is related to aaa.bbb being an entry in the local hosts file.

Since it works, not going to investigate deeply, but your idea does make sense. ABE has to let the local system issue requests through xxx.com, from aaa.etc (via the hosts lookup), to the external site. I could be mistaken on the reason (won't bother Giorgio unless it becomes a factor), but will keep this pattern in mind if it ever comes up again.

Thanks for posting back as resolved, and you're quite welcome.

Cheers,
Tom