Netgear FS526T

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

We recently purchased a Netgear FS526T. Seems spectacularly good
value for what it does, but I'm finding out something worrisome about
its web management access.

While trying to devise some simple scripts to drive its web interface,
I've several times "succeeded" in killing the box's web server. After
which, it seems that neither a web browser nor their "smart wizard"
configuration utility can get any contact with it, until the box has
been re-set manually.

I can't say that I could reproducibly kill the box at will, but this
is clearly disturbing.

But worse... the box offers to limit management access to a specified
list of IP source addresses. This, one might think, would protect it
from hostile access. But no: it happily responds to HTTP protocol
requests from any source address, right up to the point at which it
checks for a password, and only then does it deny access.

That seems crazy to me: it leaves any weaknesses in the IP, TCP, HTTP
protocol implementations (and clearly, there must be some) open to
anyone, anywhere, who can access port 80.

Bearing in mind that the firmware is upgradeable, it seems to me that
if their technical folks could be persuaded that something's wrong
here, they could fix it.

I doubt that I'd get any useful answer trying to raise this issue with
the sales structure, or even first-line technical support ("did you
remember to plug it in?"). Anyone suggest a productive approach that
wouldn't involve me in too much effort?

thanks

p.s I'm only an occasional visitor to the comp.dcom.* groups; if it's
thought that I've picked an unsuitable group to raise this question,
please do make a constructive proposal.

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Alan J. Flavell wrote:

>
> We recently purchased a Netgear FS526T. Seems spectacularly good
> value for what it does, but I'm finding out something worrisome about
> its web management access.
>
> While trying to devise some simple scripts to drive its web interface,
> I've several times "succeeded" in killing the box's web server. After
> which, it seems that neither a web browser nor their "smart wizard"
> configuration utility can get any contact with it, until the box has
> been re-set manually.
>
> I can't say that I could reproducibly kill the box at will, but this
> is clearly disturbing.
>
> But worse... the box offers to limit management access to a specified
> list of IP source addresses. This, one might think, would protect it
> from hostile access. But no: it happily responds to HTTP protocol
> requests from any source address, right up to the point at which it
> checks for a password, and only then does it deny access.
>
> That seems crazy to me: it leaves any weaknesses in the IP, TCP, HTTP
> protocol implementations (and clearly, there must be some) open to
> anyone, anywhere, who can access port 80.

It's a bridge (aka "switch" aka "layer 2 switch" aka "switching hub"), not a
router or firewall. If you don't want "anyone, anywhere" to be able to
access it then put it behind a firewall. And if your users are
sufficiently knowledgeable and untrustworthy for their access to be an
issue then you've got the wrong product.

> Bearing in mind that the firmware is upgradeable, it seems to me that
> if their technical folks could be persuaded that something's wrong
> here, they could fix it.
>
> I doubt that I'd get any useful answer trying to raise this issue with
> the sales structure, or even first-line technical support ("did you
> remember to plug it in?"). Anyone suggest a productive approach that
> wouldn't involve me in too much effort?
>
> thanks
>
> p.s I'm only an occasional visitor to the comp.dcom.* groups; if it's
> thought that I've picked an unsuitable group to raise this question,
> please do make a constructive proposal.

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:
> But worse... the box offers to limit management access to
> a specified list of IP source addresses. This, one might
> think, would protect it from hostile access. But no:
> it happily responds to HTTP protocol requests from any
> source address, right up to the point at which it checks
> for a password, and only then does it deny access.

There may be a setting to "Block WAN admin access" that
needs to be enabled before the list becomes operative.

-- Robert

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

On Tue, 25 Jan 2005, Robert Redelmeier wrote:

> Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:
> > But worse... the box offers to limit management access to
> > a specified list of IP source addresses. This, one might
> > think, would protect it from hostile access. But no:
> > it happily responds to HTTP protocol requests from any
> > source address, right up to the point at which it checks
> > for a password, and only then does it deny access.
>
> There may be a setting to "Block WAN admin access"

Sorry, I don't see the slightest indication of such an option in the
software manual. In fact, quite the contrary - it warns the reader
that the IP access list will take effect as soon as it's set, and so
one must be sure to include the address from which the changes are
being made, or else management access will be cut off at that point.

> that needs to be enabled before the list becomes operative.

Aye, but the list -is- already operative - in the sense that the box
rejects the password from any source IP which isn't in the list, and
thus denies access to any actual management functions.

The problem is, as I say, that the access list does not operate by
keeping the packets out of the IP protocol stacks; so, if there's a
security exposure in those (and my experience shows that there must
be, at least as far as facilitating a Denial of Service, if nothing
worse), there's no protection against that.

The only options then would seem to be:

- use a private IP address, which isn't routed to the public Internet

- control by a firewall (but the campus border firewall here - as is
only reasonable - is set by campus policy, not by one-off requests
from individual departments).

thanks

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

On Tue, 25 Jan 2005, J. Clarke wrote:

> It's a bridge (aka "switch" aka "layer 2 switch" aka "switching hub"),

It's a switch, of course. But its management function is, in effect,
a web server (that's why it's got an IP address), and it's the web
server that seems to be at risk.

> If you don't want "anyone, anywhere" to be able to
> access it then put it behind a firewall.

I can give the Netgear's management function an unroutable private IP
address, which seems as effective a solution (and more appropriate to
our situation) - now that I'm aware of the problem.

> And if your users are sufficiently knowledgeable and untrustworthy
> for their access to be an issue then you've got the wrong product.

Hang on, I think you're in a different argument here. I'm reasonably
well able to protect myself, and from our own users; but the unit
clearly has an unnecessary weakness, for anyone who assigns it a
public IP address - I was taking an interest in the wider issue.

best regards

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Alan J. Flavell <flavell@ph.gla.ac.uk> wrote:
> The problem is, as I say, that the access list does not
> operate by keeping the packets out of the IP protocol
> stacks; so, if there's a security exposure in those (and
> my experience shows that there must be, at least as far
> as facilitating a Denial of Service, if nothing worse),
> there's no protection against that.

First thing, these boxes have very simple MIPS CPUs and
simple protocol stacks. Not much exposure.

Second, try a different router with more features.
My Siemens does not answer from the 'net.

> - use a private IP address, which isn't routed to the
> public Internet

These cheap routers typically do NAT to priv IPs by
default. They can often open up one IP in some sort
of DMZ, or route requests by port.

-- Robert