Greetings, Here is some information that I encountered not too long ago that relates to this situation. I do not know if this applies to any router other than the NetGear RT-314 (and identical ZyXEL router, since NetGear simply OEMs the ZyXEL routers), but it *does* work on that router: Command: IP TCP MSS 0 This command (used in menu 24.8) sets the maximum segment size (TCP/IP parameter controlling how large a packet may be received or sent) to zero - thus stopping all traffic addressed directly to the router (because any packet is going to be larger than 0 bytes). By "all", I mean both WAN side and LAN side addresses - the only way to communicate directly with the router is over a serial connection. Note that this is not an "elegant" solution - there may be (probably are) better ways to accomplish this task (protocol filters, for example). But it is an easy way to do it, and for people who are actually using the filtering capabilities of this router, it gives back a few filter rules that can then be used for other purposes. You can also change the default for this setting by modifying the statement in the AUTOEXEC.NET. By default, the AUTOEXEC.NET file contains: IP TCP MSS 512 Note that this setting does not affect the routing functions of the router - only direct communication with the router (effectively closing HTTP, FTP, and Telnet access to the routers functions). Control of the router can still be done using a serial link, as can firmware updates. I know it's an inconvenience to have to go *to* the router to configure it, but it's sure a lot more secure. I've seen a large number of port 21 and port 80 attempts on the router's LAN address (more so than any other address in my network) and also a fair number on the router's WAN address. Port 23 hasn't been neglected, either, but not in anywhere near the volume as the other two (which leads me to believe that the other two are mostly other things, like Code Red variants, or people looking for hiding places for their warez). The page where I found this setting is: http://pages.infinit.net/neo2048/how-to.htm Note that the main page for the site is at (it's a frame menu, and doesn't display if you go directly to the page referenced above): http://pages.infinit.net/neo2048/frame.htm There is a fair amount of additional information on configuring the NetGear RT-314 (and, hence, the identical ZyXEL router) on these pages - some good, some bad. One thing that was very helpful to me was some of the discussion on setting up "generic filters" (bytestream filters rather than protocol filters). Note that I am not affiliated with the site in question - I just think they have some good info available. Tracy Martin ArisiaSoft > -----Original Message----- > From: Daniel Roethlisberger [mailto:danielat_private] > Sent: Wednesday, August 15, 2001 14:47 > To: bugtraqat_private > Subject: BID 3161: other ZyXEL Prestige routers affected too > > > > I've received word that the ZyXEL Prestige 202 router has its > administrative telnet/FTP services open on the WAN side too, and > preconfigured filters are not applied and do not work properly if > applied as-is. In addition, I was able to check out an oldish > Prestige 100, and it too was vulnerable, same situation. > > I suspect that the vast majority of ZyXEL Prestige family routers > have this problem. It is less of a problem with non-DSL routers > that are not online 24/7, but it is still dangerous enough in any > case. The issue must have been around for years... > > The latest vulnerability info for BID 3161 is now: > > Vulnerable: > ZyXEL Prestige 100 > ZyXEL Prestige 202 > ZyXEL Prestige 642R > ZyXEL Prestige 642R-I > > Not Vulnerable: > ZyXEL Prestige 642M > ZyXEL Prestige 642M-I > > If you have access to a ZyXEL router, check whether admin services > are open to the Internet, and let me know about the results. Thanks. > > Cheers, > Dan > > > -- > Daniel Roethlisberger <danielat_private> > PGP Key ID 0x8DE543ED with fingerprint > 6C10 83D7 2BB8 D908 10AE 7FA3 0779 0355 8DE5 43ED > >
This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 20:43:14 PDT