Acidus wrote:
This is why Layer 4 IDS/IPS will not win. There's an RFC that defined IPv4, IPv6, TCP, SSL, etc. You can easily test structure and determine malformed IP packets. You can use stateful packet inspection to check FTP. There is no RFC that defines JSON. There is no RFC that defines what what the data inside the JSON literals is going to look like. There is no RFC about the character encodings that I'm applying. I've seen web applications using pipe (|) separated quoted strings that are Base64-ed to transfer data back and forth. How do you deep inspect something when you don't know the format?

The simple answer is that the RFC isn't how you knew what the format was in the first place. Most software does not obey RFCs and IPS systems aren't designed to enforce them. IPS's are built by people who study implementations. IPS systems parse all kinds of proprietary protocols and they are built with an understanding of how proprietary implementations actually work. Blindly blocking all malformed traffic per some paper standard would simply break operational applications.

The biggest differences involved in some of these new web applications are interface complexity and customization. In the case of the former, basically there are far more ways to permutate javascript code versus an SMTP session. In the case of the later, if everyone develops his own web application than they are all different and they each have different vulnerabilities. You don't get the same economies of scale that you do when nearly everyone has the same software with the same problems.

These changes are pushing IPS toward more heuristic detection methodologies that can look for certain attack classes without having a complete knowledge of message formats, and they are pushing some security into the client -- closer to where the vulnerable interfaces are.

RE: HTTP: The Application Transport Layer?