previous up next
Previous: 4 Infestation of the Up: Two Attacks against the Next: 6 About the "inces+ncest"

Subsections


5 Counter-measures

5.1 Getting ride of the Webalizer doesn't really fix the problem

When advised of such attack against his/her own web site, the first reaction of a webmaster could be "to finally get rid of Webalizer". But I think that this is not the most efficient counter-measure. Firstly, Webalizer pages do contain useful informations, not only for the owner of the web site, but also worldwide. Secondly, beside the infestation of the Webalizer pages, the two current attacks are leading to a denial of service that should be fixed either. Lastly, the story shows that many web sites are under-administrated : this could be an occasion to reconsider the question.

5.2 How to obtain clean Webalizer pages

This is a two steps process.

  1. Right now :

    1. Let $cfgdir be the directory where the webaliser.conf file is located (should be out of your web site space).
    2. Create a new directory, say $wazdir, out of your web site space.
    3. Copy the contents of the actual Webalizer directory (say $wbzdir) to $wazdir
    4. Change one line in the webalizer.conf file so that, from now on, the Webalizer will generate its web pages into $wazdir, instead of the former $wbzdir.
    5. Change another line in the webalizer.conf file so that Webalizer generates an "All Referrers page".
  2. Thereafter :

    1. Download, towards $cfgdir, the five files located at http://www.douillet.info/~douillet/ansecpb/index.html##thepatches

    2. Use the file $cfgdir/.config to describe the directories actually used.
    3. From $cfgdir, execute (to fix the February page)
      . .config 
      referrers_rebuild 200502 
      This will generate the three files $cfgdir/ckoi_table_*.
    4. Examine the ckoi_tables. They contains the Referrers that remain after filtering according to the current blacklist. When sorting by "hit" numbers, the attackers are likely among the most frequent. Sorting by "ip" and by "name" are also available.
    5. Complete the file blacklist_txt according to your opinion, and proceed again from enu:execute-rebuild.
    6. When all the bad guys become filtered, execute  
      referrers_rebuild 200502 -c 
      This will generate your cleaned February pages (inside $cfgdir).
    7. After a last check, copy these cleaned February pages to their public place ($wbzdir).
  3. Comments.

    1. The idea at the basis of the patch is using the "All Referrers page" (the February's being named ref_200502.html) to complete the "Top 30 Table" after deletion of the attackers.
    2. If your former configuration was not to generate this additional page, the main patch will call referrers_fake  to generate the missing page. In this case, your cleaned "Top 30 Table" will be as short as necessary... and may be empty from non local Referrers.
    3. When executing step enu:execute-completing, the blacklisted entries are added to the file liste_coucous. This file keeps a list, sorted by ip's, of the web sites classified as attackers. The goal being to provide a data basis for configuring firewalls. It is also useful to detect when a filtering rule has been poorly written, leading to "false positive". Especially, the dot character must be coded [.] in the blacklist in order to avoid the regex meaning of "any character".
    4. Everything has been done to obtain a non destructive process. All the original Webalizer pages remain unchanged in the privately owned directory $wbzdir.
    5. This patch reacts to the "sex+drug" attack whose goals seem to be clear. But the goals of the other one, the "inces+ncest" attack are not so clear. It could be useful to keep track of this attack, not destroying the logs or, at least, keeping a grep of these logs.
    6. By the way, it could be useful to decode, before processing by the Webalizer, all these many % escapes that appear in the search strings. The resolve_percent file is a sed filter translating what I have encountered.

5.3 How to fix the by-side denial of service

Work in progress.

Beware of the following fact : blacklisting someone from a Webalizer pages is one thing. Blacklisting someone at a firewall level or at a routing level is another thing, with more harmful consequences. Therefore every thing must be done to avoid any "false positive".

5.4 Philosophical remarks about administration

Work in progress.


previous up next
Previous: 4 Infestation of the Up: Two Attacks against the Next: 6 About the "inces+ncest"


douillet@ensait.fr
2005-02-25