2

On my CentOS server at mydomain.com, I have an svn web application running on port 8880. I want to hide the port: at this moment, if anybody wants to access, they need to access through http://thisdomain.com:8880/svn. I want to make the application accessible at http://thisdomain.com/.

  • What do you mean by "hide," exactly? Completely inaccessible? Accessible only if you know some trick? Moved? Blackholed? – Warren Young Nov 6 '13 at 5:09
  • Close the port and access it via SSH port forwarding or a VPN tunnel. – Tim Nov 6 '13 at 15:15
  • @WarrenYoung Hide as in hide the port from the URL. It took me a while to understand. – Gilles 'SO- stop being evil' Nov 6 '13 at 21:24
3

Option 1: NAT Port Forwarding

If all you need to do here is redirect requests on external port 80 to an internal program running on port 8880, you can use iptables port forwarding for this:

# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j REDIRECT --to 127.0.0.1:8880

There are several points to understand here:

  1. I'm guessing you're running on some sort of VPS, so eth0 probably isn't the right interface name. You will have to replace this if so.

    Incidentally, if you're on shared hosting or your VPS doesn't allow iptables, skip to the next option.

  2. As written above, the rule assumes you have configured this internal program to listen only on the localhost interface, 127.0.0.1. This gets you the "hiding" behavior you've asked for.

  3. Your preexisting firewall rules may interfere with this rule as it is currently written. There's no substitute for actually understanding your current iptables rules before modifying them, but if it doesn't work, you can blindly try adding another rule like this:

    # iptables -A FORWARD -p tcp -i eth0 --dport 80 -j ACCEPT
    

    Such a thing would be needed if your default FORWARD chain's rule is DENY.

  4. You need to make sure these rules come up on boot.

    If you're careful, you can edit /etc/sysconfig/iptables on CentOS to accomplish this. This file uses a syntax similar to — but not exactly like — the iptables command line language. You should probably test this on a local VM to reduce the chances that you'll accidentally lock yourself out of your public server.

    It would be safer to put the commands in /etc/rc.local, but beware that if you restart the iptables service (e.g., service iptables reload) your custom rules will get removed if they're not in /etc/sysconfig/iptables.

If you've read through all that and wonder why I've made it Option 1 when Option 2 below is simpler, it is that it is much more efficient. Port forwarding is basically "free" in terms of resources once you've set it up.

Option 2: HTTP Proxy

Another way to go is to use some sort of HTTP proxy. I have used Tinyproxy for this sort of thing. It's more flexible than NAT port forwarding and doesn't require that you muck with the OS's firewall.

It is packaged for CentOS in EPEL, so that once you have enabled the EPEL repository, you just need to say yum install tinyproxy.

Make these changes in the stock /etc/tinyproxy/tinyproxy.conf file:

Port 80
Upstream localhost:8880

Also, comment out the Allow line, so Tinyproxy will accept connections from outside IPs:

# Allow 127.0.0.1

You need to make sure that Apache isn't running (service httpd stop) when you try to start this (service tinyproxy start), since it will be taking over port 80.

The documentation for Tinyproxy is just a terse reference, so I'm uncertain whether this use of Upstream is a hack better replaced by use of Tinyproxy's reverse proxy features. It works for me, though, and it takes fewer changes to the configuration file, so this is how I do it.

If you're wondering why I haven't just used Apache for this from the start, it's simply that it's more complex and takes more resources. Apache does have proxying features. Unless you need the full power of Apache, though, I don't see a reason to go that way over Tinyproxy.

Unlike NAT port forwarding, it does take some system resources to run Tinyproxy. It takes some RAM, and if your traffic level is high enough, it could become I/O bound. If your server isn't particularly busy, though, you probably won't even notice that it is running.

2

This would be done in your httpd.conf file as a virtual host. It would look something like:

<VirtualHost thisdomain.com:8880>
DocumentRoot /www/docs/svn/myapp
ServerName thisdomain.com
</VirtualHost

Make sure that apache is lisening for the correct port. Find where is says listen 80 and include listen 8880

  • Hi Jeight, i have this on the httpd.conf: ServerRoot "/data/csvn" Include "data/conf/csvn_modules_httpd.conf" Include "data/conf/csvn_main_httpd.conf" Include "data/conf/csvn_logging.conf" Include "data/conf/csvn_default_dirs_httpd.conf" Include "data/conf/svn_viewvc_httpd.conf" Include "data/conf/csvn_misc_httpd.conf" When u say DocumentRoot i need to point to? – Marco Herrarte Nov 6 '13 at 21:50
  • I'm not sure I understand what you are asking. DocumentRoot is the path that you want your domain to start in. So when people go to thisdomain.com it starts them using that path as root. – Jeight Nov 7 '13 at 0:05
  • I don't think this does what the OP wants. The OP has a service already listing on port 8880, and wants it to appear on port 80. Maybe you could rewrite your answer to show how to use Apache as a reverse proxy to accomplish this? – Warren Young Nov 7 '13 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.