Netgear FS526T
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||||||||||||||
|
Posted by Alan J. Flavell on January 25, 2005, 8:48 pm
Please log in for more thread options 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. | ||||||||||||||||||||||||||||
|
Posted by J. Clarke on January 25, 2005, 5:19 pm
Please log in for more thread options 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) | ||||||||||||||||||||||||||||
|
Posted by Alan J. Flavell on January 25, 2005, 11:11 pm
Please log in for more thread options 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 | ||||||||||||||||||||||||||||
|
Posted by Robert Redelmeier on January 25, 2005, 9:14 pm
Please log in for more thread options > 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 | ||||||||||||||||||||||||||||
|
Posted by Alan J. Flavell on January 25, 2005, 10:39 pm
Please log in for more thread options On Tue, 25 Jan 2005, Robert Redelmeier 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 | ||||||||||||||||||||||||||||
| Similar Threads | Posted |
| Netgear FS526T | January 25, 2005, 8:48 pm |
| NetGear WGU624 | March 16, 2006, 6:37 pm |
| Netgear WGT624 V2 Router | July 7, 2004, 2:28 pm |
| Voyager 205 and Netgear FS605 | May 6, 2005, 6:00 pm |
| Dead Netgear PE-102s | March 29, 2006, 6:09 pm |
| Netgear and Cisco Trunk | May 3, 2007, 4:04 am |
| Re: Netgear powerline extenders | May 12, 2008, 4:25 pm |
| Netgear GSM72224 VLAN config | November 8, 2004, 12:49 pm |
| Netgear router setup problem | January 7, 2006, 6:56 pm |
| Netgear router setup problem | January 7, 2006, 6:56 pm |
| Allied Telesyn vs Cisco vs netgear | March 24, 2006, 4:02 pm |
| Intra-switch VLANs Netgear | September 6, 2006, 1:46 pm |
| Third Party SFPs in Netgear Switches | September 24, 2006, 2:27 pm |
| Bizarre interaction between macbook pro and Netgear WGT624v2 | January 10, 2007, 5:52 pm |
| wireless connection only stay up for 2 min./NetGEAR WGT624 | February 21, 2005, 8:04 pm |
> 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.