as far as I know "Progressive Lockout" describes that a "policy violation" (Malware download, access of forbidden URLs, etc.) may only occur a couple of times, before a user is completely locked and will prevented from accessing the internet and/or an administrator will be informed. Also allowing a user to violate your policy a couple of times and then block him may be an option.
If this is what we are talking about, please let me know. I have a description and a sample rule set available.
allright I have some notes for the "Progressive Lockout", you may need to adjust it to your needs.
"Block and count attempts.png" shows a rule that blocks requests to a
URL whose category is listed in the associated list. The event writes
the number of attempts into PDStorage:
There is a User-Defined property used to do the "+1" calculation. This
rule is used to "count" the attempts of a user to access an URL with
I have used a modified error template here, and added the content of the
PDStorage container. Doing so you can see "how often" you have accessed
the blocked URL (see "Show connection attempts.png"):
Additionally I have created a rule set which handles the PDStorage
value. I have attached a Screenshot "Grab Progressive Lockout.png" and
the XML source for this rule set:
It has two features:
- When a user accessed a blocked ressource 10 times, it will send an
eMail to the admin:
-- snip --
Subject: WARNING: User CN=Andre Sabban,CN=Users,DC=McAfee,DC=local has
exceeded Progressive Lockout threshold
Body: Dear Admin,
the user with Client IP 192.168.122.163 and name "CN=Andre
Sabban,CN=Users,DC=McAfee,DC=local" has exceeded the allowed number of
Progressive Lockout attempts of 10.
MWG at MWG7-4
-- snip --
The second rule verified the number of attempts, and once you passed
"20" attempts, you receive a block page that tells you that you have
been "locked out" (see Locked out.png). Depending on where you place it,
it will block ALL connection attempts, even to allowed sites (which is
the use of Progressive Lockout).
In my example you can see where I have placed this rule set and it will
only allow URLs which are whitelisted by the global whitelist.
Important to note is that I placed the rule set after authentication was
done - this is required since the Progressive Lockout won´t know the
Please also note that in the rule set I have used "equals 10" and
"greater than or equals 20" for the rules. This is very important.
If you don´t use "equals" for the eMail rule, you will get an eMail for
each connection attempt. If you use "equals" for the block rule, only
the "20th" access will be blocked - the "21st" will go through.
Lockout (PDStorage) data will be kept for 1 day. You can configure this
in the Settings container that belongs to the PDStorage calls.
I hope this helps to get started. I will document this and make a nice
exmaple for the rule library, but this will take some more days.
Let me know if there are any questions or if there is any feedback.
actually you cannot control the progressive lockout in a comfortable way from the UI. I see a couple of options to unlock a user again:
- Wait the time until he is unlocked again
- Remove the file which holds the data from the disk (will most likely require a restart)
- Add a rule which calls a "PDStorage.DeleteUserData", and removes the content for Progressive Lockout for this user. This can be done by an Admin for example, after the user confessed he did something bad and wants access again.
So in summary:
Is it possible to unlock a user again? Yes
Is there a nice frontend to select a user and click "unlock"? No
I've also had a request to create something like this, and figure not being able to reset the lockout could be a pretty major problem. What I decided to do was create a token when the user gets locked out and then email that token to the administrator in a parameter on the url. This way the admin can clear out the lock, but any old user couldn't just unlock themselves by going to a specific url.
Basically when a user gets locked out we send an email that has a link in it that the administrator can click on and unlock the user.
1) user gets locked out
2) admin gets an email that says user X has been locked out, please click
http://proxy ip:proxyport/mwg-lockout/unlock?User=X&Token=<a really long somewhat unique string that noone else knows>
3) admin clicks on the link which goes to the webgateway and is caught, the token is validated and the user gets a fresh start.
There is also logging of lockouts and unlocks.
Order does matter, I would probably put the unlock and the lock user out rulesets close to the top and put the category block where the regular URL filtering is.
1) This is dependent (I believe) on authentication although could be modified for unauthenticated environments.
2) Progressive lockout is highly dangerous. Certain sites (facebook and twitter in particular) have links all over the internet and you could accidently lock someone out if you enabled this for, say, social networking.
Please tell me what you think or if you have any concerns regarding this.
Progressive Lockout.xml 52.5 K
i have also a problem with overload at a customer, but i don´t know if this could be resolved with progressive lockout.
- MWG is authenticating any webrequest
- Some applications are not aware to answer the 407 response and starting to request the internet content again and again. Some software products are generating 300 and more requests per second.
This is a real problem. Because most time IT does not know which applications are installed on a client anywhere within the organization.
I think, blocking such a client directly with progressive lockout does not solve the problem.
Is it possible to automatically generate a network protection rule to block such a client??