<?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/"
		>
<channel>
	<title>Comments on: The problem of monoculture</title>
	<atom:link href="http://www.rentedmetal.com/the-problem-of-monoculture/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rentedmetal.com/the-problem-of-monoculture/</link>
	<description>Just because you don&#039;t own it, doesn&#039;t mean it&#039;s not your problem.</description>
	<lastBuildDate>Wed, 17 Mar 2010 14:02:52 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Steve Shah</title>
		<link>http://www.rentedmetal.com/the-problem-of-monoculture/comment-page-1/#comment-195</link>
		<dc:creator>Steve Shah</dc:creator>
		<pubDate>Thu, 03 Jul 2008 06:04:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.bitcurrent.com/?p=144#comment-195</guid>
		<description>This is actually a much older problem, one felt by large web sites and large ISPs. For example, the classic issue is where an attacker launching a an attack with IP addresses spoofed from AOL&#039;s proxy servers could make a poorly managed web site shut off what may have been one of its largest user bases. The inverse problem was seen in spam control -- casual glance of IP blocks for spam senders could make dumb spam catchers block off all of Hotmail.

The unfortunate answer to the question of dealing with bad guys is that you don&#039;t block at the network level. Your best bet is blocking at the application level, if you block at all. For spam control, it was the only method that is reliable. For attacks against web sites, filters on the HTTP protocol were the only way to cope with botnets flooding a site with bogus requests. The exception is human managed tables of networks that are considered &quot;bad&quot; -- spam control has used this with good results, but nice guys still get caught in friendly fire.</description>
		<content:encoded><![CDATA[<p>This is actually a much older problem, one felt by large web sites and large ISPs. For example, the classic issue is where an attacker launching a an attack with IP addresses spoofed from AOL&#8217;s proxy servers could make a poorly managed web site shut off what may have been one of its largest user bases. The inverse problem was seen in spam control &#8212; casual glance of IP blocks for spam senders could make dumb spam catchers block off all of Hotmail.</p>
<p>The unfortunate answer to the question of dealing with bad guys is that you don&#8217;t block at the network level. Your best bet is blocking at the application level, if you block at all. For spam control, it was the only method that is reliable. For attacks against web sites, filters on the HTTP protocol were the only way to cope with botnets flooding a site with bogus requests. The exception is human managed tables of networks that are considered &#8220;bad&#8221; &#8212; spam control has used this with good results, but nice guys still get caught in friendly fire.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
