Honeypot analysis - Looking closer at SSH scans (user and passwords used)
1–9 of 9 posts
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#2Good job researching those pesky brute force scans. Is there anyway you can post the complete list with all the data collected instead of just the top 50?
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#3Nice analysis.
[advice for those not doing it right]: if your sshd config allows id/pw login, turn this off and only use kays. Also, move your sshd listener port to something besides 22 to eliminate most of the bot login attempts in your log files.
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#4Nice analysis. [advice for those not doing it right]: if your sshd config allows id/pw login, turn this off and only use kays. Also, move your sshd listener port to something besides 22 to eliminate most of the bot login attempts in your log files.
You know, lots of people talk about using keys instead of passwords... By doing that if you box is compromised, the attacker will get access to ALL your boxes.
So, the best option is to use an encrypted ssh key (so you have the type the pass everytime) or a good/different password for every box.
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#5Nice analysis. [advice for those not doing it right]: if your sshd config allows id/pw login, turn this off and only use kays. Also, move your sshd listener port to something besides 22 to eliminate most of the bot login attempts in your log files.
You know, lots of people talk about using keys instead of passwords... By doing that if you box is compromised, the attacker will get access to ALL your boxes. So, the best option is to use an encrypted ssh key (so you have the type the pass everytime) or a good/different password for every box.
When you log in to an ssh host using a public/private key pair, the server only sees the public key. So by breaking and entering the attacker can disable your ability to log in in this fashion (by deleting the key) or can enable you to log in somewhere else (by copying the key, probably useless) but they cannot use that key to log in somewhere else absent modification of the SSH server. And even then I doubt they could get the private key, although they could probably run a MITM attack.
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#6I wonder if the lack of root:alpine and mobile:dottie indicates the attack tools are smart enough to know the OS of the box they're attacking, or just a lack of interest in owning jailbroken iPhones?
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#7Nice analysis. [advice for those not doing it right]: if your sshd config allows id/pw login, turn this off and only use kays. Also, move your sshd listener port to something besides 22 to eliminate most of the bot login attempts in your log files.
You know, lots of people talk about using keys instead of passwords... By doing that if you box is compromised, the attacker will get access to ALL your boxes. So, the best option is to use an encrypted ssh key (so you have the type the pass everytime) or a good/different password for every box.
I think what your saying is that even keys need to be managed well. I agree.
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#8Earlier quoted context omitted.
You know, lots of people talk about using keys instead of passwords... By doing that if you box is compromised, the attacker will get access to ALL your boxes. So, the best option is to use an encrypted ssh key (so you have the type the pass everytime) or a good/different password for every box.
When you log in to an ssh host using a public/private key pair, the server only sees the public key. So by breaking and entering the attacker can disable your ability to log in in this fashion (by deleting the key) or can enable you to log in somewhere else (by copying the key, probably useless) but they cannot use that key to log in somewhere else absent modification of the SSH server. And even then I doubt they cou…
I believe s/he meant if the box you are using to log in is compromised, then all boxes your box has access to (by way of the private key it has in its file system) are compromised, whereas it seems you interpreted the comment to be implying that the host to which you are logging in (which only has the public key in its file system) has been compromised.
The point is that the computer on which you type becomes a lynch-pin.
Re: Honeypot analysis - Looking closer at SSH scans (user and passwords used)
#9Earlier quoted context omitted.
When you log in to an ssh host using a public/private key pair, the server only sees the public key. So by breaking and entering the attacker can disable your ability to log in in this fashion (by deleting the key) or can enable you to log in somewhere else (by copying the key, probably useless) but they cannot use that key to log in somewhere else absent modification of the SSH server. And even then I doubt they cou…
I believe s/he meant if the box you are using to log in is compromised, then all boxes your box has access to (by way of the private key it has in its file system) are compromised, whereas it seems you interpreted the comment to be implying that the host to which you are logging in (which only has the public key in its file system) has been compromised. The point is that the computer on which you type becomes a lynch…
Yes, if you have a computer with a private key that is available to the internet, and it gets knocked over, you're dead. Just as you would be if he knocked it over and installed a keylogger and you were using passwords. Cracked is cracked.
Assuming you are not running services on your main workstation, which is not that unreasonable (Ubuntu workstations are installed with 0 services available to the local network; my Mac has 0 services available by default), then you can get knocked over but it will probably happen because of an browser bug or something like that, i.e. not an active attack.
The whole point of keys is that knocking over one of the intermediate nodes in the network no longer gives you control over everything. Just because you rooted my server doesn't mean you can automatically log in to all my other machines, even if I'm using keys. Keys are better than passwords.