Believe that "paranoia" and general impractical "security" isn't security, at the best it counts as a nag, isn't "going down" anywhere.
Engineering is all about allocate the appropriate means and measures to a specific desirable end. NO MORE NO LESS! You don't see airplanes made of paper nor planes made of steel.
Topic: [SOLVED] Help with Ubuntu + MySQL (Read 4142 times)
@BCEmporium
You really think I'll go down to that level of yours now? You win, you're the greatest. If that gets you off, I'm glad I could help.
You really think I'll go down to that level of yours now? You win, you're the greatest. If that gets you off, I'm glad I could help.
Actually his method is one password, after one password and then one password. 
Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)
Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)
Lol, I think I'm gonna have to side with you on this one. Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)
Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)
I do appreciate having both of your opinions on the matter though.
Actually his method is one password, after one password and then one password.
Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)
Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)
Pass#1: To open your truecrypt container
Pass#2: PK password.
Pass#3: Your remote login. (optional, as the key pair can perform auth on their own, but you might want to su to other account)
Because he is a "security guy", probably he is using one of those password managers/generators. Which means that if you get his PC and manage to get and brutteforce his "password manager" along with his PK, you get all in one place to enter on every place he can. Surplus! Because there's no way he can remember (in the braincells) the user/pass combos he has in his password manager, you can just delete its database to lock the owner outside of his own property.
(Isn't paranoia b-e-a-u-t-i-f-u-l or what?)
I guess I don't understand the point of authenticating with a key vs a really long complicated password. Aren't they both effectively the same thing? And if I authenticated with a key, I would need a keyfile, right? Which would require that I keep a keyfile on my person whenever I wanted to access the server, whereas right now, I have the password almost memorized (a few more entries should do the trick).
You would generate a private/public key pair and place the public key on the server. The private key (which should be protected with a passphrase) stays on your PC. When you log in, no password will ever be transferred. The more servers you have, the nicer it is. As long as your pubkey is on it, you can log in with your passphrase. I wouldn't want to carry around 2-3 pages of passwords to do my daily work. Just store your private key along with your portable Bitcoin in a Truecrypt container on your usb stick.I don't carry a USB stick with me... nor do I carry pages of passwords with me. I won't go into details about my methods of saving them here though.
Guess it's just one of those different strokes for different folks thing. As long as the password isn't transmitted in plaintext for an SSH session, then I don't see why it wouldn't be a perfectly secure way of accessing a server.
I guess I don't understand the point of authenticating with a key vs a really long complicated password. Aren't they both effectively the same thing? And if I authenticated with a key, I would need a keyfile, right? Which would require that I keep a keyfile on my person whenever I wanted to access the server, whereas right now, I have the password almost memorized (a few more entries should do the trick).
You would generate a private/public key pair and place the public key on the server. The private key (which should be protected with a passphrase) stays on your PC. When you log in, no password will ever be transferred. The more servers you have, the nicer it is. As long as your pubkey is on it, you can log in with your passphrase. I wouldn't want to carry around 2-3 pages of passwords to do my daily work. Just store your private key along with your portable Bitcoin in a Truecrypt container on your usb stick. I'm not paranoid. If an attack only exists in theory, then I'm not going to go out of my way to prevent it. Especially when it costs me convenience (i.e., not being able to access the server from any computer).
Using keys has nothing to do with being able/unable to access ssh from a remote computer. Controlling that access level is done via iptables. If the remote user is allowed to go through, then he has to authenticate to ssh. Either via key or password (and actually, keys are more convenient because you can use your public key on different machines).
And I'd invaded servers where the admin was so paranoiac about some services whereas leave others way less safe open or often they put themselves down alone, blasting resources out of needless really long-shot attacks... Paranoiacs are usually a security hole not a solution.
I'm a supporter of NLS and simplicity. If I've to point something at SgtSpike's setup is about have VNC and SSH, because that's two things for the same end.
NLS is a better way to think because attacks aren't linear either, so, unless you want to keep running after patches (and be screwed if you don't get update within time) keep betting in "Linear Security Measures" and "Accountable Security".
On my "good admin" side, just got that VNC exploit I stated earlier and a list where I gave the key to the user with u:p admin:admin telling him to change it, but he decided "admin:admin" was a good combo to memorize and never changed it... can't tell was all my fault thus, either way from there on I started to handle it with generated passwords and no such linear username as "admin".
I'm a supporter of NLS and simplicity. If I've to point something at SgtSpike's setup is about have VNC and SSH, because that's two things for the same end.
NLS is a better way to think because attacks aren't linear either, so, unless you want to keep running after patches (and be screwed if you don't get update within time) keep betting in "Linear Security Measures" and "Accountable Security".
On my "good admin" side, just got that VNC exploit I stated earlier and a list where I gave the key to the user with u:p admin:admin telling him to change it, but he decided "admin:admin" was a good combo to memorize and never changed it... can't tell was all my fault thus, either way from there on I started to handle it with generated passwords and no such linear username as "admin".
So switch off your computer RIGHT NOW! And don't even think about switch it on again... as there's always a "theory" by where you may get attacked. Even using key-auth, your key can get compromised.
I made a note so I won't forget to laugh about it this weekend. When enough jokes have accumulated that is.Again; if you install a "patched" (infected) sshd it's even stupid that the "patcher" need your password to whatsoever. That said, with that done the attacker can hook to your console and perform whatever he wants. That line of though is like if a robber was already inside the vault and you were concern about the doorstep.
That line of though is like if a robber was already inside the vault through the window and grabs the key you use with all your other vaults.Let's just leave it at that. We're obviously having different ways to think about security. I've had several cases where my "paranoia" protected servers from a 0day attack.
- Theories... try to put that in practice (good luck)
Enough reason for me to drop password authentication.So switch off your computer RIGHT NOW! And don't even think about switch it on again... as there's always a "theory" by where you may get attacked. Even using key-auth, your key can get compromised.
- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".
Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.
That's an issue of who does that... you won't change that by paranoia.
Same as above, if your key get compromised (yes, your computer can be "hacked/rootkited/get infected") your advice is pointless.
Quote
That wouldn't require a brute-force; just a patched sshd because it received the password you typed in. A patch would make it dump that into a file, or mail it somewhere or whatever. But it's good you don't re-use passwords.
Again; if you install a "patched" (infected) sshd it's even stupid that the "patcher" need your password to whatsoever. That said, with that done the attacker can hook to your console and perform whatever he wants. That line of though is like if a robber was already inside the vault and you were concern about the doorstep.
I'm not paranoid. If an attack only exists in theory, then I'm not going to go out of my way to prevent it. Especially when it costs me convenience (i.e., not being able to access the server from any computer).
Using keys has nothing to do with being able/unable to access ssh from a remote computer. Controlling that access level is done via iptables. If the remote user is allowed to go through, then he has to authenticate to ssh. Either via key or password (and actually, keys are more convenient because you can use your public key on different machines).I only use that password for root - nothing else. There is no reason for someone to brute-force that password if they are already in the system.
That wouldn't require a brute-force; just a patched sshd because it received the password you typed in. A patch would make it dump that into a file, or mail it somewhere or whatever. But it's good you don't re-use passwords.That said, I still appreciate your input on the matter.
I'm just pointing things like that out because I have to deal with people who do not think about security. - Theories... try to put that in practice (good luck)
Enough reason for me to drop password authentication.- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".
Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.
I only use that password for root - nothing else. There is no reason for someone to brute-force that password if they are already in the system.
- Theories... try to put that in practice (good luck)
Enough reason for me to drop password authentication.- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".
Of course there is. Do you have any idea how many use the same password over and over again, "because it's so convenient having to remember only one"?Long story short: I will always tell users to use key based auth. There is no reason to use password auth anymore. Plus, it renders brute-force/dictionary attacks useless.
And here starts the BS... SSH is an encrypted connection like SSL.
- you can do a downgrade attack on ssh connections- on a compromised box, the attacker can patch sshd to dump your password
- Theories... try to put that in practice (good luck)
- Under such the server is already compromised, there's no reason to sniff the password, as that is an "attack from inside out".
There's no way to sniff SSH connections, the only attack surface is the MiM attack and even so the attacker have to gather the key negotiation packet and use it within a really short time frame before the server and client renegotiate the key. "Theoretically" MiM attacks works, in practice they don't. Never come to see anybody got hacked that way when using SSL (including internet banking).
And here starts the BS... SSH is an encrypted connection like SSL.
- you can do a downgrade attack on ssh connections- on a compromised box, the attacker can patch sshd to dump your password
I don't use or recommend VNC. It's known for several weaknesses and buffer-overflow attacks. I would stop that thing, as SSH is much safer and does the same.
(but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)
Interesting. I will minimize use of VNC then. (but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)
I don't use or recommend VNC. It's known for several weaknesses and buffer-overflow attacks. I would stop that thing, as SSH is much safer and does the same.
(but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)
(but that's a personal hate, as the only time I got a server "hacked" was due to VNC - RealVNC 4 at the time - a stack overflow attack allow someone to bypass the password and access that PC. Hopefully it only had some eMule downloads - mp3 and stuff alike)
Passwords can be sniffed.
And here starts the BS... SSH is an encrypted connection like SSL.
There's no issue in have SSH open, you may need to access it from somewhere else outside your home or from a different device. Just keep a good and strong password; crypt is also slow enough to make brutte-forcing not worth the while.
How can I tell if the VNC connection is encrypted? I just use RealVNC (enterprise edition).
Passwords can be sniffed.
And here starts the BS... SSH is an encrypted connection like SSL.
There's no issue in have SSH open, you may need to access it from somewhere else outside your home or from a different device. Just keep a good and strong password; crypt is also slow enough to make brutte-forcing not worth the while.
So allowing SSH from any IP is unsafe, despite having a secure password? Why?
Passwords can be sniffed.Who needs access via ssh? Only you? Good, then why allow everybody to connect? Leaving it open (with key-auth only) can be an acceptable trade-off if you don't want to end up locked out. However, that should be the last choice. Of course, everything else adds a little work, but security isn't free.
Bascially security goes like this: lock down everything. Then open what you need, but only as much as required. VNC isn't really neccessary if you have set up your ssh correctly. In the worst case you'd need a DC monkey to disable your firewall temporarily.
Sounds like I have a lot to work on with the firewall then.
Jump to: