2010-08-20 1 views
4

Quelqu'un peut-il donner des conseils sur le filtrage de mes logs d'exception Elmah (http://code.google.com/p/elmah/)?MVC, Elmah, tentatives hacker apparentes et IgnoreRoutes "génériques"

Elmah a été un outil très utile pour mettre en évidence mes erreurs et oublis évidents dans mon application web.

Cependant maintenant .. la plupart des entrées Elmah ne se rapportent pas à ma propre stupidité (bien - peut-être qu'ils le font - donc ma question), mais tous les conseils seraient très appréciés.

Mon journal Elmah a maintenant 10'000s d'entrées similaires à:

  • Le contrôleur pour le chemin « /ws/login.php » n'a pas pu être trouvé ou il ne met pas en œuvre iController.
  • Le contrôleur pour le chemin '/ text/javascript' n'a pas pu être trouvé ou il n'implémente pas IController.
  • Le contrôleur pour le chemin '/jlkqyvaugdaktp.html' n'a pas pu être trouvé ou il n'implémente pas IController. [[En fait 100s de ces !! ... Est-ce que ces pages aléatoires signifient quelque chose dans "HackerDom"? ]]
  • Le contrôleur pour le chemin '/Scripts/thickbox/macFFBgHack.png' est introuvable ou implémente IController.

donc .. à la « question »

Il est évident que la grande majorité de ces exceptions sont générées par iController ... je peux dire Elmah juste « oublier » les et continuer à enregistrer mes véritables exceptions?

Ou est-ce que ma configuration très générique de MVC IgnoreRoute n'est pas assez bonne? Devrais-je ignorer ".htm", "* .php" et tous les autres afin que je puisse voir de façon plus réaliste les rapports d'Elmah sur les pages/objets/objets que mon application manque peut-être plus sincèrement?

Un grand merci pour votre temps et considération.

Ma configuration Route Existant ressemble à ceci:

  routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); 
      routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.ico(/.*)?" }); 
      routes.IgnoreRoute("{*forums}", new { forums = @"cccForums/.*" }); 
      routes.IgnoreRoute("{file}.txt"); 

/// REAL ROUTES 
      routes.MapRoute(
       "ItemIndex", // Route name 
       "Item/Index/{page}", // URL with parameters 
       new { controller = "PageItem", action = "Index", page = 1} // Parameter defaults 
       ); 

............. 
............. 


/// LAST CASE 

routes.MapRoute("Error", "{*url}", new { controller = "Site", action = "Map" }); 
+0

Une mise à jour "Rave from the Grave" --- J'ai remarqué que maintenant j'utilise Chrome comme outil de débogage principal, beaucoup plus de ces erreurs apparaissent puisque Chrome va essayer de charger une page sur chaque touche dans sa barre d'adresse en tant que partie de son chargement "en temps réel": – JcMaltaDev

Répondre

3

Une solution consisterait à implémenter un attraper tout itinéraire qui redirigerait toute requête inconnue vers une page 404. Cela empêcherait une exception non interceptée et vos utilisateurs finaux obtiendraient une jolie page (la variété non-hacker). Placez ceci à la fin de votre fonction d'itinéraire de registre dans le global.asax. Vous devriez voir toutes vos erreurs ELMAH disparaître.

EDIT

Ne pas aller encore dormir! :) Si vous êtes intéressé à ne pas vous connecter 404 erreurs (ou tout autre type d'erreurs pour cette question avec ELMAH), vous devriez être en mesure de faire quelque chose comme ceci dans votre web.config:

<elmah> 
    ... 
    <errorFilter> 
     <test> 
      <equal binding="HttpStatusCode" value="404" type="Int32" /> 
     </test> 
    </errorFilter> 
</elmah> 

ELMAH ErrorFiltering Documentation

+0

Tommy .. ça sonne bien ... mais j'ai déjà quelque chose de similaire ... mais je vais tester ..... J'ai mis à jour ma question avec ma configuration de route actuelle – JcMaltaDev

+0

Juste testé .. avec "www. mysite.com/thisPageiskjhkjhkjh.htm ".. routage MVC DID rediriger vers" www.mysite.co.uk/Site/Map "... mais l'exception Elamh est toujours connecté :( – JcMaltaDev

+0

hah .. peut-être que cela est attrapé par mon web.config: \t \t \t \t \t \t \t JcMaltaDev

0

Si vous ignorez ces via IgnoreRoute, la tentative de fissure continue à faire aussi loin que ASP.NET. Cela charge votre serveur. Pourquoi ne pas les bloquer à votre pare-feu à la place?

+1

S'il est en hébergement mutualisé, ce serait impossible. – Tommy

+0

Merci pour votre suggestion - mais cela ne signifie-t-il pas que je devrais maintenir mes "vrais" itinéraires sur mon pare-feu, en utilisant une syntaxe et un cycle de construction complètement différents? – JcMaltaDev

+0

@JcMalta, ça dépend. La plupart des pare-feu vous permettent d'exclure, pas seulement les inclusions. @Tommy, il me semble que vous présumez d'un pare-feu matériel, mais les pare-feu logiciels (y compris celui intégré dans Server 2008 SP 2) seraient encore préférable de le faire dans ASP.NET IMHO. –

Questions connexes