<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Bright future for counter-attacks</title>
	<atom:link href="http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Mon, 08 Mar 2010 21:19:29 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-513</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Thu, 12 Apr 2007 17:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-513</guid>
		<description>Bob, nice thoughts.  I didn&#039;t notice that this was a 7 year+ battle.  The biggest hole in the case for the electronic/physical search being necessary to protect the email server is that the admin demonstrated he had the ability and means to block the attack.  Changing IP addresses within a class C is still well within the range of IP filtering.  The attacker could then just log into a middle box outside the school to get around it.  So patching the hole(s) would be a smart parallel activity.

The nice thing about it being an email (and not shell) server is it&#039;s likely the permitted services would only be SMTP and POP/IMAP (maybe +SSL, but not likely).  This gives a lot of flexibility in filtering and patching to keep the system running while locking out an ongoing attack.

UW-Madison staff should be sentenced to play &lt;a href=&quot;http://citeseer.ist.psu.edu/cowan03defcon.html&quot; rel=&quot;nofollow&quot;&gt;CTF at Defcon&lt;/a&gt; every year.</description>
		<content:encoded><![CDATA[<p>Bob, nice thoughts.  I didn&#8217;t notice that this was a 7 year+ battle.  The biggest hole in the case for the electronic/physical search being necessary to protect the email server is that the admin demonstrated he had the ability and means to block the attack.  Changing IP addresses within a class C is still well within the range of IP filtering.  The attacker could then just log into a middle box outside the school to get around it.  So patching the hole(s) would be a smart parallel activity.</p>
<p>The nice thing about it being an email (and not shell) server is it&#8217;s likely the permitted services would only be SMTP and POP/IMAP (maybe +SSL, but not likely).  This gives a lot of flexibility in filtering and patching to keep the system running while locking out an ongoing attack.</p>
<p>UW-Madison staff should be sentenced to play <a href="http://citeseer.ist.psu.edu/cowan03defcon.html" rel="nofollow">CTF at Defcon</a> every year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob Plankers</title>
		<link>http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-495</link>
		<dc:creator>Bob Plankers</dc:creator>
		<pubDate>Thu, 12 Apr 2007 02:18:47 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-495</guid>
		<description>One thing to remember is that this was quite a while ago. I am certainly not defending anybody&#039;s actions (not at all, don&#039;t even think that I am), but network security has come quite far since this whole thing started. Firewalls? Yeah, a reality now, not as common then. The server itself was AIX, and AIX didn&#039;t have host-based firewalling until last year (2006). There were certainly other methods available, though, like blackhole routes, ACLs, wait for the FBI, etc.

Another thing to consider is common carrier law. The UW-Madison, as with many institutions, walks a narrow line between the pressures of keeping an orderly, useful network and losing their defense as a &quot;common carrier&quot; for policing their network. The UW-Madison is doing some good anti-RIAA work in this regard (despite what the Wired article implies), and the policy is a lot more clear now. When Heckenkamp was terrorizing servers at the UW the policy was a lot less clear. Even law enforcement was relatively clueless about electronic issues back then, as compared to now. Getting them to do something was very, very hard, because they just didn&#039;t understand.

In this particular case both sides are equally dumb, for the lack of a better word. Heckenkamp couldn&#039;t be bothered to use common sense, like any of the points you outline above. Jeff Savoy gave Heckenkamp&#039;s defense attorneys enough ammunition for years of appeals. I don&#039;t like the idea that anybody was lucky with this judge. Justice isn&#039;t about luck, it is about proof (yeah, yeah, I know how it goes sometimes). Heckenkamp left a massive trail of electronic destruction, though, and it isn&#039;t hard to imagine that there was enough of it to point to him definitively. It was the collection of some of it that was in question, and almost ruined it.

I can imagine that there are a lot of folks, law enforcement and others, that breathed a sigh of relief at this ruling. Many people put a lot of time into collecting evidence only to have it jeopardized by a vigilante. That&#039;s why I have a hard time believing this will be a precedent. It worked this time, barely, but when you work hard on something you don&#039;t want your time to be wasted. I can envision future situations where the vigilante finds themselves fighting both the hacker and the law enforcement, with the vigilantes ending up in jail, too. Vigilantism will certainly not be a corporate policy, either. People want convictions, not eight year protracted legal battles.</description>
		<content:encoded><![CDATA[<p>One thing to remember is that this was quite a while ago. I am certainly not defending anybody&#8217;s actions (not at all, don&#8217;t even think that I am), but network security has come quite far since this whole thing started. Firewalls? Yeah, a reality now, not as common then. The server itself was AIX, and AIX didn&#8217;t have host-based firewalling until last year (2006). There were certainly other methods available, though, like blackhole routes, ACLs, wait for the FBI, etc.</p>
<p>Another thing to consider is common carrier law. The UW-Madison, as with many institutions, walks a narrow line between the pressures of keeping an orderly, useful network and losing their defense as a &#8220;common carrier&#8221; for policing their network. The UW-Madison is doing some good anti-RIAA work in this regard (despite what the Wired article implies), and the policy is a lot more clear now. When Heckenkamp was terrorizing servers at the UW the policy was a lot less clear. Even law enforcement was relatively clueless about electronic issues back then, as compared to now. Getting them to do something was very, very hard, because they just didn&#8217;t understand.</p>
<p>In this particular case both sides are equally dumb, for the lack of a better word. Heckenkamp couldn&#8217;t be bothered to use common sense, like any of the points you outline above. Jeff Savoy gave Heckenkamp&#8217;s defense attorneys enough ammunition for years of appeals. I don&#8217;t like the idea that anybody was lucky with this judge. Justice isn&#8217;t about luck, it is about proof (yeah, yeah, I know how it goes sometimes). Heckenkamp left a massive trail of electronic destruction, though, and it isn&#8217;t hard to imagine that there was enough of it to point to him definitively. It was the collection of some of it that was in question, and almost ruined it.</p>
<p>I can imagine that there are a lot of folks, law enforcement and others, that breathed a sigh of relief at this ruling. Many people put a lot of time into collecting evidence only to have it jeopardized by a vigilante. That&#8217;s why I have a hard time believing this will be a precedent. It worked this time, barely, but when you work hard on something you don&#8217;t want your time to be wasted. I can envision future situations where the vigilante finds themselves fighting both the hacker and the law enforcement, with the vigilantes ending up in jail, too. Vigilantism will certainly not be a corporate policy, either. People want convictions, not eight year protracted legal battles.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete Rittwage</title>
		<link>http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-480</link>
		<dc:creator>Pete Rittwage</dc:creator>
		<pubDate>Wed, 11 Apr 2007 13:15:57 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/04/10/bright-future-for-counter-attacks/#comment-480</guid>
		<description>They obviously have a &quot;good&quot; lawyer and were very lucky with this judge.  If they logged onto his computer remotely instead of just blocking the port when it could be proven that they can, then their argument does not stand up.  He should have a chance at a civil case against the University.  

Now, if they can prove they have no way to block the port or the traffic with any manner of security measures, then they should be held partially responsible for the intrusion as well.

Now the other problem is... This is now a precident.</description>
		<content:encoded><![CDATA[<p>They obviously have a &#8220;good&#8221; lawyer and were very lucky with this judge.  If they logged onto his computer remotely instead of just blocking the port when it could be proven that they can, then their argument does not stand up.  He should have a chance at a civil case against the University.  </p>
<p>Now, if they can prove they have no way to block the port or the traffic with any manner of security measures, then they should be held partially responsible for the intrusion as well.</p>
<p>Now the other problem is&#8230; This is now a precident.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
