5 ms·

I don't even expose redis externally, I tunnel all connections over ssh using autossh and a restricted user on the server running redis. Something like: aut

I don't even expose redis externally, I tunnel all connections over ssh using autossh and a restricted user on the server running redis. Something like: autossh -M 0 -N -L 6379:localhost:6379 -o "ServerAliveInterval 60" \ -o "ServerAliveCountMax 3" -o "StrictHostKeyChecking=no" -o "BatchMode=yes" \ -i /home/tunnel/.ssh/id_rsa redis_tunnel_user@redis.host Then on the clent side you just connect to localhost:6379 as if redis was local. Edit: Should add autossh automatically reconnects the tunnel if the connection fails. Vanilla ssh does not.

antirez 11y ago
Good point. Btw tunneling via SSH being so easy is one reason most users gave as advice, during the Redis developers London meeting, to avoid putting SSL native support inside Redis itself.
patio11 11y ago
FWIW: Appointment Reminder also does this. It's part of your healthy HIPAA-approved breakfast. (One of the other things you should strongly consider, if you care about HIPAA compliance, is using either full-disk encryption or encryping the directory where Redis' data file resides. We do this with encryptfs. We also encryptfs the Tarsnap cache directory, which holds recoverable cleartext. Tarsnap archives are encrypted automatically without requiring further work.) There also exist another dozen or so box-ticking requirements with regards to procedures and documentation, but those are the main rubber-hits-the-hard-disk things you have to do with respect to using Redis for PHI.
- iheartmemcache 11y ago
  Oh Patrick, I bet you know what I'm going to ask even before I ask it. Implementation details please.
  - patio11 11y ago
    I'm having trouble parsing this -- what details do you want about what?
    - iheartmemcache 11y ago
      Oh sorry, what other things did you do to fulfill the PHI criteria? I've had PCI-DSS, SOX and federal security experience, but nothing in healthcare. As such, I was wondering what sort of security protocols were required, and how much of it (if any) is just hand-waving security theater ?
- elcct 11y ago
  Problem is that even exposing Redis via tunnel is not really safe, because you never know what the client could be up to. You probably need a supervisor between the tunnel and the client that will manually approve each request to see if it is appropriate and doesn't contain anything illegal or malicious. That supervisor of course has to be screened by trusted body of government officials.
anewhnaccount 11y ago
I was going to object with "port forwarding is tcp over tcp!" but it turns out after a little research that this is totally wrong and its faster this way than openvpn: http://blog.backslasher.net/ssh-openvpn-tunneling.html http://blog.backslasher.net/ssh-openvpn-tunneling.html . I guess I ended up thinking this because it's how the dynamic port forwarding works?
- iheartmemcache 11y ago
  edit: Yeah, that article is not just misleading, it's constructed in a way that seems methodological enough to be concrete that it's dangerous. Different tools for different purposes, and he didn't even bother going to the vendor's own wiki to check for documentation. ugh. Don't bother reading this rant below unless you want technical details, but that administrator misconfigured his VPN to the point where OVPN underperformed by four times what it should have been. Its been ages since I played around with networking at a low-level (we're talking teenage years, when ARIN didn't charge for netblocks, and Cisco 7206VXR's could hold the entire internet BGP table in it), but I'll give it a go. 1) It's not a fair comparison to begin with since OpenVPN is effectively maintaining a lot more information as it's acting as either a) as is in his configuration, a Layer 3 router, there's bound to be more overhead as it's maintaining a lot more information than a single Point-to-Point SSH connection; he should be using Bridged Mode and routing via a virtual switch at L2 instead.[1] He sort of acknowledged this by making an appeal to the OSI layer, but then didn't check to see if there was a way to disable the full-routing functionality and move down to switching. As he himself said, he's using this simply to tunnel peer-to-peer, so if he configures his subnet as a /30 on OpenVPN, defined static routes, and read this guide [2] he'd see that an MTU at ~6000 is recommended (jumbo frames indeed!). Starting with a similar config as his (using iperf), the OpenVPN guys went from ~125Mbps to ~500 mbps. That was without kernel tuning, just parameter changing. 2) I haven't tested this, but if you read the comments within the thread (especially from those made by kasperd his networking device is misconfigured at the kernel level (for his purposes), leading to tons of fragmentation that can be rectified [see: the MTU/MSS discussion in the OP's "Read more comments"]. edit: Yep I was right. Check cite [2]. I'm sure someone who's actually in networking can address this further but this is not only apples-to-oranges but rotten-apples*-to-oranges. (where rotten-apples == a very poorly configured set of OpenVPN instances). [1] http://serverfault.com/questions/653211/ssh-tunneling-is-faster-than-openvpn-could-it-be http://serverfault.com/questions/653211/ssh-tunneling-is-fas... [2] https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_...
emmelaich 11y ago
... not stunnel? Also, FWIW, I use systemd service for an ssh tunnel instead of autossh. Works brilliantly.
- emmelaich 11y ago
  Details: [Unit] Description=SSH remote forwarding to here After=network-online.target Requires=network-online.target [Service] User=autossh ExecStart=/bin/ssh -v -N -o PasswordAuthentication=no -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 2222:localhost:22 -o TCPKeepAlive=yes -p 222 -i /home/autossh/.ssh/autossh autossh@some-hostname-redacted.com Restart=on-failure RestartSec=1200 [Install] WantedBy=multi-user.target
