Some glaring security holes? (Score: 1) by zafiro17@pipedot.org on 2014-09-19 14:01 (#2SKX) I don't code, so am unqualified to comment. But I'll do so anyway :) Seems like these are some pretty glaring security holes; I'm surprised they weren't caught before. Maybe apt works so well that developers don't feel a need to look further into it. Given the number of asshat crackers out there looking for ways to break into VPS boxes and - do what? I don't even know - cracking apt would seem like a clever point of entry. My VPS registers hundreds and hundreds of brute-force hits every day. Even sshguard fails to stop them as they now bounce your server from multiple IPs simultaneously. Let's say they finally get my server - what would they do with it? Pump out Chinese stock tips and erectile dysfunction spam? Compile themselves a new kernel? What?Meanwhile, I'm glad people look into this code and fix vulnerabilities like this. Given the number of Ubuntu and Debian servers out there serving webpages, it would seem like a weakness with the potential to do some serious harm. Re: Some glaring security holes? (Score: 0) by fnj@pipedot.org on 2014-09-19 21:48 (#2SMK) I have zero security concern about sshd on my VPS. It's pretty much child's play to make it mathematiocally impossible for them to break in even if they keep trying for billions of years using thousands of bots.1) Disallow root sshd logins. And never use root or sudo.2) For admin, have a second UID 0 user account with a long name that no one would ever find in a dictionary. Give it a long, super obscure password and make sure it is set to use SHA512 hashing. Then login to this account using an ssh key which has a long obscure passphrase. Use ssh-agent to manage the passphrase.3) For ordinary user accounts, use the same name and password policy. Re: Some glaring security holes? (Score: 1) by bryan@pipedot.org on 2014-09-21 11:55 (#2SPS) I disable password authentication entirely in favor of SSH keys. I believe that this is now the default in Ubuntu (since Trusty.) From the Ubuntu wiki:To be as hard to guess as a normal SSH key, a password would have to contain 634 random letters and numbers. Re: Some glaring security holes? (Score: 1) by zafiro17@pipedot.org on 2014-09-21 19:19 (#2SQ6) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right? I'm glad there are no intruders in my apartment, but I'm also tired of them banging on the door. I need a system that paints a big "F U" on the front door and electrifies the doorknob, front walk, and maybe parts of the sidewalk :)No really, for my front door. Although its parallel in code for my VPS would be nice, too :) Re: Some glaring security holes? (Score: 1) by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.(Sorry I'm late to the party)
Re: Some glaring security holes? (Score: 0) by fnj@pipedot.org on 2014-09-19 21:48 (#2SMK) I have zero security concern about sshd on my VPS. It's pretty much child's play to make it mathematiocally impossible for them to break in even if they keep trying for billions of years using thousands of bots.1) Disallow root sshd logins. And never use root or sudo.2) For admin, have a second UID 0 user account with a long name that no one would ever find in a dictionary. Give it a long, super obscure password and make sure it is set to use SHA512 hashing. Then login to this account using an ssh key which has a long obscure passphrase. Use ssh-agent to manage the passphrase.3) For ordinary user accounts, use the same name and password policy. Re: Some glaring security holes? (Score: 1) by bryan@pipedot.org on 2014-09-21 11:55 (#2SPS) I disable password authentication entirely in favor of SSH keys. I believe that this is now the default in Ubuntu (since Trusty.) From the Ubuntu wiki:To be as hard to guess as a normal SSH key, a password would have to contain 634 random letters and numbers. Re: Some glaring security holes? (Score: 1) by zafiro17@pipedot.org on 2014-09-21 19:19 (#2SQ6) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right? I'm glad there are no intruders in my apartment, but I'm also tired of them banging on the door. I need a system that paints a big "F U" on the front door and electrifies the doorknob, front walk, and maybe parts of the sidewalk :)No really, for my front door. Although its parallel in code for my VPS would be nice, too :) Re: Some glaring security holes? (Score: 1) by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.(Sorry I'm late to the party)
Re: Some glaring security holes? (Score: 1) by bryan@pipedot.org on 2014-09-21 11:55 (#2SPS) I disable password authentication entirely in favor of SSH keys. I believe that this is now the default in Ubuntu (since Trusty.) From the Ubuntu wiki:To be as hard to guess as a normal SSH key, a password would have to contain 634 random letters and numbers. Re: Some glaring security holes? (Score: 1) by zafiro17@pipedot.org on 2014-09-21 19:19 (#2SQ6) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right? I'm glad there are no intruders in my apartment, but I'm also tired of them banging on the door. I need a system that paints a big "F U" on the front door and electrifies the doorknob, front walk, and maybe parts of the sidewalk :)No really, for my front door. Although its parallel in code for my VPS would be nice, too :) Re: Some glaring security holes? (Score: 1) by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.(Sorry I'm late to the party)
Re: Some glaring security holes? (Score: 1) by zafiro17@pipedot.org on 2014-09-21 19:19 (#2SQ6) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right? I'm glad there are no intruders in my apartment, but I'm also tired of them banging on the door. I need a system that paints a big "F U" on the front door and electrifies the doorknob, front walk, and maybe parts of the sidewalk :)No really, for my front door. Although its parallel in code for my VPS would be nice, too :) Re: Some glaring security holes? (Score: 1) by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.(Sorry I'm late to the party)
Re: Some glaring security holes? (Score: 1) by evilviper@pipedot.org on 2014-09-24 07:03 (#2SVX) That stops them from getting in, but doesn't stop them from flooding your system (and your logs) with hundreds of tries per second, right?It does, actually. If you disable password authentication entirely (not just for root or specific users), the server will not provide any way for someone to send it a password. So that's the end of brute-forcing attempts.(Sorry I'm late to the party)