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
On my CentOS server at
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:
I'm guessing you're running on some sort of VPS, so
eth0probably 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.
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.
Your preexisting firewall rules may interfere with this rule as it is currently written. There's no substitute for actually understanding your current
iptablesrules 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
FORWARDchain's rule is
You need to make sure these rules come up on boot.
If you're careful, you can edit
/etc/sysconfig/iptableson CentOS to accomplish this. This file uses a syntax similar to — but not exactly like — the
iptablescommand 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
service iptables reload) your custom rules will get removed if they're not in
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
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.
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