0

There are lots of recommended practices and tutorials for securing various components of a LEMP/LAMP stack when running in a cluster whose private network traffic is shared by other, potentially hostile, hosts (e.g., AWS, Vultr, DigitalOcean). You can secure reverse proxy and MySQL traffic with TLS. But, for clusters which involve a set of instances hosting PHP-FPM pools, there doesn't seem to be any literature on securing the TCP traffic between the web server instance and the PHP-FPM instances.

Is it even necessary, or is there a reason there's no literature (e.g., the traffic is encrypted, or no sane VPS/cloud providers would run private network interfaces in promiscuous mode)? I can see problems when a request comes in to an HTTPS site, the site sends the request details to the PHP-FPM pool (including, say, passwords or credit card numbers), and a third party listens to that traffic somehow.

Paul d'Aoust
  • 101
  • 2

2 Answers2

1

SSH tunnels can be a great option to securely connect across a hostile network. We've found SSH tunnels very simple to implement and understand and more reliable, than some VPN options. Also can tunnel all sorts of things even when the native app protocol doesn't support SSL/TLS.

Good to put your SSH in a bash script that will run the SSH tunnel in a loop and restart it if it dies.

Here's an example of a script we use (the names have been changed to protect the dishonest):

#!/bin/bash
umask 0077
if [ -L "$0" ]
then
    EXE=`readlink -e "$0"`
else
    EXE="$0"
fi
if [ "$1" = "daemon" ]
then
    while [ 1 ]
    do
        /usr/bin/ssh -L 127.0.0.1:5432:127.0.0.1:5432 -n -T -x tunnelusername@db.yourdomain.com sleep 100000000 >> "$EXE.log" 2>&1 &                                                                                                                                                       
        echo "$!" > "$EXE.ssh.pid"
        wait
        sleep 5
    done
elif [ "$1" = "stop" ]
then
    if [ -f "$EXE.pid" ]
    then
        kill `cat "$EXE.pid"`
        sleep 0.1
        rm -f "$EXE.pid"
    fi
    if [ -f "$EXE.ssh.pid" ]
    then
        kill `cat "$EXE.ssh.pid"`
        sleep 0.1
        rm -f "$EXE.ssh.pid"
    fi
else
    "$0" stop
    nohup "$0" daemon >> "$EXE.log" 2>&1 &
    echo "$!" > "$EXE.pid"
fi

You modify the SSH line to perform appropriate tunneling. You call the script with "start" or "stop" parameters. The script runs a daemon that will restart SSH if it ever dies.

For the tunnels, make a minimally privileged user and group on the other end to connect to, "tunnelusername" here.

Dan Armstrong
  • 821
  • 4
  • 6
0

Regarding the credit cards: To operate with these, you've go get a license, which you won't if running in such environments, not by accident, but because of reasons you mentioned above. Regarding your question: If the private network is shared with others, I would recommend to encrypt all the traffic, via stunnel for example.

(But still, it's an shared environment: If the people next to you find a flaw which enables them to take over the host or other virtual machines, they could read the traffic before it's encrypted - this shouldn't render useless what I've just wrote, just to keep this in mind.)

gxx
  • 5,591
  • 2
  • 22
  • 42
  • Thanks for the response. One thing I didn't understand though: what sort of license are you referring to? – Paul d'Aoust Apr 27 '16 at 17:52
  • "License" was the wrong term, actually I wanted to refer to "standards":[The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. Essentially any merchant that has a Merchant ID (MID).](https://www.pcicomplianceguide.org/pci-faqs-2/#1) – gxx Apr 27 '16 at 18:36
  • Oh, okay, PCI-DSS standards. Makes sense, although I suspect that the PCI-DSS would permit this configuration in the right situation -- e.g., tunnelling PHP-FPM traffic through `stunnel`. What's your reading? – Paul d'Aoust Apr 27 '16 at 20:36
  • Actually I've got not really any knowledge in this topic, because up until now I've never dealt with credit cards and requirements for processing these etc., but I could / would imagine, that you're not allowed to do this on rented VPS, aka an environment, where the physical machines are not owned by yourself, because you have no way to check who got access to the data. – gxx Apr 28 '16 at 12:27