<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_06_2138221</id>
	<title>Coping With 1 Million SSH Authentication Failures?</title>
	<author>kdawson</author>
	<datestamp>1267879860000</datestamp>
	<htmltext>An anonymous reader writes <i>"I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses. Our production servers, which host about 50 sites and generate ~20K hits/week, are managed by a 3rd party that I'm sure many on Slashdot would recognize. Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year. I contacted the ISP, who had promised me that server security would be actively managed, and their recommendation was, 'change the SSH port!' Of course this makes sense and may help to an extent, but it still doesn't solve the problem I'm facing: how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)? User passwords are randomly generated, we use a non-standard SSH port, and do not use any unencrypted services such as FTP. Is there a server monitoring program you would recommend? Is there an ISP or Web-based service that specializes in this?"</i></htmltext>
<tokenext>An anonymous reader writes " I own a small Web development studio that specializes in open source software , primarily Drupal , WordPress , and Joomla for small businesses .
Our production servers , which host about 50 sites and generate ~ 20K hits/week , are managed by a 3rd party that I 'm sure many on Slashdot would recognize .
Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~ 1200 IP addresses on one of our servers over the last year .
I contacted the ISP , who had promised me that server security would be actively managed , and their recommendation was , 'change the SSH port !
' Of course this makes sense and may help to an extent , but it still does n't solve the problem I 'm facing : how do you manage server security on a tight budget with literally no system admin ( except for me and I know I 'm a n00b ) ?
User passwords are randomly generated , we use a non-standard SSH port , and do not use any unencrypted services such as FTP .
Is there a server monitoring program you would recommend ?
Is there an ISP or Web-based service that specializes in this ?
"</tokentext>
<sentencetext>An anonymous reader writes "I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses.
Our production servers, which host about 50 sites and generate ~20K hits/week, are managed by a 3rd party that I'm sure many on Slashdot would recognize.
Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year.
I contacted the ISP, who had promised me that server security would be actively managed, and their recommendation was, 'change the SSH port!
' Of course this makes sense and may help to an extent, but it still doesn't solve the problem I'm facing: how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)?
User passwords are randomly generated, we use a non-standard SSH port, and do not use any unencrypted services such as FTP.
Is there a server monitoring program you would recommend?
Is there an ISP or Web-based service that specializes in this?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385116</id>
	<title>use openvpn ?</title>
	<author>yorugua</author>
	<datestamp>1267883760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>if you can manage the set of users of your server, you can use OpenVPN and then SSH. OpenVPN has a "feature" that if each packet of the VPN is not digitally signed by a previously arranged (and distribuyed) key, then the packet is "ignored". After the VPN session is established/authenticated, your users can log in using ssh. There are even some virtual appliances and special distros (untangle.com) that have a "openvpn appliance" built in for this purpose. The how-to for openvpn is also easy to follow.</htmltext>
<tokenext>if you can manage the set of users of your server , you can use OpenVPN and then SSH .
OpenVPN has a " feature " that if each packet of the VPN is not digitally signed by a previously arranged ( and distribuyed ) key , then the packet is " ignored " .
After the VPN session is established/authenticated , your users can log in using ssh .
There are even some virtual appliances and special distros ( untangle.com ) that have a " openvpn appliance " built in for this purpose .
The how-to for openvpn is also easy to follow .</tokentext>
<sentencetext>if you can manage the set of users of your server, you can use OpenVPN and then SSH.
OpenVPN has a "feature" that if each packet of the VPN is not digitally signed by a previously arranged (and distribuyed) key, then the packet is "ignored".
After the VPN session is established/authenticated, your users can log in using ssh.
There are even some virtual appliances and special distros (untangle.com) that have a "openvpn appliance" built in for this purpose.
The how-to for openvpn is also easy to follow.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391662</id>
	<title>Re:Passwords?</title>
	<author>jon3k</author>
	<datestamp>1267987620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have to assume by easier you mean using certificated based authentication without passwords.  This is bad.  Not only is it harder to setup but keys can be stolen easily and (very much due to) have to be moved from device to device.  What you want is key + password this is "Two Factor Authentication" - something you HAVE (the keyfile) and something you KNOW (the password).</htmltext>
<tokenext>I have to assume by easier you mean using certificated based authentication without passwords .
This is bad .
Not only is it harder to setup but keys can be stolen easily and ( very much due to ) have to be moved from device to device .
What you want is key + password this is " Two Factor Authentication " - something you HAVE ( the keyfile ) and something you KNOW ( the password ) .</tokentext>
<sentencetext>I have to assume by easier you mean using certificated based authentication without passwords.
This is bad.
Not only is it harder to setup but keys can be stolen easily and (very much due to) have to be moved from device to device.
What you want is key + password this is "Two Factor Authentication" - something you HAVE (the keyfile) and something you KNOW (the password).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385820</id>
	<title>restrict access to specific hosts / networks</title>
	<author>Anonymous</author>
	<datestamp>1267889700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Don't let administrative ports/pages be open to the world on your production environment. If you think you have to (Need to log in to troubleshoot from a hotel etc) you don't.</p><p>Use a development host in an unprivileged network with unprivileged users as a jump host if absolutely needed. Don't store host keys on jump hosts. If you're just on a single host well.. too bad. See above messages about fail2ban alternative ports etc.</p><p>Patch regularly to help prevent local privilege escalation vulnerabilities.</p><p>Disallow remote root ssh logins. Use sudo with as needed command configuration. Use file groups/permissions wisely so users don't need privilege escalation to do their daily work. (777 is not wisely!)</p><p>Disallow shell access for people that only deal with content files. (sftponly for content. nologin for users that need neither file nor shell access)</p><p>And of course use strong passwords.</p></htmltext>
<tokenext>Do n't let administrative ports/pages be open to the world on your production environment .
If you think you have to ( Need to log in to troubleshoot from a hotel etc ) you do n't.Use a development host in an unprivileged network with unprivileged users as a jump host if absolutely needed .
Do n't store host keys on jump hosts .
If you 're just on a single host well.. too bad .
See above messages about fail2ban alternative ports etc.Patch regularly to help prevent local privilege escalation vulnerabilities.Disallow remote root ssh logins .
Use sudo with as needed command configuration .
Use file groups/permissions wisely so users do n't need privilege escalation to do their daily work .
( 777 is not wisely !
) Disallow shell access for people that only deal with content files .
( sftponly for content .
nologin for users that need neither file nor shell access ) And of course use strong passwords .</tokentext>
<sentencetext>Don't let administrative ports/pages be open to the world on your production environment.
If you think you have to (Need to log in to troubleshoot from a hotel etc) you don't.Use a development host in an unprivileged network with unprivileged users as a jump host if absolutely needed.
Don't store host keys on jump hosts.
If you're just on a single host well.. too bad.
See above messages about fail2ban alternative ports etc.Patch regularly to help prevent local privilege escalation vulnerabilities.Disallow remote root ssh logins.
Use sudo with as needed command configuration.
Use file groups/permissions wisely so users don't need privilege escalation to do their daily work.
(777 is not wisely!
)Disallow shell access for people that only deal with content files.
(sftponly for content.
nologin for users that need neither file nor shell access)And of course use strong passwords.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385650</id>
	<title>I love it!</title>
	<author>Bananatree3</author>
	<datestamp>1267887780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You are making them <b>work</b> for their attempt. Soon, you're servers are just too expensive time wise to make it a worthwhile investment.</htmltext>
<tokenext>You are making them work for their attempt .
Soon , you 're servers are just too expensive time wise to make it a worthwhile investment .</tokentext>
<sentencetext>You are making them work for their attempt.
Soon, you're servers are just too expensive time wise to make it a worthwhile investment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388876</id>
	<title>Re:Hardware firewall or use bfd</title>
	<author>Anonymous</author>
	<datestamp>1267972140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>bfd (and apf if you like it)</p></div><p>Seconded. From what I remember, they only work on RPM-based distros. Also, <a href="http://www.rfxn.com/projects/brute-force-detection/" title="rfxn.com" rel="nofollow">bfd</a> [rfxn.com] (brute-force detection) is useless without <a href="http://www.rfxn.com/projects/advanced-policy-firewall/" title="rfxn.com" rel="nofollow">apf</a> [rfxn.com] (advanced policy firewall), you need apf up and running before bfd will do anything.</p><p>The other benefit with apf is that it can periodically pool a few lists of known botnets or dodgy IPs and blacklists them.</p></div>
	</htmltext>
<tokenext>bfd ( and apf if you like it ) Seconded .
From what I remember , they only work on RPM-based distros .
Also , bfd [ rfxn.com ] ( brute-force detection ) is useless without apf [ rfxn.com ] ( advanced policy firewall ) , you need apf up and running before bfd will do anything.The other benefit with apf is that it can periodically pool a few lists of known botnets or dodgy IPs and blacklists them .</tokentext>
<sentencetext>bfd (and apf if you like it)Seconded.
From what I remember, they only work on RPM-based distros.
Also, bfd [rfxn.com] (brute-force detection) is useless without apf [rfxn.com] (advanced policy firewall), you need apf up and running before bfd will do anything.The other benefit with apf is that it can periodically pool a few lists of known botnets or dodgy IPs and blacklists them.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386132</id>
	<title>ACLs + port knocking</title>
	<author>adosch</author>
	<datestamp>1267892580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've seen quite a few posts about using `iptables` (which I'm 100\% for and there were some pretty stout ideas that I hadn't thought of myself) however, regardless of running SSH on it's standard service port or picking an alternative, I didn't see a lot of comments about just implementing straight ACL's other on the tcpwrappers level in<nobr> <wbr></nobr>/etc/hosts.{allow,deny}.  Everyone talks about blacklists, but I think it's import to have whitelists as well.  A new method I've started to incorporate is a strict ACL whitelist `iptables` custom table along with using a custom port knocking sequence prior to opening up access for a particular window of time.</htmltext>
<tokenext>I 've seen quite a few posts about using ` iptables ` ( which I 'm 100 \ % for and there were some pretty stout ideas that I had n't thought of myself ) however , regardless of running SSH on it 's standard service port or picking an alternative , I did n't see a lot of comments about just implementing straight ACL 's other on the tcpwrappers level in /etc/hosts. { allow,deny } .
Everyone talks about blacklists , but I think it 's import to have whitelists as well .
A new method I 've started to incorporate is a strict ACL whitelist ` iptables ` custom table along with using a custom port knocking sequence prior to opening up access for a particular window of time .</tokentext>
<sentencetext>I've seen quite a few posts about using `iptables` (which I'm 100\% for and there were some pretty stout ideas that I hadn't thought of myself) however, regardless of running SSH on it's standard service port or picking an alternative, I didn't see a lot of comments about just implementing straight ACL's other on the tcpwrappers level in /etc/hosts.{allow,deny}.
Everyone talks about blacklists, but I think it's import to have whitelists as well.
A new method I've started to incorporate is a strict ACL whitelist `iptables` custom table along with using a custom port knocking sequence prior to opening up access for a particular window of time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385766</id>
	<title>Re:Port Knocking</title>
	<author>Anonymous</author>
	<datestamp>1267889220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://cipherdyne.org/fwknop/" title="cipherdyne.org">http://cipherdyne.org/fwknop/</a> [cipherdyne.org]</p><p>This was posted above.  It accomplishes the same goal as port knocking, but removes all of the timing issues and replay attack vectors.  All of the communication is cryptographically signed and encrypted and done via a closed port.</p></htmltext>
<tokenext>http : //cipherdyne.org/fwknop/ [ cipherdyne.org ] This was posted above .
It accomplishes the same goal as port knocking , but removes all of the timing issues and replay attack vectors .
All of the communication is cryptographically signed and encrypted and done via a closed port .</tokentext>
<sentencetext>http://cipherdyne.org/fwknop/ [cipherdyne.org]This was posted above.
It accomplishes the same goal as port knocking, but removes all of the timing issues and replay attack vectors.
All of the communication is cryptographically signed and encrypted and done via a closed port.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385576</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387794</id>
	<title>Determine what you need</title>
	<author>SmallFurryCreature</author>
	<datestamp>1267957320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You get a lot of recommendations here, but people tend to just blurt out the flavor of the hour they are using without considering the essential motto of any proffesional, "the right tool for the job".
</p><p>Simplest, do you need SSH access? I once maintained servers with absolutely no remote access capability of any kind. Didn't need to, lived within 5 minutes of the hosting location and simply worked from there. Saves a LOT of security hassle when only physical access can be used on a server. Most likely not possible, but I hope it does show that you must THINK about what is needed/possible in your situation.
</p><p>For instance, moving the SSH port. It is possible, security through obscurity at its finest, but how will it affect your customers? If you then got to deal with endless service calls to explain the non-standard port, or worse, client software can't handle alternate ports, then it is not the right tool.
</p><p>An alternative to this is switching the IP. Nothings says that the IP used to access the webserver must be the same as the one used to access SSH. Again security through obscurity, but it might help.
</p><p>Also, there is no law that says every machine should be remotely accesible. If you got a lot of servers, why not create an Admin box? It can connect through all the servers over the internal network, but the world facing servers got no outside admin connections. Yes, if the Admin server is borked, you are in trouble, but I found that people in the name of "Shit might happen" open themselves up to a lot more shit.
</p><p>An other simple approach is to block parts of the world that you don't expect legit connections to come from. If you are never in China and neither are your customers, why would you allow China to connect to port 22? Just remember that you got such a block in place before you book your holiday in Hong Kong.
</p><p>An even simpler approach is to block root from using SSH, and then use only somewhat unique account names. You need two parts to login to SSH. Brute forcing passwords is only half the job unless I have been missing something all these years.
</p><p>And on the whole, 1 million failed login's is a good thing. It is the successful login that you should worry about.</p></htmltext>
<tokenext>You get a lot of recommendations here , but people tend to just blurt out the flavor of the hour they are using without considering the essential motto of any proffesional , " the right tool for the job " .
Simplest , do you need SSH access ?
I once maintained servers with absolutely no remote access capability of any kind .
Did n't need to , lived within 5 minutes of the hosting location and simply worked from there .
Saves a LOT of security hassle when only physical access can be used on a server .
Most likely not possible , but I hope it does show that you must THINK about what is needed/possible in your situation .
For instance , moving the SSH port .
It is possible , security through obscurity at its finest , but how will it affect your customers ?
If you then got to deal with endless service calls to explain the non-standard port , or worse , client software ca n't handle alternate ports , then it is not the right tool .
An alternative to this is switching the IP .
Nothings says that the IP used to access the webserver must be the same as the one used to access SSH .
Again security through obscurity , but it might help .
Also , there is no law that says every machine should be remotely accesible .
If you got a lot of servers , why not create an Admin box ?
It can connect through all the servers over the internal network , but the world facing servers got no outside admin connections .
Yes , if the Admin server is borked , you are in trouble , but I found that people in the name of " Shit might happen " open themselves up to a lot more shit .
An other simple approach is to block parts of the world that you do n't expect legit connections to come from .
If you are never in China and neither are your customers , why would you allow China to connect to port 22 ?
Just remember that you got such a block in place before you book your holiday in Hong Kong .
An even simpler approach is to block root from using SSH , and then use only somewhat unique account names .
You need two parts to login to SSH .
Brute forcing passwords is only half the job unless I have been missing something all these years .
And on the whole , 1 million failed login 's is a good thing .
It is the successful login that you should worry about .</tokentext>
<sentencetext>You get a lot of recommendations here, but people tend to just blurt out the flavor of the hour they are using without considering the essential motto of any proffesional, "the right tool for the job".
Simplest, do you need SSH access?
I once maintained servers with absolutely no remote access capability of any kind.
Didn't need to, lived within 5 minutes of the hosting location and simply worked from there.
Saves a LOT of security hassle when only physical access can be used on a server.
Most likely not possible, but I hope it does show that you must THINK about what is needed/possible in your situation.
For instance, moving the SSH port.
It is possible, security through obscurity at its finest, but how will it affect your customers?
If you then got to deal with endless service calls to explain the non-standard port, or worse, client software can't handle alternate ports, then it is not the right tool.
An alternative to this is switching the IP.
Nothings says that the IP used to access the webserver must be the same as the one used to access SSH.
Again security through obscurity, but it might help.
Also, there is no law that says every machine should be remotely accesible.
If you got a lot of servers, why not create an Admin box?
It can connect through all the servers over the internal network, but the world facing servers got no outside admin connections.
Yes, if the Admin server is borked, you are in trouble, but I found that people in the name of "Shit might happen" open themselves up to a lot more shit.
An other simple approach is to block parts of the world that you don't expect legit connections to come from.
If you are never in China and neither are your customers, why would you allow China to connect to port 22?
Just remember that you got such a block in place before you book your holiday in Hong Kong.
An even simpler approach is to block root from using SSH, and then use only somewhat unique account names.
You need two parts to login to SSH.
Brute forcing passwords is only half the job unless I have been missing something all these years.
And on the whole, 1 million failed login's is a good thing.
It is the successful login that you should worry about.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31434238</id>
	<title>Welcome to the Internets!</title>
	<author>Spit</author>
	<datestamp>1268239140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you're going to have services open to the Internet without IP restricions, expect millions of random connections. Just use ssh-key authentication, disable password over ssh and forget about it.</p></htmltext>
<tokenext>If you 're going to have services open to the Internet without IP restricions , expect millions of random connections .
Just use ssh-key authentication , disable password over ssh and forget about it .</tokentext>
<sentencetext>If you're going to have services open to the Internet without IP restricions, expect millions of random connections.
Just use ssh-key authentication, disable password over ssh and forget about it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386832</id>
	<title>port knocking</title>
	<author>Anonymous</author>
	<datestamp>1267900980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>what ever happened to port knocking?</p></htmltext>
<tokenext>what ever happened to port knocking ?</tokentext>
<sentencetext>what ever happened to port knocking?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387496</id>
	<title>best combo</title>
	<author>Anonymous</author>
	<datestamp>1267995540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>htaccess, fail2ban, denyhost, and iptables + snort</p></htmltext>
<tokenext>htaccess , fail2ban , denyhost , and iptables + snort</tokentext>
<sentencetext>htaccess, fail2ban, denyhost, and iptables + snort</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385694</id>
	<title>Wrong security concern.</title>
	<author>Vellmont</author>
	<datestamp>1267888380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i><br>I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla<br></i></p><p>Right off the bat, you're far too focused on the security of least concern, ssh.  Unless you set an idiotic password, it's not going to be guessed.  It sounds like you have that covered.</p><p>But..  the part you've missed is your FAR more vulnerable applications.  You say your ISP is "actively managing" your security, but how certain are you they're doing a decent job of it?  Do they have experts in each of these different CMS systems?</p><p>If you're serious about security, find experts to manage the security settings and versions of each of your chosen applications.  I know for a fact that Joomla has historically had some issues with it.  The others you mentioned wouldn't be terribly surprising to find problems as well.  We're not talking a lot of money here.  A good price would be in the neighborhood of $200 per application/site for an assessment of your configuration.  Look for people that are reputable, not some fly-by-night "I know all applications" joker who just runs a security scanner and charges you $200.</p><p>And no, scanners aren't going to replace expert human beings that know what to look for.</p></htmltext>
<tokenext>I own a small Web development studio that specializes in open source software , primarily Drupal , WordPress , and JoomlaRight off the bat , you 're far too focused on the security of least concern , ssh .
Unless you set an idiotic password , it 's not going to be guessed .
It sounds like you have that covered.But.. the part you 've missed is your FAR more vulnerable applications .
You say your ISP is " actively managing " your security , but how certain are you they 're doing a decent job of it ?
Do they have experts in each of these different CMS systems ? If you 're serious about security , find experts to manage the security settings and versions of each of your chosen applications .
I know for a fact that Joomla has historically had some issues with it .
The others you mentioned would n't be terribly surprising to find problems as well .
We 're not talking a lot of money here .
A good price would be in the neighborhood of $ 200 per application/site for an assessment of your configuration .
Look for people that are reputable , not some fly-by-night " I know all applications " joker who just runs a security scanner and charges you $ 200.And no , scanners are n't going to replace expert human beings that know what to look for .</tokentext>
<sentencetext>I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and JoomlaRight off the bat, you're far too focused on the security of least concern, ssh.
Unless you set an idiotic password, it's not going to be guessed.
It sounds like you have that covered.But..  the part you've missed is your FAR more vulnerable applications.
You say your ISP is "actively managing" your security, but how certain are you they're doing a decent job of it?
Do they have experts in each of these different CMS systems?If you're serious about security, find experts to manage the security settings and versions of each of your chosen applications.
I know for a fact that Joomla has historically had some issues with it.
The others you mentioned wouldn't be terribly surprising to find problems as well.
We're not talking a lot of money here.
A good price would be in the neighborhood of $200 per application/site for an assessment of your configuration.
Look for people that are reputable, not some fly-by-night "I know all applications" joker who just runs a security scanner and charges you $200.And no, scanners aren't going to replace expert human beings that know what to look for.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385464</id>
	<title>Okay</title>
	<author>mindstrm</author>
	<datestamp>1267885980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>First..... 1 million password *failures* is not a security problem by itself.  They're supposed to fail if they don't have the right password.</p><p>So - moving this to a more obscure port will definitely cut down on the automated scanning.. but it's not really the heart of the issue.</p><p>The heart of the issue is that it took you so long to realize someone was even doing this.  That probably boils down to your running a business requiring sysadmin work without a sysadmin.</p><p>There are lots and lots of ways to approach this, some of which people have touched on already.</p><p>1) You need awareness of what's going on - daily log analysis.  OSSEC is neat, give it a shot.<br>2) Moving SSH to a weird port is something some people do - I don't prefer that  - it buys some obscurity and cuts down on some scanning, but doesn't address any real security issues.<br>3) OSSEC in active mode with a whitelist so you don't block out legitimate users - works pretty well.<br>4) Hire someone to deal with security/deployment/backups/recovery/service providers (sysadmin?)</p></htmltext>
<tokenext>First..... 1 million password * failures * is not a security problem by itself .
They 're supposed to fail if they do n't have the right password.So - moving this to a more obscure port will definitely cut down on the automated scanning.. but it 's not really the heart of the issue.The heart of the issue is that it took you so long to realize someone was even doing this .
That probably boils down to your running a business requiring sysadmin work without a sysadmin.There are lots and lots of ways to approach this , some of which people have touched on already.1 ) You need awareness of what 's going on - daily log analysis .
OSSEC is neat , give it a shot.2 ) Moving SSH to a weird port is something some people do - I do n't prefer that - it buys some obscurity and cuts down on some scanning , but does n't address any real security issues.3 ) OSSEC in active mode with a whitelist so you do n't block out legitimate users - works pretty well.4 ) Hire someone to deal with security/deployment/backups/recovery/service providers ( sysadmin ?
)</tokentext>
<sentencetext>First..... 1 million password *failures* is not a security problem by itself.
They're supposed to fail if they don't have the right password.So - moving this to a more obscure port will definitely cut down on the automated scanning.. but it's not really the heart of the issue.The heart of the issue is that it took you so long to realize someone was even doing this.
That probably boils down to your running a business requiring sysadmin work without a sysadmin.There are lots and lots of ways to approach this, some of which people have touched on already.1) You need awareness of what's going on - daily log analysis.
OSSEC is neat, give it a shot.2) Moving SSH to a weird port is something some people do - I don't prefer that  - it buys some obscurity and cuts down on some scanning, but doesn't address any real security issues.3) OSSEC in active mode with a whitelist so you don't block out legitimate users - works pretty well.4) Hire someone to deal with security/deployment/backups/recovery/service providers (sysadmin?
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386242</id>
	<title>Many ways</title>
	<author>X.25</author>
	<datestamp>1267893780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Change port. Believe it or not, it does help enourmously - I didn't beleive it, but then I've done it for shits and giggles, I haven't had a single brute force attempt on my server.</p><p>Also, use sshdfilter (or fail2ban, etc).</p><p>Those 2 will take care of most SSH brute force attacks.</p><p>And if you don't want any SSH brute force attacks on your server, use public key authentication.</p></htmltext>
<tokenext>Change port .
Believe it or not , it does help enourmously - I did n't beleive it , but then I 've done it for shits and giggles , I have n't had a single brute force attempt on my server.Also , use sshdfilter ( or fail2ban , etc ) .Those 2 will take care of most SSH brute force attacks.And if you do n't want any SSH brute force attacks on your server , use public key authentication .</tokentext>
<sentencetext>Change port.
Believe it or not, it does help enourmously - I didn't beleive it, but then I've done it for shits and giggles, I haven't had a single brute force attempt on my server.Also, use sshdfilter (or fail2ban, etc).Those 2 will take care of most SSH brute force attacks.And if you don't want any SSH brute force attacks on your server, use public key authentication.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392042</id>
	<title>ban china</title>
	<author>bkissi01</author>
	<datestamp>1267989660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think everyone that has a SSH server must have the exact same issues. I have a CentOS server behind my firewall that I use for a little web development (personal projects, nothing major or really interesting) and just testing out different things but for some reason the chinese army seems hell bent on breaking in. I just set iptables to block every<nobr> <wbr></nobr>/8 IP range that I could find that was even loosely related to china. Personally, I don't understand why anyone would allow their network/machine to communicate with chinese IP ranges, there just seems to be no real need. Honestly, this cut invalid login attempts from thousands to a handful. As said before make use of your authorized\_keys file and I'd also recomend that you double check that login by root is disabled.</htmltext>
<tokenext>I think everyone that has a SSH server must have the exact same issues .
I have a CentOS server behind my firewall that I use for a little web development ( personal projects , nothing major or really interesting ) and just testing out different things but for some reason the chinese army seems hell bent on breaking in .
I just set iptables to block every /8 IP range that I could find that was even loosely related to china .
Personally , I do n't understand why anyone would allow their network/machine to communicate with chinese IP ranges , there just seems to be no real need .
Honestly , this cut invalid login attempts from thousands to a handful .
As said before make use of your authorized \ _keys file and I 'd also recomend that you double check that login by root is disabled .</tokentext>
<sentencetext>I think everyone that has a SSH server must have the exact same issues.
I have a CentOS server behind my firewall that I use for a little web development (personal projects, nothing major or really interesting) and just testing out different things but for some reason the chinese army seems hell bent on breaking in.
I just set iptables to block every /8 IP range that I could find that was even loosely related to china.
Personally, I don't understand why anyone would allow their network/machine to communicate with chinese IP ranges, there just seems to be no real need.
Honestly, this cut invalid login attempts from thousands to a handful.
As said before make use of your authorized\_keys file and I'd also recomend that you double check that login by root is disabled.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387812</id>
	<title>Easy: Server management service</title>
	<author>Skal Tura</author>
	<datestamp>1267957680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's cheap, it's professional, it's fast and it's done correctly with lots of experience. What's not to like there?<br>Of course, it's not a answer to everyone, but in your case seems to be good match.</p><p><a href="http://www.platinumservermanagement.com/" title="platinumse...gement.com">http://www.platinumservermanagement.com/</a> [platinumse...gement.com]<br>I've considered using them in the past to save my time and they seem to be good, and is recommended by many.</p></htmltext>
<tokenext>It 's cheap , it 's professional , it 's fast and it 's done correctly with lots of experience .
What 's not to like there ? Of course , it 's not a answer to everyone , but in your case seems to be good match.http : //www.platinumservermanagement.com/ [ platinumse...gement.com ] I 've considered using them in the past to save my time and they seem to be good , and is recommended by many .</tokentext>
<sentencetext>It's cheap, it's professional, it's fast and it's done correctly with lots of experience.
What's not to like there?Of course, it's not a answer to everyone, but in your case seems to be good match.http://www.platinumservermanagement.com/ [platinumse...gement.com]I've considered using them in the past to save my time and they seem to be good, and is recommended by many.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387936</id>
	<title>Re:Throttle Inbound Connections</title>
	<author>Anonymous</author>
	<datestamp>1267959720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is a recipe for DoS.</p></htmltext>
<tokenext>This is a recipe for DoS .</tokentext>
<sentencetext>This is a recipe for DoS.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385372</id>
	<title>Re:fail2ban</title>
	<author>sstern</author>
	<datestamp>1267885440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Install OSSEC, too.  There may be other stuff going on.</p></htmltext>
<tokenext>Install OSSEC , too .
There may be other stuff going on .</tokentext>
<sentencetext>Install OSSEC, too.
There may be other stuff going on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389188</id>
	<title>Re:fail2ban</title>
	<author>cynyr</author>
	<datestamp>1267973640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>fail2ban, key-auth</p></div><p>+1</p></div>
	</htmltext>
<tokenext>fail2ban , key-auth + 1</tokentext>
<sentencetext>fail2ban, key-auth+1
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386614</id>
	<title>fail2ban</title>
	<author>cigawoot</author>
	<datestamp>1267898040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><br>I know a lot of people have suggested fail2ban, and its a great solution that's easy to implement.  The best part is it uses sendmail to mail logs to the root user about brute-force attempts.  This is mainly for my curiosity.
<br>
<br>The big thing is the ban timer on fail2ban doesn't need to be very long.  The ban can be as short as 2-3 minutes and still get the message across.  Once they realize they're disconnected, they'll go elsewhere.  It'll slow them down enough that brute forcing ssh isn't practical anymore, usually at that point they'll move on to another host.
<br>An easier solution is to just use public-key authentication though, there are plenty of articles out there that deal with this.
<br>
<br>Really, just all the spam in my logs to be amusing.  I had someone use a web scanner on my box, and after it was done and found nothing of interest, it made a request for<nobr> <wbr></nobr>/fuckingshitnonexistant.php, which of course 404'd.</htmltext>
<tokenext>I know a lot of people have suggested fail2ban , and its a great solution that 's easy to implement .
The best part is it uses sendmail to mail logs to the root user about brute-force attempts .
This is mainly for my curiosity .
The big thing is the ban timer on fail2ban does n't need to be very long .
The ban can be as short as 2-3 minutes and still get the message across .
Once they realize they 're disconnected , they 'll go elsewhere .
It 'll slow them down enough that brute forcing ssh is n't practical anymore , usually at that point they 'll move on to another host .
An easier solution is to just use public-key authentication though , there are plenty of articles out there that deal with this .
Really , just all the spam in my logs to be amusing .
I had someone use a web scanner on my box , and after it was done and found nothing of interest , it made a request for /fuckingshitnonexistant.php , which of course 404 'd .</tokentext>
<sentencetext>I know a lot of people have suggested fail2ban, and its a great solution that's easy to implement.
The best part is it uses sendmail to mail logs to the root user about brute-force attempts.
This is mainly for my curiosity.
The big thing is the ban timer on fail2ban doesn't need to be very long.
The ban can be as short as 2-3 minutes and still get the message across.
Once they realize they're disconnected, they'll go elsewhere.
It'll slow them down enough that brute forcing ssh isn't practical anymore, usually at that point they'll move on to another host.
An easier solution is to just use public-key authentication though, there are plenty of articles out there that deal with this.
Really, just all the spam in my logs to be amusing.
I had someone use a web scanner on my box, and after it was done and found nothing of interest, it made a request for /fuckingshitnonexistant.php, which of course 404'd.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387742</id>
	<title>Re:So?</title>
	<author>toadlife</author>
	<datestamp>1267956300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>+1</p><p>Besides, reading the logs can be <a href="http://www.dslreports.com/forum/remark,17315327" title="dslreports.com" rel="nofollow">good for a laugh</a> [dslreports.com].</p></htmltext>
