On Wed, Dec 9, 2009 at 08:11, Ken Schaefer <[email protected]> wrote:
> URI has nothing to do with payload.
Yes, I knew that.
> POST /somefile.ext HTTP/1.1
> HOST: myserver.com
> Key=<binary blob here>
>
> Is an entirely valid HTTP request, and the URI is well formed. Unfortunately
> you
< have no visibility into the <binary blob here> part unless your
proxy happens to
> be able to decode that traffic.
Understood. As I said before:
"I at least have the minimal protection afforded by
enforcing well-formed URIs - and a few other goodies
it does. Poking an arbitrary TCP hole in the firewall
doesn't even give me that."
I also said that the only way I know of to proxy the MS Live stuff is
with ISA, and I don't have that. But, having said that, I doubt that
even ISA understands how to cleanse a malicious binary blob coming
from Live.
And, worse, I don't have, and won't be given in this lifetime, the
resources to put of an IDS/IPS and use it, though I'm trying to learn
OSSIM on my own time.
>
> How does your proxy handle SSL VPNs/SSTP or RPC over HTTPS? Or RDP over
> HTTPS? Or any number of current arbitrary protocols, that have
> non-transparent body data, that now run over HTTP/HTTPS?
>
You have put pointed out the obvious problem with most of the web we
have nowadays. Nobody can protect against it, and I block what I can
of it.
Why do you think I'm on here asking? It makes me nauseous to have to
open these ports and protocols to public servers for traffic that
should be kept internal to the org. I'm looking for my best
alternatives, under protest to management, who, as is nearly
universal, don't have a clue about security, nor care about it, and
just want the keen communications to happen. And then it'll be my
fault when it blows up, because they didn't pay attention.
If I can get them a system that keeps this traffic inside our security
boundaries (including our VPN), I'll rest easier at night.
We have a SonicWall 2000 SSL VPN unit that sits behind the firewall,
and accepts the forwarded traffic from the Sidewinder. That's as good
as I could get with the budget they would provide, and the protection
it affords is enough so that I can push that worry nearer the bottom
of my list of things that I worry about incessantly.
If I had my way, I'd default block it all, even 80/443, and whitelist
sites as business needs dictate, but as it is, I block all outbund
80/443/21 traffic, except from our squid/frox proxy. I also block all
other ports, especially 25 and 22 - the Exchange server and the
spam/AV gateway are the only ones that can do port 25, and I allow 22
outbound to specific customer sites only, from specific workstations
only, with *no* inbound port 22. The SSL VPN unit provides an SSH
shell if needed, but I haven't had to enable that yet.
Kurt
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
