Incremental Reject delay

[Krzysztof Grobelak]

   Apologies, somehow the formatting got messed up on the previous email

   Hello List,
   I have implemented the temporary blackholing as described below.
   I have created the following on the freeRadius server in the policy.d:
   blackhole_if_asshole {
           update control{
                   Tmp-String-0 := "%{sql:SELECT CONCAT(logins,'#',
   blackhole) FROM blackhole_table WHERE username=\"%{User-Name}\"}"
           }
           if("%{explode:&control:Tmp-String-0 #}" > 0){
                   if(&control:Tmp-String-0[1] != 'B'){
                           if("%{&control:Tmp-String-0[0]}" < 3){
                                   update control {
                                           Tmp-String-1 := "%{sql:UPDATE
   blackhole_table SET logins = logins + 1 WHERE username='%{User-Name}'}"
                                   }
                           }else{
                                   update control {
                                           Tmp-String-1 := "%{sql:UPDATE
   blackhole_table SET blackhole = 'B', time_blocked =
   FROM_UNIXTIME('%{%{integer:Event-Timestamp}:-0}') WHERE
   username='%{User-Name}'}"
                                   }
                           }
                   }
           }else{
                   update control {
                           Tmp-String-1 := "%{sql:INSERT INTO
   blackhole_table(username) VALUES('%{User-Name}')}"
                   }
           }
   }
   check_if_asshole {
           if("%{sql:SELECT `blackhole` FROM blackhole_table WHERE
   username=\"%{User-Name}\"}" == 'B'){
           update reply {
                           &Reply-Message += 'Username already
   Blackholled'
                   }
                   reject
           }
   }
   The first policy is performed in the "Post-Auth-Type REJECT" section in
   the default server. The second in the "authorize" section. The
   offending users are placed in the database which is cleaned up
   periodically by CRONTAB simply deleting all users that were there for
   more than an hour.
   "mysql -u radius -psupersecretpass -e 'DELETE FROM blackhole_table
   WHERE `time_blocked` < (NOW() - INTERVAL 60 MINUTE);' radius"
   What i have found is that the users rejected in the authorise section
   by my policy (or any other policy that i have) are still hitting the
   "Post-Auth-Type REJECT" and get evaluated by my blackholing policy.
   What happens then is the Event-Timestamp attribute is missing and the
   query fails. I worked around it, as shown above, by adding the default
   value but this obviously give the date as beginning of the epoch.
   My question is can I add some return value to  (or tag it somehow)
   request rejectef by a policy so that they wont be sent to the
   "Post-Auth-Type REJECT" section?
   And a bonus question out of curiosity is how come there is no
   Event-Timestamp attribute in the request after it was previously
   rejected by a policy, is it expected?
   Thanks!
   Regards,
   Krzysztof


   [1][LINK]-[2]Airspeed Telecom
   aspt

References

   1. http://www.airspeed.ie/
   2. LYNXIMGMAP:file://localhost/tmp/tmpRX3P1h.html#sociallinks

[USEMAP]
file://localhost/tmp/tmpRX3P1h.html#sociallinks