<tokenext>+ 1Besides , reading the logs can be good for a laugh [ dslreports.com ] .</tokentext>
<sentencetext>+1Besides, reading the logs can be good for a laugh [dslreports.com].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391886</id>
	<title>Re:Move to a higher order port and use denyhosts</title>
	<author>jon3k</author>
	<datestamp>1267988880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This has nothing to do with determined hackers.  This is to filter out the 99.99999\% of failed authentication attempts we're all seeing because of botnets.</htmltext>
<tokenext>This has nothing to do with determined hackers .
This is to filter out the 99.99999 \ % of failed authentication attempts we 're all seeing because of botnets .</tokentext>
<sentencetext>This has nothing to do with determined hackers.
This is to filter out the 99.99999\% of failed authentication attempts we're all seeing because of botnets.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386078</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385700</id>
	<title>Ignore it</title>
	<author>lisany</author>
	<datestamp>1267888380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Just ignore it.</htmltext>
<tokenext>Just ignore it .</tokentext>
<sentencetext>Just ignore it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385396</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267885560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I had the same problem the OP describes and implemented fail2ban.  Solved it quick.  After a while, they gave up and now it's clean.  They must watch for failures, too.</p></htmltext>
<tokenext>I had the same problem the OP describes and implemented fail2ban .
Solved it quick .
After a while , they gave up and now it 's clean .
They must watch for failures , too .</tokentext>
<sentencetext>I had the same problem the OP describes and implemented fail2ban.
Solved it quick.
After a while, they gave up and now it's clean.
They must watch for failures, too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390618</id>
	<title>VPN + allow access with iptables for the vpn IP's</title>
	<author>Anonymous</author>
	<datestamp>1267982040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just setup a VPN and make your iptables allow access to the IP block that the VPN will use. Also, allow access to the subnet of your office only(if you have one).<br>Instead of installing tools use the iptables rate-limit and automatically ban them.</p></htmltext>
<tokenext>Just setup a VPN and make your iptables allow access to the IP block that the VPN will use .
Also , allow access to the subnet of your office only ( if you have one ) .Instead of installing tools use the iptables rate-limit and automatically ban them .</tokentext>
<sentencetext>Just setup a VPN and make your iptables allow access to the IP block that the VPN will use.
Also, allow access to the subnet of your office only(if you have one).Instead of installing tools use the iptables rate-limit and automatically ban them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387674</id>
	<title>Re:fail2ban</title>
	<author>thsths</author>
	<datestamp>1267955220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>key-auth should be sufficient. The probability of guessing user name and the key is so absolutely remotely that 1 million login attempts do not get you any closer to it.</p><p>If the attempts are a performance problem (log - sync), the easiest option is to change the port, and the next is to restrict access with fail2ban or whatever flavor you fancy. Any obscure scheme will do, including "ping first with a payload of YEAH before ssh", just do not mistake obscurity for security.</p></htmltext>
<tokenext>key-auth should be sufficient .
The probability of guessing user name and the key is so absolutely remotely that 1 million login attempts do not get you any closer to it.If the attempts are a performance problem ( log - sync ) , the easiest option is to change the port , and the next is to restrict access with fail2ban or whatever flavor you fancy .
Any obscure scheme will do , including " ping first with a payload of YEAH before ssh " , just do not mistake obscurity for security .</tokentext>
<sentencetext>key-auth should be sufficient.
The probability of guessing user name and the key is so absolutely remotely that 1 million login attempts do not get you any closer to it.If the attempts are a performance problem (log - sync), the easiest option is to change the port, and the next is to restrict access with fail2ban or whatever flavor you fancy.
Any obscure scheme will do, including "ping first with a payload of YEAH before ssh", just do not mistake obscurity for security.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391568</id>
	<title>Re:Hardware firewall or use bfd</title>
	<author>jon3k</author>
	<datestamp>1267987140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The reason we use VPNs is to tunnel services securely over another network (in this case, the Internet).  If the only thing I need is a console session (obviously the case here) what do I gain by using VPN?</htmltext>
<tokenext>The reason we use VPNs is to tunnel services securely over another network ( in this case , the Internet ) .
If the only thing I need is a console session ( obviously the case here ) what do I gain by using VPN ?</tokentext>
<sentencetext>The reason we use VPNs is to tunnel services securely over another network (in this case, the Internet).
If the only thing I need is a console session (obviously the case here) what do I gain by using VPN?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385724</id>
	<title>Re:fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1267888680000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Someone fucked up big time when they taught you html:<br>[url]http://www.fail2ban.org/[/url]</p></htmltext>
<tokenext>Someone fucked up big time when they taught you html : [ url ] http : //www.fail2ban.org/ [ /url ]</tokentext>
<sentencetext>Someone fucked up big time when they taught you html:[url]http://www.fail2ban.org/[/url]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387054</id>
	<title>Nothing to worry about</title>
	<author>flyingfsck</author>
	<datestamp>1267903740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One million login hack attempts over a year is pretty normal on the standard port 22.</htmltext>
<tokenext>One million login hack attempts over a year is pretty normal on the standard port 22 .</tokentext>
<sentencetext>One million login hack attempts over a year is pretty normal on the standard port 22.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388916</id>
	<title>Do *NOT* use a password with ssh!</title>
	<author>Colin Smith</author>
	<datestamp>1267972320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>That way an attacker has to guess the one user+password, and have a legitimate userid+password to gain access.</p></div><p>Use public key authentication.</p><p>Also. The root account should not have a password at all. Passwords are a weakness which should be phased out entirely. It's (long past) time brute forcing passwords was made futile.</p><p>
&nbsp;</p></div>
	</htmltext>
<tokenext>That way an attacker has to guess the one user + password , and have a legitimate userid + password to gain access.Use public key authentication.Also .
The root account should not have a password at all .
Passwords are a weakness which should be phased out entirely .
It 's ( long past ) time brute forcing passwords was made futile .
 </tokentext>
<sentencetext>That way an attacker has to guess the one user+password, and have a legitimate userid+password to gain access.Use public key authentication.Also.
The root account should not have a password at all.
Passwords are a weakness which should be phased out entirely.
It's (long past) time brute forcing passwords was made futile.
 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385496</id>
	<title>VPN for SSH</title>
	<author>Anonymous</author>
	<datestamp>1267886220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I've used ISPs that provided separate VPN access for protected ports such as SSH, so you only had to open HTTP to the public.

But seriously, there options such as port knockers and the like.

Of course, if they are actively managing, they could try to have a firewall that automatically filtered obvious break in attempts.</htmltext>
<tokenext>I 've used ISPs that provided separate VPN access for protected ports such as SSH , so you only had to open HTTP to the public .
But seriously , there options such as port knockers and the like .
Of course , if they are actively managing , they could try to have a firewall that automatically filtered obvious break in attempts .</tokentext>
<sentencetext>I've used ISPs that provided separate VPN access for protected ports such as SSH, so you only had to open HTTP to the public.
But seriously, there options such as port knockers and the like.
Of course, if they are actively managing, they could try to have a firewall that automatically filtered obvious break in attempts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386456</id>
	<title>Re:You are being brute-forced</title>
	<author>NotQuiteReal</author>
	<datestamp>1267896480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah, seems to me a million failures is what you want to see... it is the one success that is a bitch.</htmltext>
<tokenext>Yeah , seems to me a million failures is what you want to see... it is the one success that is a bitch .</tokentext>
<sentencetext>Yeah, seems to me a million failures is what you want to see... it is the one success that is a bitch.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388586</id>
	<title>Use good passwords.</title>
	<author>jonadab</author>
	<datestamp>1267968960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Okay, so they're making a million attempts a year.<br><br>Let's say you plan to keep this server for, what, twenty years?  After that you will replace it with an entirely new system and new passwords.<br><br>Assuming that the number of attempts they make increases geometrically, starting from one million this year, in twenty years they could generate how many attempts?  A billion or so?  Maybe ten billion?  Let's say a hundred billion, because you don't want to take chances with your server security.<br><br>So just make sure all your passwords are sufficiently long and complex that the search space magnitude well and truly exceeds a hundred billion.  Ideally you want to make the hundred-billion number look absolutely ridiculous.  This is not particularly hard.  Even if you don't look beyond lowercase letters (because you want to type the password quickly with no shifting keys), 26^N goes past a trillion after just nine characters.<br><br>Personally, I'd set the minimum length to at least twenty, and make the root password more like twice that long (if you allow remote root login).  It's overkill, but when it comes to security a little bit of overkill is good.  It just may save you if you've underestimated some important element of risk (like, say, how many attempts they can make in a given time period).</htmltext>
<tokenext>Okay , so they 're making a million attempts a year.Let 's say you plan to keep this server for , what , twenty years ?
After that you will replace it with an entirely new system and new passwords.Assuming that the number of attempts they make increases geometrically , starting from one million this year , in twenty years they could generate how many attempts ?
A billion or so ?
Maybe ten billion ?
Let 's say a hundred billion , because you do n't want to take chances with your server security.So just make sure all your passwords are sufficiently long and complex that the search space magnitude well and truly exceeds a hundred billion .
Ideally you want to make the hundred-billion number look absolutely ridiculous .
This is not particularly hard .
Even if you do n't look beyond lowercase letters ( because you want to type the password quickly with no shifting keys ) , 26 ^ N goes past a trillion after just nine characters.Personally , I 'd set the minimum length to at least twenty , and make the root password more like twice that long ( if you allow remote root login ) .
It 's overkill , but when it comes to security a little bit of overkill is good .
It just may save you if you 've underestimated some important element of risk ( like , say , how many attempts they can make in a given time period ) .</tokentext>
<sentencetext>Okay, so they're making a million attempts a year.Let's say you plan to keep this server for, what, twenty years?
After that you will replace it with an entirely new system and new passwords.Assuming that the number of attempts they make increases geometrically, starting from one million this year, in twenty years they could generate how many attempts?
A billion or so?
Maybe ten billion?
Let's say a hundred billion, because you don't want to take chances with your server security.So just make sure all your passwords are sufficiently long and complex that the search space magnitude well and truly exceeds a hundred billion.
Ideally you want to make the hundred-billion number look absolutely ridiculous.
This is not particularly hard.
Even if you don't look beyond lowercase letters (because you want to type the password quickly with no shifting keys), 26^N goes past a trillion after just nine characters.Personally, I'd set the minimum length to at least twenty, and make the root password more like twice that long (if you allow remote root login).
It's overkill, but when it comes to security a little bit of overkill is good.
It just may save you if you've underestimated some important element of risk (like, say, how many attempts they can make in a given time period).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142</id>
	<title>Passwords?</title>
	<author>fm6</author>
	<datestamp>1267883880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Here's my excuse to ride my usual hobbyhorse about passwords being obsolete. SSH supports certificate-based authentication, which is not only more secure, it's less of a hassle for the user. Don't know if it would be practical for your application (you might tell us more about that) but it's worth a look.</p></htmltext>
<tokenext>Here 's my excuse to ride my usual hobbyhorse about passwords being obsolete .
SSH supports certificate-based authentication , which is not only more secure , it 's less of a hassle for the user .
Do n't know if it would be practical for your application ( you might tell us more about that ) but it 's worth a look .</tokentext>
<sentencetext>Here's my excuse to ride my usual hobbyhorse about passwords being obsolete.
SSH supports certificate-based authentication, which is not only more secure, it's less of a hassle for the user.
Don't know if it would be practical for your application (you might tell us more about that) but it's worth a look.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385482</id>
	<title>Re:whatcouldposiblygowrong</title>
	<author>Anonymous</author>
	<datestamp>1267886100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's a hell of a lot better than some "l33t h$ck3r" who does not know his ass from a whole in the ground.  I will take the "noob" any day.  They at least show an open mind and admit their weaknesses.</p></htmltext>
<tokenext>That 's a hell of a lot better than some " l33t h $ ck3r " who does not know his ass from a whole in the ground .
I will take the " noob " any day .
They at least show an open mind and admit their weaknesses .</tokentext>
<sentencetext>That's a hell of a lot better than some "l33t h$ck3r" who does not know his ass from a whole in the ground.
I will take the "noob" any day.
They at least show an open mind and admit their weaknesses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387100</id>
	<title>Re:whatcouldposiblygowrong</title>
	<author>Dan541</author>
	<datestamp>1267904100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>and advertising that fact on<nobr> <wbr></nobr>/.</p></htmltext>
<tokenext>and advertising that fact on / .</tokentext>
<sentencetext>and advertising that fact on /.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31402206</id>
	<title>re: Use VPN first</title>
	<author>hittjw</author>
	<datestamp>1268072220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Invest in a hardened VPN box, block all ports on your webserver from outside world except 80 and 443.  Only allow SSH access from the VPN.  Log into your environment only after you first have a VPN connection.  Outside world would only see the ports they are allowed access -- you would have more control over who has secure access.</p><p>Best,</p><p>Justin</p></htmltext>
<tokenext>Invest in a hardened VPN box , block all ports on your webserver from outside world except 80 and 443 .
Only allow SSH access from the VPN .
Log into your environment only after you first have a VPN connection .
Outside world would only see the ports they are allowed access -- you would have more control over who has secure access.Best,Justin</tokentext>
<sentencetext>Invest in a hardened VPN box, block all ports on your webserver from outside world except 80 and 443.
Only allow SSH access from the VPN.
Log into your environment only after you first have a VPN connection.
Outside world would only see the ports they are allowed access -- you would have more control over who has secure access.Best,Justin</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386054</id>
	<title>Re:fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1267891920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Word.   I don't ever allow password-based logins on my servers.   Users on my server don't even *have* passwords.   Random passwords are probably pretty safe, but why take the chance?   Nobody's going to guess a 2048-bit RSA key.   This means I can't use sudo, but I'm okay with that - if you need root, you need the root password, and you need to be in the group that's allowed to su.   But you almost certainly don't need root.</p></htmltext>
<tokenext>Word .
I do n't ever allow password-based logins on my servers .
Users on my server do n't even * have * passwords .
Random passwords are probably pretty safe , but why take the chance ?
Nobody 's going to guess a 2048-bit RSA key .
This means I ca n't use sudo , but I 'm okay with that - if you need root , you need the root password , and you need to be in the group that 's allowed to su .
But you almost certainly do n't need root .</tokentext>
<sentencetext>Word.
I don't ever allow password-based logins on my servers.
Users on my server don't even *have* passwords.
Random passwords are probably pretty safe, but why take the chance?
Nobody's going to guess a 2048-bit RSA key.
This means I can't use sudo, but I'm okay with that - if you need root, you need the root password, and you need to be in the group that's allowed to su.
But you almost certainly don't need root.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386078</id>
	<title>Re:Move to a higher order port and use denyhosts</title>
	<author>MrCrassic</author>
	<datestamp>1267892040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Changing the port might be troublesome if you're trying to SSH from public locations like airports and such. They usually leave port 22, 443 and 8080 open for their own services and block all others, so you will have to either set up VPN to get into your servers or wait until you're elsewhere. Additionally, an evenly-slightly determined hacker can still find where your sshd process is listening on by running a basic nmap scan.</p><p>Key exchange and disabling root login is probably the best way to go. Fail2ban worked really well when my server had a Linux distro on it.</p></htmltext>
<tokenext>Changing the port might be troublesome if you 're trying to SSH from public locations like airports and such .
They usually leave port 22 , 443 and 8080 open for their own services and block all others , so you will have to either set up VPN to get into your servers or wait until you 're elsewhere .
Additionally , an evenly-slightly determined hacker can still find where your sshd process is listening on by running a basic nmap scan.Key exchange and disabling root login is probably the best way to go .
Fail2ban worked really well when my server had a Linux distro on it .</tokentext>
<sentencetext>Changing the port might be troublesome if you're trying to SSH from public locations like airports and such.
They usually leave port 22, 443 and 8080 open for their own services and block all others, so you will have to either set up VPN to get into your servers or wait until you're elsewhere.
Additionally, an evenly-slightly determined hacker can still find where your sshd process is listening on by running a basic nmap scan.Key exchange and disabling root login is probably the best way to go.
Fail2ban worked really well when my server had a Linux distro on it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385438</id>
	<title>Re:Tar Pitting</title>
	<author>luizd</author>
	<datestamp>1267885800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Yes, I think that this is your best solution. Instead of using iptables directly, you should check your distribution software relative option.Generally is is easier (but anyway, it will ultimately result in the same iptables command)</htmltext>
<tokenext>Yes , I think that this is your best solution .
Instead of using iptables directly , you should check your distribution software relative option.Generally is is easier ( but anyway , it will ultimately result in the same iptables command )</tokentext>
<sentencetext>Yes, I think that this is your best solution.
Instead of using iptables directly, you should check your distribution software relative option.Generally is is easier (but anyway, it will ultimately result in the same iptables command)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391744</id>
	<title>Re:fwknop</title>
	<author>jon3k</author>
	<datestamp>1267988040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>"That is an exceptionally bad idea. You're simply increasing the complexity of the entire authentication system, without doing much more than requiring another password."</i>
<br> <br>
It's a very small increase in complexity to \_dramatically\_ decrease the likelihood of a successful attack.  It's just "moving ssh to another port" taken a step further.</htmltext>
<tokenext>" That is an exceptionally bad idea .
You 're simply increasing the complexity of the entire authentication system , without doing much more than requiring another password .
" It 's a very small increase in complexity to \ _dramatically \ _ decrease the likelihood of a successful attack .
It 's just " moving ssh to another port " taken a step further .</tokentext>
<sentencetext>"That is an exceptionally bad idea.
You're simply increasing the complexity of the entire authentication system, without doing much more than requiring another password.
"
 
It's a very small increase in complexity to \_dramatically\_ decrease the likelihood of a successful attack.
It's just "moving ssh to another port" taken a step further.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386388</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31394960</id>
	<title>Re:So?</title>
	<author>kriston</author>
	<datestamp>1267964940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm sorry, but using passwords is completely wrong.<br>The only real answer is to disable password authentication and only allow certificates.  It's completely easy for anyone with access to a text editor.<br>Ask your sysadmin to do this:<br>PubkeyAuthentication yes<br>PasswordAuthentication no<br>PermitEmptyPasswords no<br>ChallengeResponseAuthentication no</p><p>Your problem goes away completely.</p><p>If you think ssh certificates are hard to use then maybe web hosting is not the right business for you to be in.</p></htmltext>
<tokenext>I 'm sorry , but using passwords is completely wrong.The only real answer is to disable password authentication and only allow certificates .
It 's completely easy for anyone with access to a text editor.Ask your sysadmin to do this : PubkeyAuthentication yesPasswordAuthentication noPermitEmptyPasswords noChallengeResponseAuthentication noYour problem goes away completely.If you think ssh certificates are hard to use then maybe web hosting is not the right business for you to be in .</tokentext>
<sentencetext>I'm sorry, but using passwords is completely wrong.The only real answer is to disable password authentication and only allow certificates.
It's completely easy for anyone with access to a text editor.Ask your sysadmin to do this:PubkeyAuthentication yesPasswordAuthentication noPermitEmptyPasswords noChallengeResponseAuthentication noYour problem goes away completely.If you think ssh certificates are hard to use then maybe web hosting is not the right business for you to be in.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385344</id>
	<title>That grumpy BSD guy</title>
	<author>the\_brobdingnagian</author>
	<datestamp>1267885260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Peter N. M. Hansteen has written a nice article about a similar atack.
<a href="http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html" title="blogspot.com">http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html</a> [blogspot.com]

The first thing I would do (at install time) is to disable root login over ssh.</htmltext>
<tokenext>Peter N. M. Hansteen has written a nice article about a similar atack .
http : //bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html [ blogspot.com ] The first thing I would do ( at install time ) is to disable root login over ssh .</tokentext>
<sentencetext>Peter N. M. Hansteen has written a nice article about a similar atack.
http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html [blogspot.com]

The first thing I would do (at install time) is to disable root login over ssh.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106</id>
	<title>Hardware firewall or use bfd</title>
	<author>Golbez81</author>
	<datestamp>1267883700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>bfd (and apf if you like it) are probably the best software solutions your gonna find, but if you're facing 1 million+ auth failures, I would seriously consider a hardware firewall and VPN of some sort.</htmltext>
<tokenext>bfd ( and apf if you like it ) are probably the best software solutions your gon na find , but if you 're facing 1 million + auth failures , I would seriously consider a hardware firewall and VPN of some sort .</tokentext>
<sentencetext>bfd (and apf if you like it) are probably the best software solutions your gonna find, but if you're facing 1 million+ auth failures, I would seriously consider a hardware firewall and VPN of some sort.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386900</id>
	<title>Multiple Layers</title>
	<author>Alan Evans</author>
	<datestamp>1267901880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>1. Worry about securing Drupal, Joomla and Wordpress first...<br>
- or -<br>
2. Use a VPN and hardware firewall<br>
- or -<br>
3. Use iptables 'recent' or 'limit' modules<br>
- or -<br>
4. SSH keys<br>
- or -<br>
5. Find a managed service provider to do 1-4 so you can worry about managing the sites (check out Secure-24.com maybe)</htmltext>
<tokenext>1 .
Worry about securing Drupal , Joomla and Wordpress first.. . - or - 2 .
Use a VPN and hardware firewall - or - 3 .
Use iptables 'recent ' or 'limit ' modules - or - 4 .
SSH keys - or - 5 .
Find a managed service provider to do 1-4 so you can worry about managing the sites ( check out Secure-24.com maybe )</tokentext>
<sentencetext>1.
Worry about securing Drupal, Joomla and Wordpress first...
- or -
2.
Use a VPN and hardware firewall
- or -
3.
Use iptables 'recent' or 'limit' modules
- or -
4.
SSH keys
- or -
5.
Find a managed service provider to do 1-4 so you can worry about managing the sites (check out Secure-24.com maybe)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276</id>
	<title>Re:whatcouldposiblygowrong</title>
	<author>jo\_ham</author>
	<datestamp>1267884780000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>He could get trolled on slashdot by the very people he's coming to ask for help to become *less* of a noob.</p><p>I'll bet you teach your kid gun safety by shooting him in the neck.</p></htmltext>
<tokenext>He could get trolled on slashdot by the very people he 's coming to ask for help to become * less * of a noob.I 'll bet you teach your kid gun safety by shooting him in the neck .</tokentext>
<sentencetext>He could get trolled on slashdot by the very people he's coming to ask for help to become *less* of a noob.I'll bet you teach your kid gun safety by shooting him in the neck.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387302</id>
	<title>SSH Key</title>
	<author>rawg</author>
	<datestamp>1267992840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Instead of generating passwords, have your users supply their SSH key and turn off passwords.  Much better solution.</p></htmltext>
<tokenext>Instead of generating passwords , have your users supply their SSH key and turn off passwords .
Much better solution .</tokentext>
<sentencetext>Instead of generating passwords, have your users supply their SSH key and turn off passwords.
Much better solution.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385186</id>
	<title>Spend more than 10 minutes?</title>
	<author>Seakip18</author>
	<datestamp>1267884120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Seriously. I'm in the same shoes and it's easy. I came across it pretty quick and all these SSH log in problems went away.</p><p>Check out...waaaaait...</p><p>What's most troubling is this:</p><p><div class="quote"><p>I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses</p></div><p>You operate a business and you haven't figure out this chief problem yet...but you want us to help you out?</p><p>Well...Here's the solution: <a href="http://denyhosts.sourceforge.net/" title="sourceforge.net"> denyhosts</a> [sourceforge.net]</p><p>Someone else'll chime in with it....Just hope you read up and configure it properly....or you'll find yourself locked out of your own servers.</p></div>
	</htmltext>
<tokenext>Seriously .
I 'm in the same shoes and it 's easy .
I came across it pretty quick and all these SSH log in problems went away.Check out...waaaaait...What 's most troubling is this : I own a small Web development studio that specializes in open source software , primarily Drupal , WordPress , and Joomla for small businessesYou operate a business and you have n't figure out this chief problem yet...but you want us to help you out ? Well...Here 's the solution : denyhosts [ sourceforge.net ] Someone else 'll chime in with it....Just hope you read up and configure it properly....or you 'll find yourself locked out of your own servers .</tokentext>
<sentencetext>Seriously.
I'm in the same shoes and it's easy.
I came across it pretty quick and all these SSH log in problems went away.Check out...waaaaait...What's most troubling is this:I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businessesYou operate a business and you haven't figure out this chief problem yet...but you want us to help you out?Well...Here's the solution:  denyhosts [sourceforge.net]Someone else'll chime in with it....Just hope you read up and configure it properly....or you'll find yourself locked out of your own servers.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386396</id>
	<title>two-factor authentication</title>
	<author>Anonymous</author>
	<datestamp>1267895460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://en.wikipedia.org/wiki/Two-factor\_authentication</p></htmltext>
