Re: What constitutes authorized server access? - was Re: RPAT - Realtime Proxy Abuse Triangulation

From: Kevin Reardon (Kevin.Reardon@oracle.com)
Date: 01/02/03

  • Next message: James Turner: "Re: MS IIS 5 server is hacked leaving undeletable folders and files" 
    Date: Thu, 02 Jan 2003 10:25:52 -0800
From: Kevin Reardon <Kevin.Reardon@oracle.com>
To: Gary Flynn <flynngn@jmu.edu>

    Where you state "he 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." is not
    totally true. In the case where a road is not specifically signed to
    not trespass or properly gated, it is unknown to a reasonable man if
    this road is a government run road or private, thus a person may
    trespass without knowledge but would be innocent of the crime. Also, in
    the case of children, a swimming pool not fenced off is what is called
    an "attractive nuisance" and is itself illegal.

    "So which doors are people permitted to enter without explicit
    permission?" Now that is tough, but it could fall into the realm of
    "attractive nuisance" if you don't lock a door. I have read a few notes
    on this list where a well meaning person got into a system just to find
    out who, or what, was responsible for the attack against them.

    On the topic where you state "What if an organization wants to make SNMP
    read access available for some reason." I would like to know what brand
    of coffee maker has an SNMP interface so I can change out the nearest
    one to me (its quite a hike).

    And now for the meat of your points. The idea expressed in "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." has a very good concept.
    Granted, this feature is usually performed at a data encryption layer,
    or application layer (password), perhaps a challenge / response at the
    TCP/IP SYN handshake might be a good idea. Granted, this could create a
    severe SYN attack issue. However, if the handshake protocol's default
    behavior is private, then it could shut down this "open share," or
    equivalent, problem.

    Now that I think of it, such a protocol would not be needed if the
    default behavior of services was changed. Most software vendors have
    moved toward an "ease of use" default configuration which opens
    everything. This "ease of use" reasoning is what seems to fan the
    flames of the distribution of security holes in the Internet. Business
    reasoning (which some say is an oxymoron) has 'time to market' the
    overriding concern and anything that will delay it, like changing
    default behavior, usually gets on the back burner. This reasoning is not
    new and dates back two or three hundred years. I doubt it will go away
    anytime soon. Perhaps the RFC should deal with default configurations
    rather then a protocol.

    ---K

    Gary Flynn wrote:

    > 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 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

    Relevant Pages
    Loading