PASQL is an extension to SQL that allows users of a distributed database to specify privacy constraints on an SQL query evaluation plan. However, privacy constraints can be difficult for users to specify, and worse yet, all possible situations that could lead to a privacy violation may not be known to the user a priori. To address these challenges, we propose a GUI-based interactive process for detecting such violations and generating appropriate constraints. In this work, we demonstrate two approaches to implementing such a GUI that provide different ways of analyzing and interactively optimizing a PASQL query plan.

The declarative nature of SQL has traditionally been a major strength. Users simply state what information they are interested in, and the database management system determines the best plan for retrieving it. A consequence of this model is that should a user ever want to specify some aspect of how their queries are evaluated (e.g., a preference to read data from a specific replica, or a requirement for all joins to be performed by a single server), they are unable to. This can leave database administrators shoehorning evaluation preferences into database cost models. Further, for distributed database users, it can result in query evaluation plans that violate data handling best practices or the privacy of the user. To address such issues, we have developed a framework for declarative, user-specified constraints on the query optimization process and implemented it within PosgreSQL. Our Preference-Aware Query Optimizer (PAQO) upholds both strict requirements and partially ordered preferences that are issued alongside of the queries that it processes. In this paper, we present the design of PAQO and thoroughly evaluate its performance.

Although the declarative nature of SQL provides great utility to database users, its use in distributed database management systems can result in unintended consequences to user privacy over the course of query evaluation. By allowing users to merely say what data they are interested in accessing without providing guidance regarding how to retrieve it, query optimizers can generate plans that leak sensitive query intension. To address these types of issues, we have created a framework that empowers users with the ability to specify access controls on the intension of their queries through extensions to the SQL SELECT statement. In this demonstration, we present a version of PostgreSQL's query optimizer that we have modified to produce plans that respect these constraints while optimizing user-specified SQL queries in terms of performance.

Although the declarative nature of SQL provides great utility to database users, its use in distributed database management systems can leave users unaware of which servers in the system are evaluating portions of their queries. By allowing users to merely say what data they are interested in accessing without providing guidance regarding how to retrieve it, query optimizers can generate plans with unintended consequences to the user (e.g., violating user privacy by revealing sensitive portions of a user's query to untrusted servers, or impacting result freshness by pulling data from stale data stores). To address these types of issues, we have created a framework that empowers users with the ability to specify constraints on the kinds of plans that can be produced by the optimizer to evaluate their queries. Such constraints are specified through an extended version of SQL that we have developed which we call PASQL. With this proposal, we aim to demonstrate PAQO, a version of PostgreSQL's query optimizer that we have modified to produce plans that respect constraints specified through PASQL while optimizing user-specified SQL queries in terms of performance.

We investigate how an ISP can efficiently detect bots in its subscribers' computers, possibly as a value-added service or to prevent collateral damage to its infrastructure. By causing an ISP's email servers and network links to get clogged or blacklisted, bots reduce the quality of service the ISP provides to its subscribers. We describe DNS Flagger, a novel device for ISP bot detection, and evaluate its efficiency. DNS flagger matches subscribers' DNS traffic against IP and DNS signatures. In real-time experiments, we found that, on average, major anti-virus programs (AVs) detected only 59% of freshly caught bots, while DNS Flagger detected 73.1% or 91% of those bots, respectively on hosts that do not or do also have a major AV. There were no false alarms. Because its processing involves only a small fraction of all network traffic and can be performed at very high speed, a single DNS flagger can handle hundreds of thousands of subscribers.

Effective defenses against DDoS attacks that deplete resources at the network and transport layers have been deployed commercially. Therefore, DDoS attacks increasingly use normal- looking application-layer requests to waste server CPU or disk capacity. CAPTCHAs attempt to distinguish bots from human clients and are often used to avoid such attacks. However, CAPTCHAs themselves consume resources and frequently are defeated. Kill-Bots reduces CAPTCHA overhead by pushing client authentication into the kernel. However, Kill-Bots requires kernel modifications, which can be infeasible. We describe the design, implementation, and performance evaluation of Sentinel, a network device that overcomes several limitations in Kill-Bots. Sentinel can be easily deployed as a bridge in front of server farms, modularly accepts a variety of present and future authentication schemes, and can use network processors to accelerate authentication. Experiments show that Sentinel greatly reduces the impact of DDoS attacks on the response time experienced by legitimate clients.