<tokenext>http : //en.wikipedia.org/wiki/Two-factor \ _authentication</tokentext>
<sentencetext>http://en.wikipedia.org/wiki/Two-factor\_authentication</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386418</id>
	<title>Re:So?</title>
	<author>Korin43</author>
	<datestamp>1267895820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I'm surprised I had to scroll down half the page to find this. Seriously, what is everyone so worried about? Just set a secure password and don't even worry about it. Assuming you have a secure password (8 characters, upper and lower case letters and numbers), even a million attempts per second will take <a href="http://www.google.com/search?q=((62\%5E8+\%2F+1000000)+seconds)\%2F2" title="google.com">over 3 years on average</a> [google.com] (and ssh won't let you try that often anyway). Bump that up to 12 characters and you're looking at <a href="http://www.google.com/search?q=((62\%5E12+\%2F+1000000)+seconds)\%2F2" title="google.com">millions of years</a> [google.com].</htmltext>
<tokenext>I 'm surprised I had to scroll down half the page to find this .
Seriously , what is everyone so worried about ?
Just set a secure password and do n't even worry about it .
Assuming you have a secure password ( 8 characters , upper and lower case letters and numbers ) , even a million attempts per second will take over 3 years on average [ google.com ] ( and ssh wo n't let you try that often anyway ) .
Bump that up to 12 characters and you 're looking at millions of years [ google.com ] .</tokentext>
<sentencetext>I'm surprised I had to scroll down half the page to find this.
Seriously, what is everyone so worried about?
Just set a secure password and don't even worry about it.
Assuming you have a secure password (8 characters, upper and lower case letters and numbers), even a million attempts per second will take over 3 years on average [google.com] (and ssh won't let you try that often anyway).
Bump that up to 12 characters and you're looking at millions of years [google.com].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386382</id>
	<title>Re:Tar Pitting</title>
	<author>rahunzi</author>
	<datestamp>1267895280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>like it</htmltext>
<tokenext>like it</tokentext>
<sentencetext>like it</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387234</id>
	<title>FreeBSD - built in rate limiting / fail banning</title>
	<author>Anonymous</author>
	<datestamp>1267992120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you are using FreeBSD, you can add this (and tune it) to<nobr> <wbr></nobr>/etc/inetd.conf to cope with login bots.</p><p># throttle bot login attempts : limit sshd to 10 child processes,<br># 3 connections per IP per minute, and 5 simultaneous invocations per<br># IP address<br>ssh   stream  tcp  nowait/10/3/5  root<nobr> <wbr></nobr>/usr/sbin/sshd  sshd -i -4</p></htmltext>
<tokenext>If you are using FreeBSD , you can add this ( and tune it ) to /etc/inetd.conf to cope with login bots. # throttle bot login attempts : limit sshd to 10 child processes , # 3 connections per IP per minute , and 5 simultaneous invocations per # IP addressssh stream tcp nowait/10/3/5 root /usr/sbin/sshd sshd -i -4</tokentext>
<sentencetext>If you are using FreeBSD, you can add this (and tune it) to /etc/inetd.conf to cope with login bots.# throttle bot login attempts : limit sshd to 10 child processes,# 3 connections per IP per minute, and 5 simultaneous invocations per# IP addressssh   stream  tcp  nowait/10/3/5  root /usr/sbin/sshd  sshd -i -4</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31396716</id>
	<title>Two things you can use</title>
	<author>C\_Kode</author>
	<datestamp>1267977180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>knockd if only *you* or other technically savvy people connect to them, or option B (DenyHost) if customers actually use it too.</p><p>DenyHost can be set where it will blacklist IPs that fail ssh more than $x times and you can even whitelist IPs.</p></htmltext>
<tokenext>knockd if only * you * or other technically savvy people connect to them , or option B ( DenyHost ) if customers actually use it too.DenyHost can be set where it will blacklist IPs that fail ssh more than $ x times and you can even whitelist IPs .</tokentext>
<sentencetext>knockd if only *you* or other technically savvy people connect to them, or option B (DenyHost) if customers actually use it too.DenyHost can be set where it will blacklist IPs that fail ssh more than $x times and you can even whitelist IPs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385830</id>
	<title>Locked by default and knocking to open.</title>
	<author>Anonymous</author>
	<datestamp>1267889820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>By defaut, I drop connections on port 22.<br>I made a small script which basically waits for a file to be created in<nobr> <wbr></nobr>/tmp, the file contains one IP. When the file is created, my script opens the 22/tcp port for the specific IP.<br>To create the file, I simply load a web page with a browser.<br>This is easy and works really great.<br>If the webpage were indexed, I just have to move it somewhere else. And even if the port gets opened, it is no big deal...</p><p>The script:<br>#!/bin/sh</p><p>FILE\_IP=/tmp/unlock<br>IPTABLES\_RULE=INPUT</p><p>while :<br>do<br>sleep 1<br>[ -f $FILE\_IP ] || continue</p><p>IP=`cat $FILE\_IP`</p><p>if iptables-save | grep -q $IP<br>then<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sleep 1<br>else<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cat<nobr> <wbr></nobr>/dev/null 2&gt;&amp;1<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; then<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; iptables -I $IPTABLES\_RULE -s $IP -p tcp --dport 22 -j ACCEPT<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fi<br>fi</p><p>rm $FILE\_IP 2&gt;/dev/null</p><p>done</p><p>------<br>The web page (this is bash, but easy to write as php too) :</p><p>#!/bin/sh</p><p>echo Content-type: text/plain<br>echo ""<br>cat<nobr> <wbr></nobr>/tmp/unlock<br>$REMOTE\_ADDR<br>END</p></htmltext>
<tokenext>By defaut , I drop connections on port 22.I made a small script which basically waits for a file to be created in /tmp , the file contains one IP .
When the file is created , my script opens the 22/tcp port for the specific IP.To create the file , I simply load a web page with a browser.This is easy and works really great.If the webpage were indexed , I just have to move it somewhere else .
And even if the port gets opened , it is no big deal...The script : # ! /bin/shFILE \ _IP = /tmp/unlockIPTABLES \ _RULE = INPUTwhile : dosleep 1 [ -f $ FILE \ _IP ] | | continueIP = ` cat $ FILE \ _IP ` if iptables-save | grep -q $ IPthen                 sleep 1else                 cat /dev/null 2 &gt; &amp;1                 then                                 iptables -I $ IPTABLES \ _RULE -s $ IP -p tcp --dport 22 -j ACCEPT                 fifirm $ FILE \ _IP 2 &gt; /dev/nulldone------The web page ( this is bash , but easy to write as php too ) : # ! /bin/shecho Content-type : text/plainecho " " cat /tmp/unlock $ REMOTE \ _ADDREND</tokentext>
<sentencetext>By defaut, I drop connections on port 22.I made a small script which basically waits for a file to be created in /tmp, the file contains one IP.
When the file is created, my script opens the 22/tcp port for the specific IP.To create the file, I simply load a web page with a browser.This is easy and works really great.If the webpage were indexed, I just have to move it somewhere else.
And even if the port gets opened, it is no big deal...The script:#!/bin/shFILE\_IP=/tmp/unlockIPTABLES\_RULE=INPUTwhile :dosleep 1[ -f $FILE\_IP ] || continueIP=`cat $FILE\_IP`if iptables-save | grep -q $IPthen
                sleep 1else
                cat /dev/null 2&gt;&amp;1
                then
                                iptables -I $IPTABLES\_RULE -s $IP -p tcp --dport 22 -j ACCEPT
                fifirm $FILE\_IP 2&gt;/dev/nulldone------The web page (this is bash, but easy to write as php too) :#!/bin/shecho Content-type: text/plainecho ""cat /tmp/unlock$REMOTE\_ADDREND</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385468</id>
	<title>Security through Obscurity, sortof</title>
	<author>Seriman</author>
	<datestamp>1267886040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Obviously the port change idea is unpopular because it's just obscurity, which != security.
However, most, of not all, of those attempts are probably from scripts rather than actual human attackers actively attempting to compromise your servers.  The script kiddies rely on automation to rapidly find vulnerable hosts using easily-scripted vulnerabilities or brute force.  The simple act of changing your ssh port will render those kinds of attacks useless against you.
I had a similar scenario where my logs were full of failed ssh attempts and by changing the ssh port, they all stopped.  ALL OF THEM.  I haven't had an unknown IP attempt to log in via SSH in around five years.

fail2ban, strong passwords, or whatever additional security you want to apply is great, and recommended, but a port change will solve more of the problem than you might think.</htmltext>
<tokenext>Obviously the port change idea is unpopular because it 's just obscurity , which ! = security .
However , most , of not all , of those attempts are probably from scripts rather than actual human attackers actively attempting to compromise your servers .
The script kiddies rely on automation to rapidly find vulnerable hosts using easily-scripted vulnerabilities or brute force .
The simple act of changing your ssh port will render those kinds of attacks useless against you .
I had a similar scenario where my logs were full of failed ssh attempts and by changing the ssh port , they all stopped .
ALL OF THEM .
I have n't had an unknown IP attempt to log in via SSH in around five years .
fail2ban , strong passwords , or whatever additional security you want to apply is great , and recommended , but a port change will solve more of the problem than you might think .</tokentext>
<sentencetext>Obviously the port change idea is unpopular because it's just obscurity, which != security.
However, most, of not all, of those attempts are probably from scripts rather than actual human attackers actively attempting to compromise your servers.
The script kiddies rely on automation to rapidly find vulnerable hosts using easily-scripted vulnerabilities or brute force.
The simple act of changing your ssh port will render those kinds of attacks useless against you.
I had a similar scenario where my logs were full of failed ssh attempts and by changing the ssh port, they all stopped.
ALL OF THEM.
I haven't had an unknown IP attempt to log in via SSH in around five years.
fail2ban, strong passwords, or whatever additional security you want to apply is great, and recommended, but a port change will solve more of the problem than you might think.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390450</id>
	<title>Re:Tar Pitting</title>
	<author>awyeah</author>
	<datestamp>1267981080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And DISABLE ROOT LOGIN!</p></div><p>On many Linux distributions I've used, PermitRootLogin is enabled by default on SSH.  I find it absolutely hilarious (FreeBSD has it disabled by default).</p><p>I also find hilarious the number of machines where this is left enabled after a box is deployed into production.</p><p>This seems to be especially common at places that call themselves "Microsoft Shops."  This isn't a potshot against Windows admins - there are lots of very intelligent ones out there - it's just that there are a lot of Windows admins who don't really know Linux, but need to set up one or two Linux boxes in the data center for some software that they need to run.</p></div>
	</htmltext>
<tokenext>And DISABLE ROOT LOGIN ! On many Linux distributions I 've used , PermitRootLogin is enabled by default on SSH .
I find it absolutely hilarious ( FreeBSD has it disabled by default ) .I also find hilarious the number of machines where this is left enabled after a box is deployed into production.This seems to be especially common at places that call themselves " Microsoft Shops .
" This is n't a potshot against Windows admins - there are lots of very intelligent ones out there - it 's just that there are a lot of Windows admins who do n't really know Linux , but need to set up one or two Linux boxes in the data center for some software that they need to run .</tokentext>
<sentencetext>And DISABLE ROOT LOGIN!On many Linux distributions I've used, PermitRootLogin is enabled by default on SSH.
I find it absolutely hilarious (FreeBSD has it disabled by default).I also find hilarious the number of machines where this is left enabled after a box is deployed into production.This seems to be especially common at places that call themselves "Microsoft Shops.
"  This isn't a potshot against Windows admins - there are lots of very intelligent ones out there - it's just that there are a lot of Windows admins who don't really know Linux, but need to set up one or two Linux boxes in the data center for some software that they need to run.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390408</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267980900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You forgot to say "per IP address" - otherwise I'm assuming you like twiddling your thumbs for 24 hours every time *you* want to log in?<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>You forgot to say " per IP address " - otherwise I 'm assuming you like twiddling your thumbs for 24 hours every time * you * want to log in ?
; )</tokentext>
<sentencetext>You forgot to say "per IP address" - otherwise I'm assuming you like twiddling your thumbs for 24 hours every time *you* want to log in?
;)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31406346</id>
	<title>As someone managing an SSH server</title>
	<author>Outland Traveller</author>
	<datestamp>1268046720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If your passwords are randomly generated and long, it doesn't matter how many attempts to guess them are tried. The likelyhood of a random guess getting through are lower than your chances of winning the lottery. Let people waste their time on futile attempts.</p><p>To further decrease your chances, use public keys authentication instead of passwords, or two factor authentication, or limit connections by IP address.</p><p>Changing the post does fool most SSH scanners as well.</p><p>I don't like fail2ban because it can lead to DoS vectors.</p><p>Bottom line is that logged attacks that have no hope of getting through shouldn't cause a panic.</p></htmltext>
<tokenext>If your passwords are randomly generated and long , it does n't matter how many attempts to guess them are tried .
The likelyhood of a random guess getting through are lower than your chances of winning the lottery .
Let people waste their time on futile attempts.To further decrease your chances , use public keys authentication instead of passwords , or two factor authentication , or limit connections by IP address.Changing the post does fool most SSH scanners as well.I do n't like fail2ban because it can lead to DoS vectors.Bottom line is that logged attacks that have no hope of getting through should n't cause a panic .</tokentext>
<sentencetext>If your passwords are randomly generated and long, it doesn't matter how many attempts to guess them are tried.
The likelyhood of a random guess getting through are lower than your chances of winning the lottery.
Let people waste their time on futile attempts.To further decrease your chances, use public keys authentication instead of passwords, or two factor authentication, or limit connections by IP address.Changing the post does fool most SSH scanners as well.I don't like fail2ban because it can lead to DoS vectors.Bottom line is that logged attacks that have no hope of getting through shouldn't cause a panic.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385296</id>
	<title>fail2ban</title>
	<author>EvilIdler</author>
	<datestamp>1267884960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.fail2ban.org/wiki/index.php/Main\_Page" title="fail2ban.org">http://www.fail2ban.org/wiki/index.php/Main\_Page</a> [fail2ban.org]</p><p>That should cover automatic banning of repeat offenders. It works by reading logs, so it can work with many services. You could for example make it block all those attempting to exploit your CMSes.</p></htmltext>
<tokenext>http : //www.fail2ban.org/wiki/index.php/Main \ _Page [ fail2ban.org ] That should cover automatic banning of repeat offenders .
It works by reading logs , so it can work with many services .
You could for example make it block all those attempting to exploit your CMSes .</tokentext>
<sentencetext>http://www.fail2ban.org/wiki/index.php/Main\_Page [fail2ban.org]That should cover automatic banning of repeat offenders.
It works by reading logs, so it can work with many services.
You could for example make it block all those attempting to exploit your CMSes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387108</id>
	<title>Re:You are being brute-forced</title>
	<author>Eil</author>
	<datestamp>1267904160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>First off, do not change your SSH port. It won't do a whole lot for you, and it will be more hassle than it works.</p></div></blockquote><p>I don't see why moving the SSH port is a bad idea. It's trivial and no ssh bot or script that I've heard of will even look for SSH on other ports. Adapting to it is as simple as adding a -p argument to your ssh command. I used to admin a machine that would see at least 5 brute-force runs on SSH per day. Changed the port and there were <i>zero</i> after that. The people who write brute-force SSH attacks (either in bot of script form) are looking for the low-hanging fruit. They don't even bother broadening their scope to systems with even a modicum of hardening because there are so many insecure-by-default machines on the net to choose from.</p></div>
	</htmltext>
<tokenext>First off , do not change your SSH port .
It wo n't do a whole lot for you , and it will be more hassle than it works.I do n't see why moving the SSH port is a bad idea .
It 's trivial and no ssh bot or script that I 've heard of will even look for SSH on other ports .
Adapting to it is as simple as adding a -p argument to your ssh command .
I used to admin a machine that would see at least 5 brute-force runs on SSH per day .
Changed the port and there were zero after that .
The people who write brute-force SSH attacks ( either in bot of script form ) are looking for the low-hanging fruit .
They do n't even bother broadening their scope to systems with even a modicum of hardening because there are so many insecure-by-default machines on the net to choose from .</tokentext>
<sentencetext>First off, do not change your SSH port.
It won't do a whole lot for you, and it will be more hassle than it works.I don't see why moving the SSH port is a bad idea.
It's trivial and no ssh bot or script that I've heard of will even look for SSH on other ports.
Adapting to it is as simple as adding a -p argument to your ssh command.
I used to admin a machine that would see at least 5 brute-force runs on SSH per day.
Changed the port and there were zero after that.
The people who write brute-force SSH attacks (either in bot of script form) are looking for the low-hanging fruit.
They don't even bother broadening their scope to systems with even a modicum of hardening because there are so many insecure-by-default machines on the net to choose from.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385450</id>
	<title>Change port</title>
	<author>Anonymous</author>
	<datestamp>1267885920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is pretty common stuff trying random SSH logins on public facing servers, at least for me - just change the SSH port and have strong SSH passwords - that's all I do and stops it dead.</p><p>If you are really worried, firewall/iptables to fixed IP addresses.</p></htmltext>
<tokenext>This is pretty common stuff trying random SSH logins on public facing servers , at least for me - just change the SSH port and have strong SSH passwords - that 's all I do and stops it dead.If you are really worried , firewall/iptables to fixed IP addresses .</tokentext>
<sentencetext>This is pretty common stuff trying random SSH logins on public facing servers, at least for me - just change the SSH port and have strong SSH passwords - that's all I do and stops it dead.If you are really worried, firewall/iptables to fixed IP addresses.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386682</id>
	<title>Re:So?</title>
	<author>Anonymous</author>
	<datestamp>1267898940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You could always whitelist your target countries IP ranges.  If you know the countries that are your prospective customers, permit them, drop the rest.</p><p>Similarly, if a particular country is giving you trouble, ban the whole country, leave everyone else.</p><p>Personally, I have no interest in having anyone visit my site that isn't in my country.  So, I just permit them.  Voila! Done.  If I have hack attempts from within my own country, I call that ISP and get them to enforce their AUP.</p></htmltext>
<tokenext>You could always whitelist your target countries IP ranges .
If you know the countries that are your prospective customers , permit them , drop the rest.Similarly , if a particular country is giving you trouble , ban the whole country , leave everyone else.Personally , I have no interest in having anyone visit my site that is n't in my country .
So , I just permit them .
Voila ! Done .
If I have hack attempts from within my own country , I call that ISP and get them to enforce their AUP .</tokentext>
<sentencetext>You could always whitelist your target countries IP ranges.
If you know the countries that are your prospective customers, permit them, drop the rest.Similarly, if a particular country is giving you trouble, ban the whole country, leave everyone else.Personally, I have no interest in having anyone visit my site that isn't in my country.
So, I just permit them.
Voila! Done.
If I have hack attempts from within my own country, I call that ISP and get them to enforce their AUP.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385090</id>
	<title>suggestion:</title>
	<author>Anonymous</author>
	<datestamp>1267883580000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>eat out my asshole.  Won't help with that SSH thing, but damn I enjoy it.</htmltext>
<tokenext>eat out my asshole .
Wo n't help with that SSH thing , but damn I enjoy it .</tokentext>
<sentencetext>eat out my asshole.
Won't help with that SSH thing, but damn I enjoy it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386176</id>
	<title>UFW = FTW</title>
	<author>bdinger</author>
	<datestamp>1267893180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I second every suggestion to get a hardware firewall, and use VPN if possible.  But I know with many large hosting providers, particularly those who specialize in VM's, this isn't an option.  I have a couple of VM's through one of those hosts (and I *love* said host), so you have to do the next best thing: some sort of software protection.

If you are running Ubuntu, UFW does excellent.  I use UFW and allow SSH connections only from two spots - my work IP, and my shell server.  My shell server sits in a co-lo behind my PIX, and I VPN into it.  I'm kinda weird like that, I'll admit. I have a PIX at home as well.  Okay I'm a bit of a freakshow.

Anyway, if you aren't running ubuntu, hosts.deny, PKI, and moving SSH to a very high numbered port will *help*.  Other than that, contact the hosting provider and see if they will help you on a consulting basis.  Remember many of them are running barebones to give you good prices - don't expect too much, and you never know - if you offer they might not even take you up on it.

Finally - good luck.</htmltext>
<tokenext>I second every suggestion to get a hardware firewall , and use VPN if possible .
But I know with many large hosting providers , particularly those who specialize in VM 's , this is n't an option .
I have a couple of VM 's through one of those hosts ( and I * love * said host ) , so you have to do the next best thing : some sort of software protection .
If you are running Ubuntu , UFW does excellent .
I use UFW and allow SSH connections only from two spots - my work IP , and my shell server .
My shell server sits in a co-lo behind my PIX , and I VPN into it .
I 'm kinda weird like that , I 'll admit .
I have a PIX at home as well .
Okay I 'm a bit of a freakshow .
Anyway , if you are n't running ubuntu , hosts.deny , PKI , and moving SSH to a very high numbered port will * help * .
Other than that , contact the hosting provider and see if they will help you on a consulting basis .
Remember many of them are running barebones to give you good prices - do n't expect too much , and you never know - if you offer they might not even take you up on it .
Finally - good luck .</tokentext>
<sentencetext>I second every suggestion to get a hardware firewall, and use VPN if possible.
But I know with many large hosting providers, particularly those who specialize in VM's, this isn't an option.
I have a couple of VM's through one of those hosts (and I *love* said host), so you have to do the next best thing: some sort of software protection.
If you are running Ubuntu, UFW does excellent.
I use UFW and allow SSH connections only from two spots - my work IP, and my shell server.
My shell server sits in a co-lo behind my PIX, and I VPN into it.
I'm kinda weird like that, I'll admit.
I have a PIX at home as well.
Okay I'm a bit of a freakshow.
Anyway, if you aren't running ubuntu, hosts.deny, PKI, and moving SSH to a very high numbered port will *help*.
Other than that, contact the hosting provider and see if they will help you on a consulting basis.
Remember many of them are running barebones to give you good prices - don't expect too much, and you never know - if you offer they might not even take you up on it.
Finally - good luck.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387744</id>
	<title>Re:fail2ban</title>
	<author>DeadboltX</author>
	<datestamp>1267956360000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>is there any advantage to fail2ban over denyhosts ?</htmltext>
<tokenext>is there any advantage to fail2ban over denyhosts ?</tokentext>
<sentencetext>is there any advantage to fail2ban over denyhosts ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391638</id>
	<title>Re:use openvpn ?</title>
	<author>jon3k</author>
	<datestamp>1267987560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why are you trying to use a hand grenade to kill a mosquito?  Even if you add a device or piece of software to do VPN termination, all you've done is move the problem of brute force attacks there.
<br> <br>
There are half a dozen simple software and configuration options that solve this problem far better listed in the comments.</htmltext>
<tokenext>Why are you trying to use a hand grenade to kill a mosquito ?
Even if you add a device or piece of software to do VPN termination , all you 've done is move the problem of brute force attacks there .
There are half a dozen simple software and configuration options that solve this problem far better listed in the comments .</tokentext>
<sentencetext>Why are you trying to use a hand grenade to kill a mosquito?
Even if you add a device or piece of software to do VPN termination, all you've done is move the problem of brute force attacks there.
There are half a dozen simple software and configuration options that solve this problem far better listed in the comments.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385116</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385690</id>
	<title>Re:whatcouldposiblygowrong</title>
	<author>darkpixel2k</author>
	<datestamp>1267888380000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>He could get trolled on slashdot by the very people he's coming to ask for help to become *less* of a noob.</p><p>I'll bet you teach your kid gun safety by shooting him in the neck.</p></div><p>
LMAO!  Where are my mod points?</p></div>
	</htmltext>
<tokenext>He could get trolled on slashdot by the very people he 's coming to ask for help to become * less * of a noob.I 'll bet you teach your kid gun safety by shooting him in the neck .
LMAO ! Where are my mod points ?</tokentext>
<sentencetext>He could get trolled on slashdot by the very people he's coming to ask for help to become *less* of a noob.I'll bet you teach your kid gun safety by shooting him in the neck.
LMAO!  Where are my mod points?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385782</id>
	<title>drop the requests</title>
	<author>Anonymous</author>
	<datestamp>1267889280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>use an ACL to drop all traffic from Africa, Russia and China... problem solved</p></htmltext>
<tokenext>use an ACL to drop all traffic from Africa , Russia and China... problem solved</tokentext>
<sentencetext>use an ACL to drop all traffic from Africa, Russia and China... problem solved</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392920</id>
	<title>OSSEC</title>
	<author>doug.burks</author>
	<datestamp>1267994760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I highly recommend OSSEC (ossec.net).  It will parse your system logs (SSH, Apache, ModSecurity, Snort, and others) and block attacker's IP addresses automatically.  There's even a Wordpress plugin that will output to syslog and therefore OSSEC.  For more information, please see:
<a href="http://securityonion.blogspot.com/2010/02/defense-in-depth-using-ossec-and-other.html" title="blogspot.com" rel="nofollow">http://securityonion.blogspot.com/2010/02/defense-in-depth-using-ossec-and-other.html</a> [blogspot.com]</htmltext>
<tokenext>I highly recommend OSSEC ( ossec.net ) .
It will parse your system logs ( SSH , Apache , ModSecurity , Snort , and others ) and block attacker 's IP addresses automatically .
There 's even a Wordpress plugin that will output to syslog and therefore OSSEC .
For more information , please see : http : //securityonion.blogspot.com/2010/02/defense-in-depth-using-ossec-and-other.html [ blogspot.com ]</tokentext>
<sentencetext>I highly recommend OSSEC (ossec.net).
It will parse your system logs (SSH, Apache, ModSecurity, Snort, and others) and block attacker's IP addresses automatically.
There's even a Wordpress plugin that will output to syslog and therefore OSSEC.
For more information, please see:
http://securityonion.blogspot.com/2010/02/defense-in-depth-using-ossec-and-other.html [blogspot.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385818</id>
	<title>Simplest, bestest</title>
	<author>spencertk</author>
	<datestamp>1267889700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>deadmongrel and PhunkySchtuff have really answered your question the best of all.<br>
<br>
I can't add much to it except for these comments.  denyhosts works great and we use a threshold of 1 failure on unknown logins and only 3 failures on known logins.  It takes attention to detail as a remote user but it really works well.  We set the thing to completely shut out someone who pulls that SSH crap on us, assuming that they are a bad buy.  By extension, we use our firewall to log things that shouldn't be happening and tell us about the source IP.  Again we assume they are bad guys (or gurls) and simply shut em out forever.  Same thing goes for POP3 scans, etc.  Hey, there are only a few billion possibilities (in IP4), knock em down and coordinate your data with others to save them time.</htmltext>
<tokenext>deadmongrel and PhunkySchtuff have really answered your question the best of all .
I ca n't add much to it except for these comments .
denyhosts works great and we use a threshold of 1 failure on unknown logins and only 3 failures on known logins .
It takes attention to detail as a remote user but it really works well .
We set the thing to completely shut out someone who pulls that SSH crap on us , assuming that they are a bad buy .
By extension , we use our firewall to log things that should n't be happening and tell us about the source IP .
Again we assume they are bad guys ( or gurls ) and simply shut em out forever .
Same thing goes for POP3 scans , etc .
Hey , there are only a few billion possibilities ( in IP4 ) , knock em down and coordinate your data with others to save them time .</tokentext>
<sentencetext>deadmongrel and PhunkySchtuff have really answered your question the best of all.
I can't add much to it except for these comments.
denyhosts works great and we use a threshold of 1 failure on unknown logins and only 3 failures on known logins.
It takes attention to detail as a remote user but it really works well.
We set the thing to completely shut out someone who pulls that SSH crap on us, assuming that they are a bad buy.
By extension, we use our firewall to log things that shouldn't be happening and tell us about the source IP.
Again we assume they are bad guys (or gurls) and simply shut em out forever.
Same thing goes for POP3 scans, etc.
Hey, there are only a few billion possibilities (in IP4), knock em down and coordinate your data with others to save them time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398994</id>
	<title>Re:You are being brute-forced</title>
	<author>raju1kabir</author>
	<datestamp>1268048700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>First off, do not change your SSH port. It won't do a whole lot for you, and it will be more hassle than it works.</p></div></blockquote><p>I disagree. I changed the SSH port on all our servers. Everyone updated their<nobr> <wbr></nobr>.ssh/config files and that was the end of the hassle. Bad logins dropped from thousands a day to a handful every few weeks.</p></div>
	</htmltext>
<tokenext>First off , do not change your SSH port .
It wo n't do a whole lot for you , and it will be more hassle than it works.I disagree .
I changed the SSH port on all our servers .
Everyone updated their .ssh/config files and that was the end of the hassle .
Bad logins dropped from thousands a day to a handful every few weeks .</tokentext>
<sentencetext>First off, do not change your SSH port.
It won't do a whole lot for you, and it will be more hassle than it works.I disagree.
I changed the SSH port on all our servers.
Everyone updated their .ssh/config files and that was the end of the hassle.
Bad logins dropped from thousands a day to a handful every few weeks.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388364</id>
	<title>Re:hashlimit</title>
	<author>turbidostato</author>
	<datestamp>1267966440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>"I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!"</p><p>Quite to the point.  There's a rising trend on questions like "I'm having problems about X but I prefer being cheap on coping with X, what should I do?".  And then there's the rising trend on answering something else than "if you depend on X you'll need to invest on X".</p><p>And now, about the problem at hand: your (his) logs attest thousands of *failed* connection attempts through ssh.  In the end... so what?  Failed attempts are neither worrying nor in your hand to be avoided (changing your ssh port is the most cost effective remediation measure to maintain bots at a distance).  Bellovin already stated quite some years ago (not his exact words, but their meaning): do not monitor on the outer side of your firewall if you are not in the position of avoiding the attacks; all you get will be headaches and a ton of meaningless logs to parse (and probably losing important information among the noise).  The verily reason for your firewall to be there is already to maintain the attacks as failed attempts anyway.  Do monitor from the inner side.  In this case, monitor successful logins, not failed ones.</p></htmltext>
<tokenext>" I 'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security .
This job is usually referred to as a system administrator or network administrator .
DOH ! " Quite to the point .
There 's a rising trend on questions like " I 'm having problems about X but I prefer being cheap on coping with X , what should I do ? " .
And then there 's the rising trend on answering something else than " if you depend on X you 'll need to invest on X " .And now , about the problem at hand : your ( his ) logs attest thousands of * failed * connection attempts through ssh .
In the end... so what ?
Failed attempts are neither worrying nor in your hand to be avoided ( changing your ssh port is the most cost effective remediation measure to maintain bots at a distance ) .
Bellovin already stated quite some years ago ( not his exact words , but their meaning ) : do not monitor on the outer side of your firewall if you are not in the position of avoiding the attacks ; all you get will be headaches and a ton of meaningless logs to parse ( and probably losing important information among the noise ) .
The verily reason for your firewall to be there is already to maintain the attacks as failed attempts anyway .
Do monitor from the inner side .
In this case , monitor successful logins , not failed ones .</tokentext>
<sentencetext>"I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security.
This job is usually referred to as a system administrator or network administrator.
DOH!"Quite to the point.
There's a rising trend on questions like "I'm having problems about X but I prefer being cheap on coping with X, what should I do?".
And then there's the rising trend on answering something else than "if you depend on X you'll need to invest on X".And now, about the problem at hand: your (his) logs attest thousands of *failed* connection attempts through ssh.
In the end... so what?
Failed attempts are neither worrying nor in your hand to be avoided (changing your ssh port is the most cost effective remediation measure to maintain bots at a distance).
Bellovin already stated quite some years ago (not his exact words, but their meaning): do not monitor on the outer side of your firewall if you are not in the position of avoiding the attacks; all you get will be headaches and a ton of meaningless logs to parse (and probably losing important information among the noise).
The verily reason for your firewall to be there is already to maintain the attacks as failed attempts anyway.
Do monitor from the inner side.
In this case, monitor successful logins, not failed ones.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385796</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31395352</id>
	<title>Why Stop Them</title>
	<author>thisNameNotTaken</author>
	<datestamp>1267967940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Some advice:</p><p>Hack the ssh program, let them in, rate limit them after they give you data, then dump them. Start all over again.</p><p>I'll let you know how this works as I have a research project to do this.</p><p>I am looking for ssh friends<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Some advice : Hack the ssh program , let them in , rate limit them after they give you data , then dump them .
Start all over again.I 'll let you know how this works as I have a research project to do this.I am looking for ssh friends : )</tokentext>
<sentencetext>Some advice:Hack the ssh program, let them in, rate limit them after they give you data, then dump them.
Start all over again.I'll let you know how this works as I have a research project to do this.I am looking for ssh friends :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385554</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267886700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>you slick bastard</htmltext>
<tokenext>you slick bastard</tokentext>
<sentencetext>you slick bastard</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385168</id>
	<title>Fail2Ban</title>
	<author>j\_kenpo</author>
	<datestamp>1267884000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If your not willing to invest money into intrusion detection, vulnerability scanning, or moving to a more responsive provider, accept that your server is going to constantly be scanned by the droves of script kiddies out there throwing everything but the kitchen sink at any server that responds to a ping and keep monitoring those logs, which hopefully are stored on a separate server in case you are ever actually compromised. In the mean time, try installing Fail2Ban on your server. It will block an IP address after X number of failed authentication attempts, which will alleviate the noise of the brute force password guessing attempts.</p></htmltext>
<tokenext>If your not willing to invest money into intrusion detection , vulnerability scanning , or moving to a more responsive provider , accept that your server is going to constantly be scanned by the droves of script kiddies out there throwing everything but the kitchen sink at any server that responds to a ping and keep monitoring those logs , which hopefully are stored on a separate server in case you are ever actually compromised .
In the mean time , try installing Fail2Ban on your server .
It will block an IP address after X number of failed authentication attempts , which will alleviate the noise of the brute force password guessing attempts .</tokentext>
<sentencetext>If your not willing to invest money into intrusion detection, vulnerability scanning, or moving to a more responsive provider, accept that your server is going to constantly be scanned by the droves of script kiddies out there throwing everything but the kitchen sink at any server that responds to a ping and keep monitoring those logs, which hopefully are stored on a separate server in case you are ever actually compromised.
In the mean time, try installing Fail2Ban on your server.
It will block an IP address after X number of failed authentication attempts, which will alleviate the noise of the brute force password guessing attempts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388514</id>
	<title>Re:Tar Pitting</title>
	<author>1s44c</author>
	<datestamp>1267968060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm a big fan of tarpitting SSH connections myself. It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.</p><p>Basically, an iptables rule:<br>-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP</p></div><p>That doesn't look like tarpitting, you are just dropping the connections. Tarpitting would be holding the connection open but not sending useful data down it.</p><p>Not that there is anything wrong with just dropping the connections, it's a good approach.</p></div>
	</htmltext>
<tokenext>I 'm a big fan of tarpitting SSH connections myself .
It dramatically cuts down on the repeated ssh attempts , and keeps my logs much cleaner.Basically , an iptables rule : -A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROPThat does n't look like tarpitting , you are just dropping the connections .
Tarpitting would be holding the connection open but not sending useful data down it.Not that there is anything wrong with just dropping the connections , it 's a good approach .</tokentext>
<sentencetext>I'm a big fan of tarpitting SSH connections myself.
It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.Basically, an iptables rule:-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROPThat doesn't look like tarpitting, you are just dropping the connections.
Tarpitting would be holding the connection open but not sending useful data down it.Not that there is anything wrong with just dropping the connections, it's a good approach.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391578</id>
	<title>Port Knocking</title>
	<author>skyphyr</author>
	<datestamp>1267987260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You could consider implementing port knocking.

It will be somewhat of an inconvenience for your clients, but it will
almost eliminate your ssh authentication failures.</htmltext>
<tokenext>You could consider implementing port knocking .
It will be somewhat of an inconvenience for your clients , but it will almost eliminate your ssh authentication failures .</tokentext>
<sentencetext>You could consider implementing port knocking.
It will be somewhat of an inconvenience for your clients, but it will
almost eliminate your ssh authentication failures.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386962</id>
	<title>contrack module ipt\_recent</title>
	<author>doktorjayd</author>
	<datestamp>1267902660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>works quite well for me</p><p><a href="http://www.snowman.net/projects/ipt\_recent/" title="snowman.net">http://www.snowman.net/projects/ipt\_recent/</a> [snowman.net]</p><p>its been around for years, and has kept my ssh service nice and available for almost as long.</p><p>basically, keeps a contrack record for tcp new attempts on the configured port(s), with threshholds for how many attempts before being temporarily blacklisted, then a timeout for how long before they can go again.</p><p>fail2ban and denyhosts fee way to high up in the stack for my liking</p></htmltext>
<tokenext>works quite well for mehttp : //www.snowman.net/projects/ipt \ _recent/ [ snowman.net ] its been around for years , and has kept my ssh service nice and available for almost as long.basically , keeps a contrack record for tcp new attempts on the configured port ( s ) , with threshholds for how many attempts before being temporarily blacklisted , then a timeout for how long before they can go again.fail2ban and denyhosts fee way to high up in the stack for my liking</tokentext>
<sentencetext>works quite well for mehttp://www.snowman.net/projects/ipt\_recent/ [snowman.net]its been around for years, and has kept my ssh service nice and available for almost as long.basically, keeps a contrack record for tcp new attempts on the configured port(s), with threshholds for how many attempts before being temporarily blacklisted, then a timeout for how long before they can go again.fail2ban and denyhosts fee way to high up in the stack for my liking</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31405926</id>
	<title>Use ClearOS</title>
	<author>pr0f3550r</author>
	<datestamp>1268045400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is why i use <a href="http://www.clearfoundation.com/" title="clearfoundation.com" rel="nofollow">ClearOS</a> [clearfoundation.com]. It comes with Intrusion Prevention via Snort right out of the box. It proactively blocks failed SSH attempts and keeps my boxes off the lists happy and smiley!</htmltext>
<tokenext>This is why i use ClearOS [ clearfoundation.com ] .
It comes with Intrusion Prevention via Snort right out of the box .
It proactively blocks failed SSH attempts and keeps my boxes off the lists happy and smiley !</tokentext>
<sentencetext>This is why i use ClearOS [clearfoundation.com].
It comes with Intrusion Prevention via Snort right out of the box.
It proactively blocks failed SSH attempts and keeps my boxes off the lists happy and smiley!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386388</id>
	<title>Re:fwknop</title>
	<author>phantomcircuit</author>
	<datestamp>1267895340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That is an exceptionally bad idea.  You're simply increasing the complexity of the entire authentication system, without doing much more than requiring another password.</p></htmltext>
<tokenext>That is an exceptionally bad idea .
You 're simply increasing the complexity of the entire authentication system , without doing much more than requiring another password .</tokentext>
<sentencetext>That is an exceptionally bad idea.
You're simply increasing the complexity of the entire authentication system, without doing much more than requiring another password.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386180</id>
	<title>sshdfilter?</title>
	<author>MoFoQ</author>
	<datestamp>1267893180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>you can always use iptables and hashlimit module to limit the number of connections to port 22 as well as using <a href="http://www.csc.liv.ac.uk/~greg/sshdfilter/" title="liv.ac.uk">sshdfilter</a> [liv.ac.uk]</p></htmltext>
<tokenext>you can always use iptables and hashlimit module to limit the number of connections to port 22 as well as using sshdfilter [ liv.ac.uk ]</tokentext>
<sentencetext>you can always use iptables and hashlimit module to limit the number of connections to port 22 as well as using sshdfilter [liv.ac.uk]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386800</id>
	<title>First step: Don't worry.</title>
	<author>GNUALMAFUERTE</author>
	<datestamp>1267900500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's not really that bad. I manage several Unix systems. I have done so for all of my professional life. Some servers get in someone's list, some others don't.</p><p>I currently work for an international telco, with base in the US, and servers in the US, Brazil and Argentina. It's a small firm, and I manage the whole operation. Some servers get attack attempts all the time. Others don't.<br>The first thing you have to find out is: Are those attacks targeted? Many times, you'll get a new server up, assign a fresh IP, and immediately inherit shitloads of connection attempts. Those've been probably targeted at that IP for years. Most probably aren't even meant for your particular platform. I get shitloads of IIS+Windows attacks targeted at my Slackware + Apache2 servers. I see connections to my SSH daemons trying to exploit vulnerabilities that have been patched for at least 5 years.<br>But mostly, I get stupid dictionary attacks. With oh so crappy dictionaries that look mostly for usual names and system defaults.</p><p>This are the steps you should follow:</p><p>1st: Move SSH out of port 22. That'll filter out 75\% of all attempts.<br>2nd: Use Portsentry. You'll eventually have to whitelist some guy unfairly banned, but most of the time, it works like a charm.<br>3rd: Implement way of the many scripts (or write your own) that bans IPs or ranges of IPs that have failed auth many times to your opensshd. This is your most important defense here.<br>4rd: Implement longer delays after failed passwords<br>5th: Seat back, and relax. Change passwords regularly. Keep them strong. Watch logs regularly, keep an eye for sofisticated, targeted attacks, and ignore the script kiddies.</p><p>Most of the time, those logs just mean that you are out there on a public network, and you've got an IP on way too many people's lists. If it's sucking up too much bandwidth, ask your ISP for a new IP.</p><p>If you ever became worried about some guys, feel no shame about banning whole ranges of IPs. If you truly expect no traffic from those places, dropping China, Brasil and Russia from ever reaching your ssh port is a great idea. Actually, if you only expects connections from certain places, whitelist those ranges and drop anything else.</p><p>Finally, don't focus so much on SSH. OpenSSH is stable and secure, and it'll rarely be the source of you getting rooted. Focus on more vulnerable services, like crappy php webapps, ftp servers, etc.</p></htmltext>
<tokenext>It 's not really that bad .
I manage several Unix systems .
I have done so for all of my professional life .
Some servers get in someone 's list , some others do n't.I currently work for an international telco , with base in the US , and servers in the US , Brazil and Argentina .
It 's a small firm , and I manage the whole operation .
Some servers get attack attempts all the time .
Others do n't.The first thing you have to find out is : Are those attacks targeted ?
Many times , you 'll get a new server up , assign a fresh IP , and immediately inherit shitloads of connection attempts .
Those 've been probably targeted at that IP for years .
Most probably are n't even meant for your particular platform .
I get shitloads of IIS + Windows attacks targeted at my Slackware + Apache2 servers .
I see connections to my SSH daemons trying to exploit vulnerabilities that have been patched for at least 5 years.But mostly , I get stupid dictionary attacks .
With oh so crappy dictionaries that look mostly for usual names and system defaults.This are the steps you should follow : 1st : Move SSH out of port 22 .
That 'll filter out 75 \ % of all attempts.2nd : Use Portsentry .
You 'll eventually have to whitelist some guy unfairly banned , but most of the time , it works like a charm.3rd : Implement way of the many scripts ( or write your own ) that bans IPs or ranges of IPs that have failed auth many times to your opensshd .
This is your most important defense here.4rd : Implement longer delays after failed passwords5th : Seat back , and relax .
Change passwords regularly .
Keep them strong .
Watch logs regularly , keep an eye for sofisticated , targeted attacks , and ignore the script kiddies.Most of the time , those logs just mean that you are out there on a public network , and you 've got an IP on way too many people 's lists .
If it 's sucking up too much bandwidth , ask your ISP for a new IP.If you ever became worried about some guys , feel no shame about banning whole ranges of IPs .
If you truly expect no traffic from those places , dropping China , Brasil and Russia from ever reaching your ssh port is a great idea .
Actually , if you only expects connections from certain places , whitelist those ranges and drop anything else.Finally , do n't focus so much on SSH .
OpenSSH is stable and secure , and it 'll rarely be the source of you getting rooted .
Focus on more vulnerable services , like crappy php webapps , ftp servers , etc .</tokentext>
<sentencetext>It's not really that bad.
I manage several Unix systems.
I have done so for all of my professional life.
Some servers get in someone's list, some others don't.I currently work for an international telco, with base in the US, and servers in the US, Brazil and Argentina.
It's a small firm, and I manage the whole operation.
Some servers get attack attempts all the time.
Others don't.The first thing you have to find out is: Are those attacks targeted?
Many times, you'll get a new server up, assign a fresh IP, and immediately inherit shitloads of connection attempts.
Those've been probably targeted at that IP for years.
Most probably aren't even meant for your particular platform.
I get shitloads of IIS+Windows attacks targeted at my Slackware + Apache2 servers.
I see connections to my SSH daemons trying to exploit vulnerabilities that have been patched for at least 5 years.But mostly, I get stupid dictionary attacks.
With oh so crappy dictionaries that look mostly for usual names and system defaults.This are the steps you should follow:1st: Move SSH out of port 22.
That'll filter out 75\% of all attempts.2nd: Use Portsentry.
You'll eventually have to whitelist some guy unfairly banned, but most of the time, it works like a charm.3rd: Implement way of the many scripts (or write your own) that bans IPs or ranges of IPs that have failed auth many times to your opensshd.
This is your most important defense here.4rd: Implement longer delays after failed passwords5th: Seat back, and relax.
Change passwords regularly.
Keep them strong.
Watch logs regularly, keep an eye for sofisticated, targeted attacks, and ignore the script kiddies.Most of the time, those logs just mean that you are out there on a public network, and you've got an IP on way too many people's lists.
If it's sucking up too much bandwidth, ask your ISP for a new IP.If you ever became worried about some guys, feel no shame about banning whole ranges of IPs.
If you truly expect no traffic from those places, dropping China, Brasil and Russia from ever reaching your ssh port is a great idea.
Actually, if you only expects connections from certain places, whitelist those ranges and drop anything else.Finally, don't focus so much on SSH.
OpenSSH is stable and secure, and it'll rarely be the source of you getting rooted.
Focus on more vulnerable services, like crappy php webapps, ftp servers, etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386758</id>
	<title>Learn firewall and security</title>
	<author>Sudheer\_BV</author>
	<datestamp>1267899780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Learn iptables. There are many good books available covering iptables and server security topics.</htmltext>
<tokenext>Learn iptables .
There are many good books available covering iptables and server security topics .</tokentext>
<sentencetext>Learn iptables.
There are many good books available covering iptables and server security topics.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392022</id>
	<title>Re:Lock it down.</title>
	<author>jon3k</author>
	<datestamp>1267989540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>"Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners."</i>
<br> <br>
You're clearly very uninformed on the actual threat.  99\%+ of these attacks are automated attacks from botnets.  There's no port scanning it's a waste of resources for them.  They just attempt to login via port 22 using a few dozen default passwords and move on.</htmltext>
<tokenext>" Do n't bother changing it to some random port , security through obscurity is total bullshit in this age of port scanners .
" You 're clearly very uninformed on the actual threat .
99 \ % + of these attacks are automated attacks from botnets .
There 's no port scanning it 's a waste of resources for them .
They just attempt to login via port 22 using a few dozen default passwords and move on .</tokentext>
<sentencetext>"Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.
"
 
You're clearly very uninformed on the actual threat.
99\%+ of these attacks are automated attacks from botnets.
There's no port scanning it's a waste of resources for them.
They just attempt to login via port 22 using a few dozen default passwords and move on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385754</id>
	<title>Re:Passwords?</title>
	<author>markdavis</author>
	<datestamp>1267889040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>I agree that PKI would be more secure, but it is a LOT more hassle for most users.  The simple fact is, a tarpit is *extremely* effective.  Even a relatively weak password is going to be nearly impossible to break if the attackers are limited to only a few tries per hour or day or whatever.</htmltext>
<tokenext>I agree that PKI would be more secure , but it is a LOT more hassle for most users .
The simple fact is , a tarpit is * extremely * effective .
Even a relatively weak password is going to be nearly impossible to break if the attackers are limited to only a few tries per hour or day or whatever .</tokentext>
<sentencetext>I agree that PKI would be more secure, but it is a LOT more hassle for most users.
The simple fact is, a tarpit is *extremely* effective.
Even a relatively weak password is going to be nearly impossible to break if the attackers are limited to only a few tries per hour or day or whatever.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385846</id>
	<title>Re:Tar Pitting</title>
	<author>PCM2</author>
	<datestamp>1267889880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The delay (in seconds) is the number of attempts in the last 30 minutes, squared. This makes all but the most determined attacker give up and go away very quickly.</p></div><p>I like the idea but your settings seem very aggressive. The attackers may go away "very quickly"... but do they go away quickly enough? Under your system, if an attacker has tried to login just eight times in the last half hour, any legitimate user who tries to login will have to wait <i>a full minute</i> after establishing the connection until they're allowed to enter their password. If that was me, I might hangup the connection and try again (compounding the problem).</p></div>
	</htmltext>
<tokenext>The delay ( in seconds ) is the number of attempts in the last 30 minutes , squared .
This makes all but the most determined attacker give up and go away very quickly.I like the idea but your settings seem very aggressive .
The attackers may go away " very quickly " ... but do they go away quickly enough ?
Under your system , if an attacker has tried to login just eight times in the last half hour , any legitimate user who tries to login will have to wait a full minute after establishing the connection until they 're allowed to enter their password .
If that was me , I might hangup the connection and try again ( compounding the problem ) .</tokentext>
<sentencetext>The delay (in seconds) is the number of attempts in the last 30 minutes, squared.
This makes all but the most determined attacker give up and go away very quickly.I like the idea but your settings seem very aggressive.
The attackers may go away "very quickly"... but do they go away quickly enough?
Under your system, if an attacker has tried to login just eight times in the last half hour, any legitimate user who tries to login will have to wait a full minute after establishing the connection until they're allowed to enter their password.
If that was me, I might hangup the connection and try again (compounding the problem).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31405534</id>
	<title>When I had this problem</title>
	<author>coolsnowmen</author>
	<datestamp>1268043720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I did a reverse lookup on the ip addresses that were trying to randomly guess user/pass on my machine and found that the majority were from: China, Korea, india, and Japan.  I then filled the hosts.deny file with the subnets from those countries and cut back on 97\% of the break-in attempts.</p><p>I also told my boss noone from those countries was ever going to be able to see our website let alone login w/o bouncing it through a different computer first.  I also block root login and users that can login have to be in the sshd group and don't have simple login names like "fred",</p><p>I believe something fail2ban-like to be a better solution in the long run, but this was faster for me to setup and understand exactly what was going on.</p></htmltext>
<tokenext>I did a reverse lookup on the ip addresses that were trying to randomly guess user/pass on my machine and found that the majority were from : China , Korea , india , and Japan .
I then filled the hosts.deny file with the subnets from those countries and cut back on 97 \ % of the break-in attempts.I also told my boss noone from those countries was ever going to be able to see our website let alone login w/o bouncing it through a different computer first .
I also block root login and users that can login have to be in the sshd group and do n't have simple login names like " fred " ,I believe something fail2ban-like to be a better solution in the long run , but this was faster for me to setup and understand exactly what was going on .</tokentext>
<sentencetext>I did a reverse lookup on the ip addresses that were trying to randomly guess user/pass on my machine and found that the majority were from: China, Korea, india, and Japan.
I then filled the hosts.deny file with the subnets from those countries and cut back on 97\% of the break-in attempts.I also told my boss noone from those countries was ever going to be able to see our website let alone login w/o bouncing it through a different computer first.
I also block root login and users that can login have to be in the sshd group and don't have simple login names like "fred",I believe something fail2ban-like to be a better solution in the long run, but this was faster for me to setup and understand exactly what was going on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387646</id>
	<title>Re:You are being brute-forced</title>
	<author>dfsmith</author>
	<datestamp>1267954800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Or shut down the ssh port altogether.  Simply open up the telnet port if you need CL access.  B-)</p><p>This is not quite as silly as it seems.  It's fairly easy to make "advent"-like scripts on the other side of telnet to access a real ssh port.  E.g, "KILL TROLL WITH DAGGER" to start the ssh daemon with access from that IP address.</p></htmltext>
