<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_15_1653228</id>
	<title>The "Hail Mary Cloud" Is Growing</title>
	<author>Soulskill</author>
	<datestamp>1258305780000</datestamp>
	<htmltext>badger.foo writes <i>"The Australian <a href="https://apple.slashdot.org/story/09/11/08/1411259/First-iPhone-Worm-Discovered-Rickrolls-Jailbroken-Phones">rickrolling of jailbroken iPhones</a> only goes to prove that bad passwords are bad for you, Peter Hansteen points out, as he reports on the further exploits of <a href="http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html">the password-guessing Hail Mary Cloud</a> (which <a href="http://linux.slashdot.org/story/09/10/04/2054259/Sloppy-Linux-Admins-Enable-Slow-Brute-Force-Attacks">we've discussed</a> in the past). The article contains log data that could indicate that the cloud of distributed, password-guessing hosts is growing. 'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand, and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list. The busier your SSH deamon is with normal traffic, the harder it will be to detect the footprint of Hail Mary activity, and likely a lot of this goes undetected.'"</i></htmltext>
<tokenext>badger.foo writes " The Australian rickrolling of jailbroken iPhones only goes to prove that bad passwords are bad for you , Peter Hansteen points out , as he reports on the further exploits of the password-guessing Hail Mary Cloud ( which we 've discussed in the past ) .
The article contains log data that could indicate that the cloud of distributed , password-guessing hosts is growing .
'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand , and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list .
The busier your SSH deamon is with normal traffic , the harder it will be to detect the footprint of Hail Mary activity , and likely a lot of this goes undetected .
' "</tokentext>
<sentencetext>badger.foo writes "The Australian rickrolling of jailbroken iPhones only goes to prove that bad passwords are bad for you, Peter Hansteen points out, as he reports on the further exploits of the password-guessing Hail Mary Cloud (which we've discussed in the past).
The article contains log data that could indicate that the cloud of distributed, password-guessing hosts is growing.
'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand, and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list.
The busier your SSH deamon is with normal traffic, the harder it will be to detect the footprint of Hail Mary activity, and likely a lot of this goes undetected.
'"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107656</id>
	<title>DenyHosts is not security through obscurity!</title>
	<author>Anonymous</author>
	<datestamp>1258315920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It bans or denies connection to IPs that have repeatedly failed to login. That is real security, not obscurity. That being said, it is totally useless against today's threats.</p></htmltext>
<tokenext>It bans or denies connection to IPs that have repeatedly failed to login .
That is real security , not obscurity .
That being said , it is totally useless against today 's threats .</tokentext>
<sentencetext>It bans or denies connection to IPs that have repeatedly failed to login.
That is real security, not obscurity.
That being said, it is totally useless against today's threats.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107172</id>
	<title>Re:What has to happen?</title>
	<author>FunPika</author>
	<datestamp>1258313160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>(or make lawmakers force them to)</p></div><p>I can't wait for the day that Congress passes a law to the effect of "If malware causes your computer to do something illegal, you will be held responsible for said illegal activities in court even if you can prove malware was the cause."</p></div>
	</htmltext>
<tokenext>( or make lawmakers force them to ) I ca n't wait for the day that Congress passes a law to the effect of " If malware causes your computer to do something illegal , you will be held responsible for said illegal activities in court even if you can prove malware was the cause .
"</tokentext>
<sentencetext>(or make lawmakers force them to)I can't wait for the day that Congress passes a law to the effect of "If malware causes your computer to do something illegal, you will be held responsible for said illegal activities in court even if you can prove malware was the cause.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30133992</id>
	<title>I may be missing something</title>
	<author>k1773re7f</author>
	<datestamp>1258449600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>But it seems to me that key based authentication mediates this risk.  Am I the only one that does this?  What the heck does everyone think ssh is for? I use password authentication the very first time I access a server.  I put my pub key there, then disable password authentication. My private key never leaves the thumb drive I wear around my neck. Being a CHL holder, it is very unlikely you'll get to that without leaving your DNA and most probably grey matter all over the place. Plus, my cat sets my passwords.</htmltext>
<tokenext>But it seems to me that key based authentication mediates this risk .
Am I the only one that does this ?
What the heck does everyone think ssh is for ?
I use password authentication the very first time I access a server .
I put my pub key there , then disable password authentication .
My private key never leaves the thumb drive I wear around my neck .
Being a CHL holder , it is very unlikely you 'll get to that without leaving your DNA and most probably grey matter all over the place .
Plus , my cat sets my passwords .</tokentext>
<sentencetext>But it seems to me that key based authentication mediates this risk.
Am I the only one that does this?
What the heck does everyone think ssh is for?
I use password authentication the very first time I access a server.
I put my pub key there, then disable password authentication.
My private key never leaves the thumb drive I wear around my neck.
Being a CHL holder, it is very unlikely you'll get to that without leaving your DNA and most probably grey matter all over the place.
Plus, my cat sets my passwords.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106980</id>
	<title>Re:Put in denyhosts...</title>
	<author>l2718</author>
	<datestamp>1258311960000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>Denyhosts<nobr> <wbr></nobr>... "filter[s] out requests<nobr> <wbr></nobr>... by<nobr> <wbr></nobr>... blocking the originating IP addresses."</p></div></blockquote><p>Unfortunately, these phones do not have fixed IP addresses.  IP-based authorization won't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all, you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked.  You need host-based or user-based authentication that does not depend on IP addresses. For example, SSH supports user-based cryptographic keys.</p><p>I also think that <i>blocking</i> hosts is the wrong way to go.  Most people do not run open-to-the-public login servers, either on their home computers or on their phones.  If you must do host-based blocking then the correct approach is that of hosts.allow &mdash; deny all requests by default except for those that you trust.</p></div>
	</htmltext>
<tokenext>Denyhosts ... " filter [ s ] out requests ... by ... blocking the originating IP addresses .
" Unfortunately , these phones do not have fixed IP addresses .
IP-based authorization wo n't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all , you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked .
You need host-based or user-based authentication that does not depend on IP addresses .
For example , SSH supports user-based cryptographic keys.I also think that blocking hosts is the wrong way to go .
Most people do not run open-to-the-public login servers , either on their home computers or on their phones .
If you must do host-based blocking then the correct approach is that of hosts.allow    deny all requests by default except for those that you trust .</tokentext>
<sentencetext>Denyhosts ... "filter[s] out requests ... by ... blocking the originating IP addresses.
"Unfortunately, these phones do not have fixed IP addresses.
IP-based authorization won't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all, you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked.
You need host-based or user-based authentication that does not depend on IP addresses.
For example, SSH supports user-based cryptographic keys.I also think that blocking hosts is the wrong way to go.
Most people do not run open-to-the-public login servers, either on their home computers or on their phones.
If you must do host-based blocking then the correct approach is that of hosts.allow — deny all requests by default except for those that you trust.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112012</id>
	<title>Re:The cloud attack isn't new</title>
	<author>Anonymous</author>
	<datestamp>1258306800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><ul> <li>Make sure your users use strong passwords</li></ul></div><p>In which alternate reality is brute-forcing RSA passwords possible? Do people there use roo&gt;t accounts? Else, that single point is more than enough to protect your system.</p><p>What if I have a user called god, and they have a list that goes (root,john,ken,god,rms,...)?</p><p>Then their brute-forcing instead of taking more than the lifespan of our universe x nPossibleUserNames, it will take more than the lifespan of our universe x 4. I feel so insecure.</p><p>If you don't want to have the SSH server working overtime move it away from port 22 but as far as security goes it is only nPorts x better.</p></div>
	</htmltext>