cperciva 11y ago
You might want to look at using spiped for this. It's much simpler (aka. more secure) than any ssh implementation, and because it uses one TCP connection per TCP connection, it avoids reconnection and multiplexing issues.
- aidenn0 11y ago
  Absolutely, I use spiped to encrypt connections between my reverse-proxy and backend. It's marvelously easy to setup.

antirez 11y ago

Good point. Btw tunneling via SSH being so easy is one reason most users gave as advice, during the Redis developers London meeting, to avoid putting SSL native support inside Redis itself.

patio11 11y ago

FWIW: Appointment Reminder also does this. It's part of your healthy HIPAA-approved breakfast. (One of the other things you should strongly consider, if you care about HIPAA compliance, is using either full-disk encryption or encryping the directory where Redis' data file resides. We do this with encryptfs. We also encryptfs the Tarsnap cache directory, which holds recoverable cleartext. Tarsnap archives are encrypted automatically without requiring further work.) There also exist another dozen or so box-ticking requirements with regards to procedures and documentation, but those are the main rubber-hits-the-hard-disk things you have to do with respect to using Redis for PHI.

iheartmemcache 11y ago
Oh Patrick, I bet you know what I'm going to ask even before I ask it. Implementation details please.
- patio11 11y ago
  I'm having trouble parsing this -- what details do you want about what?
  - iheartmemcache 11y ago
    Oh sorry, what other things did you do to fulfill the PHI criteria? I've had PCI-DSS, SOX and federal security experience, but nothing in healthcare. As such, I was wondering what sort of security protocols were required, and how much of it (if any) is just hand-waving security theater ?
elcct 11y ago
Problem is that even exposing Redis via tunnel is not really safe, because you never know what the client could be up to. You probably need a supervisor between the tunnel and the client that will manually approve each request to see if it is appropriate and doesn't contain anything illegal or malicious. That supervisor of course has to be screened by trusted body of government officials.

anewhnaccount 11y ago

I was going to object with "port forwarding is tcp over tcp!" but it turns out after a little research that this is totally wrong and its faster this way than openvpn: http://blog.backslasher.net/ssh-openvpn-tunneling.html http://blog.backslasher.net/ssh-openvpn-tunneling.html . I guess I ended up thinking this because it's how the dynamic port forwarding works?

iheartmemcache 11y ago
edit: Yeah, that article is not just misleading, it's constructed in a way that seems methodological enough to be concrete that it's dangerous. Different tools for different purposes, and he didn't even bother going to the vendor's own wiki to check for documentation. ugh. Don't bother reading this rant below unless you want technical details, but that administrator misconfigured his VPN to the point where OVPN underperformed by four times what it should have been. Its been ages since I played around with networking at a low-level (we're talking teenage years, when ARIN didn't charge for netblocks, and Cisco 7206VXR's could hold the entire internet BGP table in it), but I'll give it a go. 1) It's not a fair comparison to begin with since OpenVPN is effectively maintaining a lot more information as it's acting as either a) as is in his configuration, a Layer 3 router, there's bound to be more overhead as it's maintaining a lot more information than a single Point-to-Point SSH connection; he should be using Bridged Mode and routing via a virtual switch at L2 instead.[1] He sort of acknowledged this by making an appeal to the OSI layer, but then didn't check to see if there was a way to disable the full-routing functionality and move down to switching. As he himself said, he's using this simply to tunnel peer-to-peer, so if he configures his subnet as a /30 on OpenVPN, defined static routes, and read this guide [2] he'd see that an MTU at ~6000 is recommended (jumbo frames indeed!). Starting with a similar config as his (using iperf), the OpenVPN guys went from ~125Mbps to ~500 mbps. That was without kernel tuning, just parameter changing. 2) I haven't tested this, but if you read the comments within the thread (especially from those made by kasperd his networking device is misconfigured at the kernel level (for his purposes), leading to tons of fragmentation that can be rectified [see: the MTU/MSS discussion in the OP's "Read more comments"]. edit: Yep I was right. Check cite [2]. I'm sure someone who's actually in networking can address this further but this is not only apples-to-oranges but rotten-apples*-to-oranges. (where rotten-apples == a very poorly configured set of OpenVPN instances). [1] http://serverfault.com/questions/653211/ssh-tunneling-is-faster-than-openvpn-could-it-be http://serverfault.com/questions/653211/ssh-tunneling-is-fas... [2] https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_...

emmelaich 11y ago

... not stunnel? Also, FWIW, I use systemd service for an ssh tunnel instead of autossh. Works brilliantly.

emmelaich 11y ago
Details: [Unit] Description=SSH remote forwarding to here After=network-online.target Requires=network-online.target [Service] User=autossh ExecStart=/bin/ssh -v -N -o PasswordAuthentication=no -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 2222:localhost:22 -o TCPKeepAlive=yes -p 222 -i /home/autossh/.ssh/autossh autossh@some-hostname-redacted.com Restart=on-failure RestartSec=1200 [Install] WantedBy=multi-user.target

cperciva 11y ago

You might want to look at using spiped for this. It's much simpler (aka. more secure) than any ssh implementation, and because it uses one TCP connection per TCP connection, it avoids reconnection and multiplexing issues.

aidenn0 11y ago
Absolutely, I use spiped to encrypt connections between my reverse-proxy and backend. It's marvelously easy to setup.