<tokenext>Or shut down the ssh port altogether .
Simply open up the telnet port if you need CL access .
B- ) This is not quite as silly as it seems .
It 's fairly easy to make " advent " -like scripts on the other side of telnet to access a real ssh port .
E.g , " KILL TROLL WITH DAGGER " to start the ssh daemon with access from that IP address .</tokentext>
<sentencetext>Or shut down the ssh port altogether.
Simply open up the telnet port if you need CL access.
B-)This is not quite as silly as it seems.
It's fairly easy to make "advent"-like scripts on the other side of telnet to access a real ssh port.
E.g, "KILL TROLL WITH DAGGER" to start the ssh daemon with access from that IP address.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385340</id>
	<title>I don't understand the problem</title>
	<author>Anonymous</author>
	<datestamp>1267885260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>So there have been a million failed attempts to log in over SSH in a year. That's about one failed attempt every 30 seconds.</p><p>What's wrong with that? It's not like they're getting in, right?</p></htmltext>
<tokenext>So there have been a million failed attempts to log in over SSH in a year .
That 's about one failed attempt every 30 seconds.What 's wrong with that ?
It 's not like they 're getting in , right ?</tokentext>
<sentencetext>So there have been a million failed attempts to log in over SSH in a year.
That's about one failed attempt every 30 seconds.What's wrong with that?
It's not like they're getting in, right?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386674</id>
	<title>Another Buffer.. blockAPNIC</title>
	<author>FlyingGuy</author>
	<datestamp>1267898760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Google for it.  It is a pretty up to date list of all the undesirable IP ranges and your attempts will go <b>way</b> down.</p><p>Most recently they added 1.0.0.0<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Google for it .
It is a pretty up to date list of all the undesirable IP ranges and your attempts will go way down.Most recently they added 1.0.0.0 : )</tokentext>
<sentencetext>Google for it.
It is a pretty up to date list of all the undesirable IP ranges and your attempts will go way down.Most recently they added 1.0.0.0 :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391698</id>
	<title>Something a little more advanced?</title>
	<author>jon3k</author>
	<datestamp>1267987860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is there a piece of software similar to <a href="http://www.sshguard.net/" title="sshguard.net">SSHGuard</a> [sshguard.net] but instead of adding local IPTables rules can function in conjunction with a hardware firewall (eg - Cisco ASA) ?  I'm thinking of a device inside the private network pulling logs off hosts in the DMZ and using the results to dynamically manage firewall denies.</htmltext>
<tokenext>Is there a piece of software similar to SSHGuard [ sshguard.net ] but instead of adding local IPTables rules can function in conjunction with a hardware firewall ( eg - Cisco ASA ) ?
I 'm thinking of a device inside the private network pulling logs off hosts in the DMZ and using the results to dynamically manage firewall denies .</tokentext>
<sentencetext>Is there a piece of software similar to SSHGuard [sshguard.net] but instead of adding local IPTables rules can function in conjunction with a hardware firewall (eg - Cisco ASA) ?
I'm thinking of a device inside the private network pulling logs off hosts in the DMZ and using the results to dynamically manage firewall denies.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387914</id>
	<title>I use BlockHosts</title>
	<author>houghi</author>
	<datestamp>1267959360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.aczoom.com/cms/blockhosts/" title="aczoom.com">http://www.aczoom.com/cms/blockhosts/</a> [aczoom.com]<br>The advantage is that it does things live. So no log scanning (well, it does the first time, just to see what it can add) and therefore even if several hundred scans are done from the same IP at the same time, you do not need to wait a minute for some cron job to start and read all the adresses again.</p><p>As it works with hosts.allow (or deny) you can determine IP addresses that will never fail, so you have always access. You can also determine the amount of times users can try as well as how long you want to block the IP address.</p></htmltext>
<tokenext>http : //www.aczoom.com/cms/blockhosts/ [ aczoom.com ] The advantage is that it does things live .
So no log scanning ( well , it does the first time , just to see what it can add ) and therefore even if several hundred scans are done from the same IP at the same time , you do not need to wait a minute for some cron job to start and read all the adresses again.As it works with hosts.allow ( or deny ) you can determine IP addresses that will never fail , so you have always access .
You can also determine the amount of times users can try as well as how long you want to block the IP address .</tokentext>
<sentencetext>http://www.aczoom.com/cms/blockhosts/ [aczoom.com]The advantage is that it does things live.
So no log scanning (well, it does the first time, just to see what it can add) and therefore even if several hundred scans are done from the same IP at the same time, you do not need to wait a minute for some cron job to start and read all the adresses again.As it works with hosts.allow (or deny) you can determine IP addresses that will never fail, so you have always access.
You can also determine the amount of times users can try as well as how long you want to block the IP address.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387290</id>
	<title>wow 20k hits/week</title>
	<author>Anonymous</author>
	<datestamp>1267992660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>you're not really successful. stop calling yourself developer and stop calling your bedroom studio. go back to serving burgers at mcd.</p></htmltext>
<tokenext>you 're not really successful .
stop calling yourself developer and stop calling your bedroom studio .
go back to serving burgers at mcd .</tokentext>
<sentencetext>you're not really successful.
stop calling yourself developer and stop calling your bedroom studio.
go back to serving burgers at mcd.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385682</id>
	<title>Do nothing</title>
	<author>dmiller</author>
	<datestamp>1267888080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you are randomly generating your passwords and they are of a decent length then you don't really need to do anything. If your passwords contain lower-case letters only (not recommended), but are eight characters long then your million authentication attempts would represent only a 0.0005\% chance of success. If you passwords contain numbers and upper-case characters too, then the likelihood is 1000 times less.</htmltext>
<tokenext>If you are randomly generating your passwords and they are of a decent length then you do n't really need to do anything .
If your passwords contain lower-case letters only ( not recommended ) , but are eight characters long then your million authentication attempts would represent only a 0.0005 \ % chance of success .
If you passwords contain numbers and upper-case characters too , then the likelihood is 1000 times less .</tokentext>
<sentencetext>If you are randomly generating your passwords and they are of a decent length then you don't really need to do anything.
If your passwords contain lower-case letters only (not recommended), but are eight characters long then your million authentication attempts would represent only a 0.0005\% chance of success.
If you passwords contain numbers and upper-case characters too, then the likelihood is 1000 times less.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387722</id>
	<title>Re:You are being brute-forced</title>
	<author>TheTurtlesMoves</author>
	<datestamp>1267956000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The other thing you can do immediately is simply turn off password authentication in ssh.</p></div><p>Which changes the problem to managing a secrete passkey file on every machine i want to use to access it. Not necessarily an improvement in some cases and user nightmare in many.
<br> <br>
Passwords are fine, if you can prevent offline attacks.</p></div>
	</htmltext>
<tokenext>The other thing you can do immediately is simply turn off password authentication in ssh.Which changes the problem to managing a secrete passkey file on every machine i want to use to access it .
Not necessarily an improvement in some cases and user nightmare in many .
Passwords are fine , if you can prevent offline attacks .</tokentext>
<sentencetext>The other thing you can do immediately is simply turn off password authentication in ssh.Which changes the problem to managing a secrete passkey file on every machine i want to use to access it.
Not necessarily an improvement in some cases and user nightmare in many.
Passwords are fine, if you can prevent offline attacks.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385536</id>
	<title>It happens.  Deal with it.</title>
	<author>IGnatius T Foobar</author>
	<datestamp>1267886580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I hate to sound unsympathetic here, but the Internet is a hostile place.  If you have port 22 open to the world, you should expect to get pummelled with password cracking attempts more or less constantly.<br> <br>Either learn to live with it, or at least take some steps to slow them down.  I find that throttling back the number of connections any one IP address can make in a short time pretty much slows it down to a reasonable level.  Alternatively, you can also put some "trap" logins on your system.  Usernames like "admin" or "oracle" with the password set to the same as the username are good.  When the login succeeds, you immediately drop the connection and lock the source IP address out using iptables.<br> <br>Unless it's really causing a lot of pain, though, please don't harass the ISP from which the connection is originating.  You're just going to make some overworked sysadmin's day a little more unpleasant.  Chances are, they're already doing everything they can to keep rogues off their network.</htmltext>
<tokenext>I hate to sound unsympathetic here , but the Internet is a hostile place .
If you have port 22 open to the world , you should expect to get pummelled with password cracking attempts more or less constantly .
Either learn to live with it , or at least take some steps to slow them down .
I find that throttling back the number of connections any one IP address can make in a short time pretty much slows it down to a reasonable level .
Alternatively , you can also put some " trap " logins on your system .
Usernames like " admin " or " oracle " with the password set to the same as the username are good .
When the login succeeds , you immediately drop the connection and lock the source IP address out using iptables .
Unless it 's really causing a lot of pain , though , please do n't harass the ISP from which the connection is originating .
You 're just going to make some overworked sysadmin 's day a little more unpleasant .
Chances are , they 're already doing everything they can to keep rogues off their network .</tokentext>
<sentencetext>I hate to sound unsympathetic here, but the Internet is a hostile place.
If you have port 22 open to the world, you should expect to get pummelled with password cracking attempts more or less constantly.
Either learn to live with it, or at least take some steps to slow them down.
I find that throttling back the number of connections any one IP address can make in a short time pretty much slows it down to a reasonable level.
Alternatively, you can also put some "trap" logins on your system.
Usernames like "admin" or "oracle" with the password set to the same as the username are good.
When the login succeeds, you immediately drop the connection and lock the source IP address out using iptables.
Unless it's really causing a lot of pain, though, please don't harass the ISP from which the connection is originating.
You're just going to make some overworked sysadmin's day a little more unpleasant.
Chances are, they're already doing everything they can to keep rogues off their network.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</id>
	<title>So?</title>
	<author>Anonymous</author>
	<datestamp>1267884240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>If you really have secure passwords, the  random guessers aren't going to get them. Log it and move on.</p><p>I get thousands of Chinese hackers attempting to break into the battery monitor in my tool shed, big deal. I don't know why my battery voltage and solar current is so important to them, but they can knock themselves out all day.</p><p>If the logs bother you then install <b>fail2ban</b> and configure it to lock people out after a few bad guesses. (Then be ready to unlock yourself from an alternate IP when you inevitably lock yourself out.)</p></htmltext>