<tokenext>Make sure your users use strong passwordsIn which alternate reality is brute-forcing RSA passwords possible ?
Do people there use roo &gt; t accounts ?
Else , that single point is more than enough to protect your system.What if I have a user called god , and they have a list that goes ( root,john,ken,god,rms,... ) ? Then their brute-forcing instead of taking more than the lifespan of our universe x nPossibleUserNames , it will take more than the lifespan of our universe x 4 .
I feel so insecure.If you do n't want to have the SSH server working overtime move it away from port 22 but as far as security goes it is only nPorts x better .</tokentext>
<sentencetext> Make sure your users use strong passwordsIn which alternate reality is brute-forcing RSA passwords possible?
Do people there use roo&gt;t accounts?
Else, that single point is more than enough to protect your system.What if I have a user called god, and they have a list that goes (root,john,ken,god,rms,...)?Then their brute-forcing instead of taking more than the lifespan of our universe x nPossibleUserNames, it will take more than the lifespan of our universe x 4.
I feel so insecure.If you don't want to have the SSH server working overtime move it away from port 22 but as far as security goes it is only nPorts x better.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107412</id>
	<title>Re:The cloud attack isn't new</title>
	<author>Daimanta</author>
	<datestamp>1258314240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I manage a server on my local university and I simply whitelist SSH access and all other ports are precisely controlled via whitelists too.</p><p>Users have basic access to standard ports like http and https but for any other port you need to be in a whitelist. Works like a charm and it allows me to see attacks very easily.</p></htmltext>
<tokenext>I manage a server on my local university and I simply whitelist SSH access and all other ports are precisely controlled via whitelists too.Users have basic access to standard ports like http and https but for any other port you need to be in a whitelist .
Works like a charm and it allows me to see attacks very easily .</tokentext>
<sentencetext>I manage a server on my local university and I simply whitelist SSH access and all other ports are precisely controlled via whitelists too.Users have basic access to standard ports like http and https but for any other port you need to be in a whitelist.
Works like a charm and it allows me to see attacks very easily.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109216</id>
	<title>Re:DenyHosts will not save you; disable passwords</title>
	<author>nedlohs</author>
	<datestamp>1258282080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Do you know what the word "public" means?</p><p>Can you see how it makes that irrelevant?</p></htmltext>
<tokenext>Do you know what the word " public " means ? Can you see how it makes that irrelevant ?</tokentext>
<sentencetext>Do you know what the word "public" means?Can you see how it makes that irrelevant?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107922</id>
	<title>Re:The cloud attack isn't new</title>
	<author>ceoyoyo</author>
	<datestamp>1258317300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My logs show several different types of attack at the same time.  One is the distributed guessing in the article, an attempt by a different host every ten seconds or so.  There's another, from a single host name, that gets stopped in it's tracks because the address doesn't reverse map and yet another, from a variety of hostnames that do not reverse map.</p></htmltext>
<tokenext>My logs show several different types of attack at the same time .
One is the distributed guessing in the article , an attempt by a different host every ten seconds or so .
There 's another , from a single host name , that gets stopped in it 's tracks because the address does n't reverse map and yet another , from a variety of hostnames that do not reverse map .</tokentext>
<sentencetext>My logs show several different types of attack at the same time.
One is the distributed guessing in the article, an attempt by a different host every ten seconds or so.
There's another, from a single host name, that gets stopped in it's tracks because the address doesn't reverse map and yet another, from a variety of hostnames that do not reverse map.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107640</id>
	<title>Re:Put in denyhosts...</title>
	<author>v1</author>
	<datestamp>1258315860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and <b>blocking the originating IP addresses</b>. "</i></p><p>RTFA.  From the looks of the logs he posted, it's deliberately only trying a couple times from any given IP, specifically to prevent this sort of detection.</p><p>I used to do this sort of thing with scripts on my server, after running into an occasional spurt of several hours of an IP address trying every username in the book, apparently hoping for a blank password or same-as-login password.  I had it set to autoban the IP at 5 of any sort of failed attempts in a row.  I had to do it this way unlike your above example because the guesses kept changing the username, and most traditional "delayed authentication failure" responses nowadays are only effective after multiple attempts on the same <i>username</i>, and they were running a username dictionary, not a password dictionary.</p><p>But your method is <i>100\% worthless</i> against this attack.</p><p>Nowadays, my servers listen on a nonstandard port, and rsa key login is manditory.  End of problem.</p></htmltext>
<tokenext>It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses .
" RTFA. From the looks of the logs he posted , it 's deliberately only trying a couple times from any given IP , specifically to prevent this sort of detection.I used to do this sort of thing with scripts on my server , after running into an occasional spurt of several hours of an IP address trying every username in the book , apparently hoping for a blank password or same-as-login password .
I had it set to autoban the IP at 5 of any sort of failed attempts in a row .
I had to do it this way unlike your above example because the guesses kept changing the username , and most traditional " delayed authentication failure " responses nowadays are only effective after multiple attempts on the same username , and they were running a username dictionary , not a password dictionary.But your method is 100 \ % worthless against this attack.Nowadays , my servers listen on a nonstandard port , and rsa key login is manditory .
End of problem .</tokentext>
<sentencetext>It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses.
"RTFA.  From the looks of the logs he posted, it's deliberately only trying a couple times from any given IP, specifically to prevent this sort of detection.I used to do this sort of thing with scripts on my server, after running into an occasional spurt of several hours of an IP address trying every username in the book, apparently hoping for a blank password or same-as-login password.
I had it set to autoban the IP at 5 of any sort of failed attempts in a row.
I had to do it this way unlike your above example because the guesses kept changing the username, and most traditional "delayed authentication failure" responses nowadays are only effective after multiple attempts on the same username, and they were running a username dictionary, not a password dictionary.But your method is 100\% worthless against this attack.Nowadays, my servers listen on a nonstandard port, and rsa key login is manditory.
End of problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107756</id>
	<title>Re:Put in denyhosts...</title>
	<author>Anonymous</author>
	<datestamp>1258316580000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p><div class="quote"><p>The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once. I've spent way too much time going into my hosted box via somewhere else to let myself back in.</p></div><p>Dude, you're such a fucking genius.  A normal person would have that happen one time and then they'd just learn how to correctly use an ssh-based file system.  Or they'd remember their own passwords.  But not you!  No, you push the envelope and you defy the edge by letting that happen more than once so you can practice letting yourself back in.  Brilliant!  With all that practice I bet you can let yourself back in your own machine in half the time it would take me!</p></div>
	</htmltext>
<tokenext>The main role of Denyhosts is to lock you out of your own box if you 're using an ssh-based file system , which applies your incorrect password multiple times rather than once .
I 've spent way too much time going into my hosted box via somewhere else to let myself back in.Dude , you 're such a fucking genius .
A normal person would have that happen one time and then they 'd just learn how to correctly use an ssh-based file system .
Or they 'd remember their own passwords .
But not you !
No , you push the envelope and you defy the edge by letting that happen more than once so you can practice letting yourself back in .
Brilliant ! With all that practice I bet you can let yourself back in your own machine in half the time it would take me !</tokentext>
<sentencetext>The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once.
I've spent way too much time going into my hosted box via somewhere else to let myself back in.Dude, you're such a fucking genius.
A normal person would have that happen one time and then they'd just learn how to correctly use an ssh-based file system.
Or they'd remember their own passwords.
But not you!
No, you push the envelope and you defy the edge by letting that happen more than once so you can practice letting yourself back in.
Brilliant!  With all that practice I bet you can let yourself back in your own machine in half the time it would take me!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107134</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106722</id>
	<title>Why Is This The Linux Section?!!</title>
	<author>Anonymous</author>
	<datestamp>1258309800000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>I don't see any relevant of this to Linux whatsover.</p><p>Are you guys really running out of news to put in there?</p></htmltext>
<tokenext>I do n't see any relevant of this to Linux whatsover.Are you guys really running out of news to put in there ?</tokentext>
<sentencetext>I don't see any relevant of this to Linux whatsover.Are you guys really running out of news to put in there?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107062</id>
	<title>How do these two parts relate?</title>
	<author>damn\_registrars</author>
	<datestamp>1258312440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The summary starts by talking about jailbroken iphones getting rickrolled.  It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured *nix boxes to log in to.</htmltext>
<tokenext>The summary starts by talking about jailbroken iphones getting rickrolled .
It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured * nix boxes to log in to .</tokentext>
<sentencetext>The summary starts by talking about jailbroken iphones getting rickrolled.
It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured *nix boxes to log in to.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106932</id>
	<title>Re:How to ID an Infected Computer</title>
	<author>certain death</author>
	<datestamp>1258311600000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext>You have a router in front of your iPhone?!?  WOW!  I have GOT to get that app.</htmltext>
<tokenext>You have a router in front of your iPhone ? ! ?
WOW ! I have GOT to get that app .</tokentext>
<sentencetext>You have a router in front of your iPhone?!?
WOW!  I have GOT to get that app.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107134</id>
	<title>Re:Put in denyhosts...</title>
	<author>David Gerard</author>
	<datestamp>1258312920000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once. I've spent way too much time going into my hosted box via somewhere else to let myself back in.</htmltext>
<tokenext>The main role of Denyhosts is to lock you out of your own box if you 're using an ssh-based file system , which applies your incorrect password multiple times rather than once .
I 've spent way too much time going into my hosted box via somewhere else to let myself back in .</tokentext>
<sentencetext>The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once.
I've spent way too much time going into my hosted box via somewhere else to let myself back in.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30116338</id>
	<title>Four simple things</title>
	<author>skeeto</author>
	<datestamp>1258391520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger. Applying the first item, and any subset of the last three should be pretty good.</p><p>One, turn off root log in. Then they have to guess both a user name <i>and</i> a password. This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, let alone a correct password. It tries names like root, admin, apache, samba, so if you have these make sure they can't log in with ssh.</p><p>Two, use a decent password. A lot of people will tell you to take the inconvenient route of disabling password logins, saying they are dangerous. However, guessing over ssh is extremely slow, compared to a brute force attempt on a local machine. This means they really only get a chance to guess the most obvious passwords. If you trust all the passwords on the system to have decent strength, which is the case if, say, you are the only person logging into the machine, then you don't need to disable password logins.</p><p>Three, in case they did somehow figure out the name of an account that can log in, run DenyHosts. This will stop non-distributed attacks in their tracks, as they only get a few guesses.</p><p>Four, move the ssh port to something other than the default 22. I moved mine to 443 (https), since it's accessible from highly firewalled networks behind which I may be trapped, and people are already used to seeing encrypted traffic on that port. Ever since I did this, I haven't seen a single login attempt on my server other than myself. This means my server also wastes less time rejecting remote logins.</p><p>The ssh brute force bots I've seen are very stupid. I'm not really sure what the bot operators are doing. In my ssh honeypot where I have the root password set to "password", most bots won't ever guess it after thousands of attempts. Of the ones that do eventually guess the right password, most log out right away, <i>then go right back to guessing root passwords again!</i> Maybe trying to detect if it's a honeypot? Then there are ones that do log in and stop guessing, but they immediately log out and don't ever return (that is, no one has ever shown up and logged in without making guesses). Security researchers? Maybe marked my honeypot down for some future abuse? Maybe detected that it was a honeypot? I'm not sure what's going on with that.</p></htmltext>
