{"id":333,"date":"2020-09-03T00:13:24","date_gmt":"2020-09-02T22:13:24","guid":{"rendered":"https:\/\/raulbalanza.me\/?p=333"},"modified":"2024-01-18T23:18:42","modified_gmt":"2024-01-18T22:18:42","slug":"hiding-a-servers-ip-by-means-of-a-reverse-proxy","status":"publish","type":"post","link":"https:\/\/raulbalanza.me\/es\/2020\/09\/03\/hiding-a-servers-ip-by-means-of-a-reverse-proxy\/","title":{"rendered":"Hiding a server’s IP by means of a reverse proxy"},"content":{"rendered":"

Este art\u00edculo fue escrito originalmente en Ingl\u00e9s. Sin embargo, una versi\u00f3n traducida autom\u00e1ticamente se encuentra aqu\u00ed<\/a>.<\/em><\/p>\n\n\n\n

When it comes to hosting public services online<\/strong> (such as a website, the backend of an application…), several options can be considered. The most common one is to rent a dedicated server from a hosting company and to host the desired service there. However, this option can end up being too costly depending on the hardware and software needs of such service, that could lead us to consider an alternative option.<\/p>\n\n\n\n

A great choice could be to host our own server<\/strong>, either at home or in the office. In that case, two problems arise: having a dynamic IP, which is what most ISPs offer to the general public (and could be solved by using Dynamic DNS); and the hassle of sharing the public IP of our office\/home, so that anyone can connect to the service (and also attack it).<\/p>\n\n\n\n

Moreover, due to the IPv4 address exhaustion problem<\/strong>[1]<\/sup>, lately several ISPs are starting to implement a network design approach known as Carrier-Grade NAT<\/em>[2]<\/sup> (or CG-NAT), that groups several clients in the same public IP, which does not allow for port forwarding, and could make it impossible to host any public service from our local network.<\/p>\n\n\n

\n
\"\"
Figure 1. CG-NAT scheme<\/figcaption><\/figure><\/div>\n\n\n

In those cases, or in any other in which it is of our interest to hide the IP of a computer that hosts a public service, a reverse proxy<\/strong> could be the solution to that problem.<\/p>\n\n\n\n

Definition<\/h2>\n\n\n\n

A reverse proxy<\/strong>[3]<\/sup> can be defined as a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the server itself<\/em>.<\/p>\n\n\n

\n
\"\"
Figure 2. Reverse proxy diagram<\/figcaption><\/figure><\/div>\n\n\n

The process of interchanging network packets would be as follows:<\/p>\n\n\n\n

    \n
  1. The client <\/strong>connects to the proxy<\/strong>‘s IP, sending some packets<\/li>\n\n\n\n
  2. The proxy <\/strong>redirects those packets to the final server<\/strong> through a VPN.<\/li>\n\n\n\n
  3. The final server<\/strong> processes the request and returns the packets to the proxy<\/strong>.<\/li>\n\n\n\n
  4. The proxy <\/strong>sends the reply to the client<\/strong>, who sees from his perspective that the packets have been processed in the proxy.<\/li>\n<\/ol>\n\n\n\n

    Using this method, the IP that would be exposed to the Internet would be the proxy one, so in case of receiving an attack, it would be enough to shutdown the proxy machine in order to stop the attack and to save the local network from going down.<\/p>\n\n\n\n

    Installation<\/h2>\n\n\n\n

    For the installation process[4]<\/sup>, it is assumed that both systems run a Debian-based Linux distribution. The following steps are divided into two parts: the proxy <\/strong>server and the final server<\/strong> side.<\/p>\n\n\n\n

    1: Proxy server<\/h3>\n\n\n\n

    For the proxy server, iptables <\/em>will be the software in charge of routing the packets to the final server. Although it comes preinstalled in most Linux distributions, we will make sure by running:<\/p>\n\n\n\n

    sudo apt-get install iptables<\/strong><\/p>\n\n\n\n

    Once the installation ends, the next step is to install the VPN server that will establish the connection between the proxy and the final server, which in this case is OpenVPN<\/em>. To do so, we will run the following command[5]<\/sup>:<\/p>\n\n\n\n

    wget https:\/\/git.io\/vpn -O openvpn-install.sh && bash openvpn-install.sh<\/strong><\/p>\n\n\n

    \n
    \"\"
    Figure 3. OpenVPN install script<\/figcaption><\/figure><\/div>\n\n\n

    The installer will ask for several preferences, that you can mostly leave with their default values. When the server finishes its installation, it will be automatically started, and a VPN profile with the ‘.ovpn<\/em><\/strong>‘ extension will be created. That file needs to be transferred to the final server<\/strong>.<\/p>\n\n\n\n

    2: Final server<\/h3>\n\n\n\n

    Now that we already have the VPN up and running, we can connect to it from our final server. To do so, first of all the OpenVPN client must be installed, by running:<\/p>\n\n\n\n

    sudo apt-get install openvpn<\/strong><\/p>\n\n\n\n

    When the installation finishes, we can now connect to the server. We will navigate to the folder in which the previous ‘.ovpn<\/em><\/strong>‘ file is now located, and then the connection can be started by running:<\/p>\n\n\n\n

    sudo openvpn profile.ovpn<\/strong><\/p>\n\n\n\n

    At this time the tunnel between the proxy and the final server is already created, and only packet redirection is left to configure. For the last part of the installation in the proxy server, we need to get the IP address that the VPN adapter has assigned to the final server. This address can be obtained by using:<\/p>\n\n\n\n

    sudo ip a<\/strong><\/p>\n\n\n\n

    And then it will be located in the inet<\/em> <\/strong>section of the corresponding adapter, that will have a name like ‘tun0<\/strong>‘. You should take note of it, as it will be required in further steps.<\/p>\n\n\n\n

    3: Proxy server<\/h3>\n\n\n\n

    Once we have the VPN tunnel already set up, the last step is to create the forwarding rules that will route packets from the proxy to the final server. To do it, we will change the iptables<\/em>‘ configuration.<\/p>\n\n\n\n

    First, export your current configuration by executing the following command:<\/p>\n\n\n\n

    sudo iptables-save > \/path\/to\/config.cfg<\/strong><\/p>\n\n\n\n

    After the previous command, the current configuration will be stored in the specified path. Next up, open it with a text editor and modify the ‘*nat<\/strong>‘ section with the following values:<\/p>\n\n\n\n

    *nat\n:PREROUTING ACCEPT [0:0]\n:INPUT ACCEPT [0:0]\n:OUTPUT ACCEPT [0:0]\n:POSTROUTING ACCEPT [0:0]\n# Forwarding incoming port 80 on proxy to final server IP's port 8080 through it's VPN IP\n-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination IP_VPN_FINAL<\/b>:8080\n# Change source ips from VPN IP to VPS' IP for all outbound traffic\n-A POSTROUTING -s 10.8.0.0\/24 -j SNAT --to-source VPS_PUBLIC_IP<\/b><\/pre>\n\n\n\n
    The previous example contains a forwarding rule that redirects connections arriving to proxy’s port 80, to final server’s port 8080 in the TCP protocol. However, several lines can be added to allow for different ports and protocols to be forwarded, following this pattern:<\/p>\n\n\n\n
    -A PREROUTING -p PROTOCOL<\/b> -m PROTOCOL<\/b> --dport PROXY_PORT<\/b> -j DNAT --to-destination IP_VPN_FINAL<\/strong>:SERVER_PORT<\/b><\/pre>\n\n\n\n
    In that configuration example, some values must be also replaced depending on your own addresses:<\/p>\n\n\n\n