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.

0

2 Answers 2

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 [email protected] 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.

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

4

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .