BOSTON – Two engineers from Netflix this week released to open source a security tool that detects attacks against web applications—and also reacts to those attacks with responses they hope will flummox a hacker to the point that he moves on to his next target.
The utility is called Ensnare and is available on Github. It is a Ruby on Rails gem plug-in and once added to a Web application, it will add steps to requests browsers make to a web application server that will quickly detect attacks, characterize them, and send responses back to the browser that range from error messages, to security alerts, to agonizing delays. What makes Ensnare noteworthy is that it’s customizable and doesn’t interject itself with legitimate site users and affect their experience.
“We wanted to build something that was easy to use, that you could get running on a real application in 15 minutes and does advanced response handling,” said Scott Behrens, a senior application security engineer at Netflix, during his talk Wednesday at Source Boston. “We wanted to make it extensible too so that you could contribute to the project. We hope to collect metrics, learn about attacks and use that data to extend Ensnare to be more effective.”
Behrens said Ensare sits alongside an application and examines requests looking for bad behavior such as SQL injection or cross-site scripting attempts, and logs those. It can also be configured in the application layer to set booby-traps, or honey traps as they call them, that will be triggered by malicious activities in areas where legitimate users would never browse.
Behrens’s colleague Andy Hoernecke said when those traps are triggered, customizable responses can be sent to the attacker’s browser based on the aggregate number of violations and their severity. Legitimate requests, in the meantime, aren’t subjected to this experience.
“You can modify the response that comes back from the server; you can send a 404 message or send a message that says ‘We know what you’re doing,” or send an alert to the security team,” Hoernecke said. “It can send a message to you and hopefully it’s enough to move you on to something else.”
The first step Ensnare takes is to check for violations in requests; it determines whether they are malicious by matching them to a signature, for example.
“Violations are bad behavior tracked over time and aggregated. They are triggered by things like bad paths or exploit strings in request,” Hoernecke said. “They’re based on a particular configuration and weighted.”
It then determines a threshold for the requestor, who is logged via IP address, session ID or user ID in a database.
“By aggregating all three, Ensnare is more robust,” Hoernecke said. “We can track things if an attacker is doing tricky stuff to get around our protections that are in place.”
Thresholds are established through a number of attributes, including the number of violations that have occurred and how long the user is put into a trap.
“This is powerful state handling. We can do a lot of things to get the attacker to go away such as confusing them, distracting them or slowing them down,” Hoernecke said.
For example, if a user racks up five violations, the threshold can be configured to delay by 20 percent the time it takes to make a request and delaying the response by as long as 15 to 20 seconds. If the number of violations climbs to 20, the attacker could see delays climb into minutes—all without affecting site performance for legitimate users.
“If an attacker is testing the site, and the site starts delaying or redirecting, it gets frustrating,” Hoernecke said. “The responses are techniques that prevent an attacker from being successful in finding vulnerabilities or attacking the site. We hope to slow them down, block them, alert them or even annoy them.”