<tokenext>If you really have secure passwords , the random guessers are n't going to get them .
Log it and move on.I get thousands of Chinese hackers attempting to break into the battery monitor in my tool shed , big deal .
I do n't know why my battery voltage and solar current is so important to them , but they can knock themselves out all day.If the logs bother you then install fail2ban and configure it to lock people out after a few bad guesses .
( Then be ready to unlock yourself from an alternate IP when you inevitably lock yourself out .
)</tokentext>
<sentencetext>If you really have secure passwords, the  random guessers aren't going to get them.
Log it and move on.I get thousands of Chinese hackers attempting to break into the battery monitor in my tool shed, big deal.
I don't know why my battery voltage and solar current is so important to them, but they can knock themselves out all day.If the logs bother you then install fail2ban and configure it to lock people out after a few bad guesses.
(Then be ready to unlock yourself from an alternate IP when you inevitably lock yourself out.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31397230</id>
	<title>Mod parent up funny -- oh wait</title>
	<author>ansak</author>
	<datestamp>1267981800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I already see it as a 5. Oh well... "I get thousands of Chinese hackers attempting to break into the battery monitor..." I'm still laughing.</htmltext>
<tokenext>I already see it as a 5 .
Oh well... " I get thousands of Chinese hackers attempting to break into the battery monitor... " I 'm still laughing .</tokentext>
<sentencetext>I already see it as a 5.
Oh well... "I get thousands of Chinese hackers attempting to break into the battery monitor..." I'm still laughing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388816</id>
	<title>DenyHosts</title>
	<author>frambris</author>
	<datestamp>1267971840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>We use DenyHosts, a program watching your secure-log for failed logins and after a few of those adds their IP to<nobr> <wbr></nobr>/etc/hosts.deny. It can also sync with a central repository.</htmltext>
<tokenext>We use DenyHosts , a program watching your secure-log for failed logins and after a few of those adds their IP to /etc/hosts.deny .
It can also sync with a central repository .</tokentext>
<sentencetext>We use DenyHosts, a program watching your secure-log for failed logins and after a few of those adds their IP to /etc/hosts.deny.
It can also sync with a central repository.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398792</id>
	<title>Re:fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1268046540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>DoS protection software:</p><p>http://protobalance.com/</p><p>load balancers do exactly this - you can limit the number of connection attempts per second</p><p>-paul</p></htmltext>
<tokenext>DoS protection software : http : //protobalance.com/load balancers do exactly this - you can limit the number of connection attempts per second-paul</tokentext>
<sentencetext>DoS protection software:http://protobalance.com/load balancers do exactly this - you can limit the number of connection attempts per second-paul</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214</id>
	<title>Move to a higher order port and use denyhosts</title>
	<author>Anonymous</author>
	<datestamp>1267884420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>I use one or more of these on my public facing servers.<br>1. Move the default ssh port to a higher order port (5000+)<br>2. Use Denyhosts <a href="http://denyhosts.sourceforge.net/" title="sourceforge.net">http://denyhosts.sourceforge.net/</a> [sourceforge.net] to block repeated attempts<br>3. use key exchange instead of username/password<br>4. use network based IPS.<br>Just moving the ssh port reduced the ssh brute force attack for me. Either stop being a noob or hire a sys admin.</p></htmltext>
<tokenext>I use one or more of these on my public facing servers.1 .
Move the default ssh port to a higher order port ( 5000 + ) 2 .
Use Denyhosts http : //denyhosts.sourceforge.net/ [ sourceforge.net ] to block repeated attempts3 .
use key exchange instead of username/password4 .
use network based IPS.Just moving the ssh port reduced the ssh brute force attack for me .
Either stop being a noob or hire a sys admin .</tokentext>
<sentencetext>I use one or more of these on my public facing servers.1.
Move the default ssh port to a higher order port (5000+)2.
Use Denyhosts http://denyhosts.sourceforge.net/ [sourceforge.net] to block repeated attempts3.
use key exchange instead of username/password4.
use network based IPS.Just moving the ssh port reduced the ssh brute force attack for me.
Either stop being a noob or hire a sys admin.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31423652</id>
	<title>Mobile OTP</title>
	<author>Anonymous</author>
	<datestamp>1268252820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I am wondering why no one did not mention OTP solutions as well?<br>You can have Mobile OTP. Also Port Knocking or SPA with SSH certificates.</p></htmltext>
<tokenext>I am wondering why no one did not mention OTP solutions as well ? You can have Mobile OTP .
Also Port Knocking or SPA with SSH certificates .</tokentext>
<sentencetext>I am wondering why no one did not mention OTP solutions as well?You can have Mobile OTP.
Also Port Knocking or SPA with SSH certificates.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385702</id>
	<title>Good methods</title>
	<author>hmmdar</author>
	<datestamp>1267888440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A good method would be to configure your iptables to drop all packets that come in from a new connection on all ports by default, and only allow through the specific ports you want the outside world to have access to.

It is also an extremely good idea to move the ssh port higher than 5k.  With the right iptable  rules you can configure your system to ignore repeat attacks at the kernel level.

And for the love of all that is good do not use passwords use key auth only, and disable root ssh login.</htmltext>
<tokenext>A good method would be to configure your iptables to drop all packets that come in from a new connection on all ports by default , and only allow through the specific ports you want the outside world to have access to .
It is also an extremely good idea to move the ssh port higher than 5k .
With the right iptable rules you can configure your system to ignore repeat attacks at the kernel level .
And for the love of all that is good do not use passwords use key auth only , and disable root ssh login .</tokentext>
<sentencetext>A good method would be to configure your iptables to drop all packets that come in from a new connection on all ports by default, and only allow through the specific ports you want the outside world to have access to.
It is also an extremely good idea to move the ssh port higher than 5k.
With the right iptable  rules you can configure your system to ignore repeat attacks at the kernel level.
And for the love of all that is good do not use passwords use key auth only, and disable root ssh login.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386448</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267896360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>I'm a big fan of tarpitting SSH connections myself. It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.</p><p>Basically, an iptables rule:<br>-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP</p></div><p>Or better, change ssh port, and use iptables tar option on port 22</p></div>
	</htmltext>
<tokenext>I 'm a big fan of tarpitting SSH connections myself .
It dramatically cuts down on the repeated ssh attempts , and keeps my logs much cleaner.Basically , an iptables rule : -A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROPOr better , change ssh port , and use iptables tar option on port 22</tokentext>
<sentencetext>I'm a big fan of tarpitting SSH connections myself.
It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.Basically, an iptables rule:-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROPOr better, change ssh port, and use iptables tar option on port 22
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385292</id>
	<title>An iptables recipie</title>
	<author>Simon Carr</author>
	<datestamp>1267884900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT<br>-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j LOG --log-prefix "SSH\_brute\_force "<br>-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROP</p><p>Stops 'em *somewhat* dead.  If you want to whitelist hosts so they are not impacted by this rule, just add;</p><p>-A INPUT -s your.ip.address -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT</p><p>Before the throttling ruleset.</p></htmltext>
<tokenext>-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j LOG --log-prefix " SSH \ _brute \ _force " -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROPStops 'em * somewhat * dead .
If you want to whitelist hosts so they are not impacted by this rule , just add ; -A INPUT -s your.ip.address -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPTBefore the throttling ruleset .</tokentext>
<sentencetext>-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j LOG --log-prefix "SSH\_brute\_force "-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROPStops 'em *somewhat* dead.
If you want to whitelist hosts so they are not impacted by this rule, just add;-A INPUT -s your.ip.address -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPTBefore the throttling ruleset.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387042</id>
	<title>some perspective maybe</title>
	<author>Anonymous</author>
	<datestamp>1267903560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There are lots of comments here and I doubt "Anonymous Coward" will make for a respectable post, but here goes anyway on my experiences.</p><p>- So, random passwords are a good start. My experience has been that most attacks on my systems start with specific organized password hacks.<br>- I don't agree with using off-the-wall port numbers or things like port-knocking. Here is why: When I connect to a standard port number for a specific service with an established site, I do have the impression that security is usually addressed and that malicious attacks will get nowhere. When I connect to a non-standard port or use port-knocking or whatever on an established site, I have the impression that the sys-admins don't know jack about real security, that they are scared, and that "security through obscurity" has become the main line of defense. I'd much rather put things out in the open and show a locked door, than give the impression of an unlocked door that is hidden.<br>- fail2ban, as others have mentioned, is a great tool. By default, it will only ban an IP for 10 minutes or so... which is more than enough time to cause the attacking machine to effectively lose interest. But, if you want to make sure other machines on your network are protected, a plan on action could be as follows: I run fail2ban on multiple machines and tally the results daily with logwatch, the corresponding bad IP addresses are taken (there are usually not many) and blocked using hosts.deny on each machine. I've found over and over again that this drastically limits the amount of malicious traffic that I get attacking multiple machines.<br>- An obvious point from above is to disable root via ssh. This doesn't disable your specific login's super user root access, btw.<br>- If you find that you are attacked more from specific domains (and you do have the ability to address entire domains and subnets with most of these options) and it causes system resource problems, then try to understand how your machines are communicating with the attacking machines... which are 100\% of the time scripted. Using the TARPIT option in IPTABLES may be a good approach here. The main advantage that a script has in attacking your machines is that it can blow through multiple attempts in a short time... and so you basically drag it out so the script becomes useless or until the script thinks your machine is not responding.</p></htmltext>
<tokenext>There are lots of comments here and I doubt " Anonymous Coward " will make for a respectable post , but here goes anyway on my experiences.- So , random passwords are a good start .
My experience has been that most attacks on my systems start with specific organized password hacks.- I do n't agree with using off-the-wall port numbers or things like port-knocking .
Here is why : When I connect to a standard port number for a specific service with an established site , I do have the impression that security is usually addressed and that malicious attacks will get nowhere .
When I connect to a non-standard port or use port-knocking or whatever on an established site , I have the impression that the sys-admins do n't know jack about real security , that they are scared , and that " security through obscurity " has become the main line of defense .
I 'd much rather put things out in the open and show a locked door , than give the impression of an unlocked door that is hidden.- fail2ban , as others have mentioned , is a great tool .
By default , it will only ban an IP for 10 minutes or so... which is more than enough time to cause the attacking machine to effectively lose interest .
But , if you want to make sure other machines on your network are protected , a plan on action could be as follows : I run fail2ban on multiple machines and tally the results daily with logwatch , the corresponding bad IP addresses are taken ( there are usually not many ) and blocked using hosts.deny on each machine .
I 've found over and over again that this drastically limits the amount of malicious traffic that I get attacking multiple machines.- An obvious point from above is to disable root via ssh .
This does n't disable your specific login 's super user root access , btw.- If you find that you are attacked more from specific domains ( and you do have the ability to address entire domains and subnets with most of these options ) and it causes system resource problems , then try to understand how your machines are communicating with the attacking machines... which are 100 \ % of the time scripted .
Using the TARPIT option in IPTABLES may be a good approach here .
The main advantage that a script has in attacking your machines is that it can blow through multiple attempts in a short time... and so you basically drag it out so the script becomes useless or until the script thinks your machine is not responding .</tokentext>
<sentencetext>There are lots of comments here and I doubt "Anonymous Coward" will make for a respectable post, but here goes anyway on my experiences.- So, random passwords are a good start.
My experience has been that most attacks on my systems start with specific organized password hacks.- I don't agree with using off-the-wall port numbers or things like port-knocking.
Here is why: When I connect to a standard port number for a specific service with an established site, I do have the impression that security is usually addressed and that malicious attacks will get nowhere.
When I connect to a non-standard port or use port-knocking or whatever on an established site, I have the impression that the sys-admins don't know jack about real security, that they are scared, and that "security through obscurity" has become the main line of defense.
I'd much rather put things out in the open and show a locked door, than give the impression of an unlocked door that is hidden.- fail2ban, as others have mentioned, is a great tool.
By default, it will only ban an IP for 10 minutes or so... which is more than enough time to cause the attacking machine to effectively lose interest.
But, if you want to make sure other machines on your network are protected, a plan on action could be as follows: I run fail2ban on multiple machines and tally the results daily with logwatch, the corresponding bad IP addresses are taken (there are usually not many) and blocked using hosts.deny on each machine.
I've found over and over again that this drastically limits the amount of malicious traffic that I get attacking multiple machines.- An obvious point from above is to disable root via ssh.
This doesn't disable your specific login's super user root access, btw.- If you find that you are attacked more from specific domains (and you do have the ability to address entire domains and subnets with most of these options) and it causes system resource problems, then try to understand how your machines are communicating with the attacking machines... which are 100\% of the time scripted.
Using the TARPIT option in IPTABLES may be a good approach here.
The main advantage that a script has in attacking your machines is that it can blow through multiple attempts in a short time... and so you basically drag it out so the script becomes useless or until the script thinks your machine is not responding.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385498</id>
	<title>Working as intended.</title>
	<author>Schraegstrichpunkt</author>
	<datestamp>1267886220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><ul>
<li>Protocol 2</li><li>Set PermitRootLogin to "no" or "without-password"</li><li>ChallengeResponseAuthentication no</li><li>PasswordAuthentication no</li></ul><p>

And then just ignore the attempts.  fail2ban can sometimes be ok, but be aware that it creates a denial-of-service vulnerability that is exploitable by attackers who can can spoof source addresses.</p></htmltext>
<tokenext>Protocol 2Set PermitRootLogin to " no " or " without-password " ChallengeResponseAuthentication noPasswordAuthentication no And then just ignore the attempts .
fail2ban can sometimes be ok , but be aware that it creates a denial-of-service vulnerability that is exploitable by attackers who can can spoof source addresses .</tokentext>
<sentencetext>
Protocol 2Set PermitRootLogin to "no" or "without-password"ChallengeResponseAuthentication noPasswordAuthentication no

And then just ignore the attempts.
fail2ban can sometimes be ok, but be aware that it creates a denial-of-service vulnerability that is exploitable by attackers who can can spoof source addresses.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144</id>
	<title>fwknop</title>
	<author>Anonymous</author>
	<datestamp>1267883880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>They can't fail authentication if they don't know it's there.

<a href="http://cipherdyne.org/fwknop/" title="cipherdyne.org">http://cipherdyne.org/fwknop/</a> [cipherdyne.org]</htmltext>
<tokenext>They ca n't fail authentication if they do n't know it 's there .
http : //cipherdyne.org/fwknop/ [ cipherdyne.org ]</tokentext>
<sentencetext>They can't fail authentication if they don't know it's there.
http://cipherdyne.org/fwknop/ [cipherdyne.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390062</id>
	<title>Re:OpenBSD PF</title>
	<author>dissy</author>
	<datestamp>1267978740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>you know what I am saying?</i></p><p>You down with BSD, yea you know me?</p><p>(Sorry, sorry...)</p></htmltext>
<tokenext>you know what I am saying ? You down with BSD , yea you know me ?
( Sorry , sorry... )</tokentext>
<sentencetext>you know what I am saying?You down with BSD, yea you know me?
(Sorry, sorry...)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484</id>
	<title>Re:Tar Pitting</title>
	<author>cptdondo</author>
	<datestamp>1267886100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>That, and create only a single user who can log in, that takes you to the real log in prompt.  That way an attacker has to guess the one user+password, and have a legitimate userid+password to gain access.</p><p>It's not foolproof, but it foils the vast majority of script attackers.</p><p>And DISABLE ROOT LOGIN!</p></htmltext>
<tokenext>That , and create only a single user who can log in , that takes you to the real log in prompt .
That way an attacker has to guess the one user + password , and have a legitimate userid + password to gain access.It 's not foolproof , but it foils the vast majority of script attackers.And DISABLE ROOT LOGIN !</tokentext>
<sentencetext>That, and create only a single user who can log in, that takes you to the real log in prompt.
That way an attacker has to guess the one user+password, and have a legitimate userid+password to gain access.It's not foolproof, but it foils the vast majority of script attackers.And DISABLE ROOT LOGIN!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386208</id>
	<title>Basic network security</title>
	<author>JWSmythe</author>
	<datestamp>1267893480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><tt> First, hire someone who knows what they're doing. You just posted to a pool of roughly 1 million technical folks, and at least a couple hundred thousand who know what they're doing. A good percentage of them are unemployed or underemployed right now.<br> <br> Changing the SSH port is an excellent idea. Folks scan huge swaths of the Internet looking for ports with services that they expect. Leave SSH on port 22, they'll assume you haven't done much for security and have a chance of exploiting a buggy version or finding an easy password. I knew someone who allowed root logins, with the password of "password" with SSH on port 22. The box was compromised within days.<br> <br> These folks generally go for low hanging fruit. Let that be someone else.<br> <br> Make your machines invisible. Well, almost invisible. Make them so they won't ping, and won't respond to anything but an authorized request. Tools like nmap default to ICMP pings first, and then will follow up with a detailed port scan. If you have high visibility sites, you'll still get curious people who look hard to find something. Make it impossible for them to get to anything sensitive.<br> <br> Set up iptables (or the firewall applicable for your platform) is essential for security. Here's a little script that I used for a long time. Networks and some ports have been modified to protect the guilty^H^H^H^H^H^H innocent. This script is for Linux. It may require modification for your platform. The general idea will apply to any *nix platform. Modify as necessary. I had an ipchains version, but that was retired long ago. You may want to add to your enemies list (in the code below) automatically based on some honeypot services. Maybe code up a little something as an inetd process that simply appends their IP to enemies.list (and distributes to your peers) if someone tries to SSH in on port 22. Use that with caution though. It's a shame when you lock out yourself accidentally.<br> <br> You could either start DROP rules on the fly, or work up the list automagically and have this script rerun at an interval (every 5 minutes, ever hour, every week, whatever suits your tastes).<br> <br>#!/usr/bin/perl<br># rc.firewall<br># secure yer webserver<br># (c) 2010 - JWSmythe<br># Free to reproduce and modify with attribution.<br> <br># Publicly accessible ports. These are any ports you want the general public to hit.<br>@pub\_ports  = (<br>         "80", # HTTP<br>         "443", # HTTPS<br>         "8080" # Streaming something<br>        );<br> <br># These are private ports. Only our private\_net users. Any other ports will be completely inaccessible.<br>@private\_ports = (<br>         "22222", # Our SSH port<br>         "33066" # Our DB port<br>        );<br> <br># Permitted Networks/Hosts.<br># Use / subnet notation<br># Use the smallest subnet possible.<br> <br>@private\_net = (<br>        "192.168.1.0/24", # Where our servers are<br>        "198.81.129.0/24", # Another companion network<br>        "63.97.94.0/24", # Someone else that works with us.<br>        "216.34.181.45", # home<br>        );<br> <br># These are known enemies. You can collect these<br>$enemy\_list = "/etc/firewall/enemies.list";<br> <br>#<br># Normally you won't modify beyond here.<br>#</tt></htmltext>
<tokenext>First , hire someone who knows what they 're doing .
You just posted to a pool of roughly 1 million technical folks , and at least a couple hundred thousand who know what they 're doing .
A good percentage of them are unemployed or underemployed right now .
Changing the SSH port is an excellent idea .
Folks scan huge swaths of the Internet looking for ports with services that they expect .
Leave SSH on port 22 , they 'll assume you have n't done much for security and have a chance of exploiting a buggy version or finding an easy password .
I knew someone who allowed root logins , with the password of " password " with SSH on port 22 .
The box was compromised within days .
These folks generally go for low hanging fruit .
Let that be someone else .
Make your machines invisible .
Well , almost invisible .
Make them so they wo n't ping , and wo n't respond to anything but an authorized request .
Tools like nmap default to ICMP pings first , and then will follow up with a detailed port scan .
If you have high visibility sites , you 'll still get curious people who look hard to find something .
Make it impossible for them to get to anything sensitive .
Set up iptables ( or the firewall applicable for your platform ) is essential for security .
Here 's a little script that I used for a long time .
Networks and some ports have been modified to protect the guilty ^ H ^ H ^ H ^ H ^ H ^ H innocent .
This script is for Linux .
It may require modification for your platform .
The general idea will apply to any * nix platform .
Modify as necessary .
I had an ipchains version , but that was retired long ago .
You may want to add to your enemies list ( in the code below ) automatically based on some honeypot services .
Maybe code up a little something as an inetd process that simply appends their IP to enemies.list ( and distributes to your peers ) if someone tries to SSH in on port 22 .
Use that with caution though .
It 's a shame when you lock out yourself accidentally .
You could either start DROP rules on the fly , or work up the list automagically and have this script rerun at an interval ( every 5 minutes , ever hour , every week , whatever suits your tastes ) .
# ! /usr/bin/perl # rc.firewall # secure yer webserver # ( c ) 2010 - JWSmythe # Free to reproduce and modify with attribution .
# Publicly accessible ports .
These are any ports you want the general public to hit .
@ pub \ _ports = ( " 80 " , # HTTP " 443 " , # HTTPS " 8080 " # Streaming something ) ; # These are private ports .
Only our private \ _net users .
Any other ports will be completely inaccessible .
@ private \ _ports = ( " 22222 " , # Our SSH port " 33066 " # Our DB port ) ; # Permitted Networks/Hosts. # Use / subnet notation # Use the smallest subnet possible .
@ private \ _net = ( " 192.168.1.0/24 " , # Where our servers are " 198.81.129.0/24 " , # Another companion network " 63.97.94.0/24 " , # Someone else that works with us .
" 216.34.181.45 " , # home ) ; # These are known enemies .
You can collect these $ enemy \ _list = " /etc/firewall/enemies.list " ; # # Normally you wo n't modify beyond here. #</tokentext>
<sentencetext> First, hire someone who knows what they're doing.
You just posted to a pool of roughly 1 million technical folks, and at least a couple hundred thousand who know what they're doing.
A good percentage of them are unemployed or underemployed right now.
Changing the SSH port is an excellent idea.
Folks scan huge swaths of the Internet looking for ports with services that they expect.
Leave SSH on port 22, they'll assume you haven't done much for security and have a chance of exploiting a buggy version or finding an easy password.
I knew someone who allowed root logins, with the password of "password" with SSH on port 22.
The box was compromised within days.
These folks generally go for low hanging fruit.
Let that be someone else.
Make your machines invisible.
Well, almost invisible.
Make them so they won't ping, and won't respond to anything but an authorized request.
Tools like nmap default to ICMP pings first, and then will follow up with a detailed port scan.
If you have high visibility sites, you'll still get curious people who look hard to find something.
Make it impossible for them to get to anything sensitive.
Set up iptables (or the firewall applicable for your platform) is essential for security.
Here's a little script that I used for a long time.
Networks and some ports have been modified to protect the guilty^H^H^H^H^H^H innocent.
This script is for Linux.
It may require modification for your platform.
The general idea will apply to any *nix platform.
Modify as necessary.
I had an ipchains version, but that was retired long ago.
You may want to add to your enemies list (in the code below) automatically based on some honeypot services.
Maybe code up a little something as an inetd process that simply appends their IP to enemies.list (and distributes to your peers) if someone tries to SSH in on port 22.
Use that with caution though.
It's a shame when you lock out yourself accidentally.
You could either start DROP rules on the fly, or work up the list automagically and have this script rerun at an interval (every 5 minutes, ever hour, every week, whatever suits your tastes).
#!/usr/bin/perl# rc.firewall# secure yer webserver# (c) 2010 - JWSmythe# Free to reproduce and modify with attribution.
# Publicly accessible ports.
These are any ports you want the general public to hit.
@pub\_ports  = (         "80", # HTTP         "443", # HTTPS         "8080" # Streaming something        ); # These are private ports.
Only our private\_net users.
Any other ports will be completely inaccessible.
@private\_ports = (         "22222", # Our SSH port         "33066" # Our DB port        ); # Permitted Networks/Hosts.# Use / subnet notation# Use the smallest subnet possible.
@private\_net = (        "192.168.1.0/24", # Where our servers are        "198.81.129.0/24", # Another companion network        "63.97.94.0/24", # Someone else that works with us.
"216.34.181.45", # home        ); # These are known enemies.
You can collect these$enemy\_list = "/etc/firewall/enemies.list"; ## Normally you won't modify beyond here.#</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385884</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267890300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's asking for a dos attack though, send thousands of connection attempts to port 22 and the server will end up holding them for eternity until port/connection exhaustion.</p></htmltext>
<tokenext>That 's asking for a dos attack though , send thousands of connection attempts to port 22 and the server will end up holding them for eternity until port/connection exhaustion .</tokentext>
<sentencetext>That's asking for a dos attack though, send thousands of connection attempts to port 22 and the server will end up holding them for eternity until port/connection exhaustion.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390538</id>
	<title>Re:You are being brute-forced</title>
	<author>awyeah</author>
	<datestamp>1267981620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I still see failed login attempts on my non-standard ssh port.  Not nearly as many, though.  Anecdotal evidence... but still.</p></htmltext>
<tokenext>I still see failed login attempts on my non-standard ssh port .
Not nearly as many , though .
Anecdotal evidence... but still .</tokentext>
<sentencetext>I still see failed login attempts on my non-standard ssh port.
Not nearly as many, though.
Anecdotal evidence... but still.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385800</id>
	<title>Changing the Port should be just fine</title>
	<author>Gypsy2012</author>
	<datestamp>1267889580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Serious, I shifted my port for ssh several years ago. I have yet to see a failed attempt that wasn't a legitimate user who screwed up since I changed.

Sure, I know that someone could be port scanning and stuff, but really, I just don't see it happening.</htmltext>
<tokenext>Serious , I shifted my port for ssh several years ago .
I have yet to see a failed attempt that was n't a legitimate user who screwed up since I changed .
Sure , I know that someone could be port scanning and stuff , but really , I just do n't see it happening .</tokentext>
<sentencetext>Serious, I shifted my port for ssh several years ago.
I have yet to see a failed attempt that wasn't a legitimate user who screwed up since I changed.
Sure, I know that someone could be port scanning and stuff, but really, I just don't see it happening.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385254</id>
	<title>Re:Tar Pitting</title>
	<author>jonesy2k</author>
	<datestamp>1267884660000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>That's not tarpitting. Tarpitting involves keeping the connection open in order to tie up the resources of the attacking host.</htmltext>
<tokenext>That 's not tarpitting .
Tarpitting involves keeping the connection open in order to tie up the resources of the attacking host .</tokentext>
<sentencetext>That's not tarpitting.
Tarpitting involves keeping the connection open in order to tie up the resources of the attacking host.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388398</id>
	<title>Too many issues...</title>
	<author>RichM</author>
	<datestamp>1267966800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Drupal, WordPress, and Joomla</p></div></blockquote><p>

You have bigger security problems than SSH.</p></div>
	</htmltext>
<tokenext>Drupal , WordPress , and Joomla You have bigger security problems than SSH .</tokentext>
<sentencetext>Drupal, WordPress, and Joomla

You have bigger security problems than SSH.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</id>
	<title>Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267883700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>I'm a big fan of tarpitting SSH connections myself. It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.</p><p>Basically, an iptables rule:<br>-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP</p></htmltext>
<tokenext>I 'm a big fan of tarpitting SSH connections myself .
It dramatically cuts down on the repeated ssh attempts , and keeps my logs much cleaner.Basically , an iptables rule : -A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP</tokentext>
<sentencetext>I'm a big fan of tarpitting SSH connections myself.
It dramatically cuts down on the repeated ssh attempts, and keeps my logs much cleaner.Basically, an iptables rule:-A INPUTCHAIN -m state --state NEW -m recent -p tcp --dport 22 --update --seconds 30 --hitcount 4 --rttl --name SSH -j DROP</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389056</id>
	<title>Do *NOT* use a password with ssh!</title>
	<author>cptdondo</author>
	<datestamp>1267972980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, that works as long as you never, ever have to log in to from a random terminal.  Which I do.</p><p>And if your laptop gets stolen, then your key gets stolen with it.  Ditto USB stick, etc.</p><p>So pubic key is less vulnerable to brute force attacks, but more vulnerable to physical attacks.  Pick which one you want.</p></htmltext>
<tokenext>Well , that works as long as you never , ever have to log in to from a random terminal .
Which I do.And if your laptop gets stolen , then your key gets stolen with it .
Ditto USB stick , etc.So pubic key is less vulnerable to brute force attacks , but more vulnerable to physical attacks .
Pick which one you want .</tokentext>
<sentencetext>Well, that works as long as you never, ever have to log in to from a random terminal.
Which I do.And if your laptop gets stolen, then your key gets stolen with it.
Ditto USB stick, etc.So pubic key is less vulnerable to brute force attacks, but more vulnerable to physical attacks.
Pick which one you want.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31399752</id>
	<title>Re:Move to a higher order port and use denyhosts</title>
	<author>ladadadada</author>
	<datestamp>1268058360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My thoughts on these suggestions:</p><ol>
<li>The purpose of changing the port is not security (a simple portscan will undo that) but reduction of logged error messages while still allowing all IP addresses anywhere to SSH to the machine.</li><li>The port you choose is important.  At one place I worked we used port 10000.  This is already used for Webmin (although we never used Webmin) and hence we got thousands of Webmin brute force attacks against our SSH port.  They could never have been successful but it didn't cut down on the logged error messages very much.</li><li>Denyhosts and Fail2ban both have the ability to be quite nasty on false positives and are rather prone to them.  Amongst all the suggestions above to use these products, I would also add to make sure you whitelist a place you can always get access to.  You should also have an out-of-band communication method with your servers.  That way, when you do finally get locked out of your own server by your security tool, you know how to get in and fix the problem.  The same goes for an IPS if you install one.  Make sure you can still access it when it decides you are an intruder.</li><li>Check your SSH error log to make sure something like denyhosts or fail2ban would even be of any use.  I have seen plenty of brute force attempts where each IP address only tries three different username/password combinations and then moves on to another server.  Then another picks up where the first one left off.  These guys wouldn't even notice if you were using fail2ban.  Sharing your denyhosts with the denyhosts site might help.  You could use the shared denyhosts block lists to configure fail2ban if you preferred it.</li></ol><p>And to the original poster who gets a million per year across 50 or so domains... I got a new box installed a few weeks ago that had 45,000 attempts in the three days it was online before my ISP gave me the IP address.  That's a million attempts about every two months.  Per server.  You have only yet seen the tip of the iceberg.</p></htmltext>
<tokenext>My thoughts on these suggestions : The purpose of changing the port is not security ( a simple portscan will undo that ) but reduction of logged error messages while still allowing all IP addresses anywhere to SSH to the machine.The port you choose is important .
At one place I worked we used port 10000 .
This is already used for Webmin ( although we never used Webmin ) and hence we got thousands of Webmin brute force attacks against our SSH port .
They could never have been successful but it did n't cut down on the logged error messages very much.Denyhosts and Fail2ban both have the ability to be quite nasty on false positives and are rather prone to them .
Amongst all the suggestions above to use these products , I would also add to make sure you whitelist a place you can always get access to .
You should also have an out-of-band communication method with your servers .
That way , when you do finally get locked out of your own server by your security tool , you know how to get in and fix the problem .
The same goes for an IPS if you install one .
Make sure you can still access it when it decides you are an intruder.Check your SSH error log to make sure something like denyhosts or fail2ban would even be of any use .
I have seen plenty of brute force attempts where each IP address only tries three different username/password combinations and then moves on to another server .
Then another picks up where the first one left off .
These guys would n't even notice if you were using fail2ban .
Sharing your denyhosts with the denyhosts site might help .
You could use the shared denyhosts block lists to configure fail2ban if you preferred it.And to the original poster who gets a million per year across 50 or so domains... I got a new box installed a few weeks ago that had 45,000 attempts in the three days it was online before my ISP gave me the IP address .
That 's a million attempts about every two months .
Per server .
You have only yet seen the tip of the iceberg .</tokentext>
<sentencetext>My thoughts on these suggestions:
The purpose of changing the port is not security (a simple portscan will undo that) but reduction of logged error messages while still allowing all IP addresses anywhere to SSH to the machine.The port you choose is important.
At one place I worked we used port 10000.
This is already used for Webmin (although we never used Webmin) and hence we got thousands of Webmin brute force attacks against our SSH port.
They could never have been successful but it didn't cut down on the logged error messages very much.Denyhosts and Fail2ban both have the ability to be quite nasty on false positives and are rather prone to them.
Amongst all the suggestions above to use these products, I would also add to make sure you whitelist a place you can always get access to.
You should also have an out-of-band communication method with your servers.
That way, when you do finally get locked out of your own server by your security tool, you know how to get in and fix the problem.
The same goes for an IPS if you install one.
Make sure you can still access it when it decides you are an intruder.Check your SSH error log to make sure something like denyhosts or fail2ban would even be of any use.
I have seen plenty of brute force attempts where each IP address only tries three different username/password combinations and then moves on to another server.
Then another picks up where the first one left off.
These guys wouldn't even notice if you were using fail2ban.
Sharing your denyhosts with the denyhosts site might help.
You could use the shared denyhosts block lists to configure fail2ban if you preferred it.And to the original poster who gets a million per year across 50 or so domains... I got a new box installed a few weeks ago that had 45,000 attempts in the three days it was online before my ISP gave me the IP address.
That's a million attempts about every two months.
Per server.
You have only yet seen the tip of the iceberg.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385104</id>
	<title>Ignore it?</title>
	<author>Anonymous</author>
	<datestamp>1267883700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you have a public site, it'll get scanned night and day by APNIC. If they see a banner for SSH, they'll jump on that. As long as you are using patched software and have good user security, what's the real emergency?</p></htmltext>
<tokenext>If you have a public site , it 'll get scanned night and day by APNIC .
If they see a banner for SSH , they 'll jump on that .
As long as you are using patched software and have good user security , what 's the real emergency ?</tokentext>
<sentencetext>If you have a public site, it'll get scanned night and day by APNIC.
If they see a banner for SSH, they'll jump on that.
As long as you are using patched software and have good user security, what's the real emergency?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31404848</id>
	<title>Re:Lock it down.</title>
	<author>BitZtream</author>
	<datestamp>1268040720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.</p></div></blockquote><p>Ahhhh spoken like the voice of someone parroting what they read on someone elses website.</p><p>After a few years of writing cryptography software, let me give you a little hint.  Its ALL security through obscurity.  TCP ports only allow for 65k possible options so its an easy guess.  You can follow the same process to break AES encryption, it just takes a lot longer to guess.</p><p>Its all security through obscurity, its just a question of how obscure the knowledge required to break it is.</p></div>
	</htmltext>
<tokenext>Do n't bother changing it to some random port , security through obscurity is total bullshit in this age of port scanners.Ahhhh spoken like the voice of someone parroting what they read on someone elses website.After a few years of writing cryptography software , let me give you a little hint .
Its ALL security through obscurity .
TCP ports only allow for 65k possible options so its an easy guess .
You can follow the same process to break AES encryption , it just takes a lot longer to guess.Its all security through obscurity , its just a question of how obscure the knowledge required to break it is .</tokentext>
<sentencetext>Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.Ahhhh spoken like the voice of someone parroting what they read on someone elses website.After a few years of writing cryptography software, let me give you a little hint.
Its ALL security through obscurity.
TCP ports only allow for 65k possible options so its an easy guess.
You can follow the same process to break AES encryption, it just takes a lot longer to guess.Its all security through obscurity, its just a question of how obscure the knowledge required to break it is.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392988</id>
	<title>Re:fail2ban</title>
	<author>segedunum</author>
	<datestamp>1267995180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>No but they can steal if from your users' computers.</p></div></blockquote><p>
How? How would they know what client machine to attack or steal and how would they know where it was? Additionally, would you say the chances of that are less or greater than a compromise being found via a normal dictionary attack that the <b>article</b> is actually talking about mitigating?</p><blockquote><div><p>It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client.</p></div></blockquote><p>
Hmmmmm, and there was me thinking that users used these insecure things called 'passwords' all the time, many of which can actually be guessed without going anywhere near their client machines.</p><blockquote><div><p>For remote access one of the securest ways is using a security token. Every time user logs in they have to enter a different number.</p></div></blockquote><p>
Possibly, but you're going to have to point out a way for the article submitter to be able to do that <i>today</i> and manage it without becoming a nightmare.<br> <br>

All in all, I don't know where this thread is going to be honest. Given the alternative problems with passwords that the article submitter is presumably trying to mitigate then SSH keys are infinitely more preferable. Pointing out potential and theoretical weaknesses with them won't change that.</p></div>
	</htmltext>
<tokenext>No but they can steal if from your users ' computers .
How ? How would they know what client machine to attack or steal and how would they know where it was ?
Additionally , would you say the chances of that are less or greater than a compromise being found via a normal dictionary attack that the article is actually talking about mitigating ? It 's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you ca n't control the security on their machines is only as secure as your dumbest client .
Hmmmmm , and there was me thinking that users used these insecure things called 'passwords ' all the time , many of which can actually be guessed without going anywhere near their client machines.For remote access one of the securest ways is using a security token .
Every time user logs in they have to enter a different number .
Possibly , but you 're going to have to point out a way for the article submitter to be able to do that today and manage it without becoming a nightmare .
All in all , I do n't know where this thread is going to be honest .
Given the alternative problems with passwords that the article submitter is presumably trying to mitigate then SSH keys are infinitely more preferable .
Pointing out potential and theoretical weaknesses with them wo n't change that .</tokentext>
<sentencetext>No but they can steal if from your users' computers.
How? How would they know what client machine to attack or steal and how would they know where it was?
Additionally, would you say the chances of that are less or greater than a compromise being found via a normal dictionary attack that the article is actually talking about mitigating?It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client.
Hmmmmm, and there was me thinking that users used these insecure things called 'passwords' all the time, many of which can actually be guessed without going anywhere near their client machines.For remote access one of the securest ways is using a security token.
Every time user logs in they have to enter a different number.
Possibly, but you're going to have to point out a way for the article submitter to be able to do that today and manage it without becoming a nightmare.
All in all, I don't know where this thread is going to be honest.
Given the alternative problems with passwords that the article submitter is presumably trying to mitigate then SSH keys are infinitely more preferable.
Pointing out potential and theoretical weaknesses with them won't change that.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386896</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385910</id>
	<title>Re:You are being brute-forced</title>
	<author>Anonymous</author>
	<datestamp>1267890540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>It won't do a whole lot for you</p></div><p>While I don't agree with security (solely) through obscurity, this statement is bunk.  I have SSH on my home server (public key auth only), and with port 22 I was seeing thousands of login attempts from East-Asian IP blocks.  After moving to an easy-to-remember port over 50000, I no longer get any attempts.</p></div>
	</htmltext>
<tokenext>It wo n't do a whole lot for youWhile I do n't agree with security ( solely ) through obscurity , this statement is bunk .
I have SSH on my home server ( public key auth only ) , and with port 22 I was seeing thousands of login attempts from East-Asian IP blocks .
After moving to an easy-to-remember port over 50000 , I no longer get any attempts .</tokentext>
<sentencetext>It won't do a whole lot for youWhile I don't agree with security (solely) through obscurity, this statement is bunk.
I have SSH on my home server (public key auth only), and with port 22 I was seeing thousands of login attempts from East-Asian IP blocks.
After moving to an easy-to-remember port over 50000, I no longer get any attempts.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388050</id>
	<title>Re:Move to a higher order port and use denyhosts</title>
	<author>Anonymous</author>
	<datestamp>1267961760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><i>1. Move the default ssh port to a higher order port (5000+)</i>
<p>
Are you sure? I would recommend at least over 9000!!
</p></htmltext>
<tokenext>1 .
Move the default ssh port to a higher order port ( 5000 + ) Are you sure ?
I would recommend at least over 9000 !
!</tokentext>
<sentencetext>1.
Move the default ssh port to a higher order port (5000+)

Are you sure?
I would recommend at least over 9000!
!
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386338</id>
	<title>Nothing.</title>
	<author>Alex Belits</author>
	<datestamp>1267894920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Computer security can not be achieved by responding to attacks. It's achieved by not being vulnerable to them.</p><p>Attacks may happen at any moment, and may target anything -- nothing that happened in the past can predict what might happen in the future considering that any host on the Internet can talk to your server. The amount of connection would matter if it is high enough to produce a DoS attack or number of attempt is so high, a brute force password guessing becomes viable. You are so far from both, pretty much any action you can perform would DECREASE the security because attackers might find a way to turn it against you. For example, if you block a host that tried to establish too many connections, they may try to spoof your host, so you will end up locking yourself out.</p></htmltext>
<tokenext>Computer security can not be achieved by responding to attacks .
It 's achieved by not being vulnerable to them.Attacks may happen at any moment , and may target anything -- nothing that happened in the past can predict what might happen in the future considering that any host on the Internet can talk to your server .
The amount of connection would matter if it is high enough to produce a DoS attack or number of attempt is so high , a brute force password guessing becomes viable .
You are so far from both , pretty much any action you can perform would DECREASE the security because attackers might find a way to turn it against you .
For example , if you block a host that tried to establish too many connections , they may try to spoof your host , so you will end up locking yourself out .</tokentext>
<sentencetext>Computer security can not be achieved by responding to attacks.
It's achieved by not being vulnerable to them.Attacks may happen at any moment, and may target anything -- nothing that happened in the past can predict what might happen in the future considering that any host on the Internet can talk to your server.
The amount of connection would matter if it is high enough to produce a DoS attack or number of attempt is so high, a brute force password guessing becomes viable.
You are so far from both, pretty much any action you can perform would DECREASE the security because attackers might find a way to turn it against you.
For example, if you block a host that tried to establish too many connections, they may try to spoof your host, so you will end up locking yourself out.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385288</id>
	<title>Throttle Inbound Connections</title>
	<author>Padrino121</author>
	<datestamp>1267884900000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>I have a similar situation and cannot limit to very specific IP ranges. I have done the following with good success. I pulled some examples from my configuration that can be tweaked for yours if you like.</p><p>1. Limit incoming SSH attempts to a low number. In my case I limit to 2 connections in 60 seconds. I can tighten it even more but this did a lot to kill brute force attempts.<br>iptables -I INPUT -p tcp -i vlan1 --dport 2242 -j DROP<br>iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state NEW -m limit --limit 2/min -j ACCEPT<br>iptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state RELATED,ESTABLISHED -j ACCEPT</p><p>2. Automatic blacklist via DenyHosts. This helps cut down attempts from known ranges without even giving them the chance even at a slow rate. http://denyhosts.sourceforge.net/</p></htmltext>
<tokenext>I have a similar situation and can not limit to very specific IP ranges .
I have done the following with good success .
I pulled some examples from my configuration that can be tweaked for yours if you like.1 .
Limit incoming SSH attempts to a low number .
In my case I limit to 2 connections in 60 seconds .
I can tighten it even more but this did a lot to kill brute force attempts.iptables -I INPUT -p tcp -i vlan1 --dport 2242 -j DROPiptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state NEW -m limit --limit 2/min -j ACCEPTiptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state RELATED,ESTABLISHED -j ACCEPT2 .
Automatic blacklist via DenyHosts .
This helps cut down attempts from known ranges without even giving them the chance even at a slow rate .
http : //denyhosts.sourceforge.net/</tokentext>
<sentencetext>I have a similar situation and cannot limit to very specific IP ranges.
I have done the following with good success.
I pulled some examples from my configuration that can be tweaked for yours if you like.1.
Limit incoming SSH attempts to a low number.
In my case I limit to 2 connections in 60 seconds.
I can tighten it even more but this did a lot to kill brute force attempts.iptables -I INPUT -p tcp -i vlan1 --dport 2242 -j DROPiptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state NEW -m limit --limit 2/min -j ACCEPTiptables -I INPUT -p tcp -i vlan1 --dport 2242 -m state --state RELATED,ESTABLISHED -j ACCEPT2.
Automatic blacklist via DenyHosts.
This helps cut down attempts from known ranges without even giving them the chance even at a slow rate.
http://denyhosts.sourceforge.net/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385114</id>
	<title>sshblack</title>
	<author>Anonymous</author>
	<datestamp>1267883760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>sshblack works very well for me.  It monitors failed ssh connections and inserts entries into iptables to block the IPs.</p></htmltext>
<tokenext>sshblack works very well for me .
It monitors failed ssh connections and inserts entries into iptables to block the IPs .</tokentext>
<sentencetext>sshblack works very well for me.
It monitors failed ssh connections and inserts entries into iptables to block the IPs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386248</id>
	<title>Stateless access controls, preferably in hardware</title>
	<author>Anonymous</author>
	<datestamp>1267893780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Whether you implement access controls in a stateless firewall appliance or server side with iptables, you will need to accept some measure of responsibility for the security of your infrastructure at some point.  Additional access controls can be introduced through SSH daemon configuration, for example by restricting access to specific users or groups.  Tcpwrappers can also provide an additional layer of protection.</p></htmltext>
<tokenext>Whether you implement access controls in a stateless firewall appliance or server side with iptables , you will need to accept some measure of responsibility for the security of your infrastructure at some point .
Additional access controls can be introduced through SSH daemon configuration , for example by restricting access to specific users or groups .
Tcpwrappers can also provide an additional layer of protection .</tokentext>
<sentencetext>Whether you implement access controls in a stateless firewall appliance or server side with iptables, you will need to accept some measure of responsibility for the security of your infrastructure at some point.
Additional access controls can be introduced through SSH daemon configuration, for example by restricting access to specific users or groups.
Tcpwrappers can also provide an additional layer of protection.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385934</id>
	<title>3 steps</title>
	<author>unity100</author>
	<datestamp>1267890720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1 - Disable direct root login - allow login only with a wheel user that is allowed to su-</p><p>2 - Use hosts\_deny to deny ssh service to any ip other than clients'. you can allow clients' ip ranges in narrow range if they have dynamic ip.</p><p>3 - Change ssh port.</p></htmltext>
<tokenext>1 - Disable direct root login - allow login only with a wheel user that is allowed to su-2 - Use hosts \ _deny to deny ssh service to any ip other than clients' .
you can allow clients ' ip ranges in narrow range if they have dynamic ip.3 - Change ssh port .</tokentext>
<sentencetext>1 - Disable direct root login - allow login only with a wheel user that is allowed to su-2 - Use hosts\_deny to deny ssh service to any ip other than clients'.
you can allow clients' ip ranges in narrow range if they have dynamic ip.3 - Change ssh port.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386018</id>
	<title>SOP</title>
	<author>Hasai</author>
	<datestamp>1267891620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1) Quickest and easiest: Change the port to something oddball.<br>2) Slightly harder: Set iptables to only permit SSH sessions from selected domains.<br>3) Getting geeky: Kill password authentication and force sshd to use certificates only.<br>4) Advanced: Set iptables to DROP IP addresses after three authentication failures within sixty seconds, for sixty seconds.<br>5) Paranoid: 2+3.<br>6) Very paranoid: 2+3+4.<br>7) Go-get-the-guys-in-the-white-suits paranoid: 1+2+3+4.</p><p>#4 is my personal favorite. It only takes about three lines in the iptables settings, and it drives script kiddies crazy when their "leet warez" hang.</p></htmltext>
