Well, again, I refer you back to analogs in the physical world. Let's consider a Best Buy or similar retailer. They have doors in front, doors in the side, doors in back. The doors in the front are clearly set up for the intended purpose of allowing the general public to enter. However, that doesn't make it legal for them to shoplift; in fact, if 10 people enter and one of them intends to shoplift, that one person has committed a crime merely by entering (unlawful entry) while the others are valued customers. This is much like a web server, set up with information that is oriented for the general unknown public, but the presence of which does not make hacking "fair game" against it. They have doors on the side, for purposes of emergency exit. These are locked from the outside and labeled clearly on the inside as to their purpose, with the warning that they not be used for any other purpose. If they happen to have a malfunctioning lock on one of those, does that make it legal for anyone to just come inside after hours, or for someone to take merchandise and exit through them without paying for it? Nope. Finally, there are the doors in the back, the loading dock and receiving area. These are in use during business hours, and additional hours as well. True, they are doors in the same building as the doors in front; this is a building the general public is supposed to enter. But does that make it ok for people to just walk into the back warehouse? Nope. In the "real" world, the notion of "acceptable entry" is conditional not upon the place being entered, but the intent of the person entering and whether they have been permitted to enter. It's more granular than just yes or no to the entire facility/area. And so it is with networks. Allowing SNMP access through your firewall is no different than screwing up and forgetting to lock the back/side doors...it's a bad idea, it's asking for trouble, it's certain to get noticed/abused sooner or later...but it doesn't make it ok for people to take advantage of it. > -----Original Message----- > From: Gary Flynn [mailto:flynngnat_private] > Sent: Tuesday, December 31, 2002 8:21 AM > To: Rob Shein > Cc: 'Mathias Wegner'; 'Kurt Seifried'; 'Stephen Friedl'; > incidentsat_private > Subject: What constitutes authorized server access? - was Re: > RPAT - Realtime Proxy Abuse Triangulation > > > Rob Shein wrote: > > >This is fundamentally flawed logic. To cite a physical-world > >equivalent, just because a door isn't locked doesn't make > entering it > >against the wishes of the occupant anything other than breaking and > >entering, plus unlawful entry if you have illegal intent > upon entering. > >The law does not recognize that failure to properly defend against > >criminal behavior means that you surrender all the protective means > >afforded by the criminal justice system. > > > So which doors are people permitted to enter without explicit > permission? HTTP server doors? ICMP echo server doors? Remote > Procedure Call doors? Universal Plug-n-Play doors? Auth (113) > doors? Netbios doors? Server Location Protocol doors? > > Or is it more complicated? Netbios doors as long as its not > C$? Kazaa doors as long as its not at the root directory? > > What if an organization wants to make SNMP read access > available for some reason. Whether for network performance > information or an SNMP coffee pot status. > > Intent is easily provided in telnet and web sessions through > common user interfaces with login banners but that is not the > case for other protocols. > > Maybe we need a new RFC governing "intent notification" so > that all servers offering services to a network will state > whether the server is > meant > for public use during session negotiation. A virtual "private > property- no trespassing" sign. Cooperating client programs > accessing a "private" > server > would require a user to acknowledge access the first time > through a pop-up window or other means. > > Of course, if vendors made the default for every service "public" to > promote > ease of use, it wouldn't do much good. > > (Forgive the HTML mail if it comes through that way. I'm at > home and wrestling with new browsers/mail clients.) > > > > > > > > ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Jan 02 2003 - 18:52:37 PST