Preventing connections bypassing firewalls when building a proxy

Question

I'm building a proxy server of sorts for a specific application. Clients connect to this server and specify what host the proxy server should connect to. From there , the proxy server connects to the final server and relays data back and forth.

When making connections, how can I prevent users of my proxy server from accessing resources they shouldn't? For instance, I wouldn't want them connecting to localhost or a VPN I use for server management. I can do some blacklisting, but I'm wondering if there is a better solution that only allows outgoing connections on a specific network interface. Maybe some way of binding a TCP client to a specific interface, or verifying that a chosen route is using a certain interface.

If it maters, I'm using Node.js to build this proxy server, and the standard net.connect() method to create TCP connections to remote servers.

Answer 1

The answer to this depends entirely on what kind of "proxy" you're building, which is unclear at the moment, perhaps rephrase?

In case you're talking about a SOCKS or HTTP proxy, I'm afraid this is impossible, there's no way to know if the target is a vpn endpoint (atleast from your proxy service's point of view). The only reference available for your proxy app to filter on is either an IP address or a DNS name being passed to your server during socks negotiation, and the source ip address where the connection is originating. You can firewall however, but this is not really proxy related ofcourse.

If you're building some sort of firewall/network stack extension/driver, iptables/kernel module etc, where you yourself are going to teardown and reestablish connections and perform serious packet fiddling, you have far greater control ofcourse, and are able to inspect pretty much every layer of connection. However in that case, your question is far to broad to answer.

What software/tools/languages are at your disposal, and what platform are you talking about?

edit: oops, missed the paragraph mentioning Node.js, so I'm assuming you're using a socks like protocol to forward the connection on to the final destination, and your proxy app is not able to query a deeper network layer. Without some further details on how your protocol works, all you have to work with is probably source IP from the established/to be established tcp connection, and destination IP/DNS being negotiated in your protocol handshake. You can perhaps use that to have your proxy service query your servers or networks vpn/routing configuration (ppp.conf/ldap/yellow pages/database/what have you) to figure out if the resource is to be restricted.

updated from information in comments:

Ok, we can divide this in 3 components:

1. A public webapplication serving browser based shoutcast clients (we can consider these two one and the same component for the sake of argument) to registered users

2. An arbitrary amount of unregulated shoutcast servers somewhere on the public internet whom these users might or might not want their clients to interface with, we may or may not be aware of these servers existence.

3. A proxy service in the middle accepting connections from webclients, forwarding streams to these servers.

I think the best way to secure these components, is by having the webapp be authoritive (it scales better, is easier to implement, easier to manage, and its already there in some shape or form). The proxy should drop any and all connections by default. Only when a user logs into the webapp/shoutcast client, does it inform the proxy which servers it can connect from and is going to connect to based on a token or user/pass combo of some sort.

When the client connects to the proxy and presents its temporary token (or other means of identification), the proxy looks it up in its internal hash table to decide where to connect to (or to verify its allowed to connect there).

You can go as far as to have adminstrators pre approve lists of existing shoutcast servers for users to select from with the webapp, or have users add there own to the system to be verified programmaticly or manually later.

As for firewalling, because ALL forwarded connections originate at the proxy application, it should also be quite easy to just drop every connection originating at the proxy and passing through certain network interfaces (admin, lan, vpn, tun, tap, etc) except for those destined to foreign adresses on the interweb.

Besides having your webapp talk to the proxy, you can even have it configure your (or amazons or whoevers) firewall rules to prevent any and all malicious traffic through your proxy (or atleast make it far easier to enforce and audit policies because any possible connection MUST therefore be owned by a valid and existing user) and also to prevent rudimentary denial of service attacks (the webapp can be hosted in the cloud far easier and cheaper then your legacy proxy service) so firewalling everything by default and opening up holes based on web/user activity is a solid game plan, both scale, complexity, performence and security wise.

Some additional common sense:

1. Protocol enforcement (you ONLY want to allow YOUR applications protocol to pass), kill any connection that doesn't conform to your rfc's/protocols. This also helps defeating exploits to vulnerable services, and prevents random other protocols to pass.

2. Establish a configurable (flatfile/database) list of sites/services (ip+port pair) that are considered to be whitelisted.

3. Establish a configureable blacklist (administrative networks, localhost, etc)

4. Be careful about the diagnostic errors you send back, or if you send back anything at all (think attacker using your proxy service to probe/map your internal networks resources by looking at the responses from your proxy).

5. Consider not implementing this proxy at all, except if you absolutely have to, if statically configured forwards/routes suffice, use that instead.. relays (open or closed) are shunned for a reason.

Kind regards,