<tokenext>1 ) Quickest and easiest : Change the port to something oddball.2 ) Slightly harder : Set iptables to only permit SSH sessions from selected domains.3 ) Getting geeky : Kill password authentication and force sshd to use certificates only.4 ) Advanced : Set iptables to DROP IP addresses after three authentication failures within sixty seconds , for sixty seconds.5 ) Paranoid : 2 + 3.6 ) Very paranoid : 2 + 3 + 4.7 ) Go-get-the-guys-in-the-white-suits paranoid : 1 + 2 + 3 + 4. # 4 is my personal favorite .
It only takes about three lines in the iptables settings , and it drives script kiddies crazy when their " leet warez " hang .</tokentext>
<sentencetext>1) Quickest and easiest: Change the port to something oddball.2) Slightly harder: Set iptables to only permit SSH sessions from selected domains.3) Getting geeky: Kill password authentication and force sshd to use certificates only.4) Advanced: Set iptables to DROP IP addresses after three authentication failures within sixty seconds, for sixty seconds.5) Paranoid: 2+3.6) Very paranoid: 2+3+4.7) Go-get-the-guys-in-the-white-suits paranoid: 1+2+3+4.#4 is my personal favorite.
It only takes about three lines in the iptables settings, and it drives script kiddies crazy when their "leet warez" hang.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31402634</id>
	<title>Re:Passwords?</title>
	<author>WindShadow</author>
	<datestamp>1268073840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem with certificates is that there are stored somewhere easier to find than inside someone's head. A certificate is a key anyone can use. But, you say, "I can password the certificate!" So the security comes back to a password again.</p><p>For really security conscious users there will be a password on the filesystem, one on the account (login), and one on the certificate. They will be non-trivial and different.</p><p>My point is that a certificate <i>by itself</i> is less secure than a password, since anyone can use it. Only by combining the certificate to identify the system and the passwords to prevent misuse will you have acceptable security. The hardest part is finding the user who will actually faithfully use all the available security.</p><p>Combine this with human factors, like fingerprint readers, and <a href="http://en.wikipedia.org/wiki/Port\_knocking" title="wikipedia.org" rel="nofollow">port knocking</a> [wikipedia.org] and you can reach whatever combination of levels matches your requirements.</p></htmltext>
<tokenext>The problem with certificates is that there are stored somewhere easier to find than inside someone 's head .
A certificate is a key anyone can use .
But , you say , " I can password the certificate !
" So the security comes back to a password again.For really security conscious users there will be a password on the filesystem , one on the account ( login ) , and one on the certificate .
They will be non-trivial and different.My point is that a certificate by itself is less secure than a password , since anyone can use it .
Only by combining the certificate to identify the system and the passwords to prevent misuse will you have acceptable security .
The hardest part is finding the user who will actually faithfully use all the available security.Combine this with human factors , like fingerprint readers , and port knocking [ wikipedia.org ] and you can reach whatever combination of levels matches your requirements .</tokentext>
<sentencetext>The problem with certificates is that there are stored somewhere easier to find than inside someone's head.
A certificate is a key anyone can use.
But, you say, "I can password the certificate!
" So the security comes back to a password again.For really security conscious users there will be a password on the filesystem, one on the account (login), and one on the certificate.
They will be non-trivial and different.My point is that a certificate by itself is less secure than a password, since anyone can use it.
Only by combining the certificate to identify the system and the passwords to prevent misuse will you have acceptable security.
The hardest part is finding the user who will actually faithfully use all the available security.Combine this with human factors, like fingerprint readers, and port knocking [wikipedia.org] and you can reach whatever combination of levels matches your requirements.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298</id>
	<title>OpenBSD PF</title>
	<author>Anonymous</author>
	<datestamp>1267884960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p> <tt>#SSH<br>pass in inet proto tcp from any to $ext\_if port ssh<br>pass out inet proto tcp from any to $ext\_if port ssh<br>pass quick proto tcp from any to $ext\_if port ssh \<br>
&nbsp; &nbsp; &nbsp; &nbsp; flags S/SA keep state \<br>
&nbsp; &nbsp; &nbsp; &nbsp; (max-src-conn 15, max-src-conn-rate 5/3, \<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; overload &lt;bruteforce&gt; flush global)</tt></p></div> </blockquote><p>you know what I am saying?</p></div>
	</htmltext>
<tokenext># SSHpass in inet proto tcp from any to $ ext \ _if port sshpass out inet proto tcp from any to $ ext \ _if port sshpass quick proto tcp from any to $ ext \ _if port ssh \         flags S/SA keep state \         ( max-src-conn 15 , max-src-conn-rate 5/3 , \           overload flush global ) you know what I am saying ?</tokentext>
<sentencetext> #SSHpass in inet proto tcp from any to $ext\_if port sshpass out inet proto tcp from any to $ext\_if port sshpass quick proto tcp from any to $ext\_if port ssh \
        flags S/SA keep state \
        (max-src-conn 15, max-src-conn-rate 5/3, \
          overload  flush global) you know what I am saying?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386258</id>
	<title>change port - disregard all other posts</title>
	<author>Anonymous</author>
	<datestamp>1267893900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>it's simple, change your port. all you're looking for is to relieve some of the bot login attempts to your ssh server.  it's not a security measure, it's a simply a annoyance measure.  bots don't have the time to search for ssh service on other ports, and if one did, so what, let it try to brute force, your server is no less secure on another port but will have several million fewer log lines.</p></htmltext>
<tokenext>it 's simple , change your port .
all you 're looking for is to relieve some of the bot login attempts to your ssh server .
it 's not a security measure , it 's a simply a annoyance measure .
bots do n't have the time to search for ssh service on other ports , and if one did , so what , let it try to brute force , your server is no less secure on another port but will have several million fewer log lines .</tokentext>
<sentencetext>it's simple, change your port.
all you're looking for is to relieve some of the bot login attempts to your ssh server.
it's not a security measure, it's a simply a annoyance measure.
bots don't have the time to search for ssh service on other ports, and if one did, so what, let it try to brute force, your server is no less secure on another port but will have several million fewer log lines.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387656</id>
	<title>Re:fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1267954920000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>You have obviously never looked at fail2ban beyond a quick scan of a summary. IPTABLES doesn't analyze logfiles, douchbag.</p></htmltext>
<tokenext>You have obviously never looked at fail2ban beyond a quick scan of a summary .
IPTABLES does n't analyze logfiles , douchbag .</tokentext>
<sentencetext>You have obviously never looked at fail2ban beyond a quick scan of a summary.
IPTABLES doesn't analyze logfiles, douchbag.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386494</id>
	<title>Re:An iptables recipie</title>
	<author>NotQuiteReal</author>
	<datestamp>1267896900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That's too much typing. My mom wants a GUI for that.</htmltext>
<tokenext>That 's too much typing .
My mom wants a GUI for that .</tokentext>
<sentencetext>That's too much typing.
My mom wants a GUI for that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385292</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</id>
	<title>fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1267883640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>fail2ban, key-auth</p></htmltext>
<tokenext>fail2ban , key-auth</tokentext>
<sentencetext>fail2ban, key-auth</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387746</id>
	<title>Fortinet</title>
	<author>Exter-C</author>
	<datestamp>1267956540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hi There,</p><p>I know its not the cheapest solution around but we use Fortinet Firewalls with their IPS feature. There is a signature for brute force SSH attacks. It works really well. We have seen a 96\% drop in SSH connections since installing these devices in front of our servers. So far we have had no reported false positive issues. Coupling that with all the other signatures in the IPS database and we have a huge drop in attacks overall.</p></htmltext>
<tokenext>Hi There,I know its not the cheapest solution around but we use Fortinet Firewalls with their IPS feature .
There is a signature for brute force SSH attacks .
It works really well .
We have seen a 96 \ % drop in SSH connections since installing these devices in front of our servers .
So far we have had no reported false positive issues .
Coupling that with all the other signatures in the IPS database and we have a huge drop in attacks overall .</tokentext>
<sentencetext>Hi There,I know its not the cheapest solution around but we use Fortinet Firewalls with their IPS feature.
There is a signature for brute force SSH attacks.
It works really well.
We have seen a 96\% drop in SSH connections since installing these devices in front of our servers.
So far we have had no reported false positive issues.
Coupling that with all the other signatures in the IPS database and we have a huge drop in attacks overall.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390470</id>
	<title>Honeypot</title>
	<author>Anonymous</author>
	<datestamp>1267981200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Run SSH server in a different port, use 22 for a honeypot:</p><p>http://code.google.com/p/kippo/</p></htmltext>
<tokenext>Run SSH server in a different port , use 22 for a honeypot : http : //code.google.com/p/kippo/</tokentext>
<sentencetext>Run SSH server in a different port, use 22 for a honeypot:http://code.google.com/p/kippo/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392054</id>
	<title>Re:You are being brute-forced</title>
	<author>jefftp</author>
	<datestamp>1267989720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, change the default SSH port. It's so rare that actual humans are behind brute force attacks anymore that changing ports makes a huge difference in automated port-scanners from even bothering with your servers.</p></htmltext>
<tokenext>No , change the default SSH port .
It 's so rare that actual humans are behind brute force attacks anymore that changing ports makes a huge difference in automated port-scanners from even bothering with your servers .</tokentext>
<sentencetext>No, change the default SSH port.
It's so rare that actual humans are behind brute force attacks anymore that changing ports makes a huge difference in automated port-scanners from even bothering with your servers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385488</id>
	<title>Re:Never passwords!</title>
	<author>Anonymous</author>
	<datestamp>1267886160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just so you know, you&rsquo;re comparing RSA public keys with entropy there. Apples and oranges. You would get equivalent security with somewhere around 20-25 random alphanumeric mixed-case characters.</p></htmltext>
<tokenext>Just so you know , you    re comparing RSA public keys with entropy there .
Apples and oranges .
You would get equivalent security with somewhere around 20-25 random alphanumeric mixed-case characters .</tokentext>
<sentencetext>Just so you know, you’re comparing RSA public keys with entropy there.
Apples and oranges.
You would get equivalent security with somewhere around 20-25 random alphanumeric mixed-case characters.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385156</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386264</id>
	<title>knockd</title>
	<author>Anonymous</author>
	<datestamp>1267893960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Set up knockd:<br>http://www.zeroflux.org/projects/knock</p><p>Port knocking took my web servers from millions of failed attempts per month to zero.</p></htmltext>
<tokenext>Set up knockd : http : //www.zeroflux.org/projects/knockPort knocking took my web servers from millions of failed attempts per month to zero .</tokentext>
<sentencetext>Set up knockd:http://www.zeroflux.org/projects/knockPort knocking took my web servers from millions of failed attempts per month to zero.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388170</id>
	<title>A million connections.</title>
	<author>Anonymous</author>
	<datestamp>1267963560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Do you have many customers who access SSH, or is it mostly you?  That could help define your problem and your solution.</p><p>As others have pointed out, a million connections divided by 50 sites, divided by 365 days, may not be all that unreasonable.</p><p>On the other hand, if it is only you, or if you like to go through your log files regularly and find it too cumbersome with all the extra noise, then there may be better solutions.</p><p>I like to use pageknocking (not portknocking) to open the SSH port for access.  This prevents access from worms and limits the number of log entries created, although others claim (incorrectly) that it is just security by obscurity... (It should be trivial to modify it for use with Linux) www.otterhole.ca/knock/</p></htmltext>
<tokenext>Do you have many customers who access SSH , or is it mostly you ?
That could help define your problem and your solution.As others have pointed out , a million connections divided by 50 sites , divided by 365 days , may not be all that unreasonable.On the other hand , if it is only you , or if you like to go through your log files regularly and find it too cumbersome with all the extra noise , then there may be better solutions.I like to use pageknocking ( not portknocking ) to open the SSH port for access .
This prevents access from worms and limits the number of log entries created , although others claim ( incorrectly ) that it is just security by obscurity... ( It should be trivial to modify it for use with Linux ) www.otterhole.ca/knock/</tokentext>
<sentencetext>Do you have many customers who access SSH, or is it mostly you?
That could help define your problem and your solution.As others have pointed out, a million connections divided by 50 sites, divided by 365 days, may not be all that unreasonable.On the other hand, if it is only you, or if you like to go through your log files regularly and find it too cumbersome with all the extra noise, then there may be better solutions.I like to use pageknocking (not portknocking) to open the SSH port for access.
This prevents access from worms and limits the number of log entries created, although others claim (incorrectly) that it is just security by obscurity... (It should be trivial to modify it for use with Linux) www.otterhole.ca/knock/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387958</id>
	<title>good against 1 attacking host -- not large botnets</title>
	<author>beh</author>
	<datestamp>1267960140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I am using fail2ban, but I do not think it's a particularly great tool when you see how many different IP addresses the attacks come from, so you're somewhere stuck in the middle trying to optimise how to make fail2ban more effective, while not being a problem for your own users:</p><p>- you configure blocking from 1 login attempt and a long block time cuts down on most of the outside attacks, but if some legitimate user mistypes his password, he'll be locked out for that same long block time...<br>- you configure several wrong password attempts and/or shorter blocking times - then the attacks do not get slowed quite as much, but it hinders your users less.</p><p>There are some things you might consider, though -</p><p>
&nbsp; - if you can, and your users always access the system from their own computers/laptops, force the use of public-key authentication and disable use of password logins; then outside access attempts via password cannot succeed.<br>
&nbsp; - if you can't do this, at least force root to use public key (and/or su/sudo from another login.  (sshd\_config either<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'PermitRootLogin without-password'  (to allow root access through authorized\_keys, but not through password, or<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'PermitRootLogin no' to block root access via ssh-login altogether.</p><p>
&nbsp; - if there are only specific accounts you might want to allow access to, look into pam\_require, then limit to those users in pam's ssh<br>
&nbsp; &nbsp; &nbsp; config:  'account    required     pam\_require.so @ssh-users myaccount'   (allows user 'myaccount' and all users in group 'ssh-users'<br>
&nbsp; &nbsp; &nbsp; to log in via ssh - everyone else will be kicked out, even with a valid password).</p><p>
&nbsp; - keep an eye on the log to see whether it's actual users that get hit, or whether you see access attempts to non-existent users<br>
&nbsp; &nbsp; &nbsp; (many of the attacks are basically dictionary based). If you find one of the valid accounts gets hit too much, consider renaming that<br>
&nbsp; &nbsp; &nbsp; user account.</p></htmltext>
<tokenext>I am using fail2ban , but I do not think it 's a particularly great tool when you see how many different IP addresses the attacks come from , so you 're somewhere stuck in the middle trying to optimise how to make fail2ban more effective , while not being a problem for your own users : - you configure blocking from 1 login attempt and a long block time cuts down on most of the outside attacks , but if some legitimate user mistypes his password , he 'll be locked out for that same long block time...- you configure several wrong password attempts and/or shorter blocking times - then the attacks do not get slowed quite as much , but it hinders your users less.There are some things you might consider , though -   - if you can , and your users always access the system from their own computers/laptops , force the use of public-key authentication and disable use of password logins ; then outside access attempts via password can not succeed .
  - if you ca n't do this , at least force root to use public key ( and/or su/sudo from another login .
