InformAction Forums

Thrawn wrote:Some of the setup that I'm talking about is on different machines, but I guess I could put it on a USB drive.

I do that all the time. Export to flash drive, plug into other machine, import.

The default export on a Windows machine is .txt, so that's good on any other Windows machine -- regardless of version, AFAIK.
So presumably, whatever is the default export file type on your *nix machines will be xfrable. -- or does *nix recognize .txt (or have an interpreter that does)?

Here's a thought, in the honorable tradition of brainstorming:

What about adding the NATpin rule to all future "development builds" of NS, but *not* stable releases -- for a while?

Although we encourage users to try dev builds, overall the average tech level of those who do is no doubt higher than those who don't.
So these users, even if they can't fix the issue themselves, know where to look for info (such as searching and finding this thread), or how to remove the rule temporarily -- or post here about it.

A couple of months of this should give a good indication of what the rate of false positives would be. If it's negligible or tolerable, then there is a sound basis to add it as a default to stable releases.

If there's any support for this idea, I'll post it as a formal RFE in NS Development.

Tom T. wrote:

Thrawn wrote:Some of the setup that I'm talking about is on different machines, but I guess I could put it on a USB drive.

I do that all the time. Export to flash drive, plug into other machine, import.

The default export on a Windows machine is .txt, so that's good on any other Windows machine -- regardless of version, AFAIK.
So presumably, whatever is the default export file type on your *nix machines will be xfrable. -- or does *nix recognize .txt (or have an interpreter that does)?

Looks like there is no default extension, but it's easy enough to open any filetype (including without an extension) in an editor. My file browser recognises that it's a text file, despite having no extension, and opens in a Notepad equivalent. And yes, most *nixes will have a file association for txt.

Tom T. wrote:What about adding the NATpin rule to all future "development builds" of NS, but *not* stable releases -- for a while?
<snip>
If there's any support for this idea, I'll post it as a formal RFE in NS Development.

I'll support any step in this direction. Surely, though, keeping it out of the stable build would be extra work for Giorgio? If so, I'd suggest just letting it go through the regular development build cycle with that P2P exception included (although I would remove the exception on my own machine).

Thrawn wrote:

Tom T. wrote:What about adding the NATpin rule to all future "development builds" of NS, but *not* stable releases -- for a while?

I'll support any step in this direction. Surely, though, keeping it out of the stable build would be extra work for Giorgio?

Valid point...

If so, I'd suggest just letting it go through the regular development build cycle with that P2P exception included...

But it's *not* a P2P port. See above finding re: the "official" usage.

Port 182 doesn't even show in Wikipedia's list of well-known ports, whereas it does show several that are commonly used for P2P.

It does note:

The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers for specific uses. However, many unofficial uses of both well-known and registered port numbers occur in practice.

So far, we've found two (2) uses of Port 182, and 50% of them had poor reputations. (Did you send the d/l from the other 50% to VirusTotal?)
A larger sample of sites using 182 would be useful.

In any case, IMHO, the fact that a site chooses non-standard ports, when there are well-defined and -recognized ports for all common browsing functions (HTTP, SSL, FTP, etc.) would raise a red flag: Why? Why are they doing this? -- and investigate further.

Should the RFE then simply request that the original NATpin rule be standard from here on? I dislike the "test it on the user" philosphy, when the user doesn't know it's a beta, dev build, release candidate, etc.

Or add the rule with 182 excluded, see if any other ABE errors occur, and if not, add back 182 in a future verison? ... unless we can find widespread use of 182, but I'd still like to know why they chose it.

Would anyone else like to add an opinion before an RFE is drafted? Thanks.

Here's an extra thought on the NAT Pinning rule: Should it automatically Accept from LOCAL? That would help with web development, if you happen to have a local/LAN web server sitting on a non-standard port.

Thrawn wrote:Here's an extra thought on the NAT Pinning rule: Should it automatically Accept from LOCAL? That would help with web development, if you happen to have a local/LAN web server sitting on a non-standard port.

Wow, here's an old topic -- had to refresh myself.
The suggestion would affect only a tiny percent of users. My main concern is still the generation of false positives, causing users to panic, to uninstall NS or disable ABE, or -- post questions here.

Must admit that I've never had a false positive, and have been using the rule for a long time. It would be good if all interested readers could please add that rule, then report any positives, true or false, over a time span of some months. IOW, a volunteer beta test group, without inflicting it on all (average) users. Anyone care to do so?

I've had false positives in a work context, with local servers running on various ports.

OK. Did you add your own suggestion, and did it solve the issue?

Yes. For example, we run a server at localhost:6666, so without the LOCAL rule addition, pages are stripped of all of resources except inline text.

Following the model of FAQs 8.5 - 8.9, would you be safer by being more port-specific?

Accept from 127.0.0.1:6666
Deny

... or similar? (didn't spend a lot of time, just off the top of head)

Tom T. wrote:Following the model of FAQs 8.5 - 8.9, would you be safer by being more port-specific?

Yes, but a) we have several servers on different ports, b) I would have to cover both IP and hostname, and c) the idea was a general suggestion to make the NAT pinning rule quieter. LOCAL is generally considered *not* to be a significant source of CSRF, right?

Thrawn wrote:... LOCAL is generally considered *not* to be a significant source of CSRF, right?

Right, which is why the SYSTEM rule is present by default. However, running a server -- or several servers, as you said -- involves much more risk than a home client.

I'm not exactly sure of the threat model here -- one of your servers gets compromised, and we want to contain the infection rather than let the entire system catch it ? -- but in general, it seems that the more specific, the better. Including both IP and hostname doesn't sound too daunting. But the bottom line is: You know your system and your risks, and I don't. It was just a generic suggestion, coming from the tinfoil hat of maximum paranoia.