<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_19_1243203</id>
	<title>Attack On a Significant Flaw In Apache Released</title>
	<author>kdawson</author>
	<datestamp>1245421020000</datestamp>
	<htmltext>Zerimar points out a <a href="http://isc.sans.org/"> significant flaw in Apache</a> that can lead to a fairly trivial DoS attack is <a href="http://ha.ckers.org/slowloris/">in the wild</a>. Apache 1.x, 2.x, dhttpd, GoAhead WebServer, and Squid are confirmed vulnerable, while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable. As of this writing, Apache Foundation does not have a patch available. From Rsnake's introduction to the attack tool: <i>"In considering the ramifications of a slow denial of service attack against particular services, rather than flooding networks, a concept emerged that would allow a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports. The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible. Slowloris was born from this concept, and is therefore relatively very stealthy compared to most flooding tools."</i></htmltext>
<tokenext>Zerimar points out a significant flaw in Apache that can lead to a fairly trivial DoS attack is in the wild .
Apache 1.x , 2.x , dhttpd , GoAhead WebServer , and Squid are confirmed vulnerable , while IIS6.0 , IIS7.0 , and lighttpd are confirmed not vulnerable .
As of this writing , Apache Foundation does not have a patch available .
From Rsnake 's introduction to the attack tool : " In considering the ramifications of a slow denial of service attack against particular services , rather than flooding networks , a concept emerged that would allow a single machine to take down another machine 's web server with minimal bandwidth and side effects on unrelated services and ports .
The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible .
Slowloris was born from this concept , and is therefore relatively very stealthy compared to most flooding tools .
"</tokentext>
<sentencetext>Zerimar points out a  significant flaw in Apache that can lead to a fairly trivial DoS attack is in the wild.
Apache 1.x, 2.x, dhttpd, GoAhead WebServer, and Squid are confirmed vulnerable, while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable.
As of this writing, Apache Foundation does not have a patch available.
From Rsnake's introduction to the attack tool: "In considering the ramifications of a slow denial of service attack against particular services, rather than flooding networks, a concept emerged that would allow a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports.
The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible.
Slowloris was born from this concept, and is therefore relatively very stealthy compared to most flooding tools.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392029</id>
	<title>Re:WTH? This is an absolutely trivial attack</title>
	<author>anomalizer</author>
	<datestamp>1245435300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I cannot believe that in this day and age, people have not come across this simple attack. Wonder why this is even considered a discovery.</htmltext>
<tokenext>I can not believe that in this day and age , people have not come across this simple attack .
Wonder why this is even considered a discovery .</tokentext>
<sentencetext>I cannot believe that in this day and age, people have not come across this simple attack.
Wonder why this is even considered a discovery.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389705</id>
	<title>Proof Of Concept</title>
	<author>calcio</author>
	<datestamp>1245425340000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext>We have a proof of concept exploit for this vulnerability at <a href="http://security.precor-incorporated.com/" title="precor-incorporated.com" rel="nofollow">http://security.precor-incorporated.com/</a> [precor-incorporated.com]</htmltext>
<tokenext>We have a proof of concept exploit for this vulnerability at http : //security.precor-incorporated.com/ [ precor-incorporated.com ]</tokentext>
<sentencetext>We have a proof of concept exploit for this vulnerability at http://security.precor-incorporated.com/ [precor-incorporated.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391993</id>
	<title>Re:Why not IIS?</title>
	<author>PitaBred</author>
	<datestamp>1245435120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Doesn't IIS leave sessions "half open" generally? Some kind of IE accelerator trick? Or did they stop doing that?</htmltext>
<tokenext>Does n't IIS leave sessions " half open " generally ?
Some kind of IE accelerator trick ?
Or did they stop doing that ?</tokentext>
<sentencetext>Doesn't IIS leave sessions "half open" generally?
Some kind of IE accelerator trick?
Or did they stop doing that?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739</id>
	<title>Re:Possible work-around</title>
	<author>Anonymous</author>
	<datestamp>1245433920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why would you ever need a timeout that high?  When is a 30 second timeout not enough?</p></htmltext>
<tokenext>Why would you ever need a timeout that high ?
When is a 30 second timeout not enough ?</tokentext>
<sentencetext>Why would you ever need a timeout that high?
When is a 30 second timeout not enough?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389809</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393465</id>
	<title>Re:Why wouldn't the following setting</title>
	<author>Anonymous</author>
	<datestamp>1245441000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's a per-packet timeout and not an overall request timeout.</p></htmltext>
<tokenext>That 's a per-packet timeout and not an overall request timeout .</tokentext>
<sentencetext>That's a per-packet timeout and not an overall request timeout.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390165</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28399643</id>
	<title>bubbles, bugs and glitches</title>
	<author>coward901283</author>
	<datestamp>1245439020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>the bubble: everyone is vulnerable. well at least one year ago (or something) every kind of http server was.

the bug: there is no bug. this is one of the flaws we live with that would require on-the-fly fixes (by sysadmin). im not sure how this became a news headline. ah wait. i also remember the "dns exploit" that was (re-)"discovered" and "fixed" by cisco,microsoft and some john doe. i also remember djb telling them ages before about it - and ofcourse providing the fix as well. but no one heard about it until the companies decided they're ready to make some profit from it. open your eyes, people.

the glitch: there is. a quite-general fix was described above by someone (killing the oldest unfinished requests) but on a heavy attack this could also kill legit requests. one should really customize a tcp pattern-based filter depending on the attack combined with safe application layer rules.

p.s.
the "timeout" settings are useless. you can fingerprint that and force timeout resets on the server side with minimum bandwidth consumptions. see an old article with source code, etc (i think you need to fix a small compilation error to be able to use it): <a href="http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html" title="pub.mud.ro" rel="nofollow">http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html</a> [pub.mud.ro]</htmltext>
<tokenext>the bubble : everyone is vulnerable .
well at least one year ago ( or something ) every kind of http server was .
the bug : there is no bug .
this is one of the flaws we live with that would require on-the-fly fixes ( by sysadmin ) .
im not sure how this became a news headline .
ah wait .
i also remember the " dns exploit " that was ( re- ) " discovered " and " fixed " by cisco,microsoft and some john doe .
i also remember djb telling them ages before about it - and ofcourse providing the fix as well .
but no one heard about it until the companies decided they 're ready to make some profit from it .
open your eyes , people .
the glitch : there is .
a quite-general fix was described above by someone ( killing the oldest unfinished requests ) but on a heavy attack this could also kill legit requests .
one should really customize a tcp pattern-based filter depending on the attack combined with safe application layer rules .
p.s . the " timeout " settings are useless .
you can fingerprint that and force timeout resets on the server side with minimum bandwidth consumptions .
see an old article with source code , etc ( i think you need to fix a small compilation error to be able to use it ) : http : //pub.mud.ro/ ~ cia/computing/apache-httpd-denial-of-service-example.html [ pub.mud.ro ]</tokentext>
<sentencetext>the bubble: everyone is vulnerable.
well at least one year ago (or something) every kind of http server was.
the bug: there is no bug.
this is one of the flaws we live with that would require on-the-fly fixes (by sysadmin).
im not sure how this became a news headline.
ah wait.
i also remember the "dns exploit" that was (re-)"discovered" and "fixed" by cisco,microsoft and some john doe.
i also remember djb telling them ages before about it - and ofcourse providing the fix as well.
but no one heard about it until the companies decided they're ready to make some profit from it.
open your eyes, people.
the glitch: there is.
a quite-general fix was described above by someone (killing the oldest unfinished requests) but on a heavy attack this could also kill legit requests.
one should really customize a tcp pattern-based filter depending on the attack combined with safe application layer rules.
p.s.
the "timeout" settings are useless.
you can fingerprint that and force timeout resets on the server side with minimum bandwidth consumptions.
see an old article with source code, etc (i think you need to fix a small compilation error to be able to use it): http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html [pub.mud.ro]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392391</id>
	<title>I am perplexed...</title>
	<author>Anonymous</author>
	<datestamp>1245436740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>.. as to how this even managed to get onto slashdot, but I suppose this is not the first time this has happened either.</p><p>If the entire script kiddie populous would utilize this method for attacking webservers, every sysadmins job would get a whole lot simpler. You don't need DoS mitigation devices to protect yourself against this attack, you can run a cron'd shell script that would do the same, or a single iptables rule that limits the amount of connections made per second.</p><p>Even in a DDoS scenario, this is trivial to protect against, considering it cannot be spoofed.</p><p>If more people would have experience with attempting to deal with spoofed syn flood DDoS's against HTTP, maybe less people would actually pay attention to something as ridiculous as this.</p><p>Also to note, there's a reason why the author of the security focus article titled it as 'a cheesy Apache / IIS DoS vuln..'.</p><p>gg</p></htmltext>
<tokenext>.. as to how this even managed to get onto slashdot , but I suppose this is not the first time this has happened either.If the entire script kiddie populous would utilize this method for attacking webservers , every sysadmins job would get a whole lot simpler .
You do n't need DoS mitigation devices to protect yourself against this attack , you can run a cron 'd shell script that would do the same , or a single iptables rule that limits the amount of connections made per second.Even in a DDoS scenario , this is trivial to protect against , considering it can not be spoofed.If more people would have experience with attempting to deal with spoofed syn flood DDoS 's against HTTP , maybe less people would actually pay attention to something as ridiculous as this.Also to note , there 's a reason why the author of the security focus article titled it as 'a cheesy Apache / IIS DoS vuln..'.gg</tokentext>
<sentencetext>.. as to how this even managed to get onto slashdot, but I suppose this is not the first time this has happened either.If the entire script kiddie populous would utilize this method for attacking webservers, every sysadmins job would get a whole lot simpler.
You don't need DoS mitigation devices to protect yourself against this attack, you can run a cron'd shell script that would do the same, or a single iptables rule that limits the amount of connections made per second.Even in a DDoS scenario, this is trivial to protect against, considering it cannot be spoofed.If more people would have experience with attempting to deal with spoofed syn flood DDoS's against HTTP, maybe less people would actually pay attention to something as ridiculous as this.Also to note, there's a reason why the author of the security focus article titled it as 'a cheesy Apache / IIS DoS vuln..'.gg</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390493</id>
	<title>Re:Why not IIS?</title>
	<author>cyberfr0g</author>
	<datestamp>1245428520000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Butthurt much?</p></htmltext>