<tokenext>In my small amount of experience observing these types of ssh attacks , and even letting them into high-interaction honeypots to see what they do , there are four simple things that can be done to really cut down on the danger .
Applying the first item , and any subset of the last three should be pretty good.One , turn off root log in .
Then they have to guess both a user name and a password .
This would stop every single attack I have ever seen in my logs , since none of them have guessed a correct user account , let alone a correct password .
It tries names like root , admin , apache , samba , so if you have these make sure they ca n't log in with ssh.Two , use a decent password .
A lot of people will tell you to take the inconvenient route of disabling password logins , saying they are dangerous .
However , guessing over ssh is extremely slow , compared to a brute force attempt on a local machine .
This means they really only get a chance to guess the most obvious passwords .
If you trust all the passwords on the system to have decent strength , which is the case if , say , you are the only person logging into the machine , then you do n't need to disable password logins.Three , in case they did somehow figure out the name of an account that can log in , run DenyHosts .
This will stop non-distributed attacks in their tracks , as they only get a few guesses.Four , move the ssh port to something other than the default 22 .
I moved mine to 443 ( https ) , since it 's accessible from highly firewalled networks behind which I may be trapped , and people are already used to seeing encrypted traffic on that port .
Ever since I did this , I have n't seen a single login attempt on my server other than myself .
This means my server also wastes less time rejecting remote logins.The ssh brute force bots I 've seen are very stupid .
I 'm not really sure what the bot operators are doing .
In my ssh honeypot where I have the root password set to " password " , most bots wo n't ever guess it after thousands of attempts .
Of the ones that do eventually guess the right password , most log out right away , then go right back to guessing root passwords again !
Maybe trying to detect if it 's a honeypot ?
Then there are ones that do log in and stop guessing , but they immediately log out and do n't ever return ( that is , no one has ever shown up and logged in without making guesses ) .
Security researchers ?
Maybe marked my honeypot down for some future abuse ?
Maybe detected that it was a honeypot ?
I 'm not sure what 's going on with that .</tokentext>
<sentencetext>In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger.
Applying the first item, and any subset of the last three should be pretty good.One, turn off root log in.
Then they have to guess both a user name and a password.
This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, let alone a correct password.
It tries names like root, admin, apache, samba, so if you have these make sure they can't log in with ssh.Two, use a decent password.
A lot of people will tell you to take the inconvenient route of disabling password logins, saying they are dangerous.
However, guessing over ssh is extremely slow, compared to a brute force attempt on a local machine.
This means they really only get a chance to guess the most obvious passwords.
If you trust all the passwords on the system to have decent strength, which is the case if, say, you are the only person logging into the machine, then you don't need to disable password logins.Three, in case they did somehow figure out the name of an account that can log in, run DenyHosts.
This will stop non-distributed attacks in their tracks, as they only get a few guesses.Four, move the ssh port to something other than the default 22.
I moved mine to 443 (https), since it's accessible from highly firewalled networks behind which I may be trapped, and people are already used to seeing encrypted traffic on that port.
Ever since I did this, I haven't seen a single login attempt on my server other than myself.
This means my server also wastes less time rejecting remote logins.The ssh brute force bots I've seen are very stupid.
I'm not really sure what the bot operators are doing.
In my ssh honeypot where I have the root password set to "password", most bots won't ever guess it after thousands of attempts.
Of the ones that do eventually guess the right password, most log out right away, then go right back to guessing root passwords again!
Maybe trying to detect if it's a honeypot?
Then there are ones that do log in and stop guessing, but they immediately log out and don't ever return (that is, no one has ever shown up and logged in without making guesses).
Security researchers?
Maybe marked my honeypot down for some future abuse?
Maybe detected that it was a honeypot?
I'm not sure what's going on with that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109530</id>
	<title>Re:DenyHosts will not save you; disable passwords</title>
	<author>dkf</author>
	<datestamp>1258284300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And if a machine that has your public key on it is compromised?</p></div><p>Either you are very very stupid, or you meant <i>private</i> key. If the former, you understand that the only reason I'm not publishing my public ssh keys here, on slashdot, is that I don't want some loony jerk giving me an account without my knowledge? I have more than enough of the damn things already. However, if you meant private keys then that's a fair point: they're best kept on machines that never run services. (OK, it would also be better if those machines never ran web browsers either given the general inability of javascript implementors to grasp what a sane security policy is, but sometimes you just have to compromise. Or carry two laptops around with you...)</p></div>
	</htmltext>
<tokenext>And if a machine that has your public key on it is compromised ? Either you are very very stupid , or you meant private key .
If the former , you understand that the only reason I 'm not publishing my public ssh keys here , on slashdot , is that I do n't want some loony jerk giving me an account without my knowledge ?
I have more than enough of the damn things already .
However , if you meant private keys then that 's a fair point : they 're best kept on machines that never run services .
( OK , it would also be better if those machines never ran web browsers either given the general inability of javascript implementors to grasp what a sane security policy is , but sometimes you just have to compromise .
Or carry two laptops around with you... )</tokentext>
<sentencetext>And if a machine that has your public key on it is compromised?Either you are very very stupid, or you meant private key.
If the former, you understand that the only reason I'm not publishing my public ssh keys here, on slashdot, is that I don't want some loony jerk giving me an account without my knowledge?
I have more than enough of the damn things already.
However, if you meant private keys then that's a fair point: they're best kept on machines that never run services.
(OK, it would also be better if those machines never ran web browsers either given the general inability of javascript implementors to grasp what a sane security policy is, but sometimes you just have to compromise.
Or carry two laptops around with you...)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107350</id>
	<title>Re:DenyHosts will not save you; disable passwords</title>
	<author>RobertLTux</author>
	<datestamp>1258314000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>and you could also have a flash key with your SSH utility that could be used to login from any other computer (heck with the price of flashkeys these days you could have your entire software stack on the key and a good bit of data)</p></htmltext>
<tokenext>and you could also have a flash key with your SSH utility that could be used to login from any other computer ( heck with the price of flashkeys these days you could have your entire software stack on the key and a good bit of data )</tokentext>
<sentencetext>and you could also have a flash key with your SSH utility that could be used to login from any other computer (heck with the price of flashkeys these days you could have your entire software stack on the key and a good bit of data)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30142158</id>
	<title>Re:The cloud attack isn't new</title>
	<author>TheEden</author>
	<datestamp>1257082920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Port forwarding is a great thing btw. I changed ssh port from 22 to something like 4254 or whatever, and that was really helpful in my case.</htmltext>
<tokenext>Port forwarding is a great thing btw .
I changed ssh port from 22 to something like 4254 or whatever , and that was really helpful in my case .</tokentext>
<sentencetext>Port forwarding is a great thing btw.
I changed ssh port from 22 to something like 4254 or whatever, and that was really helpful in my case.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30108896</id>
	<title>Set sshd to listen on a non-standard port</title>
	<author>Anonymous</author>
	<datestamp>1258279560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've try a number of things, ssh-anti-brute.pl worked well at least initially (when receiving multiple failed logins from the same destination address) but my drop chain was starting to get kinda lengthy.</p><p>I've recently moved sshd off port 22 and it seems to be doing the trick.</p></htmltext>
<tokenext>I 've try a number of things , ssh-anti-brute.pl worked well at least initially ( when receiving multiple failed logins from the same destination address ) but my drop chain was starting to get kinda lengthy.I 've recently moved sshd off port 22 and it seems to be doing the trick .</tokentext>
<sentencetext>I've try a number of things, ssh-anti-brute.pl worked well at least initially (when receiving multiple failed logins from the same destination address) but my drop chain was starting to get kinda lengthy.I've recently moved sshd off port 22 and it seems to be doing the trick.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106916</id>
	<title>Re:Put in denyhosts...</title>
	<author>the\_humeister</author>
	<datestamp>1258311480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Better would be to use public key/private key pairs and disallow username/password logins.</p></htmltext>
<tokenext>Better would be to use public key/private key pairs and disallow username/password logins .</tokentext>
<sentencetext>Better would be to use public key/private key pairs and disallow username/password logins.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30116284</id>
	<title>Disable Password Logins!!</title>
	<author>Anonymous</author>
	<datestamp>1258391340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Using an RSA or DSA  Pubkey will effectively stop these..</p><p>Add on top of that a firewall rule blocking high volume of requests to your server (I have it set at 4 per minute<nobr> <wbr></nobr>:)) works well for this.</p><p>I *NEVER* setup an SSH server using password auth..</p><p>Oh, and of course TURNING OFF SSH on your iphone when not needed is ALWAYS a good idea.</p></htmltext>
