108 lines
8.9 KiB
Plaintext
108 lines
8.9 KiB
Plaintext
{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
|
||
{\*\generator Msftedit 5.41.15.1515;}\viewkind4\uc1\pard\lang2067\b\f0\fs20 A small guide of how to use and understand the access.guard.lua script.\b0\par
|
||
\par
|
||
This script is made for ADCH++ and based on snippets and methods used in access and bans lua (thx dcdev team) and fals under the ADCH++ project copyright, its a basic flood protection for ADC commands and some specific rules/limits and above all it can be made a lot better and smaller as it has some "doubles" , its beta so .... lol.\par
|
||
\par
|
||
The final intention is to base the rate rules on a "severnes" factor meaning taking into account what the context of the command is and the size of the strings it will generate but so far it's only rate based so if somebody feels like ? lol (cologic thx for that idea, it's the only way to do it right)\par
|
||
\par
|
||
It uses also idea's i got from using the Leviathan script so also a thx to those people. \par
|
||
\par
|
||
The intention was to make on 1 side a "hubs users friendly" anti flood and guard system, so if one by "accident" spams he will receive warnings and his action will be stopped, after some time, in most cases less then 15 seconds, he can use the command again like any other user and on the other side prevent the hammering of users that do not comply to the limit rules.\par
|
||
\par
|
||
It also gathers entity's (users) info and asigns a unique ID for each one of them based on CID and keeps history records based on NI / IP if that setting is enabled ( +cfgen entitylog ), these records can be used to find a user by Nick/IP/CID and all changes that the user made. Also these tables are auto cleaning based on your +cfgen entitylogexpiretime setting.\par
|
||
\par
|
||
This script is never tested on a real 100+ users hub but speed looks great and resource use seems minimal so ......\par
|
||
\par
|
||
It gathers you statistic info like count, rate, and differential rate regarding the use of normal ADC commands (and the non existing ones or the ones with a bad context), some specific limit rules where you have for each a maximum rate setting and a expire time so the tables remain very small and are self cleaning.\par
|
||
\par
|
||
The part "entity" let you keep statistics regarding the users, both normal and regged.\par
|
||
\par
|
||
The differential rate is a last minute snapshot rate that uses a aging factor to lower its value very quick.\par
|
||
\par
|
||
If the specific stats maxrate is set to 0 it will use the default setting specified with +cfgfl fl_maxratecmd same counts for the expire time, to disable a stats rate you just need to set it -1\par
|
||
\par
|
||
On the limit rules there is also a count function that will react on the li_maxcount setting and kick the user if needed.\par
|
||
\par
|
||
Each specific stat / limit uses its own table with the users CID or IP as the index so if you create a new one you will also have to create the table for it, the rest should be a simple copy paste of a simular stats , create the settings for it and addapt the paramaters that it should watch.\par
|
||
\par
|
||
The script has 3 major parts and they are all disabled on first use.\par
|
||
\par
|
||
To enable them do:\par
|
||
\par
|
||
\b +cfgfl fl_commandstats 0 or 1 ( 0 = just flood protection , 1 = flood protection and write to a logfile on disk)\par
|
||
\par
|
||
+cfgli li_limitstats 0 or 1 ( 0 = just limits enforcing , 1 = limits enforcing and write to a logfile on disk)\par
|
||
\par
|
||
+cfgen en_entitystats 0 or 1 ( 0 = just entity logging , 1 = entity logging and write to a logfile on disk)\par
|
||
\par
|
||
Those logfiles are loaded on hub start and on enabeling a module so all data survives a restart or script reloads\par
|
||
\b0\par
|
||
After that by default all cmd stats rates and flood protection are enabled with either specific cmd values or are using the default fl_maxrate value, to enable a certain limit you need to set a specific value you see fit for a it.\par
|
||
\par
|
||
example that changes the default and a specific rate for the cmd's\par
|
||
+cfgfl fl_maxrate 30\tab\tab sets all cmd rates to a max of 30 / minutes if no rate specified on the line itself\par
|
||
or you can specify a specific cmd\par
|
||
+cfgfl cmdschtth 12\tab\tab that will allow a max rate of 12 / minute for the automatic TTH search\par
|
||
+cfgfl fl_maxwarns 25\tab\tab will kick a users after 25 flooding events\par
|
||
\par
|
||
example for the limits\par
|
||
+cfgli li_maxrate 240\tab\tab sets limit rates for those that have a limit value and no specific rate on the line itself to a max \tab\tab\tab\tab of 240 / hour (4 / minute)\par
|
||
+cfgli maxmsglenght 800\tab sets the maxmsg length to 800\par
|
||
+cfgli li_maxcount 40\tab\tab will kick a user after been warned 40 times regarding a limit rule\par
|
||
\par
|
||
\par
|
||
Enjoy and be carefull with your settings as it will send warnings, kicks and temp bans to a user that breaks those rules (if you enable that), my advise is to run it a few days with all settings like they come and use the +listcmdstats and +listlimstats commands to get a feeling of what exactely is going on in your hub.\par
|
||
\par
|
||
\par
|
||
The commands itself are in the hubs help menu and each of the settings can be seen both in its own stats and either +help cfgfl \par
|
||
\par
|
||
,help = +help cfgfl , +help cfgli and +help cfgen\par
|
||
\par
|
||
stats = +listcmdstats , +listlimstats, +showentity\par
|
||
\par
|
||
First of all the script as posted has most limits disabled, each hubowner should decide what he wants limited / logged and what not.\par
|
||
\par
|
||
Giving advice about "golden" rate values is almost impossible as it depends on the resources that the hub has available, like upload band, cpu power etc.\par
|
||
\par
|
||
Now this beeing said i will try to explain the tought behind this script a bit further and the settings i use:\par
|
||
\par
|
||
In your thinking you must make a difference between:\par
|
||
1: a real "flood" with bad intentions where something sends ADC commands with high rate and only one goal, kill the hub.\par
|
||
2: a client "flood" that's just misconfigured or does not respect its settings .\par
|
||
\par
|
||
To get protected against nr 1 cases is very straight forward , as you can see the default rate setting is 30 / m changing that to lets say 20 a min means that all stats where the maxrate is 0 will have that 30 / m as maxrate , its safe to do this for most of the stats beside 3 of them, the RES : returned search results, and CTM / NAT connect to me commands, both can be triggerd by other clients doing searches or sending a RCM command to the "victim" this will be solved in future versions if it will not become a to big resource hugh , testing that @ the moment.(these 3 commands are set to -1 default for now)\par
|
||
So with above settings your hub has a basic flood protection against script kiddy's attacks.\par
|
||
And same count for the limit stats.\par
|
||
\par
|
||
Nr 2 is a bit different there it depends completely on the hubowner what he wants and what his resources for his hub are.\par
|
||
\par
|
||
In my settings i have all command stats rate set to the default maxrate using the 0 setting exept the following.\par
|
||
\par
|
||
SCHTTH both normal and nat types are set to 3 / minute as i find that a fair number for now (its a small hub and using blom) and most normal clients standard settings are far above this.\par
|
||
\par
|
||
Warning there are some popular clients outhere who not respect these settings when a user add new stuff to its Q so ...... and only start to put a correct automatic search rate when the user re-joins the hub !!!!\par
|
||
\par
|
||
SCHMAN both normal and nat types are set to 6 / minute again most clients come with those settings so will not be a real problem.\par
|
||
\par
|
||
INF is set to 15 / minute. This was never a problem untill that new FS field was brought in, that field will generate for a user that has many slots and is uploading to alot of some older clients who disconnect on each segment a real flood of sometimes 1 every second. The band used to broadcast this on a small hub is not that much but on a big one..... \par
|
||
\par
|
||
CON connection attempts are here set to 10 / minute.and the expire time for it to 10 minutes and seems to work ok.\par
|
||
\par
|
||
\par
|
||
A second part in the guard script is the limits, those rate settings are done in counts/hour and depend completely on the hubowner, how long he will stand up with everlasting clients or other things who try over and over.\par
|
||
\par
|
||
On all of these stats and limits is a maxwarns, maxkicks, maxtmpbans (depending on your settings) verification that automatically remove users who are just not paying any attention to warns or disconnects or what so ever and there loads of them.\par
|
||
\par
|
||
And finally the reason for all of this is that a hub has a max outgoing buffer size with a timelimit , so if the traffic to a user is getting huge and he or the hub can not follow the ammount of data to be send he will end up disconnected while he did nothing wrong besides not beeing fast enough and just because a few clients decide to sending searches or anything else thats broadcasted @ stupid rates.\par
|
||
\par
|
||
Enjoy :)\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\lang1033\par
|
||
}
|
||
|