InformAction Forums

How is the localnet defined for matching with the LOCAL keyword?

My home LAN is in the 10.x.x.x private subnet and I have my netmask setup as 255.255.255.0. It seems that LOCAL is matching everything in 10.x.x.x instead of only my local LAN so I'm having problems with ABE catching addresses that are valid links between sites on the VPN I'm using.

Specific numbers are changed but this will paint the picture:

Home system: 10.5.20.22
Origin Site: 129.11.11.11
Destination: 10.7.2.1

The destination is incorrectly interpreted as a member of my LOCAL environment.

If I need to modify the "SYSTEM" rule, will it be over-written the next time I upgrade?

I tried modifying rules using IP addresses but the syntax for ABE configuration appears to be extremely restrictive.

[btw - I tried to search the forum using the keyword 'abe' but it's ignored as too common]

seiryu wrote:How is the localnet defined for matching with the LOCAL keyword?

For IPv4 probably according to RFC 1918 wherefore all IPs in the following ranges are defined as LOCAL:

• 10.0.0.0 – 10.255.255.255
• 172.16.0.0 – 172.31.255.255
• 192.168.0.0 – 192.168.255.255

This is the function currently checking for local IPs in NoScript/ABE: As you can see, it matches all (as far as I know) the IPv4 and IPv6 addresses defined as "private" by various RFCs, which internet web pages have (usually) no legitimate business in linking to.

seiryu wrote: Origin Site: 129.11.11.11
Destination: 10.7.2.1

The destination is incorrectly interpreted as a member of my LOCAL environment.

No matter which your netmask is, the "10.7.2.1" is a private address reserved for intranet usage, which should not be routable from the internet.
129.11.11.11 is an internet address, instead, and preventing it from exploiting your browser mechanisms and, indirectly, your VPN link, to access a private not routable address is exactly the task which the SYSTEM local rule has been implemented for.

Then you or your organization have a good reason to let this bypass work.
If it's so, the exception to be prepended to the local rule is the following:

seiryu wrote: the syntax for ABE configuration appears to be extremely restrictive.

You can use host names, glob expressions and regular expressions (the latter are hardly restictive for anything).
However using naked IPs is currently impossible because of a parser bug: you need to specify the protocol at least.
It will be fixed in a next release, and I'm even considering to accept subnet/mask syntax later.

To build on this question of how local is defined, I've run into a situation which dovetails w/ the OP's. If this should be a separate post, please feel free to split it out, Moderator.

In my situation, I have 8 Class C address ranges we own as part of my local network, as well as many private address ranges now being added to the mix. What I'm finding is that when I click on a link from my local web portal to one of our local web application servers, some work just fine and some get blocked by ABE. I was able to track it down to our public Class C addresses are allowed to be linked to, while our private addresses aren't.

Scenario 1: Local web portal (Class C address) links to web app server (Class C address) - ABE allows.

Scenario 2: Local web portal (Class C address) links to web app server (10.x.x.x address) - ABE blocks.

I've read the FAQs and the ABE rules, and understand this behavior is what ABE was intended to block, but I'm still stumped as to how to provide exceptions for my situation. I would like to avoid changing my Hosts file or having to list multiple individual exceptions in order to get ABE to allow these local private addresses to be linked to by local Class C public addresses of ours. What is the most efficient way to make sure our Class C addresses are rightfully considered as local addresses and aren't interfered with by ABE?

Since at this moment raw IP/subnet syntax is not supported by ABE, the easiest way to add an exception rule in SYSTEM ABE (before the LOCAL rule) is using one or more regular expressions.
If your subnet is, let's say 85.0.0.0/24, and you've got also foo.com and bar.com as domains in that subnet, you can write

Thanks for the response, Giorgio. I tried using your example, but still have the issue. Three points of clarification:

1) If I need to flesh out the IP in your example, and leave just the last octet variable, is this the right syntax?
2) In your example, does the "^https?" portion handle both HTTP and HTTPS?

3) If the URLs are using non-standard ports (values other than 80 or 443), does that need to be represented in the code?

Thanks.

EJ wrote: 1) If I need to flesh out the IP in your example, and leave just the last octet variable, is this the right syntax?

Code: Select all

Site ^https?://85.103.18\.\d+/ foo.com
Accept

Yes it is (dot escaping aside, see below).

EJ wrote: 2) In your example, does the "^https?" portion handle both HTTP and HTTPS?

Yes it does.

EJ wrote: 3) If the URLs are using non-standard ports (values other than 80 or 443), does that need to be represented in the code?

Yes: it is a non-anchored regular expression, therefore you leave it as it is it would match up to the beginning of path ("/"), and would be broken by a port specification before it.
So, if you want to take in account any port in the regular expression, you need the following:

Thanks for the reply Giorgio!

My situation is essentially the same as the other commenter on this thread. Our intranet has both internet and intranet ips and they do crosslink between each other.

Got it working with the additional input. It helped to cement how the rule system works and the acceptable syntax.

seiryu wrote:Got it working with the additional input. It helped to cement how the rule system works and the acceptable syntax.

Notice that in 1.9.6.x the syntax is considerably more flexible for your case.
Now raw IP and even subnets with masks are accepted: Now matches any request with IP in the 192.168.* and in the 10.* networks, with on-the-fly DNS resolution.
See http://noscript.net/abe for the updated rules syntax specification.

It seems to me that your code does not recognize the whole 172.16.0.0/12 network as LOCAL.
If I understand it correctly than it considers only 172.16.0.0/16 as LOCAL.

I hope I am not mistaken ...

Thanks

@Antal:
you're right, fixed in 1.9.8.9, thanks.

Thanks for the quick fix and your work on this project in general!