<tokenext>Using an RSA or DSA Pubkey will effectively stop these..Add on top of that a firewall rule blocking high volume of requests to your server ( I have it set at 4 per minute : ) ) works well for this.I * NEVER * setup an SSH server using password auth..Oh , and of course TURNING OFF SSH on your iphone when not needed is ALWAYS a good idea .</tokentext>
<sentencetext>Using an RSA or DSA  Pubkey will effectively stop these..Add on top of that a firewall rule blocking high volume of requests to your server (I have it set at 4 per minute :)) works well for this.I *NEVER* setup an SSH server using password auth..Oh, and of course TURNING OFF SSH on your iphone when not needed is ALWAYS a good idea.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106814</id>
	<title>Bad or good matters not here...</title>
	<author>Anonymous</author>
	<datestamp>1258310580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...because if the password is pre-set, default, and known to everyone accessing the software, then, yeah, exactly, you dumb s**t of an article author.</p></htmltext>
<tokenext>...because if the password is pre-set , default , and known to everyone accessing the software , then , yeah , exactly , you dumb s * * t of an article author .</tokentext>
<sentencetext>...because if the password is pre-set, default, and known to everyone accessing the software, then, yeah, exactly, you dumb s**t of an article author.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107824</id>
	<title>Re:Denyhosts</title>
	<author>ceoyoyo</author>
	<datestamp>1258316880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Over the last week my SSH server has gotten about one password guessing attempt every ten seconds.  Presumably they're not all from different hosts, but a quick visual scan didn't show up any duplicates and the ones that are close in time are certainly all from different IP addresses.</p></htmltext>
<tokenext>Over the last week my SSH server has gotten about one password guessing attempt every ten seconds .
Presumably they 're not all from different hosts , but a quick visual scan did n't show up any duplicates and the ones that are close in time are certainly all from different IP addresses .</tokentext>
<sentencetext>Over the last week my SSH server has gotten about one password guessing attempt every ten seconds.
Presumably they're not all from different hosts, but a quick visual scan didn't show up any duplicates and the ones that are close in time are certainly all from different IP addresses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106788</id>
	<title>Wet Nuns</title>
	<author>byrdfl3w</author>
	<datestamp>1258310340000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>Hail Mary's... Deamons... Rick Astley.. The final battle is closer than we ever imagined.</htmltext>
<tokenext>Hail Mary 's... Deamons... Rick Astley.. The final battle is closer than we ever imagined .</tokentext>
<sentencetext>Hail Mary's... Deamons... Rick Astley.. The final battle is closer than we ever imagined.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107240</id>
	<title>Re:Denyhosts</title>
	<author>causality</author>
	<datestamp>1258313580000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Yes indeed.  You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.</p></div><p>What I will say here applies to password logins.  For SSHD that is configured to accept only cryptographic/public-key authentication, the attacks that Denyhosts would block are only a nuisance (they fill up logfiles).
<br> <br>
That heavily-audited network-facing daemon does not concern itself with password security.  You can allow remote root logins and set your root password to "password" and that daemon will faithfully do what you told it to do.  The heavy audits are designed to make sure that a person who does not have a valid login cannot get a shell without first guessing valid login credentials.  The Python script makes it infeasible for a single host to brute-force those login credentials assuming a reasonably strong password.  Thus, it addresses a security issue that is actually beyond the scope of SSHD.
<br> <br>
Personally I prefer SSHGuard because it will use iptables to drop packets from offending hosts.  In my opinion that's a better approach than adding the hosts to a hosts.deny file.  A host listed in hosts.deny can still try to connect to your daemon; it will just be immediately disconnected.  By contrast, anything firewalled by iptables and set to DROP won't even get so much as a momentary TCP connection.  Not a big difference, but I say let them wonder if you're even online anymore.  There's also no dependency on the robustness of tcpwrappers (well-tested though they may be).</p></div>
	</htmltext>
<tokenext>Yes indeed .
You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.What I will say here applies to password logins .
For SSHD that is configured to accept only cryptographic/public-key authentication , the attacks that Denyhosts would block are only a nuisance ( they fill up logfiles ) .
That heavily-audited network-facing daemon does not concern itself with password security .
You can allow remote root logins and set your root password to " password " and that daemon will faithfully do what you told it to do .
The heavy audits are designed to make sure that a person who does not have a valid login can not get a shell without first guessing valid login credentials .
The Python script makes it infeasible for a single host to brute-force those login credentials assuming a reasonably strong password .
Thus , it addresses a security issue that is actually beyond the scope of SSHD .
Personally I prefer SSHGuard because it will use iptables to drop packets from offending hosts .
In my opinion that 's a better approach than adding the hosts to a hosts.deny file .
A host listed in hosts.deny can still try to connect to your daemon ; it will just be immediately disconnected .
By contrast , anything firewalled by iptables and set to DROP wo n't even get so much as a momentary TCP connection .
Not a big difference , but I say let them wonder if you 're even online anymore .
There 's also no dependency on the robustness of tcpwrappers ( well-tested though they may be ) .</tokentext>
<sentencetext>Yes indeed.
You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.What I will say here applies to password logins.
For SSHD that is configured to accept only cryptographic/public-key authentication, the attacks that Denyhosts would block are only a nuisance (they fill up logfiles).
That heavily-audited network-facing daemon does not concern itself with password security.
You can allow remote root logins and set your root password to "password" and that daemon will faithfully do what you told it to do.
The heavy audits are designed to make sure that a person who does not have a valid login cannot get a shell without first guessing valid login credentials.
The Python script makes it infeasible for a single host to brute-force those login credentials assuming a reasonably strong password.
Thus, it addresses a security issue that is actually beyond the scope of SSHD.
Personally I prefer SSHGuard because it will use iptables to drop packets from offending hosts.
In my opinion that's a better approach than adding the hosts to a hosts.deny file.
A host listed in hosts.deny can still try to connect to your daemon; it will just be immediately disconnected.
By contrast, anything firewalled by iptables and set to DROP won't even get so much as a momentary TCP connection.
Not a big difference, but I say let them wonder if you're even online anymore.
There's also no dependency on the robustness of tcpwrappers (well-tested though they may be).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106960</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30119324</id>
	<title>Re:What has to happen?</title>
	<author>Proteus Child</author>
	<datestamp>1258401480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?</p></div><p>The Infocalypse?</p></div>
	</htmltext>
<tokenext>Just was has to happen to make people realize ( or make lawmakers force them to ) that securing your boxes is a necessity ? The Infocalypse ?</tokentext>
<sentencetext>Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?The Infocalypse?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107230</id>
	<title>Translation for non-retards:</title>
	<author>Hurricane78</author>
	<datestamp>1258313520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>s/cloud/network/</p><p>There. Done it for ya. Was that so hard?</p><p>We should make a Greasemonkey script out of it.<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>s/cloud/network/There .
Done it for ya .
Was that so hard ? We should make a Greasemonkey script out of it .
: )</tokentext>
<sentencetext>s/cloud/network/There.
Done it for ya.
Was that so hard?We should make a Greasemonkey script out of it.
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107680</id>
	<title>Re:The cloud attack isn't new</title>
	<author>Anonymous</author>
	<datestamp>1258316100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Run "John The Ripper" against your user list to detect poor passwords before someone else does.</p></htmltext>
<tokenext>Run " John The Ripper " against your user list to detect poor passwords before someone else does .</tokentext>
<sentencetext>Run "John The Ripper" against your user list to detect poor passwords before someone else does.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109406</id>
	<title>Re:The cloud attack isn't new</title>
	<author>flyingfsck</author>
	<datestamp>1258283520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Another effective protection is to change the default port of SSH from the standard 22 to something else.  Even though a brute forcer could add a port scan to look for SSH elsewhere, the fact is that they don't.</htmltext>
<tokenext>Another effective protection is to change the default port of SSH from the standard 22 to something else .
Even though a brute forcer could add a port scan to look for SSH elsewhere , the fact is that they do n't .</tokentext>
<sentencetext>Another effective protection is to change the default port of SSH from the standard 22 to something else.
Even though a brute forcer could add a port scan to look for SSH elsewhere, the fact is that they don't.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30143688</id>
	<title>Re:The cloud attack isn't new</title>
	<author>DusterBar</author>
	<datestamp>1257091560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The one thing I always do is turn off password login via SSH.  Only authorized keys are allowed and they are strictly controlled.
</p><p>
I also have black-listed some parts of the IP address space where a vast majority of the attacks were coming from but lately this has proven not to do as much as it used to do.
</p></htmltext>
<tokenext>The one thing I always do is turn off password login via SSH .
Only authorized keys are allowed and they are strictly controlled .
I also have black-listed some parts of the IP address space where a vast majority of the attacks were coming from but lately this has proven not to do as much as it used to do .</tokentext>
<sentencetext>The one thing I always do is turn off password login via SSH.
Only authorized keys are allowed and they are strictly controlled.
I also have black-listed some parts of the IP address space where a vast majority of the attacks were coming from but lately this has proven not to do as much as it used to do.
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107426</id>
	<title>Re:Put in denyhosts...</title>
	<author>emurphy42</author>
	<datestamp>1258314360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've long since gone the opposite route, my server rejects all requests unless<nobr> <wbr></nobr>/etc/hosts.allow has already whitelisted them.  Granted, it's a home server and I'm the only one who ever uses SSH on it.  (Hotel wifi is temp-whitelisted on the fly by remote-connecting to a whitelisted work client.)</htmltext>