<tokenext>Butthurt much ?</tokentext>
<sentencetext>Butthurt much?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101</id>
	<title>HTTP hints at a solution</title>
	<author>greed</author>
	<datestamp>1245426840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>
<a href="http://www.rfc-editor.org/rfc/rfc2616.txt" title="rfc-editor.org">HTTP 1.1</a> [rfc-editor.org] specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).
</p><p>
What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body.  The timer for the body can be controlled by the type of request and the Content-Length header.  (With, of course, a specific cap.)
</p><p>
Currently, <a href="http://httpd.apache.org/docs/2.2/mod/core.html#timeout" title="apache.org">Apache 2.2</a> [apache.org] has a single timeout value for all types of requests, but it is interpreted differently for the different types.
</p><p>
If your server only handles GETs, the obvious thing is to crank that number down.  Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.
</p><p>
Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received.  Oh dear.  That's an even simpler DoS.</p><blockquote><div><p> <tt>#!/usr/bin/env perl<br> <br>use IO::Socket::INET;<br>use strict;<br>use constant DEFAULT\_PORT =&gt; "http";<br> <br>MAIN: {<br> if(@ARGV&lt;1 or @ARGV&gt;2) {<br>  die "Usage: $0 host [port]\n";<br> }<br> my($host)=shift;<br> my($port)=@ARGV?shift:DEFAULT\_PORT;<br> <br> my(@sockets);<br> <br> for(my $cnt=0;$cnt&lt;1000;++$cnt) {<br>  my $socket=new IO::Socket::INET(PeerAddr=&gt;$host,<br>          PeerPort=&gt;$port,<br>          Proto=&gt;"tcp");<br>  unless(defined($socket)) {<br>   die "Cannot create socket to $host:$port--$!\n";<br>  }<br>  $socket-&gt;print("\r\n");<br>  push(@sockets,$socket);<br>  print " Have ".@sockets." open.\n";<br> }<br>}</tt></p></div> </blockquote><p>
Not quite as stealthy, though.  At least as above.</p></div>
	</htmltext>
<tokenext>HTTP 1.1 [ rfc-editor.org ] specifies a status code for " Request Timeout " ( 408 ) and " Gateway Timeout " ( 504 ) .
What is needed , therefore , is a timer running for receiving the complete header , and a second one for accepting the body .
The timer for the body can be controlled by the type of request and the Content-Length header .
( With , of course , a specific cap .
) Currently , Apache 2.2 [ apache.org ] has a single timeout value for all types of requests , but it is interpreted differently for the different types .
If your server only handles GETs , the obvious thing is to crank that number down .
Unfortunately , for PUTs , the TimeOut value affects inter-packet time in the request , not overall request time .
Strangely , the timeout does n't seem to run in 2.2.10 and 2.2.11 before data is received .
Oh dear .
That 's an even simpler DoS .
# ! /usr/bin/env perl use IO : : Socket : : INET ; use strict ; use constant DEFAULT \ _PORT = &gt; " http " ; MAIN : { if ( @ ARGV2 ) { die " Usage : $ 0 host [ port ] \ n " ; } my ( $ host ) = shift ; my ( $ port ) = @ ARGV ? shift : DEFAULT \ _PORT ; my ( @ sockets ) ; for ( my $ cnt = 0 ; $ cnt my $ socket = new IO : : Socket : : INET ( PeerAddr = &gt; $ host , PeerPort = &gt; $ port , Proto = &gt; " tcp " ) ; unless ( defined ( $ socket ) ) { die " Can not create socket to $ host : $ port-- $ ! \ n " ; } $ socket- &gt; print ( " \ r \ n " ) ; push ( @ sockets , $ socket ) ; print " Have " . @ sockets .
" open. \ n " ; } } Not quite as stealthy , though .
At least as above .</tokentext>
<sentencetext>
HTTP 1.1 [rfc-editor.org] specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).
What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body.
The timer for the body can be controlled by the type of request and the Content-Length header.
(With, of course, a specific cap.
)

Currently, Apache 2.2 [apache.org] has a single timeout value for all types of requests, but it is interpreted differently for the different types.
If your server only handles GETs, the obvious thing is to crank that number down.
Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.
Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received.
Oh dear.
That's an even simpler DoS.
#!/usr/bin/env perl use IO::Socket::INET;use strict;use constant DEFAULT\_PORT =&gt; "http"; MAIN: { if(@ARGV2) {  die "Usage: $0 host [port]\n"; } my($host)=shift; my($port)=@ARGV?shift:DEFAULT\_PORT;  my(@sockets);  for(my $cnt=0;$cnt  my $socket=new IO::Socket::INET(PeerAddr=&gt;$host,          PeerPort=&gt;$port,          Proto=&gt;"tcp");  unless(defined($socket)) {   die "Cannot create socket to $host:$port--$!\n";  }  $socket-&gt;print("\r\n");  push(@sockets,$socket);  print " Have ".@sockets.
" open.\n"; }} 
Not quite as stealthy, though.
At least as above.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390337</id>
	<title>Re:OpenBSD's pf has some mitigation features</title>
	<author>Anonymous</author>
	<datestamp>1245427860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Since OpenBSD's version of httpd is basically a fork of regular Apache, has anyone tested this against OpenBSD's httpd?</p></htmltext>
<tokenext>Since OpenBSD 's version of httpd is basically a fork of regular Apache , has anyone tested this against OpenBSD 's httpd ?</tokentext>
<sentencetext>Since OpenBSD's version of httpd is basically a fork of regular Apache, has anyone tested this against OpenBSD's httpd?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389877</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392111</id>
	<title>Link to the specific article</title>
	<author>Megane</author>
	<datestamp>1245435660000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?
</p><p>Here is the link to the specific article: <a href="http://isc.sans.org/diary.html?storyid=6601" title="sans.org">http://isc.sans.org/diary.html?storyid=6601</a> [sans.org]</p></htmltext>
<tokenext>If you 're going to post links to isc.sans.org , can you please post links to the specific article , and not just the main page ?
Here is the link to the specific article : http : //isc.sans.org/diary.html ? storyid = 6601 [ sans.org ]</tokentext>
<sentencetext>If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?
Here is the link to the specific article: http://isc.sans.org/diary.html?storyid=6601 [sans.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737</id>
	<title>Seems to be a general problem.</title>
	<author>Z00L00K</author>
	<datestamp>1245425400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>And the only resolution right now that I can see is to have a connection timeout.</p><p>At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server. Not that you really want to restart it.</p><p>And I suspect that other services can be vulnerable to this type of attack too, not only web servers.</p></htmltext>
<tokenext>And the only resolution right now that I can see is to have a connection timeout.At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server .
Not that you really want to restart it.And I suspect that other services can be vulnerable to this type of attack too , not only web servers .</tokentext>
<sentencetext>And the only resolution right now that I can see is to have a connection timeout.At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server.
Not that you really want to restart it.And I suspect that other services can be vulnerable to this type of attack too, not only web servers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28401065</id>
	<title>flaw In Apache ?</title>
	<author>viralMeme</author>
	<datestamp>1245505560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This affects a number of webservers that use threaded processes and ironically attempt to limit that to prevent memory exhaustion - fixing one problem created another..<br> <br>

<strong>1</strong>. fingerprint the timeout on serverside<br>
<strong>2</strong>. dig the sitemap from target<br>
<strong>3</strong>. build a list of browsers to advertise to server during request<br>
<strong>4</strong>. buy proxies from black market<br>
<strong>5</strong>. start requests thru proxies to target</htmltext>
<tokenext>This affects a number of webservers that use threaded processes and ironically attempt to limit that to prevent memory exhaustion - fixing one problem created another. . 1. fingerprint the timeout on serverside 2. dig the sitemap from target 3. build a list of browsers to advertise to server during request 4. buy proxies from black market 5. start requests thru proxies to target</tokentext>
<sentencetext>This affects a number of webservers that use threaded processes and ironically attempt to limit that to prevent memory exhaustion - fixing one problem created another.. 

1. fingerprint the timeout on serverside
2. dig the sitemap from target
3. build a list of browsers to advertise to server during request
4. buy proxies from black market
5. start requests thru proxies to target</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389713</id>
	<title>Why isn't IIS affected?</title>
	<author>Anonymous</author>
	<datestamp>1245425340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Does it timeout the HTTP header from the initial open or what?</p></htmltext>
<tokenext>Does it timeout the HTTP header from the initial open or what ?</tokentext>
<sentencetext>Does it timeout the HTTP header from the initial open or what?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390017</id>
	<title>Re:Boring</title>
	<author>Anonymous</author>
	<datestamp>1245426540000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Of course it's boring to the<nobr> <wbr></nobr>/. crowd. It affects an open source product, so it must be boring. However, if the roles had been reversed and IIS was affected, everyone would be up in arms screaming defective by design etc. You people make me sick.</htmltext>
