Nice post. What is aggressive or not is hard to say, generally - YOU should decide that. All three are fine, but have different approach, usability issues, price etc.
I work for company that passes VISA/Mastercard security certification (PCI) every year and everything depends on what you do and what risks you might have. There is no company without risk, it might be minimal/insignificant for you, but risks are always present. Maybe it's enough for you to have http proxy and you are not afraid of guys, who are able to use http tunnel or use http-based remote applications etc (like Skype, Teamviewer) and you don't have control over application control, don't have an 802.1x certificate based auth on ethernet level with machine which has dual disk encryption which needs a special usb key for every bootup, despite this usb key is taken from one of 20 10-inch thick steel safes opened by splitted two passwords changed 6 hours ago, known by two guys, delivered by two security specialists with two guards and four remotely controlled cameras and all that is underground, 300m depth. What is applicable/enough for you - again, you decide.
If your employees are security experts and bad guys, able to use several tools and hide from cameras - there is no way to control them by watching their traffic and packets - they still can hide and make tunnel wherever they want, you should consider other things too (I guess Palo Alto Enterprise Perimiter can do it, if you need it so much and you pay for that USD 1 mil).
All your proposals are OK - there is nothing wrong to use any it in enterprise.
I recommend to take a look at SIEM alerting products too (Solarwinds SIEM, Trustwave SIEM, IBM Q1 Labs Qradar). Maybe you would like to watch the situation, not limit it in very details etc.
It is impossible. TCP is statefull protocol. User end computer is involved in every step of connection and it will never answer to two separate servers trying to communicate to it. All you can do is collect all http request on webserver or some proxy and replay them. But that will not give and exact concurrency or traffic conditions of a live server.
Best Answer
There are a few standard ways of proxying inbound general network traffic ("reverse proxying").
If the inbound traffic is only HTTP(S), then a web server can forward it. See e.g.
ProxyPass
in Apache.Arbitrary inbound TCP traffic can be proxied with SOCKS. A SOCKS-aware client wraps its request in a SOCKS request, and sends it to a SOCKS server, which interprets and forwards the request. This is often done with ssh, which offers the
DynamicForward
option to set up a SOCKS proxy. It opens a port that listens on the client host, forwards SOCKS traffic over the encrypted connection, and interprets and routes it on the server. Many network clients can be told to use a SOCKS proxy.Another common way is to tunnel traffic over SSL. stunnel for example will do this. On the client it listens on a port, wraps the traffic within SSL, and sends it to an server. On the server, stunnel unwraps the SSL and forwards the traffic to a configured service.
You can send different types of traffic to the same port, often 443, by using a port multiplexer on the other end to figure out what type of traffic it is and route it to the right service. sslh and sshttp are two that handle the common case of multiplexing HTTP and SSH on one port - say wrapped in SSL and sent to port 443. Finally TCPMUX is a protocol that was developed for port multiplexing. xinetd for example can interpret it, but it isn't implemented in any clients that I know of. (You'd want to wrap it in SSL.)