Error Console [ABE WAN] message clarification?

[ABEfan]

First, many thanks for yet more protection for routers.

The item "Exclusive protection against DNS-rebinding attacks targeted to routers, including WAN IP variants." in the changelog today:

I sort of understand the general idea that it's covering a hole in the ABE implementation, but I would like to verify that my install is behaving as expected.

I've read this thread
http://forums.informaction.com/viewtopi ... ng+routers
and this one
http://forums.informaction.com/viewtopi ... 43&start=0
The advice in Error Console is

Code: Select all

[ABE WAN] Detected WAN IP xxx.xx.xxx.xxx

Do I infer from this invocation of ABE that my router is vulnerable to the exploit or is every NS install getting added to the IP address pool simply as preparation for ABE to to its work?
- - btw, nice to have a very accessable trusted check of my IP - don't need to change focus from Fx to terminal to get it

[Giorgio Maone]

Do I infer from this invocation of ABE that my router is vulnerable to the exploit or is every NS install getting added to the IP address pool simply as preparation for ABE to to its work?

The latter.
However, if opening http://xxx.xxx.xxx.xxx in your browser leads you to your router's administrative console or to another sensitive web resource meant to be seen only from inside your LAN, you've got the kind of problem which the new feature is meant to repair.

Actually this makes me think that, since NoScript actually checks whether a web resource is accessible at that IP, an indicator of that could be added by default to the console logging as well...

[ABEfan]

if opening http://xxx.xxx.xxx.xxx in your browser leads you to your router's administrative console or to another sensitive web resource meant to be seen only from inside your LAN,

No, it doesn't. Thanks for clearing that up. Your test idea sounds v good.
Relaxing now...until the next hole gets publicity... routers are a real headache for us home users.

[Guest]

Actually this makes me think that, since NoScript actually checks whether a web resource is accessible at that IP, an indicator of that could be added by default to the console logging as well...

Well, how about a visible notification, asking the user whether they want/need it? I thought it was in your interest that your server doesn't fry.

Not to belittle your efforts, but I don't really need it since my router isn't vulnerable (in that it doesn't respond to requests from non-local IP addresses), and for users with a static IP address an equally static ABE rule would be just as secure.

[Giorgio Maone]

Well, how about a visible notification, asking the user whether they want/need it? I thought it was in your interest that your server doesn't fry.

Unfortunately many users wouldn't know the correct answer, see below

Not to belittle your efforts, but I don't really need it since my router isn't vulnerable (in that it doesn't respond to requests from non-local IP addresses)

In fact, the router not responding to requests from (intended as "coming from") non-local IP addresses doesn't make them less vulnerable.
The problem at hand is about those routers answering on (intended as "when requested on the") public WAN IP address assigned by your IP from your (local) address.
So, unless I didn't correctly understand your statement, you seem to be among those users who would have disabled it on a wrong assumption.

and for users with a static IP address an equally static ABE rule would be just as secure.

With an additional effort on their part, and the need to learn how to write/edit an ABE rule...

[Guest]

Unfortunately many users wouldn't know the correct answer, see below

Maybe you could give them a nudge in the right direction by checking if anything answers on their WAN IP address first (which according to you already does happen).

In fact, the router not responding to requests from (intended as "coming from") non-local IP addresses doesn't make them less vulnerable.
The problem at hand is about those routers answering on (intended as "when requested on the") public WAN IP address assigned by your IP from your (local) address.
So, unless I didn't correctly understand your statement, you seem to be among those users who would have disabled it on a wrong assumption.

Er, well. Accessing the configuration page via the public WAN IP address doesn't work is what I'm saying.

With an additional effort on their part, and the need to learn how to write/edit an ABE rule...

True, I guess.