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

From: Kevin Reardon <Kevin.Reardon(at)oracle.com>
Date: Thu Jan 02 2003 - 13:25:52 EST

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?

>>  
>>

>
>
>
>
> ----------------------------------------------------------------------------
>
> 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 Received on Thu Jan 2 14:32:39 2003