( sshd \ _config either           'PermitRootLogin without-password ' ( to allow root access through authorized \ _keys , but not through password , or           'PermitRootLogin no ' to block root access via ssh-login altogether .
  - if there are only specific accounts you might want to allow access to , look into pam \ _require , then limit to those users in pam 's ssh       config : 'account required pam \ _require.so @ ssh-users myaccount ' ( allows user 'myaccount ' and all users in group 'ssh-users '       to log in via ssh - everyone else will be kicked out , even with a valid password ) .
  - keep an eye on the log to see whether it 's actual users that get hit , or whether you see access attempts to non-existent users       ( many of the attacks are basically dictionary based ) .
If you find one of the valid accounts gets hit too much , consider renaming that       user account .</tokentext>
<sentencetext>I am using fail2ban, but I do not think it's a particularly great tool when you see how many different IP addresses the attacks come from, so you're somewhere stuck in the middle trying to optimise how to make fail2ban more effective, while not being a problem for your own users:- you configure blocking from 1 login attempt and a long block time cuts down on most of the outside attacks, but if some legitimate user mistypes his password, he'll be locked out for that same long block time...- you configure several wrong password attempts and/or shorter blocking times - then the attacks do not get slowed quite as much, but it hinders your users less.There are some things you might consider, though -
  - if you can, and your users always access the system from their own computers/laptops, force the use of public-key authentication and disable use of password logins; then outside access attempts via password cannot succeed.
  - if you can't do this, at least force root to use public key (and/or su/sudo from another login.
(sshd\_config either
          'PermitRootLogin without-password'  (to allow root access through authorized\_keys, but not through password, or
          'PermitRootLogin no' to block root access via ssh-login altogether.
  - if there are only specific accounts you might want to allow access to, look into pam\_require, then limit to those users in pam's ssh
      config:  'account    required     pam\_require.so @ssh-users myaccount'   (allows user 'myaccount' and all users in group 'ssh-users'
      to log in via ssh - everyone else will be kicked out, even with a valid password).
  - keep an eye on the log to see whether it's actual users that get hit, or whether you see access attempts to non-existent users
      (many of the attacks are basically dictionary based).
If you find one of the valid accounts gets hit too much, consider renaming that
      user account.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386612</id>
	<title>Re:You are being brute-forced</title>
	<author>Antique Geekmeister</author>
	<datestamp>1267898040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>But changing your port is easy and cuts the burden of analyzing the logs and adding clever filtering to a tiny fraction of the current burden. Switching to SSH key access alone does not help the burden of all the logs of all the failures, which clutter the heck out of my logs without filtering which is a complete waste of my resources to deal with.</p></htmltext>
<tokenext>But changing your port is easy and cuts the burden of analyzing the logs and adding clever filtering to a tiny fraction of the current burden .
Switching to SSH key access alone does not help the burden of all the logs of all the failures , which clutter the heck out of my logs without filtering which is a complete waste of my resources to deal with .</tokentext>
<sentencetext>But changing your port is easy and cuts the burden of analyzing the logs and adding clever filtering to a tiny fraction of the current burden.
Switching to SSH key access alone does not help the burden of all the logs of all the failures, which clutter the heck out of my logs without filtering which is a complete waste of my resources to deal with.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385530</id>
	<title>Okay... seriously.....</title>
	<author>Anonymous</author>
	<datestamp>1267886460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year."</p><p>What's to cope with? This isn't a problem - this is the internet.  Unless servers were actually breached, or it's actually costing you money - why do you care?  If your password practices are solid as you say - you should be fine.</p><p>People attempting to log in is not a security issue - people logging in is.</p><p>How do you manage server security with no system admin?  Either pay the extra money for managed hosting where they do this for you, or hire someone to do it for you on staff.   If those aren't viable - change your business plan (I mean, your business plan involves administering servers - somewhere along the way you made a decision that administering them yourself was the way to go for your business..... so why would you not hire a sysadmin?)</p></htmltext>
<tokenext>" Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~ 1200 IP addresses on one of our servers over the last year .
" What 's to cope with ?
This is n't a problem - this is the internet .
Unless servers were actually breached , or it 's actually costing you money - why do you care ?
If your password practices are solid as you say - you should be fine.People attempting to log in is not a security issue - people logging in is.How do you manage server security with no system admin ?
Either pay the extra money for managed hosting where they do this for you , or hire someone to do it for you on staff .
If those are n't viable - change your business plan ( I mean , your business plan involves administering servers - somewhere along the way you made a decision that administering them yourself was the way to go for your business..... so why would you not hire a sysadmin ?
)</tokentext>
<sentencetext>"Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year.
"What's to cope with?
This isn't a problem - this is the internet.
Unless servers were actually breached, or it's actually costing you money - why do you care?
If your password practices are solid as you say - you should be fine.People attempting to log in is not a security issue - people logging in is.How do you manage server security with no system admin?
Either pay the extra money for managed hosting where they do this for you, or hire someone to do it for you on staff.
If those aren't viable - change your business plan (I mean, your business plan involves administering servers - somewhere along the way you made a decision that administering them yourself was the way to go for your business..... so why would you not hire a sysadmin?
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387342</id>
	<title>Don't run the default protocols</title>
	<author>mysidia</author>
	<datestamp>1267993320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
SSH is attacked often because a lot of sites run it.
</p><p>
Disable SSHD on all machines, and
run Kerberized telnet instead.
</p></htmltext>
<tokenext>SSH is attacked often because a lot of sites run it .
Disable SSHD on all machines , and run Kerberized telnet instead .</tokentext>
<sentencetext>
SSH is attacked often because a lot of sites run it.
Disable SSHD on all machines, and
run Kerberized telnet instead.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387288</id>
	<title>Re:So?</title>
	<author>rawg</author>
	<datestamp>1267992660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Until you get 10,000 machines trying to brute force your password at 120 times per second.  Then you'll think twice about log and forget.</p></htmltext>
<tokenext>Until you get 10,000 machines trying to brute force your password at 120 times per second .
Then you 'll think twice about log and forget .</tokentext>
<sentencetext>Until you get 10,000 machines trying to brute force your password at 120 times per second.
Then you'll think twice about log and forget.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386196</id>
	<title>Re:I don't understand the problem</title>
	<author>thegrassyknowl</author>
	<datestamp>1267893300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>What's wrong with that? It's not like they're getting in, right?</p></div><p>It's not like he'd know if they were getting in - a sufficiently good attacker will cover their tracks pretty well. Not knowing the basics of securing SSH (and being a self-confessed n00b) really makes one a n00b. I'd hazard a guess that a n00b isn't capable of the forensic analysis needed to actually work out if someone did get in.</p></div>
	</htmltext>
<tokenext>What 's wrong with that ?
It 's not like they 're getting in , right ? It 's not like he 'd know if they were getting in - a sufficiently good attacker will cover their tracks pretty well .
Not knowing the basics of securing SSH ( and being a self-confessed n00b ) really makes one a n00b .
I 'd hazard a guess that a n00b is n't capable of the forensic analysis needed to actually work out if someone did get in .</tokentext>
<sentencetext>What's wrong with that?
It's not like they're getting in, right?It's not like he'd know if they were getting in - a sufficiently good attacker will cover their tracks pretty well.
Not knowing the basics of securing SSH (and being a self-confessed n00b) really makes one a n00b.
I'd hazard a guess that a n00b isn't capable of the forensic analysis needed to actually work out if someone did get in.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387052</id>
	<title>Do the math.</title>
	<author>SinShiva</author>
	<datestamp>1267903740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>~1,000,000 auth failures per year = ~2740 failures per day.  from 1200 IPs, that's 833 failures PER IP ADDRESS.  how in the bloody hell does that go amiss?  i like to think most people could figure out their password within 10 guesses (per ip).  for a problem this minimal, you don't even need to consider adding a delay between auth requests.</htmltext>
<tokenext>~ 1,000,000 auth failures per year = ~ 2740 failures per day .
from 1200 IPs , that 's 833 failures PER IP ADDRESS .
how in the bloody hell does that go amiss ?
i like to think most people could figure out their password within 10 guesses ( per ip ) .
for a problem this minimal , you do n't even need to consider adding a delay between auth requests .</tokentext>
<sentencetext>~1,000,000 auth failures per year = ~2740 failures per day.
from 1200 IPs, that's 833 failures PER IP ADDRESS.
how in the bloody hell does that go amiss?
i like to think most people could figure out their password within 10 guesses (per ip).
for a problem this minimal, you don't even need to consider adding a delay between auth requests.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385576</id>
	<title>Port Knocking</title>
	<author>chriswaco</author>
	<datestamp>1267886880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://en.wikipedia.org/wiki/Port\_knocking" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Port\_knocking</a> [wikipedia.org]<br><a href="http://www.portknocking.org/" title="portknocking.org" rel="nofollow">http://www.portknocking.org/</a> [portknocking.org]</p></htmltext>
<tokenext>http : //en.wikipedia.org/wiki/Port \ _knocking [ wikipedia.org ] http : //www.portknocking.org/ [ portknocking.org ]</tokentext>
<sentencetext>http://en.wikipedia.org/wiki/Port\_knocking [wikipedia.org]http://www.portknocking.org/ [portknocking.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390014</id>
	<title>firewall</title>
	<author>Uzik2</author>
	<datestamp>1267978440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's trivial to put in rules to only accept ssh connections from specific IP addresses. Perhaps you might consider only accepting connections from your customer's IP's, or doing the reverse and blocking abusing IP subnets.</htmltext>
<tokenext>It 's trivial to put in rules to only accept ssh connections from specific IP addresses .
Perhaps you might consider only accepting connections from your customer 's IP 's , or doing the reverse and blocking abusing IP subnets .</tokentext>
<sentencetext>It's trivial to put in rules to only accept ssh connections from specific IP addresses.
Perhaps you might consider only accepting connections from your customer's IP's, or doing the reverse and blocking abusing IP subnets.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387126</id>
	<title>Multiple ways</title>
	<author>Nuitari The Wiz</author>
	<datestamp>1267904340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I manage a bunch of physical and VPS servers, all colocated at various facilities. Using gvpe and dedicated switches, I've built a VPN between the locations and my house that allows ssh access between the machines. The vast majority of SSH servers only listen on the private IP address. There is no special access for traffic inside the VPN, and ssh keys are mandatory to login to these servers.

In case something happens to the VPN gateways, there is an alternate host that accepts connections using port knocking (which is about 100\% effective against automated attacks) and contains a whitelist of known good IP addresses.

Fail2Ban still runs on it and it can ban IP addresses on the VPN is something untowards happen.

Sometimes my customers require SSH access to the server. I apply the following order of preference:
<ul>
<li>OpenVPN/PPTP to the client machines</li><li>Port knocking</li><li>Different SSH Port</li></ul><p>

The problem is that all solutions need more work from the customer and that's sometimes something they just don't want to deal with. If I'm really really stuck, what I do is set fail2ban to block on the first failed attempt. That server also gets removed from the VPN network and thus do not get any backup or MySQL replication.

No matter what, there is no root password login enabled.</p></htmltext>
<tokenext>I manage a bunch of physical and VPS servers , all colocated at various facilities .
Using gvpe and dedicated switches , I 've built a VPN between the locations and my house that allows ssh access between the machines .
The vast majority of SSH servers only listen on the private IP address .
There is no special access for traffic inside the VPN , and ssh keys are mandatory to login to these servers .
In case something happens to the VPN gateways , there is an alternate host that accepts connections using port knocking ( which is about 100 \ % effective against automated attacks ) and contains a whitelist of known good IP addresses .
Fail2Ban still runs on it and it can ban IP addresses on the VPN is something untowards happen .
Sometimes my customers require SSH access to the server .
I apply the following order of preference : OpenVPN/PPTP to the client machinesPort knockingDifferent SSH Port The problem is that all solutions need more work from the customer and that 's sometimes something they just do n't want to deal with .
If I 'm really really stuck , what I do is set fail2ban to block on the first failed attempt .
That server also gets removed from the VPN network and thus do not get any backup or MySQL replication .
No matter what , there is no root password login enabled .</tokentext>
<sentencetext>I manage a bunch of physical and VPS servers, all colocated at various facilities.
Using gvpe and dedicated switches, I've built a VPN between the locations and my house that allows ssh access between the machines.
The vast majority of SSH servers only listen on the private IP address.
There is no special access for traffic inside the VPN, and ssh keys are mandatory to login to these servers.
In case something happens to the VPN gateways, there is an alternate host that accepts connections using port knocking (which is about 100\% effective against automated attacks) and contains a whitelist of known good IP addresses.
Fail2Ban still runs on it and it can ban IP addresses on the VPN is something untowards happen.
Sometimes my customers require SSH access to the server.
I apply the following order of preference:

OpenVPN/PPTP to the client machinesPort knockingDifferent SSH Port

The problem is that all solutions need more work from the customer and that's sometimes something they just don't want to deal with.
If I'm really really stuck, what I do is set fail2ban to block on the first failed attempt.
That server also gets removed from the VPN network and thus do not get any backup or MySQL replication.
No matter what, there is no root password login enabled.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392344</id>
	<title>Botnet brute force.</title>
	<author>Anonymous</author>
	<datestamp>1267991100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I looked at my logs the other day on my FreeBSD router and noticed the same thing this guy had.  Random IP addresses (different class A's very few repeat IP addresses) and invalid logins.  Each time the username would alphabetically increment.  So all these different IP's each taking the enxt name on the list to try to login.  It was pretty scary.</p><p>I let it get through it's list up to about 'j' before I blocked port 22.</p></htmltext>
<tokenext>I looked at my logs the other day on my FreeBSD router and noticed the same thing this guy had .
Random IP addresses ( different class A 's very few repeat IP addresses ) and invalid logins .
Each time the username would alphabetically increment .
So all these different IP 's each taking the enxt name on the list to try to login .
It was pretty scary.I let it get through it 's list up to about 'j ' before I blocked port 22 .</tokentext>
<sentencetext>I looked at my logs the other day on my FreeBSD router and noticed the same thing this guy had.
Random IP addresses (different class A's very few repeat IP addresses) and invalid logins.
Each time the username would alphabetically increment.
So all these different IP's each taking the enxt name on the list to try to login.
It was pretty scary.I let it get through it's list up to about 'j' before I blocked port 22.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31400252</id>
	<title>pam\_abl</title>
	<author>welsh git</author>
	<datestamp>1268061600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.hexten.net/wiki/index.php/Pam\_abl" title="hexten.net">http://www.hexten.net/wiki/index.php/Pam\_abl</a> [hexten.net]</p></htmltext>
<tokenext>http : //www.hexten.net/wiki/index.php/Pam \ _abl [ hexten.net ]</tokentext>
<sentencetext>http://www.hexten.net/wiki/index.php/Pam\_abl [hexten.net]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</id>
	<title>You are being brute-forced</title>
	<author>Anonymous</author>
	<datestamp>1267883940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Welcome to the internet -- this happens to every site with a public IP.</p><p>First off, do not change your SSH port.  It won't do a whole lot for you, and it will be more hassle than it works.</p><p>There are a whole lot of programs available to deal with SSH brute forcing.  sshguard is one of them, and it's not too bad (you can apt-get install it).  It's a bit of a hack -- it just watches your logs and takes appropriate action -- but it does work.</p><p>The other thing you can do immediately is simply turn off password authentication in ssh.  Anyone getting in will need a key.  This is what sourceforge and github both do.  This isn't always practical for every site, but it will damn sure keep your passwords from being brute-forced.</p></htmltext>
<tokenext>Welcome to the internet -- this happens to every site with a public IP.First off , do not change your SSH port .
It wo n't do a whole lot for you , and it will be more hassle than it works.There are a whole lot of programs available to deal with SSH brute forcing .
sshguard is one of them , and it 's not too bad ( you can apt-get install it ) .
It 's a bit of a hack -- it just watches your logs and takes appropriate action -- but it does work.The other thing you can do immediately is simply turn off password authentication in ssh .
Anyone getting in will need a key .
This is what sourceforge and github both do .
This is n't always practical for every site , but it will damn sure keep your passwords from being brute-forced .</tokentext>
<sentencetext>Welcome to the internet -- this happens to every site with a public IP.First off, do not change your SSH port.
It won't do a whole lot for you, and it will be more hassle than it works.There are a whole lot of programs available to deal with SSH brute forcing.
sshguard is one of them, and it's not too bad (you can apt-get install it).
It's a bit of a hack -- it just watches your logs and takes appropriate action -- but it does work.The other thing you can do immediately is simply turn off password authentication in ssh.
Anyone getting in will need a key.
This is what sourceforge and github both do.
This isn't always practical for every site, but it will damn sure keep your passwords from being brute-forced.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385756</id>
	<title>Simples solution: Port knocking.</title>
	<author>Hurricane78</author>
	<datestamp>1267889100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That should keep the CPU usage down, and your system secure from that type of attack. You can&rsquo;t do much more than that.</p><p>You could run a script to find the owner of all those IPs... maybe do a bit of statistics to see what you can find out... But in the end it will be someone that you can not sue or contact in any way anyway.</p></htmltext>
<tokenext>That should keep the CPU usage down , and your system secure from that type of attack .
You can    t do much more than that.You could run a script to find the owner of all those IPs... maybe do a bit of statistics to see what you can find out... But in the end it will be someone that you can not sue or contact in any way anyway .</tokentext>
<sentencetext>That should keep the CPU usage down, and your system secure from that type of attack.
You can’t do much more than that.You could run a script to find the owner of all those IPs... maybe do a bit of statistics to see what you can find out... But in the end it will be someone that you can not sue or contact in any way anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387226</id>
	<title>Re:You are being brute-forced</title>
	<author>sjames</author>
	<datestamp>1267992060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oddly enough, it WILL do a lot! The vast majority of password guess attempts are NOT targeted at your particular server where they would bother port scanning you. They just want any valid login on any server anywhere. Changing the port nomber makes them just go away at the first connection refused. It's just important to remember that that bit of obscurity only turns away the big dumb attacks, it does NOT make you more secure against a targeted attack (which, I imagine, was your point).</p></htmltext>
<tokenext>Oddly enough , it WILL do a lot !
The vast majority of password guess attempts are NOT targeted at your particular server where they would bother port scanning you .
They just want any valid login on any server anywhere .
Changing the port nomber makes them just go away at the first connection refused .
It 's just important to remember that that bit of obscurity only turns away the big dumb attacks , it does NOT make you more secure against a targeted attack ( which , I imagine , was your point ) .</tokentext>
<sentencetext>Oddly enough, it WILL do a lot!
The vast majority of password guess attempts are NOT targeted at your particular server where they would bother port scanning you.
They just want any valid login on any server anywhere.
Changing the port nomber makes them just go away at the first connection refused.
It's just important to remember that that bit of obscurity only turns away the big dumb attacks, it does NOT make you more secure against a targeted attack (which, I imagine, was your point).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385436</id>
	<title>Re:Ignore it?</title>
	<author>MichaelSmith</author>
	<datestamp>1267885800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yeah this is just normal for me. I have a script which hooks into syslog and blocks offending hosts in pf but frankly I don't think it is worth the risk of doing that. Make sure sshd has a secure configuration and don't worry about the brute forcing.</p></htmltext>
<tokenext>Yeah this is just normal for me .
I have a script which hooks into syslog and blocks offending hosts in pf but frankly I do n't think it is worth the risk of doing that .
Make sure sshd has a secure configuration and do n't worry about the brute forcing .</tokentext>
<sentencetext>Yeah this is just normal for me.
I have a script which hooks into syslog and blocks offending hosts in pf but frankly I don't think it is worth the risk of doing that.
Make sure sshd has a secure configuration and don't worry about the brute forcing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385104</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385660</id>
	<title>Re:fail2ban</title>
	<author>Anonymous</author>
	<datestamp>1267887900000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>These are the knee-jerk responses of people who are downright know-nothings.</p><p>Why the FUCK would i run some fucking shitty script, written by some unknown cunt with ABSOLUTELY NO CLUE ABOUT ANYTHING, on a production system?</p><p>Why, when iptables recent module does the same thing, and doesnt require lame hackery by some dumb faggot who can't read man pages?</p><p>Seriously, anyone using fail2ban has failed themselves. The person who wrote it must be holding their head in shame knowing they re-invented a wheel that had rough bumpy bits which sometimes failed.</p></htmltext>
<tokenext>These are the knee-jerk responses of people who are downright know-nothings.Why the FUCK would i run some fucking shitty script , written by some unknown cunt with ABSOLUTELY NO CLUE ABOUT ANYTHING , on a production system ? Why , when iptables recent module does the same thing , and doesnt require lame hackery by some dumb faggot who ca n't read man pages ? Seriously , anyone using fail2ban has failed themselves .
The person who wrote it must be holding their head in shame knowing they re-invented a wheel that had rough bumpy bits which sometimes failed .</tokentext>
<sentencetext>These are the knee-jerk responses of people who are downright know-nothings.Why the FUCK would i run some fucking shitty script, written by some unknown cunt with ABSOLUTELY NO CLUE ABOUT ANYTHING, on a production system?Why, when iptables recent module does the same thing, and doesnt require lame hackery by some dumb faggot who can't read man pages?Seriously, anyone using fail2ban has failed themselves.
The person who wrote it must be holding their head in shame knowing they re-invented a wheel that had rough bumpy bits which sometimes failed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390870</id>
	<title>Re:BlockHosts</title>
	<author>Thumper\_SVX</author>
	<datestamp>1267983420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Seconded on Blockhosts. Had the exact same problem, exact same results. Nowadays my average is about 200 blocked IP's, and I run the script every 15 minutes. I also use certificate auth only so the password problem really is a non-problem. In the event I need to get in to download a cert to a new machine (if I don't have my USB key on me that has the cert already there), I also have an IPSec VPN tunnel set up that's a piece of cake to connect up. The VPN is handled by its own hardware firewall (a Sonicwall Pro 2040), and I allow password auth only from the internal subnet on the back side of the firewall.</p><p>In 4 years of running sites on that server, the only successful hack I've ever had was because of a problem with an application hosted on the site. That application was removed pretty rapidly, and the only real impact was that all of a sudden I got people telling me that people couldn't get to their site because there were hidden links that were dead or slow on the served up pages.</p><p>HTH</p></htmltext>
<tokenext>Seconded on Blockhosts .
Had the exact same problem , exact same results .
Nowadays my average is about 200 blocked IP 's , and I run the script every 15 minutes .
I also use certificate auth only so the password problem really is a non-problem .
In the event I need to get in to download a cert to a new machine ( if I do n't have my USB key on me that has the cert already there ) , I also have an IPSec VPN tunnel set up that 's a piece of cake to connect up .
The VPN is handled by its own hardware firewall ( a Sonicwall Pro 2040 ) , and I allow password auth only from the internal subnet on the back side of the firewall.In 4 years of running sites on that server , the only successful hack I 've ever had was because of a problem with an application hosted on the site .
That application was removed pretty rapidly , and the only real impact was that all of a sudden I got people telling me that people could n't get to their site because there were hidden links that were dead or slow on the served up pages.HTH</tokentext>
<sentencetext>Seconded on Blockhosts.
Had the exact same problem, exact same results.
Nowadays my average is about 200 blocked IP's, and I run the script every 15 minutes.
I also use certificate auth only so the password problem really is a non-problem.
In the event I need to get in to download a cert to a new machine (if I don't have my USB key on me that has the cert already there), I also have an IPSec VPN tunnel set up that's a piece of cake to connect up.
The VPN is handled by its own hardware firewall (a Sonicwall Pro 2040), and I allow password auth only from the internal subnet on the back side of the firewall.In 4 years of running sites on that server, the only successful hack I've ever had was because of a problem with an application hosted on the site.
That application was removed pretty rapidly, and the only real impact was that all of a sudden I got people telling me that people couldn't get to their site because there were hidden links that were dead or slow on the served up pages.HTH</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385266</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098</id>
	<title>whatcouldposiblygowrong</title>
	<author>Anonymous</author>
	<datestamp>1267883640000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>self-proclaimed "noobs" managing public facing servers</p></htmltext>
<tokenext>self-proclaimed " noobs " managing public facing servers</tokentext>
<sentencetext>self-proclaimed "noobs" managing public facing servers</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31399618</id>
	<title>open ssh port = bad</title>
	<author>Anonymous</author>
	<datestamp>1268057160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1. Dont have open ssh ports on the net...<br>2. Use vpn tunnles to get to your network<br>3. ONly allow port 22 connections from your vpn network.<br>4. Stop getting hacked</p><p>Who the hell leaves an ssh port open to the net on a production server ?<br>Also while fail2ban is very effective as i have used it in the past, its not a perfect solution.</p><p>again while in gods name do you have ssh ports open to the net, realy you should not have any admin access avaible strait from the net, if you do your just asking to get burned</p></htmltext>
<tokenext>1 .
Dont have open ssh ports on the net...2 .
Use vpn tunnles to get to your network3 .
ONly allow port 22 connections from your vpn network.4 .
Stop getting hackedWho the hell leaves an ssh port open to the net on a production server ? Also while fail2ban is very effective as i have used it in the past , its not a perfect solution.again while in gods name do you have ssh ports open to the net , realy you should not have any admin access avaible strait from the net , if you do your just asking to get burned</tokentext>
<sentencetext>1.
Dont have open ssh ports on the net...2.
Use vpn tunnles to get to your network3.
ONly allow port 22 connections from your vpn network.4.
Stop getting hackedWho the hell leaves an ssh port open to the net on a production server ?Also while fail2ban is very effective as i have used it in the past, its not a perfect solution.again while in gods name do you have ssh ports open to the net, realy you should not have any admin access avaible strait from the net, if you do your just asking to get burned</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</id>
	<title>Re:Tar Pitting</title>
	<author>Anonymous</author>
	<datestamp>1267884840000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>I use a variation on tarpitting that has worked very well for me.<br>It cut the attempts down from 60,000/day to 20 or 30 per day.</p><p>I just add a small delay between the initial connection attempt<br>and when I send the username/password prompt.   The delay (in<br>seconds) is the number of attempts in the last 30 minutes,<br>squared.   This makes all but the most determined attacker<br>give up and go away very quickly.</p><p>I have been using this with both FTP and SSH for the last<br>year, and it works great.</p></htmltext>
<tokenext>I use a variation on tarpitting that has worked very well for me.It cut the attempts down from 60,000/day to 20 or 30 per day.I just add a small delay between the initial connection attemptand when I send the username/password prompt .
The delay ( inseconds ) is the number of attempts in the last 30 minutes,squared .
This makes all but the most determined attackergive up and go away very quickly.I have been using this with both FTP and SSH for the lastyear , and it works great .</tokentext>
<sentencetext>I use a variation on tarpitting that has worked very well for me.It cut the attempts down from 60,000/day to 20 or 30 per day.I just add a small delay between the initial connection attemptand when I send the username/password prompt.
The delay (inseconds) is the number of attempts in the last 30 minutes,squared.
This makes all but the most determined attackergive up and go away very quickly.I have been using this with both FTP and SSH for the lastyear, and it works great.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386412</id>
	<title>Use sshutout</title>
	<author>2ndRateSoul</author>
	<datestamp>1267895640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This works great for reducing the effectiveness of dictionary attacks:</p><p><a href="http://freshmeat.net/projects/sshutout" title="freshmeat.net" rel="nofollow">http://freshmeat.net/projects/sshutout</a> [freshmeat.net]</p></htmltext>
<tokenext>This works great for reducing the effectiveness of dictionary attacks : http : //freshmeat.net/projects/sshutout [ freshmeat.net ]</tokentext>
<sentencetext>This works great for reducing the effectiveness of dictionary attacks:http://freshmeat.net/projects/sshutout [freshmeat.net]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385194</id>
	<title>DenyHosts</title>
	<author>Utoxin</author>
	<datestamp>1267884120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Great tool that pools the resources of multiple servers to proactively block IPs that are trying to brute-force the SSH port on any server in the pool:</p><p><a href="http://denyhosts.sourceforge.net/" title="sourceforge.net">http://denyhosts.sourceforge.net/</a> [sourceforge.net]</p><p>I use it, and it has Just Worked for years.</p></htmltext>
<tokenext>Great tool that pools the resources of multiple servers to proactively block IPs that are trying to brute-force the SSH port on any server in the pool : http : //denyhosts.sourceforge.net/ [ sourceforge.net ] I use it , and it has Just Worked for years .</tokentext>
<sentencetext>Great tool that pools the resources of multiple servers to proactively block IPs that are trying to brute-force the SSH port on any server in the pool:http://denyhosts.sourceforge.net/ [sourceforge.net]I use it, and it has Just Worked for years.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390158</id>
	<title>Re:fail2ban</title>
	<author>titten</author>
	<datestamp>1267979280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Odds are the web server is protected by a firewall.</p><p>If you only intend to serve web pages from this server, open port(s) 80 (and 443) on the firewall towards that host.<br>To reach other services, VPN into the DMZ or another network that has access to your DMZ and initiate SSH from there.</p><p>No SSH visible on the Internet, no SSH bot attacks.</p></htmltext>
<tokenext>Odds are the web server is protected by a firewall.If you only intend to serve web pages from this server , open port ( s ) 80 ( and 443 ) on the firewall towards that host.To reach other services , VPN into the DMZ or another network that has access to your DMZ and initiate SSH from there.No SSH visible on the Internet , no SSH bot attacks .</tokentext>
<sentencetext>Odds are the web server is protected by a firewall.If you only intend to serve web pages from this server, open port(s) 80 (and 443) on the firewall towards that host.To reach other services, VPN into the DMZ or another network that has access to your DMZ and initiate SSH from there.No SSH visible on the Internet, no SSH bot attacks.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387640</id>
	<title>Re:OpenBSD PF</title>
	<author>funkboy</author>
	<datestamp>1267954740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The tutorial that explains what all this does is <a href="http://home.nuug.no/~peter/pf/en/bruteforce.html" title="home.nuug.no" rel="nofollow">here</a> [home.nuug.no].  They've also added a nice feature called <a href="http://home.nuug.no/~peter/pf/en/bruteforce.html#EXPIRETABLE" title="home.nuug.no" rel="nofollow">expiretables</a> [home.nuug.no] that keeps the "bruteforce" table small &amp; efficient by expiring entries that haven't seen any hits after a definable period of time.</p><p>FWIW, there's also an entry in <a href="http://www.openbsd.org/faq/pf/filter.html#stateopts" title="openbsd.org" rel="nofollow">the official PF FAQ</a> [openbsd.org] on this...</p></htmltext>
<tokenext>The tutorial that explains what all this does is here [ home.nuug.no ] .
They 've also added a nice feature called expiretables [ home.nuug.no ] that keeps the " bruteforce " table small &amp; efficient by expiring entries that have n't seen any hits after a definable period of time.FWIW , there 's also an entry in the official PF FAQ [ openbsd.org ] on this.. .</tokentext>
<sentencetext>The tutorial that explains what all this does is here [home.nuug.no].
They've also added a nice feature called expiretables [home.nuug.no] that keeps the "bruteforce" table small &amp; efficient by expiring entries that haven't seen any hits after a definable period of time.FWIW, there's also an entry in the official PF FAQ [openbsd.org] on this...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385226</id>
	<title>Keys...</title>
	<author>Anonymous</author>
	<datestamp>1267884540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Key-based authentication is really what you need. If your situation doesn't allow for key-based auth, Fail2Ban can help reduce brute-force attempts for password-based auth, and allowing connections from specific IPs, if possible, can heighten security quite nicely.</htmltext>
<tokenext>Key-based authentication is really what you need .
If your situation does n't allow for key-based auth , Fail2Ban can help reduce brute-force attempts for password-based auth , and allowing connections from specific IPs , if possible , can heighten security quite nicely .</tokentext>
<sentencetext>Key-based authentication is really what you need.
If your situation doesn't allow for key-based auth, Fail2Ban can help reduce brute-force attempts for password-based auth, and allowing connections from specific IPs, if possible, can heighten security quite nicely.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389150</id>
	<title>Use "artificial ignorance" and cron, daily</title>
	<author>davecb</author>
	<datestamp>1267973460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>  The short answer is to get someone to read all your logs daily and email you only if there's something non-routine in them.  That will find <i>anything</i> that gets logged, so you will have good coverage and rapid notification.

</p><p> Since no-one in their right mind is going to offer that service for a reasonable price, you can have cron run an 'artificial ignorance" script nightly.  The tern coems from <a href="http://www.ranum.com/security/computer\_security/papers/ai/index.html" title="ranum.com">Marcus Ranum</a> [ranum.com], and there's a complete discussion of filtering syslog at <a href="http://datacenterworks.com/stories/antilog.html" title="datacenterworks.com">Sherlock Holmes on Log Files</a> [datacenterworks.com].

</p><p>In practice, I get a few emails a month about new things, and add them to the list in the script if they're uninteresting.

</p><p>--dave</p></htmltext>
<tokenext>The short answer is to get someone to read all your logs daily and email you only if there 's something non-routine in them .
That will find anything that gets logged , so you will have good coverage and rapid notification .
Since no-one in their right mind is going to offer that service for a reasonable price , you can have cron run an 'artificial ignorance " script nightly .
The tern coems from Marcus Ranum [ ranum.com ] , and there 's a complete discussion of filtering syslog at Sherlock Holmes on Log Files [ datacenterworks.com ] .
In practice , I get a few emails a month about new things , and add them to the list in the script if they 're uninteresting .
--dave</tokentext>
<sentencetext>  The short answer is to get someone to read all your logs daily and email you only if there's something non-routine in them.
That will find anything that gets logged, so you will have good coverage and rapid notification.
Since no-one in their right mind is going to offer that service for a reasonable price, you can have cron run an 'artificial ignorance" script nightly.
The tern coems from Marcus Ranum [ranum.com], and there's a complete discussion of filtering syslog at Sherlock Holmes on Log Files [datacenterworks.com].
In practice, I get a few emails a month about new things, and add them to the list in the script if they're uninteresting.
--dave</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385158</id>
	<title>Fail2ban or denyhosts</title>
	<author>mystik</author>
	<datestamp>1267883940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><a href="http://www.fail2ban.org/wiki/index.php/Main\_Page" title="fail2ban.org">Fail2ban</a> [fail2ban.org] or <a href="http://denyhosts.sourceforge.net/" title="sourceforge.net">denyhosts</a> [sourceforge.net] activly target ssh.  fail2ban includes rules for other services, but denyhosts includes a mechanism for sharing lists of your denied hosts w/ other admins, as well as using their ban lists to protect your ssh logins.</htmltext>
<tokenext>Fail2ban [ fail2ban.org ] or denyhosts [ sourceforge.net ] activly target ssh .
fail2ban includes rules for other services , but denyhosts includes a mechanism for sharing lists of your denied hosts w/ other admins , as well as using their ban lists to protect your ssh logins .</tokentext>
<sentencetext>Fail2ban [fail2ban.org] or denyhosts [sourceforge.net] activly target ssh.
fail2ban includes rules for other services, but denyhosts includes a mechanism for sharing lists of your denied hosts w/ other admins, as well as using their ban lists to protect your ssh logins.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387900</id>
	<title>Ob.Whine quoted</title>
	<author>elronxenu</author>
	<datestamp>1267959240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> <i>
how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)?
</i></p></div> </blockquote><p>
You do the best you can. Sheesh. Learn about the system and how to secure it. It's not slashdot's problem you're under-funded and under-resourced.
</p><p>
There's a triangular spectrum. Corner 1 is how much you're willing to pay. Corner 2 is how much you're willing to learn and do by yourself. Corner 3 is your probability of getting r00ted. If you don't want to spend any money on sysadmin and you don't want to spend any time to secure your system, then expect to get r00ted sometime.
</p></div>
	</htmltext>
<tokenext>how do you manage server security on a tight budget with literally no system admin ( except for me and I know I 'm a n00b ) ?
You do the best you can .
Sheesh. Learn about the system and how to secure it .
It 's not slashdot 's problem you 're under-funded and under-resourced .
There 's a triangular spectrum .
Corner 1 is how much you 're willing to pay .
Corner 2 is how much you 're willing to learn and do by yourself .
Corner 3 is your probability of getting r00ted .
If you do n't want to spend any money on sysadmin and you do n't want to spend any time to secure your system , then expect to get r00ted sometime .</tokentext>
<sentencetext> 
how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)?
You do the best you can.
Sheesh. Learn about the system and how to secure it.
It's not slashdot's problem you're under-funded and under-resourced.
There's a triangular spectrum.
Corner 1 is how much you're willing to pay.
Corner 2 is how much you're willing to learn and do by yourself.
Corner 3 is your probability of getting r00ted.
If you don't want to spend any money on sysadmin and you don't want to spend any time to secure your system, then expect to get r00ted sometime.

	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385796</id>
	<title>hashlimit</title>
	<author>suso</author>
	<datestamp>1267889520000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>You can also use the hashlimit module for iptables. I find it works pretty well for allowing people in who need to access and block things like the ssh worm that was causing ssh to run out of resources.</p><p>You might check out the end of this presentation that I made 4 years ago.</p><p><a href="http://www.bloomingtonlinux.org/wiki/15th\_meeting" title="bloomingtonlinux.org">http://www.bloomingtonlinux.org/wiki/15th\_meeting</a> [bloomingtonlinux.org]</p><p>I've been using hashlimit successfully for years in a web hosting environment.</p><p>I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!</p></htmltext>
<tokenext>You can also use the hashlimit module for iptables .
I find it works pretty well for allowing people in who need to access and block things like the ssh worm that was causing ssh to run out of resources.You might check out the end of this presentation that I made 4 years ago.http : //www.bloomingtonlinux.org/wiki/15th \ _meeting [ bloomingtonlinux.org ] I 've been using hashlimit successfully for years in a web hosting environment.I 'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security .
This job is usually referred to as a system administrator or network administrator .
DOH !</tokentext>
<sentencetext>You can also use the hashlimit module for iptables.
I find it works pretty well for allowing people in who need to access and block things like the ssh worm that was causing ssh to run out of resources.You might check out the end of this presentation that I made 4 years ago.http://www.bloomingtonlinux.org/wiki/15th\_meeting [bloomingtonlinux.org]I've been using hashlimit successfully for years in a web hosting environment.I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security.
This job is usually referred to as a system administrator or network administrator.
DOH!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31393146</id>
	<title>Re:fwknop</title>
	<author>Anonymous</author>
	<datestamp>1267953060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ugh, please no. Use Moxie's knockknock: http://www.thoughtcrime.org/software/knockknock</p></htmltext>
<tokenext>Ugh , please no .
Use Moxie 's knockknock : http : //www.thoughtcrime.org/software/knockknock</tokentext>
<sentencetext>Ugh, please no.
Use Moxie's knockknock: http://www.thoughtcrime.org/software/knockknock</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386534</id>
	<title>Security for n00bs</title>
	<author>mstrebe</author>
	<datestamp>1267897320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How do you manage security if you're a n00b? Only you can manage your security. Only you care enough to do the work.</p><p>Start reading. And FAST!</p></htmltext>
<tokenext>How do you manage security if you 're a n00b ?
Only you can manage your security .
Only you care enough to do the work.Start reading .
And FAST !</tokentext>
<sentencetext>How do you manage security if you're a n00b?
Only you can manage your security.
Only you care enough to do the work.Start reading.
And FAST!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391770</id>
	<title>Re:You are being brute-forced</title>
	<author>jon3k</author>
	<datestamp>1267988160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>"First off, do not change your SSH port. It won't do a whole lot for you, and it will be more hassle than it works."</i>
<br> <br>
Couldn't disagree more.  If you were more familiar with these attacks you'd know that they are botnet driven brute force attempts that only use the default SSH port.  And seriously, hassle?  What hassle?  Having to specify a port?  Seriously?  Are you kidding me?  Anyone I know who's bright enough to use/need ssh access to a host is more than competent to specify a port number.  We're talking 99.999999999\% here.</htmltext>
<tokenext>" First off , do not change your SSH port .
It wo n't do a whole lot for you , and it will be more hassle than it works .
" Could n't disagree more .
If you were more familiar with these attacks you 'd know that they are botnet driven brute force attempts that only use the default SSH port .
And seriously , hassle ?
What hassle ?
Having to specify a port ?
Seriously ? Are you kidding me ?
Anyone I know who 's bright enough to use/need ssh access to a host is more than competent to specify a port number .
We 're talking 99.999999999 \ % here .</tokentext>
<sentencetext>"First off, do not change your SSH port.
It won't do a whole lot for you, and it will be more hassle than it works.
"
 
Couldn't disagree more.
If you were more familiar with these attacks you'd know that they are botnet driven brute force attempts that only use the default SSH port.
And seriously, hassle?
What hassle?
Having to specify a port?
Seriously?  Are you kidding me?
Anyone I know who's bright enough to use/need ssh access to a host is more than competent to specify a port number.
We're talking 99.999999999\% here.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386174</id>
	<title>Re:Move to a higher order port and use denyhosts</title>
	<author>thegrassyknowl</author>
	<datestamp>1267893120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>1. Move the default ssh port to a higher order port (5000+)</p></div><p>This is \_not\_ a good idea. Aside from the fact that now any n00b client that needs SSH access to the server is going to have to also remember a new port number, a sufficiently determined logged in user can cause the SSH daemon to crash and then replace it with one of their own which can sniff keys and passwords, contains back doors, etc.</p><p>You can get around this by changing the privileged port numbers using a sysctl, but that has other drawbacks. You could do a little firewall trickery to redirect a higher order port to the lower one and blocking the low port from external access.</p><p>But I reiterate, unless it's just for your own private use changing the SSH port is not a sufficiently good solution.</p><p>Tarpitting seems like a really good solution to me.  Configuring SSH better is also a good start.</p><p>Settings like LoginGraceTime, PermitRootLogin=no and MaxStartups, MaxAuthTries, MaxSessions are all good to reduce the number of failed login attempts.  Most scripts (what you are seeing) use a single session and try to stuff as many auth tries down it as possible. The do this to avoid firewall-based IDS systems from rate limiting or blacklisting them. Reducing the grace time to 15 seconds is a good start (if your clients do not have reverse lookup PTRs on their addresses this will be bad). Reducing MaxAuthTries to 2 or 3 will help. MaxSessions can be reduced also. Of course these also have drawbacks. If you're only using shell access to the machine you don't really need many sessions on a single TCP connection.</p></div>
	</htmltext>
<tokenext>1 .
Move the default ssh port to a higher order port ( 5000 + ) This is \ _not \ _ a good idea .
Aside from the fact that now any n00b client that needs SSH access to the server is going to have to also remember a new port number , a sufficiently determined logged in user can cause the SSH daemon to crash and then replace it with one of their own which can sniff keys and passwords , contains back doors , etc.You can get around this by changing the privileged port numbers using a sysctl , but that has other drawbacks .
You could do a little firewall trickery to redirect a higher order port to the lower one and blocking the low port from external access.But I reiterate , unless it 's just for your own private use changing the SSH port is not a sufficiently good solution.Tarpitting seems like a really good solution to me .
Configuring SSH better is also a good start.Settings like LoginGraceTime , PermitRootLogin = no and MaxStartups , MaxAuthTries , MaxSessions are all good to reduce the number of failed login attempts .
Most scripts ( what you are seeing ) use a single session and try to stuff as many auth tries down it as possible .
The do this to avoid firewall-based IDS systems from rate limiting or blacklisting them .
Reducing the grace time to 15 seconds is a good start ( if your clients do not have reverse lookup PTRs on their addresses this will be bad ) .
Reducing MaxAuthTries to 2 or 3 will help .
MaxSessions can be reduced also .
Of course these also have drawbacks .
If you 're only using shell access to the machine you do n't really need many sessions on a single TCP connection .</tokentext>
<sentencetext>1.
Move the default ssh port to a higher order port (5000+)This is \_not\_ a good idea.
Aside from the fact that now any n00b client that needs SSH access to the server is going to have to also remember a new port number, a sufficiently determined logged in user can cause the SSH daemon to crash and then replace it with one of their own which can sniff keys and passwords, contains back doors, etc.You can get around this by changing the privileged port numbers using a sysctl, but that has other drawbacks.
You could do a little firewall trickery to redirect a higher order port to the lower one and blocking the low port from external access.But I reiterate, unless it's just for your own private use changing the SSH port is not a sufficiently good solution.Tarpitting seems like a really good solution to me.
Configuring SSH better is also a good start.Settings like LoginGraceTime, PermitRootLogin=no and MaxStartups, MaxAuthTries, MaxSessions are all good to reduce the number of failed login attempts.
Most scripts (what you are seeing) use a single session and try to stuff as many auth tries down it as possible.
The do this to avoid firewall-based IDS systems from rate limiting or blacklisting them.
Reducing the grace time to 15 seconds is a good start (if your clients do not have reverse lookup PTRs on their addresses this will be bad).
Reducing MaxAuthTries to 2 or 3 will help.
MaxSessions can be reduced also.
Of course these also have drawbacks.
If you're only using shell access to the machine you don't really need many sessions on a single TCP connection.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385738</id>
	<title>apply patches fastidiously</title>
	<author>sneakyimp</author>
	<datestamp>1267888800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Somebody might want to check my math here...my stats are a bit rusty</p><p>Ok let's assume a few things:<br>1) your passwords are 8 chars long and use upper and lowercase alpha and numbers only<br>2) they are essentially random passwords that are NOT in the dictionary.</p><p>This would mean that there are 2^62 possible passwords in your password space. That's 4,611,686,018,427,387,904 possible passwords.  The chances of guessing one password in that space within a million random tries is 1,000,000/4,611,686,018,427,387,904.  That's about one chance in 4,611,686,018,427.  I believe that one in 4.5 <i>trillion</i> is about as remote a possibility as you getting struck by a meteor.</p><p>I think it's much more likely that someone will exploit a buffer overflow or sql injection vulnerability on your servers than someone guessing a password. You should make sure that you've applied whatever patches that you can and that any sensitive data traveling to or from your servers is encrypted.</p><p>I also like the iptables suggestion -- this means your machine will ignore entire regions of the internet so your server's exposure is at least limited to friendly subnets.</p><p>Another useful technique is to prohibit root access to SSH on initial login.  This means that everyone has to login with some other username before they can acquire root privileges.  For hackers, this means guessing not just a password but also a username that is allowed to login via SSH on the machine.</p></htmltext>
<tokenext>Somebody might want to check my math here...my stats are a bit rustyOk let 's assume a few things : 1 ) your passwords are 8 chars long and use upper and lowercase alpha and numbers only2 ) they are essentially random passwords that are NOT in the dictionary.This would mean that there are 2 ^ 62 possible passwords in your password space .
That 's 4,611,686,018,427,387,904 possible passwords .
The chances of guessing one password in that space within a million random tries is 1,000,000/4,611,686,018,427,387,904 .
That 's about one chance in 4,611,686,018,427 .
I believe that one in 4.5 trillion is about as remote a possibility as you getting struck by a meteor.I think it 's much more likely that someone will exploit a buffer overflow or sql injection vulnerability on your servers than someone guessing a password .
You should make sure that you 've applied whatever patches that you can and that any sensitive data traveling to or from your servers is encrypted.I also like the iptables suggestion -- this means your machine will ignore entire regions of the internet so your server 's exposure is at least limited to friendly subnets.Another useful technique is to prohibit root access to SSH on initial login .
This means that everyone has to login with some other username before they can acquire root privileges .
For hackers , this means guessing not just a password but also a username that is allowed to login via SSH on the machine .</tokentext>
<sentencetext>Somebody might want to check my math here...my stats are a bit rustyOk let's assume a few things:1) your passwords are 8 chars long and use upper and lowercase alpha and numbers only2) they are essentially random passwords that are NOT in the dictionary.This would mean that there are 2^62 possible passwords in your password space.
That's 4,611,686,018,427,387,904 possible passwords.
The chances of guessing one password in that space within a million random tries is 1,000,000/4,611,686,018,427,387,904.
That's about one chance in 4,611,686,018,427.
I believe that one in 4.5 trillion is about as remote a possibility as you getting struck by a meteor.I think it's much more likely that someone will exploit a buffer overflow or sql injection vulnerability on your servers than someone guessing a password.
You should make sure that you've applied whatever patches that you can and that any sensitive data traveling to or from your servers is encrypted.I also like the iptables suggestion -- this means your machine will ignore entire regions of the internet so your server's exposure is at least limited to friendly subnets.Another useful technique is to prohibit root access to SSH on initial login.
This means that everyone has to login with some other username before they can acquire root privileges.
For hackers, this means guessing not just a password but also a username that is allowed to login via SSH on the machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31403506</id>
	<title>OWASP Live CD</title>
	<author>Anonymous</author>
	<datestamp>1268077980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>OWASP Live CD http://www.appseclive.org/content/downloads</p></htmltext>
<tokenext>OWASP Live CD http : //www.appseclive.org/content/downloads</tokentext>
<sentencetext>OWASP Live CD http://www.appseclive.org/content/downloads</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385780</id>
	<title>Denyhosts</title>
	<author>someguysomewhere</author>
	<datestamp>1267889280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I use 'denyhosts' which actively monitors and blacklists based on failed login attempts.

I usually set it to ban anyone that tries to login as root more than once since root logins are disabled anyway no one should be trying that.  And to ban anyone trying to login as an unknown user.  Valid users are allowed a lot more leeway, 10 retries I think.</htmltext>
<tokenext>I use 'denyhosts ' which actively monitors and blacklists based on failed login attempts .
I usually set it to ban anyone that tries to login as root more than once since root logins are disabled anyway no one should be trying that .
And to ban anyone trying to login as an unknown user .
Valid users are allowed a lot more leeway , 10 retries I think .</tokentext>
<sentencetext>I use 'denyhosts' which actively monitors and blacklists based on failed login attempts.
I usually set it to ban anyone that tries to login as root more than once since root logins are disabled anyway no one should be trying that.
And to ban anyone trying to login as an unknown user.
Valid users are allowed a lot more leeway, 10 retries I think.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386090</id>
	<title>I have been seeing...</title>
	<author>QuietLagoon</author>
	<datestamp>1267892160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>... many, many (dozens per second) SSH probes recently.  Make sure your passwords are solid.</htmltext>
<tokenext>... many , many ( dozens per second ) SSH probes recently .
Make sure your passwords are solid .</tokentext>
<sentencetext>... many, many (dozens per second) SSH probes recently.
Make sure your passwords are solid.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388562</id>
	<title>One million sounds like a lot, but isn't really</title>
	<author>badger.foo</author>
	<datestamp>1267968660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Or to put it another way, what you're seeing is the Internet's background noise. There is at least one, possibly several, smallish botnets that do brute force ssh password guessing all across the Internet.<br> <br>
I see others have already mentioned my articles such as <a href="http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html" title="blogspot.com">http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html</a> [blogspot.com], and if you take a peek in the list of addresses I put there, I would not be at all surprised if there's a great deal of overlap with the hosts that keep sniffing your servers (my data for that round has a little over 4000 hosts). In fact, it would be interesting to know how large or small the overlap is. They will keep trying (in fact I'm just seeing the start of another alphabetic phase over the last few days here) but there are a few things you can do to make it less likely they will succeed.<br>
<br>
The general advice is, as you have heard many times before, to enforce a policy of no passwords, usin only key authentication, of course disable root logins and if practical limit where you can log in from to 'known good' IP addresses or ranges. The first two won't rid you of the logged attempts, but sensible in any case and makes the probability of ssh-based compromise quite a bit less likely.
<p>
Rate limiting helps get rid of the classical rapid-fire variety password guesser, but will not help at all when you're faced with the coordinated 'hail mary cloud' where each individual host could be attempting to access your system or network only every few hours.
<br> <br>
As for portknocking, I seriously think the port knockers would be equally well served by switching all passwords to unicode. That provides a practical alphabet of the same number of unique characters (16 bits, remember), and for anyone with a large enough fleet of password guessers, the mechanics of guessing the right one is not all that different. Oh well, I just spilled the beans for the main point of an upcoming column, that won't spoil the fun later, I hope.</p></htmltext>
<tokenext>Or to put it another way , what you 're seeing is the Internet 's background noise .
There is at least one , possibly several , smallish botnets that do brute force ssh password guessing all across the Internet .
I see others have already mentioned my articles such as http : //bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html [ blogspot.com ] , and if you take a peek in the list of addresses I put there , I would not be at all surprised if there 's a great deal of overlap with the hosts that keep sniffing your servers ( my data for that round has a little over 4000 hosts ) .
In fact , it would be interesting to know how large or small the overlap is .
They will keep trying ( in fact I 'm just seeing the start of another alphabetic phase over the last few days here ) but there are a few things you can do to make it less likely they will succeed .
The general advice is , as you have heard many times before , to enforce a policy of no passwords , usin only key authentication , of course disable root logins and if practical limit where you can log in from to 'known good ' IP addresses or ranges .
The first two wo n't rid you of the logged attempts , but sensible in any case and makes the probability of ssh-based compromise quite a bit less likely .
Rate limiting helps get rid of the classical rapid-fire variety password guesser , but will not help at all when you 're faced with the coordinated 'hail mary cloud ' where each individual host could be attempting to access your system or network only every few hours .
As for portknocking , I seriously think the port knockers would be equally well served by switching all passwords to unicode .
That provides a practical alphabet of the same number of unique characters ( 16 bits , remember ) , and for anyone with a large enough fleet of password guessers , the mechanics of guessing the right one is not all that different .
Oh well , I just spilled the beans for the main point of an upcoming column , that wo n't spoil the fun later , I hope .</tokentext>
<sentencetext>Or to put it another way, what you're seeing is the Internet's background noise.
There is at least one, possibly several, smallish botnets that do brute force ssh password guessing all across the Internet.
I see others have already mentioned my articles such as http://bsdly.blogspot.com/2009/11/rickrolled-get-ready-for-hail-mary.html [blogspot.com], and if you take a peek in the list of addresses I put there, I would not be at all surprised if there's a great deal of overlap with the hosts that keep sniffing your servers (my data for that round has a little over 4000 hosts).
In fact, it would be interesting to know how large or small the overlap is.
They will keep trying (in fact I'm just seeing the start of another alphabetic phase over the last few days here) but there are a few things you can do to make it less likely they will succeed.
The general advice is, as you have heard many times before, to enforce a policy of no passwords, usin only key authentication, of course disable root logins and if practical limit where you can log in from to 'known good' IP addresses or ranges.
The first two won't rid you of the logged attempts, but sensible in any case and makes the probability of ssh-based compromise quite a bit less likely.
Rate limiting helps get rid of the classical rapid-fire variety password guesser, but will not help at all when you're faced with the coordinated 'hail mary cloud' where each individual host could be attempting to access your system or network only every few hours.
As for portknocking, I seriously think the port knockers would be equally well served by switching all passwords to unicode.
That provides a practical alphabet of the same number of unique characters (16 bits, remember), and for anyone with a large enough fleet of password guessers, the mechanics of guessing the right one is not all that different.
Oh well, I just spilled the beans for the main point of an upcoming column, that won't spoil the fun later, I hope.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387104</id>
	<title>Re:whatcouldposiblygowrong</title>
	<author>Dan541</author>
	<datestamp>1267904160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'll bet you teach your kid gun safety by shooting him in the neck.</p></div><p>I bet he is terrified of guns after, the system works.</p></div>
	</htmltext>
<tokenext>I 'll bet you teach your kid gun safety by shooting him in the neck.I bet he is terrified of guns after , the system works .</tokentext>
<sentencetext>I'll bet you teach your kid gun safety by shooting him in the neck.I bet he is terrified of guns after, the system works.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385156</id>
	<title>Never passwords!</title>
	<author>Anonymous</author>
	<datestamp>1267883940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Use public key authentication. It's super easy and much more secure, unless your random passwords happen to be over 300 characters long (ssh-keygen makes 2048-bit keys by default; assume 6 bits per character in a random password if each character is in the base64 set). Also, sshguard is your friend. After a small number of invalid logins - 4 by default - that IP gets firewalled for a short period of time.</p></htmltext>
<tokenext>Use public key authentication .
It 's super easy and much more secure , unless your random passwords happen to be over 300 characters long ( ssh-keygen makes 2048-bit keys by default ; assume 6 bits per character in a random password if each character is in the base64 set ) .
Also , sshguard is your friend .
After a small number of invalid logins - 4 by default - that IP gets firewalled for a short period of time .</tokentext>
<sentencetext>Use public key authentication.
It's super easy and much more secure, unless your random passwords happen to be over 300 characters long (ssh-keygen makes 2048-bit keys by default; assume 6 bits per character in a random password if each character is in the base64 set).
Also, sshguard is your friend.
After a small number of invalid logins - 4 by default - that IP gets firewalled for a short period of time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385816</id>
	<title>Re:So?</title>
	<author>Skapare</author>
	<datestamp>1267889640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>They don't know it's a battery monitor. All they know is, it has an IP address, and it listens on a port they suspect is SSH, and if they can get in, they can probably use it to get back out to somewhere else using your IP and your bandwidth, to do things ranging from sending out millions of spam to performing denial of service attacks on some target.</p><p>FYI, moving the port is (at least for now) more effective than banning them for a few tries. If they get banned, they just share your IP with their friends, who will also try. If they never get a connection, they don't share it. And there are fewer pointless log entries. Simple as that. If adding a "Port" statement in your ~/.ssh/config file is too hard for you, oh well.</p></htmltext>
<tokenext>They do n't know it 's a battery monitor .
All they know is , it has an IP address , and it listens on a port they suspect is SSH , and if they can get in , they can probably use it to get back out to somewhere else using your IP and your bandwidth , to do things ranging from sending out millions of spam to performing denial of service attacks on some target.FYI , moving the port is ( at least for now ) more effective than banning them for a few tries .
If they get banned , they just share your IP with their friends , who will also try .
If they never get a connection , they do n't share it .
And there are fewer pointless log entries .
Simple as that .
If adding a " Port " statement in your ~ /.ssh/config file is too hard for you , oh well .</tokentext>
<sentencetext>They don't know it's a battery monitor.
All they know is, it has an IP address, and it listens on a port they suspect is SSH, and if they can get in, they can probably use it to get back out to somewhere else using your IP and your bandwidth, to do things ranging from sending out millions of spam to performing denial of service attacks on some target.FYI, moving the port is (at least for now) more effective than banning them for a few tries.
If they get banned, they just share your IP with their friends, who will also try.
If they never get a connection, they don't share it.
And there are fewer pointless log entries.
Simple as that.
If adding a "Port" statement in your ~/.ssh/config file is too hard for you, oh well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385312</id>
	<title>pam\_abl</title>
	<author>otis wildflower</author>
	<datestamp>1267885020000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><a href="http://lmgtfy.com/?q=pam\_abl" title="lmgtfy.com">http://lmgtfy.com/?q=pam\_abl</a> [lmgtfy.com]</p><p>Share and enjoy!</p></htmltext>
<tokenext>http : //lmgtfy.com/ ? q = pam \ _abl [ lmgtfy.com ] Share and enjoy !</tokentext>
<sentencetext>http://lmgtfy.com/?q=pam\_abl [lmgtfy.com]Share and enjoy!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386260</id>
	<title>Re:You are being brute-forced</title>
	<author>mcrbids</author>
	<datestamp>1267893960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>DISABLE PASSWORD AUTHENTICATION! I wish I had points to mod you up with! I use several strategies:</p><p>1) Nonstandard port (despite what you say, it does stop you from getting the automated SSH scans hitting you)</p><p>2) Disable password Auth</p><p>3) RSA keys with passphrases.</p><p>4) Disable the root password. Yes, I'm serious. If I'm remote, I can become root with my passphrase protected RSA key. If I'm local, I can reboot and run kernel mode single. The root password is simply not something I need, so it's only a liability.</p><p>5) Sleep peacefully at night.</p></htmltext>
<tokenext>DISABLE PASSWORD AUTHENTICATION !
I wish I had points to mod you up with !
I use several strategies : 1 ) Nonstandard port ( despite what you say , it does stop you from getting the automated SSH scans hitting you ) 2 ) Disable password Auth3 ) RSA keys with passphrases.4 ) Disable the root password .
Yes , I 'm serious .
If I 'm remote , I can become root with my passphrase protected RSA key .
If I 'm local , I can reboot and run kernel mode single .
The root password is simply not something I need , so it 's only a liability.5 ) Sleep peacefully at night .</tokentext>
<sentencetext>DISABLE PASSWORD AUTHENTICATION!
I wish I had points to mod you up with!
I use several strategies:1) Nonstandard port (despite what you say, it does stop you from getting the automated SSH scans hitting you)2) Disable password Auth3) RSA keys with passphrases.4) Disable the root password.
Yes, I'm serious.
If I'm remote, I can become root with my passphrase protected RSA key.
If I'm local, I can reboot and run kernel mode single.
The root password is simply not something I need, so it's only a liability.5) Sleep peacefully at night.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386896</id>
	<title>Re:fail2ban</title>
	<author>codeguy007</author>
	<datestamp>1267901820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p> Nobody's going to guess a 2048-bit RSA key.</p> </div><p>No but they can steal if from your users' computers. It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client. Of course if they can hack and steal keys, they can probably steal passwords as well. For remote access one of the securest ways is using a security token. Every time user logs in they have to enter a different number.</p></div>
	</htmltext>