<tokenext>Of course it 's boring to the / .
crowd. It affects an open source product , so it must be boring .
However , if the roles had been reversed and IIS was affected , everyone would be up in arms screaming defective by design etc .
You people make me sick .</tokentext>
<sentencetext>Of course it's boring to the /.
crowd. It affects an open source product, so it must be boring.
However, if the roles had been reversed and IIS was affected, everyone would be up in arms screaming defective by design etc.
You people make me sick.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</id>
	<title>WTH?  This is an absolutely trivial attack</title>
	<author>Rogerborg</author>
	<datestamp>1245425280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>It's just holding sockets open; that's the "Hello, world!" of DOS attacks.

</p><p>I'm finding it hard to believe that Apache is genuinely vulnerable to this.  Did nobody see it coming?  For <em>real</em>?</p></htmltext>
<tokenext>It 's just holding sockets open ; that 's the " Hello , world !
" of DOS attacks .
I 'm finding it hard to believe that Apache is genuinely vulnerable to this .
Did nobody see it coming ?
For real ?</tokentext>
<sentencetext>It's just holding sockets open; that's the "Hello, world!
" of DOS attacks.
I'm finding it hard to believe that Apache is genuinely vulnerable to this.
Did nobody see it coming?
For real?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28456299</id>
	<title>Python based version of this attack method.</title>
	<author>Motoma</author>
	<datestamp>1245872040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There <a href="http://pyloris.sourceforge.net/" title="sourceforge.net" rel="nofollow">http://pyloris.sourceforge.net/</a> [sourceforge.net]</htmltext>
<tokenext>There http : //pyloris.sourceforge.net/ [ sourceforge.net ]</tokentext>
<sentencetext>There http://pyloris.sourceforge.net/ [sourceforge.net]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392027</id>
	<title>Re:Many othere services are probably vulnerable</title>
	<author>Akatosh</author>
	<datestamp>1245435300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oh, sendmail isn't probably 'vulnerable', it definitely is. That's why sendmail has FEATURE(`conncontrol',<nobr> <wbr></nobr>,`terminate'), to limit simultaneous sessions per client. Spammers have been abusing it for eons. I put vulnerable in quotes because that feature is configurable, but not a default. If your daemon doesn't have a way of dealing with these things (apache does with a module), there's always</p><p>iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP</p></htmltext>
<tokenext>Oh , sendmail is n't probably 'vulnerable ' , it definitely is .
That 's why sendmail has FEATURE ( ` conncontrol ' , , ` terminate ' ) , to limit simultaneous sessions per client .
Spammers have been abusing it for eons .
I put vulnerable in quotes because that feature is configurable , but not a default .
If your daemon does n't have a way of dealing with these things ( apache does with a module ) , there 's alwaysiptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP</tokentext>
<sentencetext>Oh, sendmail isn't probably 'vulnerable', it definitely is.
That's why sendmail has FEATURE(`conncontrol', ,`terminate'), to limit simultaneous sessions per client.
Spammers have been abusing it for eons.
I put vulnerable in quotes because that feature is configurable, but not a default.
If your daemon doesn't have a way of dealing with these things (apache does with a module), there's alwaysiptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 10 -j DROP</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389671</id>
	<title>Re:Well its not just Apache</title>
	<author>Anonymous</author>
	<datestamp>1245425160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>while IIS6.0, IIS7.0, and lighttpd are confirmed <b>not</b> vulnerable</i><br>You didnt even read the summary?!  Wow...</p></htmltext>
<tokenext>while IIS6.0 , IIS7.0 , and lighttpd are confirmed not vulnerableYou didnt even read the summary ? !
Wow.. .</tokentext>
<sentencetext>while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerableYou didnt even read the summary?!
Wow...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28395535</id>
	<title>Re:Other Web Servers....Proxies......?</title>
	<author>sakti</author>
	<datestamp>1245405060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; Nginx is a threaded web server...</p><p>I thought nginx was strictly an async based server like lighttpd? Every resource I find states this and the 2 are often compared due to this.</p></htmltext>
<tokenext>&gt; Nginx is a threaded web server...I thought nginx was strictly an async based server like lighttpd ?
Every resource I find states this and the 2 are often compared due to this .</tokentext>
<sentencetext>&gt; Nginx is a threaded web server...I thought nginx was strictly an async based server like lighttpd?
Every resource I find states this and the 2 are often compared due to this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390837</id>
	<title>Ideal Fix</title>
	<author>physburn</author>
	<datestamp>1245430140000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>0</modscore>
	<htmltext>The ideal fix, would be to have a variable timeout on open connection, depending on how many open ones there are.
A simple thing like auto timing out the oldest connection once the a near maximum number of connections are
open should be enough. Apache should also be  limit the number of connections from any one IP address, to a small number.

Hope  these go in Apache soon.</htmltext>
<tokenext>The ideal fix , would be to have a variable timeout on open connection , depending on how many open ones there are .
A simple thing like auto timing out the oldest connection once the a near maximum number of connections are open should be enough .
Apache should also be limit the number of connections from any one IP address , to a small number .
Hope these go in Apache soon .</tokentext>
<sentencetext>The ideal fix, would be to have a variable timeout on open connection, depending on how many open ones there are.
A simple thing like auto timing out the oldest connection once the a near maximum number of connections are
open should be enough.
Apache should also be  limit the number of connections from any one IP address, to a small number.
Hope  these go in Apache soon.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783</id>
	<title>Other Web Servers....Proxies......?</title>
	<author>segedunum</author>
	<datestamp>1245425640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Could you potentially get around this if you're proxying to another web server, say lighttpd or Mongrel, or will this just blanketly affected Apache if you have it in front? I'm gathering the latter from the article:<blockquote><div><p>At the moment I'm not sure what can be done in Apache's configuration to prevent this attack - increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.</p></div></blockquote><p>

Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server. I wonder how that fares?</p></div>
	</htmltext>
<tokenext>Could you potentially get around this if you 're proxying to another web server , say lighttpd or Mongrel , or will this just blanketly affected Apache if you have it in front ?
I 'm gathering the latter from the article : At the moment I 'm not sure what can be done in Apache 's configuration to prevent this attack - increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely .
One of our readers , Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server .
Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server .
I wonder how that fares ?</tokentext>
<sentencetext>Could you potentially get around this if you're proxying to another web server, say lighttpd or Mongrel, or will this just blanketly affected Apache if you have it in front?
I'm gathering the latter from the article:At the moment I'm not sure what can be done in Apache's configuration to prevent this attack - increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely.
One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.
Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server.
I wonder how that fares?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390553</id>
	<title>HTTP, not apache</title>
	<author>CarpetShark</author>
	<datestamp>1245428820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The article states that this is like a syn flood, but on the HTTP level, rather than the TCP level.  So essentially, it sounds like a flaw in previous understanding of HTTP, which will now be rectified by patching servers INCLUDING Apache.</p><p>It's a pity the reports of affected servers wasn't more comprehensive though; I'd like to know where Cherokee and nginx stand.</p></htmltext>
<tokenext>The article states that this is like a syn flood , but on the HTTP level , rather than the TCP level .
So essentially , it sounds like a flaw in previous understanding of HTTP , which will now be rectified by patching servers INCLUDING Apache.It 's a pity the reports of affected servers was n't more comprehensive though ; I 'd like to know where Cherokee and nginx stand .</tokentext>
<sentencetext>The article states that this is like a syn flood, but on the HTTP level, rather than the TCP level.
So essentially, it sounds like a flaw in previous understanding of HTTP, which will now be rectified by patching servers INCLUDING Apache.It's a pity the reports of affected servers wasn't more comprehensive though; I'd like to know where Cherokee and nginx stand.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389809</id>
	<title>Possible work-around</title>
	<author>Anonymous</author>
	<datestamp>1245425700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>From the source:<blockquote><div><p> <tt>if ( $delay &lt; 166 ) {<br>    print &lt;&lt;EOSUCKS2BU;<br>Since the timeout ended up being so small ($delay seconds) and it generally<br>takes between 200-500 threads for most servers and assuming any latency at<br>all... you might have trouble using Slowloris against this target. You can<br>tweak the -tcpto flag down to 1 second but it still may not build the sockets<br>in time.<br>EOSUCKS2BU<br>  }</tt></p></div> </blockquote><p>Lower Apache's timeout to below 166 seconds.</p></div>
	</htmltext>
<tokenext>From the source : if ( $ delay print Since the timeout ended up being so small ( $ delay seconds ) and it generallytakes between 200-500 threads for most servers and assuming any latency atall... you might have trouble using Slowloris against this target .
You cantweak the -tcpto flag down to 1 second but it still may not build the socketsin time.EOSUCKS2BU } Lower Apache 's timeout to below 166 seconds .</tokentext>
<sentencetext>From the source: if ( $delay     print Since the timeout ended up being so small ($delay seconds) and it generallytakes between 200-500 threads for most servers and assuming any latency atall... you might have trouble using Slowloris against this target.
You cantweak the -tcpto flag down to 1 second but it still may not build the socketsin time.EOSUCKS2BU  } Lower Apache's timeout to below 166 seconds.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391283</id>
	<title>Re:WTH? This is an absolutely trivial attack</title>
	<author>suso</author>
	<datestamp>1245432000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Yes, I agree.  I've seen a handful of attacks like this over the years.  Maybe not exactly this one, but Apache has been vulnerable to this for years and I thought all webservers were.  And I thought people just knew about it already.  This one is a tough one to fix, its not like Apache can just patch something.  It sounds like an architectural change is needed.</p></htmltext>
<tokenext>Yes , I agree .
I 've seen a handful of attacks like this over the years .
Maybe not exactly this one , but Apache has been vulnerable to this for years and I thought all webservers were .
And I thought people just knew about it already .
This one is a tough one to fix , its not like Apache can just patch something .
It sounds like an architectural change is needed .</tokentext>
<sentencetext>Yes, I agree.
I've seen a handful of attacks like this over the years.
Maybe not exactly this one, but Apache has been vulnerable to this for years and I thought all webservers were.
And I thought people just knew about it already.
This one is a tough one to fix, its not like Apache can just patch something.
It sounds like an architectural change is needed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390547</id>
	<title>Am i the only one who thinks that it's retarded...</title>
	<author>Anonymous</author>
	<datestamp>1245428820000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>that I should have to reboot my MacBook for a freaking web browser update?  And a minor release, at that.  I just rebooted last week for a damned QuickTime update (also ridiculous).  Come on, Apple engineers.  Get your freaking head in the game!</p></htmltext>
