URL de requête inhabituelle dans l'événement de surveillance de l'intégrité ASP.NET

Question

Je vois une occurrence plutôt étrange dans la section d'informations de demande d'un e-mail de surveillance de l'état de santé ASP.NET J'espère que quelqu'un peut faire la lumière. C'est un site Web public qui fonctionne sur l'infrastructure chez un fournisseur d'hébergement indien. La surveillance de l'état de santé nous signale les erreurs de serveur par courrier électronique automatisé, mais de temps à autre, l'URL demandée apparaît comme un site Web totalement différent. Par exemple:

Request information: 
    Request URL: http://www.baidu.com/Default.aspx 
    Request path: /Default.aspx 
    User host address: 221.13.128.175 
    User: 
    Is authenticated: False 
    Authentication Type: 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Il est évident que le site en question n'est pas Baidu et, évidemment, cet attribut est pas le referrer soit; la valeur "Request URL" est le chemin qui a généré l'erreur. L'adresse IP est located in Beijing (coïncidente étant donné l'adresse Baidu?) Et dans ce cas, il semble que le backend SQL Server n'était pas accessible (je n'ai pas inclus le message d'erreur complet pour des raisons de sécurité). Qu'est-ce qui entraînerait la modification arbitraire de l'attribut de l'URL de la requête à celui d'un autre site? Je n'ai jamais vu cela se produire dans un événement de surveillance de la santé avant. Merci! Pour ceux qui ne connaissent pas Baidu, c'est le plus grand moteur de recherche de Chine et ne fonctionne absolument pas sur la même infrastructure indienne que ce site particulier.

Answer 1

Vous pouvez provoquer cela en modifiant votre fichier hosts pour inclure une entrée sur www.baidu.com à l'adresse IP de votre serveur puis en demandant http://www.baidu.com/Default.aspx.

Il se terminerait probablement sur le site Web par défaut si les HostHeaders dans IIS pour cela sont vides. Cela peut être différent de votre site Web habituel, ce qui pourrait expliquer le message d'erreur SQL que vous receviez. Pourquoi quelqu'un ferait cela, je ne suis pas sûr. Peut-être une erreur DNS innocente quelque part ou un bot mal écrit?