<tokenext>I 've long since gone the opposite route , my server rejects all requests unless /etc/hosts.allow has already whitelisted them .
Granted , it 's a home server and I 'm the only one who ever uses SSH on it .
( Hotel wifi is temp-whitelisted on the fly by remote-connecting to a whitelisted work client .
)</tokentext>
<sentencetext>I've long since gone the opposite route, my server rejects all requests unless /etc/hosts.allow has already whitelisted them.
Granted, it's a home server and I'm the only one who ever uses SSH on it.
(Hotel wifi is temp-whitelisted on the fly by remote-connecting to a whitelisted work client.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106826</id>
	<title>Re:Put in denyhosts...</title>
	<author>Anonymous</author>
	<datestamp>1258310640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Denyhosts will *not* protect you from Hail Mary. Read the article...this particular botnet may send you only a single login from a single IP, but the cloud as a whole will send you hundreds of attempts.<br>The correct solution is to disable password login, and use pubkey auth instead.</p></htmltext>
<tokenext>Denyhosts will * not * protect you from Hail Mary .
Read the article...this particular botnet may send you only a single login from a single IP , but the cloud as a whole will send you hundreds of attempts.The correct solution is to disable password login , and use pubkey auth instead .</tokentext>
<sentencetext>Denyhosts will *not* protect you from Hail Mary.
Read the article...this particular botnet may send you only a single login from a single IP, but the cloud as a whole will send you hundreds of attempts.The correct solution is to disable password login, and use pubkey auth instead.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30108486</id>
	<title>Re:DenyHosts will not save you; disable passwords</title>
	<author>shentino</author>
	<datestamp>1258277100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What we really ought to do is start cracking down more on botnets.</p><p>Letting criminals sheperd up huge flocks of zombie computers is the root of two very serious problems:  spam and DDoS attacks.</p><p>Forget electronic terrorism.  These guys have a fucking ARMY of computers.</p></htmltext>
<tokenext>What we really ought to do is start cracking down more on botnets.Letting criminals sheperd up huge flocks of zombie computers is the root of two very serious problems : spam and DDoS attacks.Forget electronic terrorism .
These guys have a fucking ARMY of computers .</tokentext>
<sentencetext>What we really ought to do is start cracking down more on botnets.Letting criminals sheperd up huge flocks of zombie computers is the root of two very serious problems:  spam and DDoS attacks.Forget electronic terrorism.
These guys have a fucking ARMY of computers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106960</id>
	<title>Re:Denyhosts</title>
	<author>Anonymous</author>
	<datestamp>1258311840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext>Yes indeed.  You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.</htmltext>
<tokenext>Yes indeed .
You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet .</tokentext>
<sentencetext>Yes indeed.
You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107822</id>
	<title>Re:Put in denyhosts...</title>
	<author>Anonymous</author>
	<datestamp>1258316880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>The nice thing about denyhosts is you can participate in the global shared DB, so one failed login on your machine, one on mine, etc, we all report the same IP, it gets flagged in the global DB, so we all block it.  Machines that IP hasn't hit now won't allow login attempts from it.</p></htmltext>
<tokenext>The nice thing about denyhosts is you can participate in the global shared DB , so one failed login on your machine , one on mine , etc , we all report the same IP , it gets flagged in the global DB , so we all block it .
Machines that IP has n't hit now wo n't allow login attempts from it .</tokentext>
<sentencetext>The nice thing about denyhosts is you can participate in the global shared DB, so one failed login on your machine, one on mine, etc, we all report the same IP, it gets flagged in the global DB, so we all block it.
Machines that IP hasn't hit now won't allow login attempts from it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106826</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112074</id>
	<title>Re:Put in denyhosts...</title>
	<author>doug</author>
	<datestamp>1258307580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> Oh, I get it.  We build a cloud to fight their cloud. </p></htmltext>
<tokenext>Oh , I get it .
We build a cloud to fight their cloud .</tokentext>
<sentencetext> Oh, I get it.
We build a cloud to fight their cloud. </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107822</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740</id>
	<title>What has to happen?</title>
	<author>Anonymous</author>
	<datestamp>1258309980000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?</p><p>What? Tell me, please, what has to happen? How much damage is needed? We'll see it happen, no matter how much damage is required. The question is only whether it's too late or whether we can repair it.</p></htmltext>
<tokenext>Just was has to happen to make people realize ( or make lawmakers force them to ) that securing your boxes is a necessity ? What ?
Tell me , please , what has to happen ?
How much damage is needed ?
We 'll see it happen , no matter how much damage is required .
The question is only whether it 's too late or whether we can repair it .</tokentext>
<sentencetext>Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?What?
Tell me, please, what has to happen?
How much damage is needed?
We'll see it happen, no matter how much damage is required.
The question is only whether it's too late or whether we can repair it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107472</id>
	<title>Re:Put in denyhosts...</title>
	<author>jimicus</author>
	<datestamp>1258314600000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Very true, but it'll only keep out an absolute moron.  Anyone with half a brain will use a distributed mechanism, which means DenyHosts will only see failed password attempts from a given host a few times.</p><p>There's plenty more to do:</p><p>- Don't allow root logins via SSH, or limit them to key-based logins (trivially easy in<nobr> <wbr></nobr>/etc/ssh/sshd.conf)<br>- Disable shell accounts unless they're really needed.  rssh is useful here - limit what a user with SSH login authority can do.<br>- Lock down other services.  What good does DenyHosts do you if SSH and a separate app which can't be locked with DenyHosts both use the same password mechanism?<br>- Lock accounts which have more than N failed logins.  (Though if you've centralised logins such as in the above example, it'd probably be better to do this from whatever system deals with the authentication, eg. LDAP).</p></htmltext>
<tokenext>Very true , but it 'll only keep out an absolute moron .
Anyone with half a brain will use a distributed mechanism , which means DenyHosts will only see failed password attempts from a given host a few times.There 's plenty more to do : - Do n't allow root logins via SSH , or limit them to key-based logins ( trivially easy in /etc/ssh/sshd.conf ) - Disable shell accounts unless they 're really needed .
rssh is useful here - limit what a user with SSH login authority can do.- Lock down other services .
What good does DenyHosts do you if SSH and a separate app which ca n't be locked with DenyHosts both use the same password mechanism ? - Lock accounts which have more than N failed logins .
( Though if you 've centralised logins such as in the above example , it 'd probably be better to do this from whatever system deals with the authentication , eg .
LDAP ) .</tokentext>
<sentencetext>Very true, but it'll only keep out an absolute moron.
Anyone with half a brain will use a distributed mechanism, which means DenyHosts will only see failed password attempts from a given host a few times.There's plenty more to do:- Don't allow root logins via SSH, or limit them to key-based logins (trivially easy in /etc/ssh/sshd.conf)- Disable shell accounts unless they're really needed.
rssh is useful here - limit what a user with SSH login authority can do.- Lock down other services.
What good does DenyHosts do you if SSH and a separate app which can't be locked with DenyHosts both use the same password mechanism?- Lock accounts which have more than N failed logins.
(Though if you've centralised logins such as in the above example, it'd probably be better to do this from whatever system deals with the authentication, eg.
LDAP).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950</id>
	<title>DenyHosts will not save you; disable passwords</title>
	<author>Radhruin</author>
	<datestamp>1258311720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>This is a distributed effort, and any one host will not hit your machine more than once. You could configure it to block entire country's subnets, but that's still only marginal protection.

</p><p>What you want to do is disable username/password authentication on your ssh hosts. This is one of the first things I do. Set up your machine's public and private key, copy your public key to all your other machine's authorized\_keys file, and edit your sshd config and add the line "PasswordAuthentication no". Now, broken crypto libraries aside, you will be safe from this sort of attack.</p></htmltext>
<tokenext>This is a distributed effort , and any one host will not hit your machine more than once .
You could configure it to block entire country 's subnets , but that 's still only marginal protection .
What you want to do is disable username/password authentication on your ssh hosts .
This is one of the first things I do .
Set up your machine 's public and private key , copy your public key to all your other machine 's authorized \ _keys file , and edit your sshd config and add the line " PasswordAuthentication no " .
Now , broken crypto libraries aside , you will be safe from this sort of attack .</tokentext>
<sentencetext>This is a distributed effort, and any one host will not hit your machine more than once.
You could configure it to block entire country's subnets, but that's still only marginal protection.
What you want to do is disable username/password authentication on your ssh hosts.
This is one of the first things I do.
Set up your machine's public and private key, copy your public key to all your other machine's authorized\_keys file, and edit your sshd config and add the line "PasswordAuthentication no".
Now, broken crypto libraries aside, you will be safe from this sort of attack.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762</id>
	<title>Put in denyhosts...</title>
	<author>Anonymous</author>
	<datestamp>1258310160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Denyhosts is available for most linux distros.

You can tune its behavior and it will basically filter out requests coming from misbehaving hosts.

From Wikipedia:

"DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses. "</htmltext>
<tokenext>Denyhosts is available for most linux distros .
You can tune its behavior and it will basically filter out requests coming from misbehaving hosts .
From Wikipedia : " DenyHosts is a Python based security tool for SSH servers .
It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses .
"</tokentext>
<sentencetext>Denyhosts is available for most linux distros.
You can tune its behavior and it will basically filter out requests coming from misbehaving hosts.
From Wikipedia:

"DenyHosts is a Python based security tool for SSH servers.
It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses.
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740</id>
	<title>Re:DenyHosts will not save you; disable passwords</title>
	<author>nurb432</author>
	<datestamp>1258316400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And if a machine that has your public key on it is compromised ?</p></htmltext>
<tokenext>And if a machine that has your public key on it is compromised ?</tokentext>
<sentencetext>And if a machine that has your public key on it is compromised ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106776</id>
	<title>How to ID an Infected Computer</title>
	<author>derrickh</author>
	<datestamp>1258310280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So is there any way other than looking at the packets on your router to know if a system is compromised? This is a question thats been asked many times before but Ive yet to see a straight answer.</p></htmltext>
<tokenext>So is there any way other than looking at the packets on your router to know if a system is compromised ?
This is a question thats been asked many times before but Ive yet to see a straight answer .</tokentext>
<sentencetext>So is there any way other than looking at the packets on your router to know if a system is compromised?
This is a question thats been asked many times before but Ive yet to see a straight answer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109220</id>
	<title>hairy business</title>
	<author>Anonymous</author>
	<datestamp>1258282140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Am I the only one who misread the title as "The 'Hairy Mail Cloud' is Growing"?</p></htmltext>
<tokenext>Am I the only one who misread the title as " The 'Hairy Mail Cloud ' is Growing " ?</tokentext>
<sentencetext>Am I the only one who misread the title as "The 'Hairy Mail Cloud' is Growing"?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112414</id>
	<title>Re:Translation for non-retards:</title>
	<author>RyuuzakiTetsuya</author>
	<datestamp>1258312080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Then reading Final fantasy VII faqs and Meterology websites would get really strange.</p></htmltext>
<tokenext>Then reading Final fantasy VII faqs and Meterology websites would get really strange .</tokentext>
<sentencetext>Then reading Final fantasy VII faqs and Meterology websites would get really strange.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107230</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106982</id>
	<title>Re:What has to happen?</title>
	<author>Anonymous</author>
	<datestamp>1258311960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Clearly, for most people the damage so far hasn't outweighed the costs of properly securing their systems, or at least hasn't outweighed the benefits of using Windows (or their goddamn iPhones, in this case).</p><p>This is just the free market at work.</p><p>That said, those of us who aren't fucktards are making use of OpenBSD, which actually takes security somewhat seriously, unlike virtually every other operating system out there.</p></htmltext>
<tokenext>Clearly , for most people the damage so far has n't outweighed the costs of properly securing their systems , or at least has n't outweighed the benefits of using Windows ( or their goddamn iPhones , in this case ) .This is just the free market at work.That said , those of us who are n't fucktards are making use of OpenBSD , which actually takes security somewhat seriously , unlike virtually every other operating system out there .</tokentext>
<sentencetext>Clearly, for most people the damage so far hasn't outweighed the costs of properly securing their systems, or at least hasn't outweighed the benefits of using Windows (or their goddamn iPhones, in this case).This is just the free market at work.That said, those of us who aren't fucktards are making use of OpenBSD, which actually takes security somewhat seriously, unlike virtually every other operating system out there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026</id>
	<title>The cloud attack isn't new</title>
	<author>damn\_registrars</author>
	<datestamp>1258312260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>I've <a href="http://slashdot.org/~damn\_registrars/journal/228777" title="slashdot.org">mentioned </a> [slashdot.org] <a href="http://slashdot.org/~damn\_registrars/journal/227687" title="slashdot.org">distributed </a> [slashdot.org] <a href="http://slashdot.org/~damn\_registrars/journal/220535" title="slashdot.org">attempts </a> [slashdot.org] <a href="http://slashdot.org/~damn\_registrars/journal/218467" title="slashdot.org">against </a> [slashdot.org] <a href="http://slashdot.org/~damn\_registrars/journal/218091" title="slashdot.org">my own </a> [slashdot.org] <a href="http://slashdot.org/~damn\_registrars/journal/206933" title="slashdot.org">system </a> [slashdot.org] before.  The only thing that has changed over time is the number of systems involved in a cycle.  I suspect my own system is currently (by nothing other than bad luck) the target of multiple concurrent cycles.  I suspect this because I see different parts of the alphabet being cycled at different rates (in terms of attempts per user name) at the same time.<br> <br>
Although in spite of all the advice people offer to ward off the attacks, there are a couple of really simple things to do that will keep it at bay with excellent effectiveness:<ul> <li>Don't allow remote root login</li><li>Keep your list of allowed users as short as possible and practical</li><li>Avoid common login names (especially common first names) if possible</li><li>Make sure your users use strong passwords</li></ul><p>
If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there weren't any attempts on valid names.  Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts...</p></htmltext>
<tokenext>I 've mentioned [ slashdot.org ] distributed [ slashdot.org ] attempts [ slashdot.org ] against [ slashdot.org ] my own [ slashdot.org ] system [ slashdot.org ] before .
The only thing that has changed over time is the number of systems involved in a cycle .
I suspect my own system is currently ( by nothing other than bad luck ) the target of multiple concurrent cycles .
I suspect this because I see different parts of the alphabet being cycled at different rates ( in terms of attempts per user name ) at the same time .
Although in spite of all the advice people offer to ward off the attacks , there are a couple of really simple things to do that will keep it at bay with excellent effectiveness : Do n't allow remote root loginKeep your list of allowed users as short as possible and practicalAvoid common login names ( especially common first names ) if possibleMake sure your users use strong passwords If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there were n't any attempts on valid names .
Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts.. .</tokentext>
<sentencetext>I've mentioned  [slashdot.org] distributed  [slashdot.org] attempts  [slashdot.org] against  [slashdot.org] my own  [slashdot.org] system  [slashdot.org] before.
The only thing that has changed over time is the number of systems involved in a cycle.
I suspect my own system is currently (by nothing other than bad luck) the target of multiple concurrent cycles.
I suspect this because I see different parts of the alphabet being cycled at different rates (in terms of attempts per user name) at the same time.
Although in spite of all the advice people offer to ward off the attacks, there are a couple of really simple things to do that will keep it at bay with excellent effectiveness: Don't allow remote root loginKeep your list of allowed users as short as possible and practicalAvoid common login names (especially common first names) if possibleMake sure your users use strong passwords
If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there weren't any attempts on valid names.
Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107382</id>
	<title>Plaintext passwords over ssh</title>
	<author>m.dillon</author>
	<datestamp>1258314120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Plaintext passwords over ssh have always bothered me.  I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.</p><p>The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in<nobr> <wbr></nobr>/etc/ssh/sshd\_config (or wherever it lives).  Problem solved.</p><p>Nobody should be using that sort of authentication any more anyway.</p><p>-Matt</p></htmltext>
<tokenext>Plaintext passwords over ssh have always bothered me .
I always had a little program called 'sshlockout ' which checks for failed password attempts via auth.log and lockout the IP , but that clearly wo n't work against something like this.The only real solution is to disallow tunneled plaintext password logins entirely... simple enough , just set 'PasswordAuthentication no ' in /etc/ssh/sshd \ _config ( or wherever it lives ) .
Problem solved.Nobody should be using that sort of authentication any more anyway.-Matt</tokentext>
<sentencetext>Plaintext passwords over ssh have always bothered me.
I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in /etc/ssh/sshd\_config (or wherever it lives).
Problem solved.Nobody should be using that sort of authentication any more anyway.-Matt</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798</id>
	<title>Denyhosts</title>
	<author>EllisDees</author>
	<datestamp>1258310400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I would think that anyone running an ssh server should also be running something like <a href="http://denyhosts.sourceforge.net/" title="sourceforge.net">the Denyhosts daemon</a> [sourceforge.net]. After a set number of failed logon attempts, it will automatically add the connecting ip address to hosts.deny and their hack attempt is over.</p></htmltext>
<tokenext>I would think that anyone running an ssh server should also be running something like the Denyhosts daemon [ sourceforge.net ] .
After a set number of failed logon attempts , it will automatically add the connecting ip address to hosts.deny and their hack attempt is over .</tokentext>
<sentencetext>I would think that anyone running an ssh server should also be running something like the Denyhosts daemon [sourceforge.net].
After a set number of failed logon attempts, it will automatically add the connecting ip address to hosts.deny and their hack attempt is over.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109406
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112414
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107230
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107472
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107756
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107134
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106980
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107240
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106960
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106982
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107922
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107350
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107426
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30143688
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107172
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112012
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30142158
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107680
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30108486
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30119324
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109216
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107640
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_15_1653228_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112074
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106826
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106722
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106776
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106932
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106814
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107026
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30142158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30143688
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109406
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107680
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107922
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112012
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106798
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107824
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106960
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107240
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107062
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106762
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106826
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107822
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112074
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107426
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106916
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106980
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107640
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107472
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107134
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107756
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107230
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30112414
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106950
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107350
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107740
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109216
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30109530
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30108486
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_15_1653228.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106740
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30119324
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30107172
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_15_1653228.30106982
</commentlist>
</conversation>
