Application Considerations to prevent Abusive User Behaviour

This page is meant to be a sounding board and general discussion area for the issue of preventing users from knowingly or unknowingly abusing services through VO enabled applications. The topic is of interest both to application developers and data providers. The goal is to make VO enabled applications less likely to enable problematic behaviour by default and to develop possible solutions for data providers that can alleviate or prevent service disruptions.

Common examples of "abusive behaviour" include Denial of Service attacks (where a user overloads a service with requests, effectively crashing it), and ...

Incident Examples and Proposed Solutions

• Topcat Multicone DoS on WFAU services
  • Description: In January and March 2013 there were incidents where users unknowingly crashed the cone search services for WFAU's archives. In both cases the users were running multiple instances of Topcat, performing multi-cone queries with the multi-threaded setting activated. In the worst case the user was effectively running 600 concurrent connections to the cone-search services continously for 72 hours, with each query requesting 1 degree square of tabular results. The web container running the services was overloaded and eventually crashed, bring down access for all users.
  • Lessons Learned: A bug was identified in Topcat whereby the "Stop" button didn't actually stop subsequent queries from being submitted. The user thought they had stopped their requests multiple times, when in fact the queries continued in the background alongside all subsequent queries they were submitting. This bug is now fixed.
  • Proposed Solutions:
    1. VO Applications should use low default settings for options like multithreading. When possible, they should also provide warning messages when a user selects a setting that could be considered unreasonable.
    2. VO Services could provide 'HTTP 307 Temporary Redirect' messages to clients that are overloading their services. The temporary redirect would point to a page with time delayed redirect, and the time on that would be set by the server to delay query response. As more requests come in the wait time would grow. The client applications must be capable of understanding the redirect message and act accordingly.