Re: publicly available resources and the law

[Ken Williams <jkwilli2 () unity ncsu edu>]

On Tue, 23 Feb 1999, Benjamin Tomhave wrote:

> Date: Tue, 23 Feb 1999 10:56:36 -0600
> From: Benjamin Tomhave <Falcon () CyberSecret com>
> To: HD Moore <hdmoore () usa net>, nmap-hackers () insecure org
> Subject: Re: publicly available resources and the law
>
> As best as I know, this is the guideline, and the legal technicalities that 
> answer the question of port scanning legality versus access a system.  I 
> definitely should not be considered an absolute authority on legality, so 
> please put the flamethrowers aside for now.  Let me preface my comments 
> by saying that I am a firm believer in freedom of information and open 
> systems, but I also am a firm believer in justice and fairness.  It is a fine line 
> to walk between security/paranoia/dictatorship and personal liberty.  
> Comments are welcomed and encouraged!
>
> 1)  When you go to a site such as www.nsa.gov, connecting via port 80 and 
> using http, you have been authorized to access that site via the declared 
> method (in this case, web browser).  In fine, nit-picking terms, you are 
> authorized by the NSA to connect to their web site via port 80, and nothing 
> else.  This would also be the case with anonymous FTP.  Again, you have 
> been granted specific permissions with a narrow scope.  To do anything that 
> does not fall within that scope can be construed as "unauthorized access" 
> even if you are utilizing the port made available.  Just because a port is open 
> for a specific application does not mean that it is a "public" port.  And even if 
> it were public, there is a certain amount of responsibility that does along with 
> have public assets available for use.
>
> 2)  Port scanning can be deemed illegal, unauthorized access along the 
> strictest of lines.  If you have not been granted explicit access to a system, 
> regardless of how the ports are assigned to applications, then port scanning 
> violates those restrictions.  However, along with this the owner of the 
> machine must also have policies in place that can legally back up their 
> description of "authorized access", etc.
>
> 3)  Legality is a touchy issue right now and basically comes down to walking 
> a fine line.  On the one hand, it is the responsibility of the owner to 
> thoroughly document usage policies and make the information widely 
> available.  If that is done, then most of the time that is enough legal 
> precedence should a court case be opened.  Negligence is not a viable 
> defense.  On the other hand, if there is no policy in place defining "authorized 
> access" then there is less legal recourse for responding to an intrusion, 
> whether or be a port scan or an actual root compromise.
>
> 4)  Analogy:  If you have a piece of land that you do not want people to hunt 
> on (I'm from Minnesota, btw), you have to post "No Trespassing" signs all 
> around the border of that property.  If you do not make an effort to post your 
> land, then you have no legal recourse should a hunter wander onto your land. 
>  Similar methods must be used for computer systems.  Unfortunately, at 
> least right now, there isn't any easy or nice way to post your system w/o 
> allowing a person to access that system.  Thus, the law loosens a bit in 
> favour of the owner with the understanding that it is highly difficult, if not 
> impossible, to thoroughly and effectively post your property.
>
> 5)  On the flip side:  A case was tried and won by a hacker (defendant) who 
> broke into a site.  The company had stated in the banner of the system 
> "Welcome to <router name>".  The court ruled that saying "Welcome" was 
> the same as inviting someone to enter their system and play around.  I 
> believe that this ruling was overturned later by a higher court because 
> adequate policy existed prohibiting certain kinds of access to the system.  
> Regardless, seemingly trivial things like this can work against a site.
>
> Cheers,
>
> -ben

Hi,

Nice summation. I generally ignore it if somebody hits a couple ports 
while trying to probe or scan one of my boxes. Of course after the first
hit, they get blocked by wrappers, firewalled out completely. Abacus
Sentry is a fine tool, especially when used with some custom firewall
script hacks. If it is a personal box, then I close tcp/23, and just use
ssh/22.  ftpd is left running just so people who want to check for anon
access can try it, get dropped, and get added to hosts.deny as soon as 
they connect.

Such configurations may be impractical for most people, especially when
running commercial web servers, but I'm a megalomaniac when it comes to
security and administration. :-)

If I am serving up web pages, then the following message is promiently 
displayed:

"Use of this system constitutes consent to security testing and 
monitoring. ALL network traffic on this system is constantly monitored 
for security, copyright, and statistical purposes. Unauthorized attempts 
to upload or change information, to download this entire web site, or
otherwise cause damage are strictly prohibited and may be punishable 
under the Computer Fraud and Abuse Act of 1986 and any other applicable 
local, state, federal and/or international laws."

Since most of the web sites that I maintain or have any control over are 
located on servers in Oregon, I feel relatively secure from a legal 
standpoint.  I do wonder though how a judge would interpret the disclaimer
that is plastered on the web sites:

"DISCLAIMER: If there Is a God, YOU are an AUTHORIZED REPRESENTATIVE.
Do whatever you deem necessary and appropriate."

So far, only UUnet and philips.com have been entirely worthless and 
uncooperative when I have had to respond to extended remote probes or 
attacks. I felt that over 6,000,000 attempts to brute force an 
.htaccess-protected web site directory (that was empty!) during a six 
day period was rather annoying and tasteless, especially since the bugger 
only got half-way through the "C"s with his sequential brute force attack 
from a philips.com server. philips.com didn't think so though; they 
consequently weren't allowed to drop by and visit for the next six months. 

Regards,

Ken Williams
jkwilli2 () csc ncsu edu 

Packet Storm Security                 http://packetstorm.genocide2600.com/
Trinux: Linux Security Toolkit http://www.trinux.org/ ftp://ftp.trinux.org
PGP DH/DSS/RSA Public Keys     http://packetstorm.genocide2600.com/pgpkey/
E.H.A.P. VP & Head of Operations http://www.ehap.org/   tattooman () ehap org
NCSU Computer Science      http://www.csc.ncsu.edu/  jkwilli2 () csc ncsu edu