Warda-DNSDocs Warda: from ward — to protect, guardian
v0.6.9

Unblock requests

Ask to unblock, in the account menu (the initial at the top right; business.unblock, Warda Business, beta: open to every installation during the beta; internal/admin/unblock.go) lets any account ask the administrators to unblock a name for one of its devices: the devices of its person, those of the groups its account made, and the one it uses now when it is given to nobody else. The page lists the names blocked on these devices in the last 24 hours, with what blocked them (a list, a category, a service, a rule, the data loss prevention), and whether a request waits.

  • A request: the device, the name, a duration (15, 30, 45 or 60 minutes, or for good) and a justification (required, 280 characters at most). Only a name blocked on that device in the last 24 hours (those the page lists) may be asked: another is refused (400). Not requestable: the protections against the threats (data leaks through DNS, look-alike names, spyware, DNS rebinding, quarantine, the category Security threats), the illegal content, and the hours of Internet of a child.
  • Limits: one request waiting per device and name, 10 a day per account; a request without an answer expires after 7 days; the history is kept a year (the page of the account shows its own of the last 90 days, with the answer and the comment). When an account is removed, its requests stay in the history of the administrators but belong to no account any more (a new account never sees them).
  • Answer: the administrators (rules.write) see the requests waiting on the dashboard (a card Unblock requests waiting) and on Business → Unblock requests (waiting, and the history of 90 days), and Approve or Refuse, with a comment the account sees. Approved, the name is allowed by a rule of the device, for that device only: for the time asked (the rule ends by itself, reliably across restarts; the rules page shows "until …") or for good. An allow of the device already given for the name is never shortened: one for good stays for good, one that ends later keeps its end. The request is approved only once its rule is written. An allow rule of the device also lifts a service blocked on Services and safe search and a block of the data loss prevention. A block rule of the device for the same name is the administrators' decision: approving answers 409 until it is removed.
  • Log: unblock.request, unblock.approved, unblock.refused, unblock.end in the administration log (and so in the SIEM when the administration log is exported). The task End of the unblocks (business.unblock) ends the unblocks on time and expires the requests.
  • Each request is also a doubt of the collective base (reason blocked_request) when it is on.

API: GET /api/v1/me/unblock (the devices, the names blocked lately, the requests of the account, the durations) and POST /api/v1/me/unblock {"device_id": 12, "domain": "wetransfer.com", "minutes": 30, "justification": "…"} (minutes 0: for good) for every account; GET /api/v1/unblock-requests and POST /api/v1/unblock-requests/{id}/approve|refuse {"comment": "…"} (rules.write). The API token and the command line ask for every device.