[SOLVED] Help with Ubuntu + MySQL

[SgtSpike]

Just a tip, don't bind MySQL to 0.0.0.0, it has no protection at all against brutte-forcing, rather create a XML or JSON RPC to filter and output data between servers.

I was hoping I could bind it to a specific external IP address (mine), but also still have it accessible from the localhost.  Evidently not.  All it would have been for is convenience, so I can live without that.  Thanks for the heads up on 0.0.0.0 though.

[1714103901]

1714103901

[Bitsky]

You can bind mysqld to an IP of your server, or to all. Then lock down the port 3306 in iptables (of course you already firewalled your server, right?) and then whitelist your IP. If you have a static IP it's simple; if not, get a dyndns entry and put together a little bash script which adjust your firewall rules every x minutes.

Or learn using the mysql shell directly; there's no need for a remote management tool at all. Then you can lock mysqld down on localhost only.

[SgtSpike]

You can bind mysqld to an IP of your server, or to all. Then lock down the port 3306 in iptables (of course you already firewalled your server, right?) and then whitelist your IP. If you have a static IP it's simple; if not, get a dyndns entry and put together a little bash script which adjust your firewall rules every x minutes.

Or learn using the mysql shell directly; there's no need for a remote management tool at all. Then you can lock mysqld down on localhost only.

I haven't installed or tweaked the firewall beyond whatever is default in Ubuntu, no.  Probably something I should do.    I don't have anything important on the server yet though.  But thanks for the advice.

My IP isn't static, but it has only changed once in the last 10 months.  I guess losing all access if my IP changed would be a bad thing though. 

[Bitsky]

Lock down everything and only allow the ports you really need (eg 80) to be accessed from the outside. You could allow ssh if you switch to public-keys and disable password auth. Of course it would be better to restrict that too, but that way you can still ssh in if you don't want to go the dyndns route if your IP changes. You can also use something like fail2ban too.

[SgtSpike]

Lock down everything and only allow the ports you really need (eg 80) to be accessed from the outside. You could allow ssh if you switch to public-keys and disable password auth. Of course it would be better to restrict that too, but that way you can still ssh in if you don't want to go the dyndns route if your IP changes. You can also use something like fail2ban too.

So allowing SSH from any IP is unsafe, despite having a secure password?  Why?

I do have VNC access, so perhaps I could use that as the failsafe if my IP changed.

I'll look in to fail2ban as well, thanks for the suggestion.

[Bitsky]

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.

[SgtSpike]

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.

Considering who the VPS is rented from, I won't rely on them for immediate assistance.

Sounds like I have a lot to work on with the firewall then. 

[BCEmporium]

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.

[SgtSpike]

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.

Thanks for the clarification.  I thought that was the case, but still know little enough that my knowledge is easily swayed.

How can I tell if the VNC connection is encrypted?  I just use RealVNC (enterprise edition).

[BCEmporium]

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)

[SgtSpike]

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.

[Bitsky]

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

[BCEmporium]

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).

[Bitsky]

- 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.

[SgtSpike]

- 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'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).  That said, I still appreciate your input on the matter.

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.

[Bitsky]

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.

[BCEmporium]

- 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.

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.

[Bitsky]

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.

[BCEmporium]

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".

[SgtSpike]

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 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).