<tokenext>that I should have to reboot my MacBook for a freaking web browser update ?
And a minor release , at that .
I just rebooted last week for a damned QuickTime update ( also ridiculous ) .
Come on , Apple engineers .
Get your freaking head in the game !</tokentext>
<sentencetext>that I should have to reboot my MacBook for a freaking web browser update?
And a minor release, at that.
I just rebooted last week for a damned QuickTime update (also ridiculous).
Come on, Apple engineers.
Get your freaking head in the game!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</id>
	<title>Why not IIS?</title>
	<author>MBCook</author>
	<datestamp>1245425340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Why isn't IIS vulnerable? Does it just assume the headers are done after some amount of time? Does it have a limit to the number of headers it accepts?</p><p>Can this even be fixed without technically breaking the protocol (since it sounds like what's going on is correct behavior, theoretically)?</p></htmltext>
<tokenext>Why is n't IIS vulnerable ?
Does it just assume the headers are done after some amount of time ?
Does it have a limit to the number of headers it accepts ? Can this even be fixed without technically breaking the protocol ( since it sounds like what 's going on is correct behavior , theoretically ) ?</tokentext>
<sentencetext>Why isn't IIS vulnerable?
Does it just assume the headers are done after some amount of time?
Does it have a limit to the number of headers it accepts?Can this even be fixed without technically breaking the protocol (since it sounds like what's going on is correct behavior, theoretically)?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391121</id>
	<title>Re:Why not IIS?</title>
	<author>Anonymous</author>
	<datestamp>1245431340000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><blockquote><div><p>Why isn't IIS vulnerable</p></div></blockquote><p>
My guess is that the DoS attack is so slow that, by the time it would have completed, the server has already crashed for a different reason.</p></div>
	</htmltext>
<tokenext>Why is n't IIS vulnerable My guess is that the DoS attack is so slow that , by the time it would have completed , the server has already crashed for a different reason .</tokentext>
<sentencetext>Why isn't IIS vulnerable
My guess is that the DoS attack is so slow that, by the time it would have completed, the server has already crashed for a different reason.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391669</id>
	<title>Re:Boring</title>
	<author>amicusNYCL</author>
	<datestamp>1245433680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>fairly trivial to fix<nobr> <wbr></nobr>...<br>I'd be embarrassed to publish something like this</p></div><p>So why isn't it fixed?  Let me guess: it's a case of all of the Apache developers saying "you have access to the code, <i>you</i> fix it, it's trivial."</p></div>
	</htmltext>
<tokenext>fairly trivial to fix ...I 'd be embarrassed to publish something like thisSo why is n't it fixed ?
Let me guess : it 's a case of all of the Apache developers saying " you have access to the code , you fix it , it 's trivial .
"</tokentext>
<sentencetext>fairly trivial to fix ...I'd be embarrassed to publish something like thisSo why isn't it fixed?
Let me guess: it's a case of all of the Apache developers saying "you have access to the code, you fix it, it's trivial.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390165</id>
	<title>Why wouldn't the following setting</title>
	<author>McNihil</author>
	<datestamp>1245427140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>mitigate it somewhat:</p><p>In httpd.conf</p><p>#<br># Timeout: The number of seconds before receives and sends time out.<br>#<br>Timeout 120</p><p>Unless of course this timeout is for after the header is received only... which I don't think it is... but as they say... assumption is the mother of all f*ckups.</p></htmltext>
<tokenext>mitigate it somewhat : In httpd.conf # # Timeout : The number of seconds before receives and sends time out. # Timeout 120Unless of course this timeout is for after the header is received only... which I do n't think it is... but as they say... assumption is the mother of all f * ckups .</tokentext>
<sentencetext>mitigate it somewhat:In httpd.conf## Timeout: The number of seconds before receives and sends time out.#Timeout 120Unless of course this timeout is for after the header is received only... which I don't think it is... but as they say... assumption is the mother of all f*ckups.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394311</id>
	<title>Re:Possible work-around</title>
	<author>KingMotley</author>
	<datestamp>1245444000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Many many times, actually.</p></htmltext>
<tokenext>Many many times , actually .</tokentext>
<sentencetext>Many many times, actually.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389693</id>
	<title>Re:Well its not just Apache</title>
	<author>Anonymous</author>
	<datestamp>1245425280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>RTFS</p><p>"while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable"</p></htmltext>
<tokenext>RTFS " while IIS6.0 , IIS7.0 , and lighttpd are confirmed not vulnerable "</tokentext>
<sentencetext>RTFS"while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369</id>
	<title>Re:So slashdot...</title>
	<author>jamie</author>
	<datestamp>1245427980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.
</p><p>I kinda doubt this would work on us.
</p><p>Note, I am not inviting anyone to try. It might work great for all I know<nobr> <wbr></nobr>:(</p></htmltext>
<tokenext>We have a hardware load-balancer and a software reverse proxy ( varnish ) in front of our apache .
I kinda doubt this would work on us .
Note , I am not inviting anyone to try .
It might work great for all I know : (</tokentext>
<sentencetext>We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.
I kinda doubt this would work on us.
Note, I am not inviting anyone to try.
It might work great for all I know :(</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390209</id>
	<title>Re:Why not IIS?</title>
	<author>Amouth</author>
	<datestamp>1245427380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>unless you are using Session()'s in asp in IIS then one thread in IIS handles multiple connections.</p><p>what this is doing is opening a connection (getting a thread to work it) and holding it open (keeping the thread busy)  and just keep asking for new ones.</p><p>it is very common (always i think) for Apache and allot of web servers to have a max thread's so that the site under heavy traffic doesn't open more connections than it can handle.</p><p>where IIS also has a worker thread limit - there is no limit *(you can set one - but not on by default) on how many concurrent connections can be managed by a thread (and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections)..</p><p>if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..</p><p>where apache would slowly lose access to workable threads as this keeps them busy.</p><p>this isn't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it's best practices for managing it.</p></htmltext>
<tokenext>unless you are using Session ( ) 's in asp in IIS then one thread in IIS handles multiple connections.what this is doing is opening a connection ( getting a thread to work it ) and holding it open ( keeping the thread busy ) and just keep asking for new ones.it is very common ( always i think ) for Apache and allot of web servers to have a max thread 's so that the site under heavy traffic does n't open more connections than it can handle.where IIS also has a worker thread limit - there is no limit * ( you can set one - but not on by default ) on how many concurrent connections can be managed by a thread ( and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections ) ..if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..where apache would slowly lose access to workable threads as this keeps them busy.this is n't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it 's best practices for managing it .</tokentext>
<sentencetext>unless you are using Session()'s in asp in IIS then one thread in IIS handles multiple connections.what this is doing is opening a connection (getting a thread to work it) and holding it open (keeping the thread busy)  and just keep asking for new ones.it is very common (always i think) for Apache and allot of web servers to have a max thread's so that the site under heavy traffic doesn't open more connections than it can handle.where IIS also has a worker thread limit - there is no limit *(you can set one - but not on by default) on how many concurrent connections can be managed by a thread (and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections)..if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..where apache would slowly lose access to workable threads as this keeps them busy.this isn't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it's best practices for managing it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396859</id>
	<title>Re:So slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1245411120000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Wow, you were quick to crawl out of the woodwork for that wankfest of a comment, weren't you?</p></htmltext>
<tokenext>Wow , you were quick to crawl out of the woodwork for that wankfest of a comment , were n't you ?</tokentext>
<sentencetext>Wow, you were quick to crawl out of the woodwork for that wankfest of a comment, weren't you?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390835</id>
	<title>DDOS!</title>
	<author>GNUPublicLicense</author>
	<datestamp>1245430140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Oh God! Apache web server having a security hole!
Better write this day down. The others web servers have already an endless list of days written down, and they are not deployed like apache...</htmltext>
<tokenext>Oh God !
Apache web server having a security hole !
Better write this day down .
The others web servers have already an endless list of days written down , and they are not deployed like apache.. .</tokentext>
<sentencetext>Oh God!
Apache web server having a security hole!
Better write this day down.
The others web servers have already an endless list of days written down, and they are not deployed like apache...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391979</id>
	<title>Re:Many othere services are probably vulnerable</title>
	<author>Anonymous</author>
	<datestamp>1245435060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Are you referring to SYN flooding, grandpa?</p></htmltext>
<tokenext>Are you referring to SYN flooding , grandpa ?</tokentext>
<sentencetext>Are you referring to SYN flooding, grandpa?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390253</id>
	<title>What a timely posting (not)</title>
	<author>BuhDuh</author>
	<datestamp>1245427560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>2009-06-18 15:25:37 New Apache DOS Tool (Index,The Internet) (pending)</htmltext>
<tokenext>2009-06-18 15 : 25 : 37 New Apache DOS Tool ( Index,The Internet ) ( pending )</tokentext>
<sentencetext>2009-06-18 15:25:37 New Apache DOS Tool (Index,The Internet) (pending)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</id>
	<title>Well its not just Apache</title>
	<author>Chrisq</author>
	<datestamp>1245425040000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext>It is clear that this is not an Apache but web servers in general, with IIS also being affected. Now I wonder which will issue a security patch first</htmltext>
<tokenext>It is clear that this is not an Apache but web servers in general , with IIS also being affected .
Now I wonder which will issue a security patch first</tokentext>
<sentencetext>It is clear that this is not an Apache but web servers in general, with IIS also being affected.
Now I wonder which will issue a security patch first</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390043</id>
	<title>Re:Seems to be a general problem.</title>
	<author>sjames</author>
	<datestamp>1245426660000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>A connection timeout should be fine. Just start the clock upon accept(). Give the client a generous but limited amount of time to send headers. If the timer expires before the empty line is received, close the connection.</p><p>Bonus points for not getting the thread pool involved until the header is complete.</p><p>Extra credit for a config option to send a flood of junk to the client and THEN close the socket. That could make attackers considerably more visible to their upstream provider.</p></htmltext>
<tokenext>A connection timeout should be fine .
Just start the clock upon accept ( ) .
Give the client a generous but limited amount of time to send headers .
If the timer expires before the empty line is received , close the connection.Bonus points for not getting the thread pool involved until the header is complete.Extra credit for a config option to send a flood of junk to the client and THEN close the socket .
That could make attackers considerably more visible to their upstream provider .</tokentext>
<sentencetext>A connection timeout should be fine.
Just start the clock upon accept().
Give the client a generous but limited amount of time to send headers.
If the timer expires before the empty line is received, close the connection.Bonus points for not getting the thread pool involved until the header is complete.Extra credit for a config option to send a flood of junk to the client and THEN close the socket.
That could make attackers considerably more visible to their upstream provider.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397757</id>
	<title>Hmm.</title>
	<author>reiisi</author>
	<datestamp>1245417600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It seems to me that if you have a single thread responding to multiple requests, a single slip in the code anywhere past the the pool is going to open every connection to the pool to every other.</p><p>If not, the pool will have to have some sort of wall between connections, and there will be a way to attack the wall.</p><p>Thus, IIS may not be "vulnerable" to this version of the attack, but it will be vulnerable to an attack modified to whatever attempt IIS makes at putting up a wall, and it will also (because we know that no programer or pool of programers is perfect) be vulnerable to all sorts of cross-talk between connections.</p></htmltext>
<tokenext>It seems to me that if you have a single thread responding to multiple requests , a single slip in the code anywhere past the the pool is going to open every connection to the pool to every other.If not , the pool will have to have some sort of wall between connections , and there will be a way to attack the wall.Thus , IIS may not be " vulnerable " to this version of the attack , but it will be vulnerable to an attack modified to whatever attempt IIS makes at putting up a wall , and it will also ( because we know that no programer or pool of programers is perfect ) be vulnerable to all sorts of cross-talk between connections .</tokentext>
<sentencetext>It seems to me that if you have a single thread responding to multiple requests, a single slip in the code anywhere past the the pool is going to open every connection to the pool to every other.If not, the pool will have to have some sort of wall between connections, and there will be a way to attack the wall.Thus, IIS may not be "vulnerable" to this version of the attack, but it will be vulnerable to an attack modified to whatever attempt IIS makes at putting up a wall, and it will also (because we know that no programer or pool of programers is perfect) be vulnerable to all sorts of cross-talk between connections.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390209</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390057</id>
	<title>Lingering connections handling</title>
	<author>moon3</author>
	<datestamp>1245426660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>If you keep lingerers for more then 160 seconds then no wonder this is possible. <br> <br>It should be non-issues on better designed servers that keep an eye on connections anyway. Any single IP spawning lots of unfinished connections gets flagged fast and remembered for the future, so it will get limited access and bandwidth, marked as abuser etc. This is serving 101.</htmltext>
<tokenext>If you keep lingerers for more then 160 seconds then no wonder this is possible .
It should be non-issues on better designed servers that keep an eye on connections anyway .
Any single IP spawning lots of unfinished connections gets flagged fast and remembered for the future , so it will get limited access and bandwidth , marked as abuser etc .
This is serving 101 .</tokentext>
<sentencetext>If you keep lingerers for more then 160 seconds then no wonder this is possible.
It should be non-issues on better designed servers that keep an eye on connections anyway.
Any single IP spawning lots of unfinished connections gets flagged fast and remembered for the future, so it will get limited access and bandwidth, marked as abuser etc.
This is serving 101.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390457</id>
	<title>It dont want to work for me</title>
	<author>Anonymous</author>
	<datestamp>1245428400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Apache 2.2.10 mpm\_worker, anyone know how to set up that lil script to DoS it ? ive tried setting 10000 connections and its still dont want to stop working</p></htmltext>
<tokenext>Apache 2.2.10 mpm \ _worker , anyone know how to set up that lil script to DoS it ?
ive tried setting 10000 connections and its still dont want to stop working</tokentext>
<sentencetext>Apache 2.2.10 mpm\_worker, anyone know how to set up that lil script to DoS it ?
ive tried setting 10000 connections and its still dont want to stop working</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394203</id>
	<title>Re:HTTP hints at a solution</title>
	<author>Covener</author>
	<datestamp>1245443640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe you're on an OS with a dataready or HTTP accept filter. Timeout applies to reading the entire first line of the request.</p></htmltext>
<tokenext>Maybe you 're on an OS with a dataready or HTTP accept filter .
Timeout applies to reading the entire first line of the request .</tokentext>
<sentencetext>Maybe you're on an OS with a dataready or HTTP accept filter.
Timeout applies to reading the entire first line of the request.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390791</id>
	<title>Re:Seems to be a general problem.</title>
	<author>Anonymous</author>
	<datestamp>1245429900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified</p></div><p>That's not necessarily true. As <a href="http://ha.ckers.org/blog/20090504/using-denial-of-service-for-hacking/" title="ckers.org" rel="nofollow">another blog post</a> [ckers.org] (linked to from TFA) points out, DoS attacks can be used to facilitate intrusions in cases where timing is of importance or used as a diversion.</p></div>
	</htmltext>
<tokenext>At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectifiedThat 's not necessarily true .
As another blog post [ ckers.org ] ( linked to from TFA ) points out , DoS attacks can be used to facilitate intrusions in cases where timing is of importance or used as a diversion .</tokentext>
<sentencetext>At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectifiedThat's not necessarily true.
As another blog post [ckers.org] (linked to from TFA) points out, DoS attacks can be used to facilitate intrusions in cases where timing is of importance or used as a diversion.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389733</id>
	<title>iptables helps</title>
	<author>samjam</author>
	<datestamp>1245425400000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this</p><p># iptables -t nat -A -PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80</p><p>and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.</p></htmltext>
<tokenext>You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this # iptables -t nat -A -PREROUTING -d !
127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80and then you do n't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config .</tokentext>
<sentencetext>You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this# iptables -t nat -A -PREROUTING -d !
127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389665</id>
	<title>Re:Well its not just Apache</title>
	<author>The End Of Days</author>
	<datestamp>1245425160000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>You may have missed the 'not' in the summary there.</p></htmltext>
<tokenext>You may have missed the 'not ' in the summary there .</tokentext>
<sentencetext>You may have missed the 'not' in the summary there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091</id>
	<title>Not a flaw, easily configured around</title>
	<author>Anonymous</author>
	<datestamp>1245426780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>http://httpd.apache.org/docs/2.2/mod/core.html#timeout</p><p>The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time.  Drop that from 300 to 5, and the "attack" goes away.  If you are running the default Apache config in production, you shouldn't be.</p></htmltext>
<tokenext>http : //httpd.apache.org/docs/2.2/mod/core.html # timeoutThe issue is that the default configuration waits 5 minutes for the full request , which is painfully to long a period of time .
Drop that from 300 to 5 , and the " attack " goes away .
If you are running the default Apache config in production , you should n't be .</tokentext>
<sentencetext>http://httpd.apache.org/docs/2.2/mod/core.html#timeoutThe issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time.
Drop that from 300 to 5, and the "attack" goes away.
If you are running the default Apache config in production, you shouldn't be.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389679</id>
	<title>Re:Well its not just Apache</title>
	<author>Anonymous</author>
	<datestamp>1245425220000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext>IIS <b>not</b> affected <br> learn to read</htmltext>
<tokenext>IIS not affected learn to read</tokentext>
<sentencetext>IIS not affected  learn to read</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393873</id>
	<title>(Un)fortunately, lighttpd is not vulnerable</title>
	<author>Xtifr</author>
	<datestamp>1245442500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I might subscribe to your theory if it weren't for the fact that <a href="http://www.lighttpd.net/" title="lighttpd.net">lighttpd</a> [lighttpd.net], which is a first-rate open-source web server, is explicitly listed as not vulnerable.</p></htmltext>
<tokenext>I might subscribe to your theory if it were n't for the fact that lighttpd [ lighttpd.net ] , which is a first-rate open-source web server , is explicitly listed as not vulnerable .</tokentext>
<sentencetext>I might subscribe to your theory if it weren't for the fact that lighttpd [lighttpd.net], which is a first-rate open-source web server, is explicitly listed as not vulnerable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389691</id>
	<title>What about ...</title>
	<author>Anonymous</author>
	<datestamp>1245425220000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>Opera Unite?</htmltext>
<tokenext>Opera Unite ?</tokentext>
<sentencetext>Opera Unite?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621</id>
	<title>So slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1245424920000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>be prepared to feel the slashdot-effect yourself for once!</htmltext>
<tokenext>be prepared to feel the slashdot-effect yourself for once !</tokentext>
<sentencetext>be prepared to feel the slashdot-effect yourself for once!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041</id>
	<title>Re:Why not IIS?</title>
	<author>Anonymous</author>
	<datestamp>1245426660000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>If the vulnerability is based on correct, standard conform behaviour of the server, I can see why IIS isn't susceptible to it.</p></htmltext>
<tokenext>If the vulnerability is based on correct , standard conform behaviour of the server , I can see why IIS is n't susceptible to it .</tokentext>
<sentencetext>If the vulnerability is based on correct, standard conform behaviour of the server, I can see why IIS isn't susceptible to it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390319</id>
	<title>I can just hear the words...</title>
	<author>petrus4</author>
	<datestamp>1245427740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>...of one of the 14 year olds who uses this, as she runs the script.</p><p>"Dodge this."<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>...of one of the 14 year olds who uses this , as she runs the script .
" Dodge this .
" ; )</tokentext>
<sentencetext>...of one of the 14 year olds who uses this, as she runs the script.
"Dodge this.
" ;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392153</id>
	<title>Re:Am i the only one who thinks that it's retarded</title>
	<author>Anonymous</author>
	<datestamp>1245435780000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>Well, come on, you're using a Mac.  It's not like you're doing any actual *work*...</htmltext>
<tokenext>Well , come on , you 're using a Mac .
It 's not like you 're doing any actual * work * .. .</tokentext>
<sentencetext>Well, come on, you're using a Mac.
It's not like you're doing any actual *work*...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719</id>
	<title>Boring</title>
	<author>Anonymous</author>
	<datestamp>1245425340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>Talk about a boring exploit: no chance for expanding the attack into anything other than a DOS, and if it becomes widespread enough, fairly trivial to fix... (just kill the oldest waiting client that does not have a full header when the last client is taken.) I'd be embarrassed to publish something like this....</htmltext>
<tokenext>Talk about a boring exploit : no chance for expanding the attack into anything other than a DOS , and if it becomes widespread enough , fairly trivial to fix... ( just kill the oldest waiting client that does not have a full header when the last client is taken .
) I 'd be embarrassed to publish something like this... .</tokentext>
<sentencetext>Talk about a boring exploit: no chance for expanding the attack into anything other than a DOS, and if it becomes widespread enough, fairly trivial to fix... (just kill the oldest waiting client that does not have a full header when the last client is taken.
) I'd be embarrassed to publish something like this....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390431</id>
	<title>Here it comes...</title>
	<author>Anonymous</author>
	<datestamp>1245428280000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Only 40 comments? OK, I will do my nerd duty and get the flame war started:<br> <br> <b>This event is proof that proprietary software is more secure that open source.</b> <br> <br>Next up: Emacs: better than vi or way better than vi?</htmltext>
<tokenext>Only 40 comments ?
OK , I will do my nerd duty and get the flame war started : This event is proof that proprietary software is more secure that open source .
Next up : Emacs : better than vi or way better than vi ?</tokentext>
<sentencetext>Only 40 comments?
OK, I will do my nerd duty and get the flame war started:  This event is proof that proprietary software is more secure that open source.
Next up: Emacs: better than vi or way better than vi?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391697</id>
	<title>Re:Seems to be a general problem.</title>
	<author>amicusNYCL</author>
	<datestamp>1245433800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>the damage is easily rectified - restart the web server</p></div><p>Good idea, mitigate a DoS attack by taking the server offline.</p></div>
	</htmltext>
<tokenext>the damage is easily rectified - restart the web serverGood idea , mitigate a DoS attack by taking the server offline .</tokentext>
<sentencetext>the damage is easily rectified - restart the web serverGood idea, mitigate a DoS attack by taking the server offline.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390921</id>
	<title>Re:Not a flaw, easily configured around</title>
	<author>dlgeek</author>
	<datestamp>1245430500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>The problem with that is it will break nontrivial uploads using POST since they won't complete in 5 seconds. The real solution is to not count threads or connections below a certain utilization threashold towards the capped max and kill them once you hit real starvation.</htmltext>
<tokenext>The problem with that is it will break nontrivial uploads using POST since they wo n't complete in 5 seconds .
The real solution is to not count threads or connections below a certain utilization threashold towards the capped max and kill them once you hit real starvation .</tokentext>
<sentencetext>The problem with that is it will break nontrivial uploads using POST since they won't complete in 5 seconds.
The real solution is to not count threads or connections below a certain utilization threashold towards the capped max and kill them once you hit real starvation.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391705</id>
	<title>Are web servers really this dumb?</title>
	<author>Anonymous</author>
	<datestamp>1245433800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Our little crappy web server even has more brains than that.  Are you seriously telling me Apache never concidered this case and has no  effective anti-dos measures to close slow clients when there is connection pressure?</p><p>Holding open connections is the hallmark of any DOS 101 implimentation.</p><p>Its hard to believe this is the case and I refuse to believe this somehow constititues a new discovery.  Its absurd.</p></htmltext>
<tokenext>Our little crappy web server even has more brains than that .
Are you seriously telling me Apache never concidered this case and has no effective anti-dos measures to close slow clients when there is connection pressure ? Holding open connections is the hallmark of any DOS 101 implimentation.Its hard to believe this is the case and I refuse to believe this somehow constititues a new discovery .
Its absurd .</tokentext>
<sentencetext>Our little crappy web server even has more brains than that.
Are you seriously telling me Apache never concidered this case and has no  effective anti-dos measures to close slow clients when there is connection pressure?Holding open connections is the hallmark of any DOS 101 implimentation.Its hard to believe this is the case and I refuse to believe this somehow constititues a new discovery.
Its absurd.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391629</id>
	<title>Re:Why not IIS?</title>
	<author>amicusNYCL</author>
	<datestamp>1245433500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is it really correct and standard to hold a session open for a client that isn't sending any data, while excluding other clients in the process?  Where in the spec does it say to do that?</p></htmltext>
<tokenext>Is it really correct and standard to hold a session open for a client that is n't sending any data , while excluding other clients in the process ?
Where in the spec does it say to do that ?</tokentext>
<sentencetext>Is it really correct and standard to hold a session open for a client that isn't sending any data, while excluding other clients in the process?
Where in the spec does it say to do that?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389877</id>
	<title>OpenBSD's pf has some mitigation features</title>
	<author>Anonymous</author>
	<datestamp>1245425940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>OpenBSD's <a href="http://www.openbsd.org/faq/pf/filter.html" title="openbsd.org">pf</a> [openbsd.org] firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack.  Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.</p><p>Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:</p><dl><dt> <tt>max <i>number</i> </tt></dt><dd>Limit the maximum number of state entries the rule can create to<br><i>number</i>.<br>If the maximum is reached, packets that would normally create state<br>fail to match this rule until the number of existing states decreases<br>below the limit.</dd><dt> <tt>no state</tt></dt><dd>Prevents the rule from automatically creating a state entry.</dd><dt> <tt>source-track</tt></dt><dd>This option enables the tracking of number of states created per<br>source IP address.<p>The total number of source IP addresses tracked globally can be<br>controlled via the</p><p><a href="options.html\%23limit" title="slashdot.org"> <tt>src-nodes</tt> runtime option</a> [slashdot.org].</p></dd><dt> <tt>max-src-nodes <i>number</i> </tt></dt><dd>When the <tt>source-track</tt> option is used,<br><tt>max-src-nodes</tt> will limit the number of source IP addresses that<br>can simultaneously create state.<br>This option can only be used with <tt>source-track rule</tt>.</dd><dt> <tt>max-src-states <i>number</i> </tt></dt><dd>When the <tt>source-track</tt> option is used,<br><tt>max-src-states</tt> will limit the number of simultaneous state<br>entries that can be created per source IP address.<br>The scope of this limit (i.e., states created by this rule only or<br>states created by all rules that use <tt>source-track</tt>) is dependent<br>on the <tt>source-track</tt> option specified.</dd></dl></htmltext>
<tokenext>OpenBSD 's pf [ openbsd.org ] firewall has some options that can help mitigate the " single attacker , single source IP " version of this attack .
Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS , this becomes much harder to deal with until Apache has a patch.Filter rules that create state entries can specify various options to control the behavior of the resulting state entry .
The following options are available : max number Limit the maximum number of state entries the rule can create tonumber.If the maximum is reached , packets that would normally create statefail to match this rule until the number of existing states decreasesbelow the limit .
no statePrevents the rule from automatically creating a state entry .
source-trackThis option enables the tracking of number of states created persource IP address.The total number of source IP addresses tracked globally can becontrolled via the src-nodes runtime option [ slashdot.org ] .
max-src-nodes number When the source-track option is used,max-src-nodes will limit the number of source IP addresses thatcan simultaneously create state.This option can only be used with source-track rule .
max-src-states number When the source-track option is used,max-src-states will limit the number of simultaneous stateentries that can be created per source IP address.The scope of this limit ( i.e. , states created by this rule only orstates created by all rules that use source-track ) is dependenton the source-track option specified .</tokentext>
<sentencetext>OpenBSD's pf [openbsd.org] firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack.
Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.Filter rules that create state entries can specify various options to control the behavior of the resulting state entry.
The following options are available: max number Limit the maximum number of state entries the rule can create tonumber.If the maximum is reached, packets that would normally create statefail to match this rule until the number of existing states decreasesbelow the limit.
no statePrevents the rule from automatically creating a state entry.
source-trackThis option enables the tracking of number of states created persource IP address.The total number of source IP addresses tracked globally can becontrolled via the src-nodes runtime option [slashdot.org].
max-src-nodes number When the source-track option is used,max-src-nodes will limit the number of source IP addresses thatcan simultaneously create state.This option can only be used with source-track rule.
max-src-states number When the source-track option is used,max-src-states will limit the number of simultaneous stateentries that can be created per source IP address.The scope of this limit (i.e., states created by this rule only orstates created by all rules that use source-track) is dependenton the source-track option specified.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390681</id>
	<title>Re:Not a flaw, easily configured around</title>
	<author>Anonymous</author>
	<datestamp>1245429360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>From the article:<br> <br> <i>"...the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated."</i> <br> <br>In other words.. the connection is not allowed to "timeout" as there is (bogus) traffic on the connection.</htmltext>
<tokenext>From the article : " ...the server will open the connection and wait for the complete header to be received .
However , the client ( the DoS tool ) will not send it and will instead keep sending bogus header lines which will keep the connection allocated .
" In other words.. the connection is not allowed to " timeout " as there is ( bogus ) traffic on the connection .</tokentext>
<sentencetext>From the article:  "...the server will open the connection and wait for the complete header to be received.
However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
"  In other words.. the connection is not allowed to "timeout" as there is (bogus) traffic on the connection.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391433</id>
	<title>Re:HTTP hints at a solution</title>
	<author>arjennienhuis</author>
	<datestamp>1245432660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A HTTP response can not start until the whole request has finished. So sending a status code is impossible.</p><p>The same problem happens if you try to POST a file that is too large. The webserver knows this after the Content-Length header but cannot respond until after you send the whole file. The only thing the webserver can do is to close the connection.</p></htmltext>
<tokenext>A HTTP response can not start until the whole request has finished .
So sending a status code is impossible.The same problem happens if you try to POST a file that is too large .
The webserver knows this after the Content-Length header but can not respond until after you send the whole file .
The only thing the webserver can do is to close the connection .</tokentext>
<sentencetext>A HTTP response can not start until the whole request has finished.
So sending a status code is impossible.The same problem happens if you try to POST a file that is too large.
The webserver knows this after the Content-Length header but cannot respond until after you send the whole file.
The only thing the webserver can do is to close the connection.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390651</id>
	<title>Attack of a 1000 snails.</title>
	<author>leuk\_he</author>
	<datestamp>1245429240000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>This type is already known as "attack by a 1000 snails" type attack. It is harder to defned against than you would think. A user can be slow, but coders are hesitant to drop users that ar too slow or too fast.</p><p>A user kan just keep the TCP/IP alive by sending one byte every x seconds. If this is patched at http header level, you will see you can do the same kind of attack on the application, that can have limited php or perl sessions.</p></htmltext>
<tokenext>This type is already known as " attack by a 1000 snails " type attack .
It is harder to defned against than you would think .
A user can be slow , but coders are hesitant to drop users that ar too slow or too fast.A user kan just keep the TCP/IP alive by sending one byte every x seconds .
If this is patched at http header level , you will see you can do the same kind of attack on the application , that can have limited php or perl sessions .</tokentext>
<sentencetext>This type is already known as "attack by a 1000 snails" type attack.
It is harder to defned against than you would think.
A user can be slow, but coders are hesitant to drop users that ar too slow or too fast.A user kan just keep the TCP/IP alive by sending one byte every x seconds.
If this is patched at http header level, you will see you can do the same kind of attack on the application, that can have limited php or perl sessions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389685</id>
	<title>Re:Well its not just Apache</title>
	<author>segedunum</author>
	<datestamp>1245425220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>IIS is not vulnerable, as confirmed in TFAs and the summary. Seems as though a DoS attack has affected some peoples' eyes.</htmltext>
<tokenext>IIS is not vulnerable , as confirmed in TFAs and the summary .
Seems as though a DoS attack has affected some peoples ' eyes .</tokentext>
<sentencetext>IIS is not vulnerable, as confirmed in TFAs and the summary.
Seems as though a DoS attack has affected some peoples' eyes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392859</id>
	<title>Re:HTTP hints at a solution</title>
	<author>psydeshow</author>
	<datestamp>1245438780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's informative, but I thought the point about GET vs. POST and PUT was confusing.</p><p>To be clear, the Timeout directive can be set low without affecting the ability of people to upload large files to the server. Timeout only applies to the time between packets, which should be a few hundred milliseconds apart under most circumstances, right?</p><p>From the httpd manual:</p><blockquote><div><p>The TimeOut directive currently defines the amount of time Apache will wait for three things:</p><p>
&nbsp; &nbsp; &nbsp; 1. The total amount of time it takes to receive a GET request.<br>
&nbsp; &nbsp; &nbsp; 2. The amount of time between receipt of TCP packets on a POST or PUT request.<br>
&nbsp; &nbsp; &nbsp; 3. The amount of time between ACKs on transmissions of TCP packets in responses.</p><p>We plan on making these separately configurable at some point down the road. The timer used to default to 1200 before 1.2, but has been lowered to 300 which is still far more than necessary in most situations. It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent.</p></div></blockquote></div>
	</htmltext>
<tokenext>That 's informative , but I thought the point about GET vs. POST and PUT was confusing.To be clear , the Timeout directive can be set low without affecting the ability of people to upload large files to the server .
Timeout only applies to the time between packets , which should be a few hundred milliseconds apart under most circumstances , right ? From the httpd manual : The TimeOut directive currently defines the amount of time Apache will wait for three things :       1 .
The total amount of time it takes to receive a GET request .
      2 .
The amount of time between receipt of TCP packets on a POST or PUT request .
      3 .
The amount of time between ACKs on transmissions of TCP packets in responses.We plan on making these separately configurable at some point down the road .
The timer used to default to 1200 before 1.2 , but has been lowered to 300 which is still far more than necessary in most situations .
It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent .</tokentext>
<sentencetext>That's informative, but I thought the point about GET vs. POST and PUT was confusing.To be clear, the Timeout directive can be set low without affecting the ability of people to upload large files to the server.
Timeout only applies to the time between packets, which should be a few hundred milliseconds apart under most circumstances, right?From the httpd manual:The TimeOut directive currently defines the amount of time Apache will wait for three things:
      1.
The total amount of time it takes to receive a GET request.
      2.
The amount of time between receipt of TCP packets on a POST or PUT request.
      3.
The amount of time between ACKs on transmissions of TCP packets in responses.We plan on making these separately configurable at some point down the road.
The timer used to default to 1200 before 1.2, but has been lowered to 300 which is still far more than necessary in most situations.
It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103</id>
	<title>Many othere services are probably vulnerable</title>
	<author>karl.auerbach</author>
	<datestamp>1245431280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sendmail and other servers are probably vulnerable to this kind of thing.  And it is not necessarily the server application itself may not be where the core of the server slowdown occurs.  For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks.  (And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.)</p><p>There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive.  Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.</p><p>There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open.  Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine.  Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.</p></htmltext>
<tokenext>Sendmail and other servers are probably vulnerable to this kind of thing .
And it is not necessarily the server application itself may not be where the core of the server slowdown occurs .
For example , if one were to spread this kind of attack across several different types of TCP-based protocols ( SMTP/SMTPS , IMAP ( S ) , HTTP ( S ) , DNS ( tcp version ) , etc then the operating system 's TCP engine might start suffer from too many TCP control blocks .
( And it is n't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks .
) There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive .
Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open .
Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine .
Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers .</tokentext>
<sentencetext>Sendmail and other servers are probably vulnerable to this kind of thing.
And it is not necessarily the server application itself may not be where the core of the server slowdown occurs.
For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks.
(And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.
)There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive.
Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open.
Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine.
Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390269</id>
	<title>Re:Boring</title>
	<author>aztektum</author>
	<datestamp>1245427620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'd be embarrassed to publish something like this....</p></div><p>Says the Anonymous Coward</p></div>
	</htmltext>
<tokenext>I 'd be embarrassed to publish something like this....Says the Anonymous Coward</tokentext>
<sentencetext>I'd be embarrassed to publish something like this....Says the Anonymous Coward
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389991</id>
	<title>Our system may be safe</title>
	<author>cjb-nc</author>
	<datestamp>1245426420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>Obviously need to verify this, but we already run <a href="http://sourceforge.net/projects/cband/" title="sourceforge.net" rel="nofollow">mod\_cband</a> [sourceforge.net] with a per-IP connection limit of 5. This is in place to stop the over-zealous "download accelerators" from taking all our connections and DOS'ing us. I expect it would stop a single attacker using this attack, but we'd still be vulnerable to a concerted attack by MaxChildren/5 IPs.</htmltext>
<tokenext>Obviously need to verify this , but we already run mod \ _cband [ sourceforge.net ] with a per-IP connection limit of 5 .
This is in place to stop the over-zealous " download accelerators " from taking all our connections and DOS'ing us .
I expect it would stop a single attacker using this attack , but we 'd still be vulnerable to a concerted attack by MaxChildren/5 IPs .</tokentext>
<sentencetext>Obviously need to verify this, but we already run mod\_cband [sourceforge.net] with a per-IP connection limit of 5.
This is in place to stop the over-zealous "download accelerators" from taking all our connections and DOS'ing us.
I expect it would stop a single attacker using this attack, but we'd still be vulnerable to a concerted attack by MaxChildren/5 IPs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394871</id>
	<title>Re:Possible work-around</title>
	<author>Anonymous</author>
	<datestamp>1245402660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>30 seconds may be enough for YOU, but there's two of you involved when you're in..... wait..... what were we talking about?</p></htmltext>
<tokenext>30 seconds may be enough for YOU , but there 's two of you involved when you 're in..... wait..... what were we talking about ?</tokentext>
<sentencetext>30 seconds may be enough for YOU, but there's two of you involved when you're in..... wait..... what were we talking about?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396049</id>
	<title>Re:So slashdot...</title>
	<author>dominious</author>
	<datestamp>1245407220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.
<br> <br>
I kinda doubt this would work on us.
<br> <br>
<b>Note, I am not inviting anyone to try. It might work great for all I know<nobr> <wbr></nobr>:(</b></p> </div><p>Thanks for the info! What a better way to find out than to post this on<nobr> <wbr></nobr>/. ?</p></div>
	</htmltext>
<tokenext>We have a hardware load-balancer and a software reverse proxy ( varnish ) in front of our apache .
I kinda doubt this would work on us .
Note , I am not inviting anyone to try .
It might work great for all I know : ( Thanks for the info !
What a better way to find out than to post this on / .
?</tokentext>
<sentencetext>We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.
I kinda doubt this would work on us.
Note, I am not inviting anyone to try.
It might work great for all I know :( Thanks for the info!
What a better way to find out than to post this on /.
?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392577</id>
	<title>Queuing and timeout</title>
	<author>pdxp</author>
	<datestamp>1245437640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>IIS worker processes have a request queue. Whether or not you use asynchronous functions to handle requests, there is a fixed maximum number of threads each worker process will run to process requests. While reading from a socket, the worker thread does block but more threads are not spawned to handle connections. Instead, the worker process puts new requests into a queue until more threads are available.
<br> <br>
I believe this works because there is a timeout associated with the completion of a request. Sure, it might be difficult to distinguish a slow DoS from a slow client, but it wouldn't be impossible to set a reasonable time limit on non-POST requests. That would be a relatively easy way to fix the issue in Apache.
<br> <br>
As far as POST goes... well, that's a different (and valid) way to perform a slow DoS attack:
<br> <br>
<b>Server:</b> What would you like? Ham bacon spam, or spam eggs bacon spam with spam?<br>
<b>Client:</b> I'm actually here to deliver some SPAM!<br>
<b>Server:</b> How much SPAM?<br>
<b>Client:</b> SPAM, SPAM, SPAM.... (3 hours later)<nobr> <wbr></nobr>... SPAM SPAM SPAM...<br>
<br>
Slowloris can do this too. By default, IIS only reads the up to first 48KB of post data (I see much smaller numbers in practice), at which point the request is sent to an extension/app. Before this, the request doesn't leave the kernel-mode driver (http.sys). The apps can easily ignore the data or read more (on a timeout). I wouldn't be surprised if Lighttpd did the same thing (sans kernel driver).</htmltext>
<tokenext>IIS worker processes have a request queue .
Whether or not you use asynchronous functions to handle requests , there is a fixed maximum number of threads each worker process will run to process requests .
While reading from a socket , the worker thread does block but more threads are not spawned to handle connections .
Instead , the worker process puts new requests into a queue until more threads are available .
I believe this works because there is a timeout associated with the completion of a request .
Sure , it might be difficult to distinguish a slow DoS from a slow client , but it would n't be impossible to set a reasonable time limit on non-POST requests .
That would be a relatively easy way to fix the issue in Apache .
As far as POST goes... well , that 's a different ( and valid ) way to perform a slow DoS attack : Server : What would you like ?
Ham bacon spam , or spam eggs bacon spam with spam ?
Client : I 'm actually here to deliver some SPAM !
Server : How much SPAM ?
Client : SPAM , SPAM , SPAM.... ( 3 hours later ) ... SPAM SPAM SPAM.. . Slowloris can do this too .
By default , IIS only reads the up to first 48KB of post data ( I see much smaller numbers in practice ) , at which point the request is sent to an extension/app .
Before this , the request does n't leave the kernel-mode driver ( http.sys ) .
The apps can easily ignore the data or read more ( on a timeout ) .
I would n't be surprised if Lighttpd did the same thing ( sans kernel driver ) .</tokentext>
<sentencetext>IIS worker processes have a request queue.
Whether or not you use asynchronous functions to handle requests, there is a fixed maximum number of threads each worker process will run to process requests.
While reading from a socket, the worker thread does block but more threads are not spawned to handle connections.
Instead, the worker process puts new requests into a queue until more threads are available.
I believe this works because there is a timeout associated with the completion of a request.
Sure, it might be difficult to distinguish a slow DoS from a slow client, but it wouldn't be impossible to set a reasonable time limit on non-POST requests.
That would be a relatively easy way to fix the issue in Apache.
As far as POST goes... well, that's a different (and valid) way to perform a slow DoS attack:
 
Server: What would you like?
Ham bacon spam, or spam eggs bacon spam with spam?
Client: I'm actually here to deliver some SPAM!
Server: How much SPAM?
Client: SPAM, SPAM, SPAM.... (3 hours later) ... SPAM SPAM SPAM...

Slowloris can do this too.
By default, IIS only reads the up to first 48KB of post data (I see much smaller numbers in practice), at which point the request is sent to an extension/app.
Before this, the request doesn't leave the kernel-mode driver (http.sys).
The apps can easily ignore the data or read more (on a timeout).
I wouldn't be surprised if Lighttpd did the same thing (sans kernel driver).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391309</id>
	<title>Re:Not a flaw, easily configured around</title>
	<author>Cajun Hell</author>
	<datestamp>1245432120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If you are running the default Apache config in production, you shouldn't be.</p></div></blockquote><p>
That's one of the most damning things you can say about a package.</p></div>
	</htmltext>
<tokenext>If you are running the default Apache config in production , you should n't be .
That 's one of the most damning things you can say about a package .</tokentext>
<sentencetext>If you are running the default Apache config in production, you shouldn't be.
That's one of the most damning things you can say about a package.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397163</id>
	<title>Re:WTH? This is an absolutely trivial attack</title>
	<author>brunoacf</author>
	<datestamp>1245412920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>It's just holding sockets open; that's the "Hello, world!" of DOS attacks. </i>
<br>
<br>
Yeah, a very effective 'Hello World', unfortunately.</htmltext>
<tokenext>It 's just holding sockets open ; that 's the " Hello , world !
" of DOS attacks .
Yeah , a very effective 'Hello World ' , unfortunately .</tokentext>
<sentencetext>It's just holding sockets open; that's the "Hello, world!
" of DOS attacks.
Yeah, a very effective 'Hello World', unfortunately.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390329</id>
	<title>Re:WTH? This is an absolutely trivial attack</title>
	<author>Anonymous</author>
	<datestamp>1245427800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>I'm finding it hard to believe that Apache is genuinely vulnerable to this. Did nobody see it coming? For real?</i></p><p>10.4.9 408 Request Timeout</p><p>
&nbsp; &nbsp; &nbsp; The client did not produce a request within the time that the server<br>
&nbsp; &nbsp; &nbsp; was prepared to wait. The client MAY repeat the request without<br>
&nbsp; &nbsp; &nbsp; modifications at any later time.</p><p>It makes no mention of a default or required timeout.<br>This is just a case of the specs being written long (10 years this month) before people started adding protection measures into the specs.  Luckily, unlike SMTP specs, this is easy to fix without breaking t'internet.</p></htmltext>
<tokenext>I 'm finding it hard to believe that Apache is genuinely vulnerable to this .
Did nobody see it coming ?
For real ? 10.4.9 408 Request Timeout       The client did not produce a request within the time that the server       was prepared to wait .
The client MAY repeat the request without       modifications at any later time.It makes no mention of a default or required timeout.This is just a case of the specs being written long ( 10 years this month ) before people started adding protection measures into the specs .
Luckily , unlike SMTP specs , this is easy to fix without breaking t'internet .</tokentext>
<sentencetext>I'm finding it hard to believe that Apache is genuinely vulnerable to this.
Did nobody see it coming?
For real?10.4.9 408 Request Timeout
      The client did not produce a request within the time that the server
      was prepared to wait.
The client MAY repeat the request without
      modifications at any later time.It makes no mention of a default or required timeout.This is just a case of the specs being written long (10 years this month) before people started adding protection measures into the specs.
Luckily, unlike SMTP specs, this is easy to fix without breaking t'internet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391613</id>
	<title>Re:So slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1245433500000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>A beefy hardware load balancer won't save you from this unless the load balancer is in full HTTP proxy mode (which yours probably is).  A different problem that's harder to deal with is slow reads on a dynamic content pages that are not cached (and won't be) and whose size is greater than the LB's 4 or 8K TCP buffer size.</p></htmltext>
<tokenext>A beefy hardware load balancer wo n't save you from this unless the load balancer is in full HTTP proxy mode ( which yours probably is ) .
A different problem that 's harder to deal with is slow reads on a dynamic content pages that are not cached ( and wo n't be ) and whose size is greater than the LB 's 4 or 8K TCP buffer size .</tokentext>
<sentencetext>A beefy hardware load balancer won't save you from this unless the load balancer is in full HTTP proxy mode (which yours probably is).
A different problem that's harder to deal with is slow reads on a dynamic content pages that are not cached (and won't be) and whose size is greater than the LB's 4 or 8K TCP buffer size.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390073</id>
	<title>Re:Other Web Servers....Proxies......?</title>
	<author>natbudin</author>
	<datestamp>1245426780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>I just tried it against nginx 0.6.37.  The attack appears to work there as well.</htmltext>
<tokenext>I just tried it against nginx 0.6.37 .
The attack appears to work there as well .</tokentext>
<sentencetext>I just tried it against nginx 0.6.37.
The attack appears to work there as well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390681
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390493
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390337
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389877
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391993
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392859
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390921
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392153
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389671
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389679
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397163
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391697
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392029
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393465
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390165
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390269
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394203
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394871
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389809
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389665
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391629
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391309
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394311
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389809
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397757
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390209
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390017
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392027
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391283
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390329
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396859
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391669
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390431
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389693
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390791
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393873
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28395535
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391979
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389685
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390651
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390553
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396049
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391613
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390073
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391121
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_19_1243203_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391433
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390091
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390681
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390921
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391309
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390101
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391433
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392859
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394203
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389737
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391697
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390043
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390791
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389991
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390057
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389719
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391669
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390017
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390269
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389877
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390337
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389711
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390041
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391629
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393873
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390209
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397757
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391121
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391993
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390493
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389733
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392577
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389809
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391739
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394871
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28394311
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389621
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390431
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390369
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396859
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28396049
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391613
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390547
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392153
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391103
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391979
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392027
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389783
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390073
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28395535
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390165
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28393465
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389637
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389665
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390553
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389685
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389693
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389671
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389679
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390835
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_19_1243203.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28389703
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28391283
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390329
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28392029
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28397163
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_19_1243203.28390651
</commentlist>
</conversation>
