Java, you had your chance…
-
OK, this java mess is not going away. Yet another hole found today.
I was digging around to see what SonicWall and the low-end Cisco ASAs offer, and they all have the ability to block java applets. I'd love to give this a shot in pfsense. I only need java on a few select sites (and usually via VPN anyhow, as they're IP-KVM interfaces), but there's always a chance I'll forget to disable the web plugin after using it. I'd like to use pfsense to shield me from that.
I have not looked at the Layer-7 filtering at all since upgrading to a recent 2.1 snapshot. Can this help me accomplish my task of blocking java applets? If so, and if it's not horribly complicated, it would be nice to sticky this on one of the forums (and if it works well, put out a news release - this java mess is a big deal, and Oracle being Oracle, I'm sure we're in for many more vulns going forward).
-
You can block Java with Squid, Google it. Such web things can't be done without a proxy (including on the commercial boxes, they just hide the fact it's proxied).
-
Dang. My connection is too fast and my pfsense box too slow to push everything through squid.
What can the "layer 7" filtering be used for? Is it more about recognizing an application based on src/dst ports or something? Seems like kind of a misnomer if that's the case.
-
Is it possible to you create proxy-server which runs squid/proxy only. If your pfsense box is not capable to handle all the proxydata
-
Proxy doesn't add much load, and it's a trivial amount vs. L7 which is CPU-intensive. Our L7 can do what any L7 purely per-packet (read: non-proxied) solution can, identify protocols that are identifiable via regex on a single packet. Things deep into HTTP like if something is Java aren't reliably identifiable without proxying web traffic. You have to evaluate the full web page before passing it to the client and that's impossible without proxying - the firewall must make that actual web request on its own, evaluate it, and then send it to the client or block it.
-
Yup, the proxy approach is also needed since HTTPs traffic has to be decrypted before it can get inspected.
I guess pfSense can't do this. To retain security, the proxy would also have to reject all connections with self-signed, outdated or otherwise suspicious certificates, as the client has no more chance of verifying the original certificate itself.
I remember that Proxomitron does HTTPS decryption. It runs under Windows, though.
Edit: it appears that some people are already working on it: http://forum.pfsense.org/index.php/topic,58368.0.html