<tokenext>Nobody 's going to guess a 2048-bit RSA key .
No but they can steal if from your users ' computers .
It 's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you ca n't control the security on their machines is only as secure as your dumbest client .
Of course if they can hack and steal keys , they can probably steal passwords as well .
For remote access one of the securest ways is using a security token .
Every time user logs in they have to enter a different number .</tokentext>
<sentencetext> Nobody's going to guess a 2048-bit RSA key.
No but they can steal if from your users' computers.
It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client.
Of course if they can hack and steal keys, they can probably steal passwords as well.
For remote access one of the securest ways is using a security token.
Every time user logs in they have to enter a different number.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386054</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385972</id>
	<title>Re:Tar Pitting</title>
	<author>M. Baranczak</author>
	<datestamp>1267891200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So by sending a connection request every couple of minutes, I can effectively prevent all legitimate users from logging into the system?</p></htmltext>
<tokenext>So by sending a connection request every couple of minutes , I can effectively prevent all legitimate users from logging into the system ?</tokentext>
<sentencetext>So by sending a connection request every couple of minutes, I can effectively prevent all legitimate users from logging into the system?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385166</id>
	<title>SSH public key authentication</title>
	<author>Anonymous</author>
	<datestamp>1267883940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>This kind of brute-forcing is common. The simplest way to deal with it is to set up SSH public key authentication, disable SSH password authentication, and forget about it.</htmltext>
<tokenext>This kind of brute-forcing is common .
The simplest way to deal with it is to set up SSH public key authentication , disable SSH password authentication , and forget about it .</tokentext>
<sentencetext>This kind of brute-forcing is common.
The simplest way to deal with it is to set up SSH public key authentication, disable SSH password authentication, and forget about it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706</id>
	<title>Lock it down.</title>
	<author>Anonymous</author>
	<datestamp>1267955820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I can't believe the person who set the server up left this port open to the world. If you want the server secure then you will close all the ports that are not actually needed - in your case this likely means you keep 80 and 443 open.</p><p>For remote management make get a few IPs for the desktops that are meant to connect to it and make sure the ISP opens SSH port only to the IPs.</p><p>You can tunnel X over SSH and do file management, whatever you need so it should be enough.</p><p>Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.</p></htmltext>
<tokenext>I ca n't believe the person who set the server up left this port open to the world .
If you want the server secure then you will close all the ports that are not actually needed - in your case this likely means you keep 80 and 443 open.For remote management make get a few IPs for the desktops that are meant to connect to it and make sure the ISP opens SSH port only to the IPs.You can tunnel X over SSH and do file management , whatever you need so it should be enough.Do n't bother changing it to some random port , security through obscurity is total bullshit in this age of port scanners .</tokentext>
<sentencetext>I can't believe the person who set the server up left this port open to the world.
If you want the server secure then you will close all the ports that are not actually needed - in your case this likely means you keep 80 and 443 open.For remote management make get a few IPs for the desktops that are meant to connect to it and make sure the ISP opens SSH port only to the IPs.You can tunnel X over SSH and do file management, whatever you need so it should be enough.Don't bother changing it to some random port, security through obscurity is total bullshit in this age of port scanners.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387298</id>
	<title>Re:Hardware firewall or use bfd</title>
	<author>coolgeek</author>
	<datestamp>1267992780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'll second the bfd and apf.  It could be the 1M ssh attempts are sourced from a relatively small number of ip addresses, but since they are allowed to run unchecked, they run a whole dictionary or maybe even a brute force attack.  I've found with bfd, once the bots start getting timeouts, they give up.</p></htmltext>
<tokenext>I 'll second the bfd and apf .
It could be the 1M ssh attempts are sourced from a relatively small number of ip addresses , but since they are allowed to run unchecked , they run a whole dictionary or maybe even a brute force attack .
I 've found with bfd , once the bots start getting timeouts , they give up .</tokentext>
<sentencetext>I'll second the bfd and apf.
It could be the 1M ssh attempts are sourced from a relatively small number of ip addresses, but since they are allowed to run unchecked, they run a whole dictionary or maybe even a brute force attack.
I've found with bfd, once the bots start getting timeouts, they give up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385266</id>
	<title>BlockHosts</title>
	<author>Anonymous</author>
	<datestamp>1267884720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>We started using BlockHosts to feed iptables rules, and our failure logs went from 30-50k per day to 100.  Basically, with more than 'x' failed logins within 'y' time frame, the source IP is blocked for 'z' time period.  Since it uses iptables, you could block it from just the ssh port, or the entire system (we do the latter).<br>All three variables are configurable, and we also have whitelisted a few select standby IPs for contingency use.  (As another poster said, you **will** lock yourself out eventually.)</p></htmltext>
<tokenext>We started using BlockHosts to feed iptables rules , and our failure logs went from 30-50k per day to 100 .
Basically , with more than 'x ' failed logins within 'y ' time frame , the source IP is blocked for 'z ' time period .
Since it uses iptables , you could block it from just the ssh port , or the entire system ( we do the latter ) .All three variables are configurable , and we also have whitelisted a few select standby IPs for contingency use .
( As another poster said , you * * will * * lock yourself out eventually .
)</tokentext>
<sentencetext>We started using BlockHosts to feed iptables rules, and our failure logs went from 30-50k per day to 100.
Basically, with more than 'x' failed logins within 'y' time frame, the source IP is blocked for 'z' time period.
Since it uses iptables, you could block it from just the ssh port, or the entire system (we do the latter).All three variables are configurable, and we also have whitelisted a few select standby IPs for contingency use.
(As another poster said, you **will** lock yourself out eventually.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385176</id>
	<title>What could all those people want to badly?</title>
	<author>Anonymous</author>
	<datestamp>1267884060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Everybody wants free porn. You're just going to have to live with that. You sleep with dogs, you're bound to get flees (unless you have mandatory government filters).</p></htmltext>
<tokenext>Everybody wants free porn .
You 're just going to have to live with that .
You sleep with dogs , you 're bound to get flees ( unless you have mandatory government filters ) .</tokentext>
<sentencetext>Everybody wants free porn.
You're just going to have to live with that.
You sleep with dogs, you're bound to get flees (unless you have mandatory government filters).</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385266
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390870
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385576
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385766
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385754
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385396
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388876
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398994
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385104
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385436
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387646
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385650
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31402634
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387674
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387234
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387958
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386260
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387298
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385156
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385488
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385372
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390450
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387288
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385438
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31404848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385796
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385482
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386896
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392988
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31399752
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390158
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385116
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391638
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31393146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392054
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391770
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31397230
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388916
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31394960
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385972
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389188
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385254
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386612
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385554
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387722
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390538
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388050
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387104
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385724
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385340
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386196
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386078
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392022
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391568
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391662
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398792
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387936
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387100
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388514
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385660
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387656
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385690
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387742
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386682
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387640
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385292
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386494
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_06_2138221_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387226
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385116
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391638
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385106
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391568
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388876
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387298
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385166
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385186
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385098
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385276
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385690
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387104
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385482
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387100
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385092
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387958
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385660
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387656
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389188
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385796
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388364
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398792
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385724
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385372
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387674
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386054
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386896
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392988
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385498
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390470
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385298
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387640
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385158
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385104
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385436
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387706
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392022
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31404848
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31389056
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385292
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386494
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385204
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387742
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387288
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386682
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385816
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386418
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31394960
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31397230
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385090
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385682
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385156
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385488
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385150
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391770
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31398994
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387722
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387108
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390538
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386260
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387226
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386612
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31392054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387646
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386456
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391662
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385754
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31402634
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385576
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385766
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387812
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385288
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31387936
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386800
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386412
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390870
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391698
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388514
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385254
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385438
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386448
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385284
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385972
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385554
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385846
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390408
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386382
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385650
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385884
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385396
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385484
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388916
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31390450
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385344
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31388050
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386078
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31399752
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386174
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385144
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386388
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31391744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31393146
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_06_2138221.30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31385340
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_06_2138221.31386196
</commentlist>
</conversation>
