Indirectly relaying intranet server to outside world

Question

I have an internal network of IP network cameras. The feeds from these cameras are ingested by a single server and presented from a unified web interface both internally and to the outside world (both after password screening).

There are two layers of protection - one fairly simple one at the barrier to the WAN that designates a second router as a (still limited) DMZ. The first one has some basic controls in place on type of traffic, detecting port scans and DoS attempts. While a range of ports are permitted through, key unwelcome ones are prohibited and the ports that the cameras are configured to use for communication are explicitly excluded. The second router (that handles internal traffic and their connection to the outside world) port maps to specific internal servers with unintended traffic otherwise blocked there. The network cameras may be viewed and controlled from the web interface within reason - there are a number of preset locations and scan settings for each. To communicate directly with any of the cameras would require hacking each of the routers themselves - and they are configured to only permit logins from the internal network.

The cameras contain their own http host and services - and the server that I access from outside connects to those cameras and relays images, jpeg streams, etc. to the outside world. I want to be able to optionally provide relay service to those cameras' admin interfaces without directly providing routing to those cameras from the outside world (simply because I can control what software is on the relay host but have relatively little control over the camera firmware). There are a variety of administrative features of the cameras (control over infrared, changing preset angles, etc) that I would rather avoid having to write alternate interfaces to and would like to be able to provide their interfaces through a relay that I could monitor and filter should exploits for the cameras themselves become known. Mostly, I'm concerned that since the cameras themselves are fairly sophisticated web hosts, that if directly revealed to the outside they could roll out the welcome mat to intruding on the internal network. I've done a lot to limit my exposure (and thus let me concentrate my security efforts). Opaque third-party hardware shouldn't be my weak spot.

An http relay wouldn't be completely onerous to write - I've done a fair amount of port-level coding in the past - but mature, existing solutions would be nice.

So the question is: is there an approach to implementing an existing http relay that will meet my requirements?

(Note that I'm currently using VPN to get into the network from outside when I need to tweak something - but that's not the user experience I'm looking for)

Answer 1

Since access has been sufficiently restricted, the weakest link is the HTTP request. This is especially true based on comments regarding the poor interfaces of the IP cameras. They likely won't do well if irregular requests are sent. Therefore consider a Web Application Firewall (WAF) such as ModSecurity as it will provide more flexibility over what traffic is allowed by defining rules for what a request should really look like.

Answer 2

Proxying as you propose doing gives you the ability to add additional authentication and encryption, but nothing else.

IP cameras have terrible interfaces and terrible code. If you simply proxy the requests you will be proxying every possible exploit in the camera. If authenticated user sessions are considered a potential attack vector in your risk assessment, you shouldn't simply proxy, you need at the very least to validate every request is expected.

If authenticated user sessions are not considered an attack vector in your risk assessment, then that's a problem you should fix first.