Any good reason localized tcp traffic should be encrypted?

[Red Squirrel]

Let's say I have a server app that runs on localhost, and a client on said host connects to it, and there is sensitive data being transferred back and forth. Is there any reason to encrypt it even though it's local? I'm speaking mostly for Linux here. Say a few regular users have shell access, is there anything they can actually do to sniff the local traffic? Like even if I ensure they don't have access to tcpdump, could one theoretically upload a packet sniffer and still be able to sniff the local traffic?

 

[n0cmonkey]

If they can get a sniffer on there and run it with the proper privileges, they can get the data. Why not encrypt it?

 

[Red Squirrel]

Hmm was afraid of that. I'll have to look at a way to code in encryption then. This is for a custom app I'll be writing so it's not as easy as turning encryption on. Actually have to code it and make it secure and not easy to crack.

Come to think of it, is MySQL normally encrypted?

 

[Crusty]

Hmm was afraid of that. I'll have to look at a way to code in encryption then. This is for a custom app I'll be writing so it's not as easy as turning encryption on. Actually have to code it and make it secure and not easy to crack.

Come to think of it, is MySQL normally encrypted?

No, you can specify SSL certs in the configuration options to enable it though.

 

[Zugzwang152]

another option is to create an IPSEC tunnel between the server and the hosts that are authorized to connect to it.

 

[Red Squirrel]

No, you can specify SSL certs in the configuration options to enable it though.

Hmm is this something that is normally turned on in a shared hosting environment? I'm just considering my security measures for when I start a web host, which will be in quite a while. I'm even debating on just not giving out shell access, that will make things much easier, but I know lot of people rather have it. I know personally, I like having it so I can automate stuff like backups.

 

[Crusty]

I've had great success using autossh to keep a persistent SSH tunnel between my virtual servers that can't use a vpn due to kernel restrictions. I've used stunnel in the past as well and it worked great, but during this last upgrade I decided to try autossh and it's been working great since. Just put one command in your /etc/rc.local file and you've got a persistent secure tunnel between computers assuming you've already got SSH setup with public/private keys setup.

Even though all these links are on private networks they are still out of my control and I definitely don't want my mysql data being sent in clear text on any network I don't have physical control over.

 

[Crusty]

Hmm is this something that is normally turned on in a shared hosting environment? I'm just considering my security measures for when I start a web host, which will be in quite a while. I'm even debating on just not giving out shell access, that will make things much easier, but I know lot of people rather have it. I know personally, I like having it so I can automate stuff like backups.

If you are connecting to mysqld listening on localhost you've got no reason to worry as you can use the UNIX socket specified in the my.cnf file to communicate with mysqld. IIRC most client libraries will give you the option of using this over TCP sockets.

There's no reason to give shell access to clients on shared hosting, give them the ability to schedule cron jobs and that's it. cPanel has a good implementation of this IMO as they also give you the option to setup jailed shells for clients, but the default is no shell access.

 

[Red Squirrel]

If you are connecting to mysqld listening on localhost you've got no reason to worry as you can use the UNIX socket specified in the my.cnf file to communicate with mysqld. IIRC most client libraries will give you the option of using this over TCP sockets.

There's no reason to give shell access to clients on shared hosting, give them the ability to schedule cron jobs and that's it. cPanel has a good implementation of this IMO as they also give you the option to setup jailed shells for clients, but the default is no shell access.

Though with a cron job, one could technically run a shell script that starts tcpdump or something, can they? I've never used the cron feature in cpanel, so not sure how it works exactly.

If I don't give out ssh access then I probably have to worry less about local data security, as long as I block other means to gain access. I'd probably have to block the "Exec" commands in php as well. Something to read up on, I'm not quite there yet.