From 2c5e756f154c7b5ed39a2262f24297b16ae43680 Mon Sep 17 00:00:00 2001 From: Thomas Waldmann Date: Sun, 1 Dec 2013 12:17:10 +0100 Subject: [PATCH] add --flag-abuse, add some docs about abuse handling --- docs/admin.rst | 34 +++++++++++++++++++++++++- nsupdate/management/commands/faults.py | 17 ++++++++++++- 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/docs/admin.rst b/docs/admin.rst index ed7f162..0049fb2 100644 --- a/docs/admin.rst +++ b/docs/admin.rst @@ -81,13 +81,45 @@ it runs as the same user as the nsupdate.info wsgi application:: # reinitialize the test user: 50 2 * * * django-admin.py testuser # reset the fault counters: - 55 2 * * * django-admin.py faults --reset-client --reset-server + 55 2 * * * django-admin.py faults --flag-abuse=20 --reset-client # clear expired sessions from the database, use your correct settings module: 0 3 * * 1 django-admin.py clearsessions # clear outdated registrations: 0 3 * * 2 django-admin.py cleanupregistration +Dealing with abuse +------------------ + +In the regular jobs example in the previous section, +--flag-abuse=20 means that it'll set the abuse flag if the client fault counter +is over 20 (and, for these cases, it'll also reset the fault counter back to 0). + +--reset-client additionally sets all client fault counters back to 0, so all +counts are just "per day". + +So, if you run this daily, it means that more than 20 client faults per day are +considered abuse (e.g. if someone runs a stupid cronjob to update the IP instead +of a well-behaved update client). + +Hosts with the abuse flag set won't accept updates, but the user will be able to +see the abuse flag (as ABUSE on the web interface and also their update client +should show it somehow), fix the problem on the client side and reset the abuse +flag via the web interface. If the problem was not really fixed, then it will +set the abuse flag again the next day. + +This procedure should make sure that users of the service run sane and correctly +working update clients while being able to fix issues on their own without +needing help from service administration. + +For really bad cases of intentional or ongoing abuse, there is also a +abuse_blocked flag that can only be set or reset manually by service +administration (using django admin interface). +While abuse_blocked is set, the service won't accept updates for this host. +The user can see the ABUSE-BLOCKED status on the web interface, but can not +change the flag. + + Configuration ============= diff --git a/nsupdate/management/commands/faults.py b/nsupdate/management/commands/faults.py index 9283023..3a5b906 100644 --- a/nsupdate/management/commands/faults.py +++ b/nsupdate/management/commands/faults.py @@ -56,6 +56,13 @@ class Command(BaseCommand): default=True, help='reset the available flag (to True) of all hosts', ), + make_option('--flag-abuse', + action='store', + dest='flag_abuse', + default=None, + type='int', + help='if client faults > N then set abuse flag and reset client faults', + ), ) def handle(self, *args, **options): @@ -66,6 +73,7 @@ class Command(BaseCommand): reset_available = options['reset_available'] reset_abuse = options['reset_abuse'] reset_abuse_blocked = options['reset_abuse_blocked'] + flag_abuse = options['flag_abuse'] for h in Host.objects.all(): if show_client or show_server: output = u"" @@ -75,7 +83,14 @@ class Command(BaseCommand): output += u"%-6d " % h.server_faults output += u"%s %s\n" % (h.created_by.username, h.get_fqdn(), ) self.stdout.write(output) - if reset_client or reset_server or reset_available or reset_abuse or reset_abuse_blocked: + if (flag_abuse is not None or reset_client or reset_server or + reset_available or reset_abuse or reset_abuse_blocked): + if flag_abuse is not None: + if h.client_faults > flag_abuse: + h.abuse = True + self.stdout.write("setting abuse flag for host %s (created by %s, client faults: %d)\n" % ( + h.get_fqdn(), h.created_by, h.client_faults)) + h.client_faults = 0 if reset_client: h.client_faults = 0 if reset_server: