După cum ați menționat deja, filtrarea cererilor IIS ar trebui să vă poată ajuta.
Utilizați un site MVC asp.net, astfel încât orice adresă URL solicitată este verificată cu toate rutele configurate. Aceasta înseamnă că stratul de aplicație este folosit pentru a răspunde cu un 404 la cerere.
În mod ideal, doriți un 404 mai devreme în conducta de solicitare înainte ca stratul de aplicație să fie invocat.
Există mai multe opțiuni:
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence="/system/login" />
</denyUrlSequences>
<hiddenSegments>
<add segment="system" />
</hiddenSegments>
<filteringRules>
<filteringRule name="systemLogin" scanUrl="true" scanQueryString="false">
<denyStrings>
<add string="system/login" />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>
</system.webServer>
Ar trebui doar să vă jucați care dintre ele funcționează cel mai bine pentru dvs. și nu vă afectează propria aplicație.
Dacă activați Urmărirea cererilor eșuate, puteți vedea unde a fost creat răspunsul 404. În testul meu, folosind filtrarea fără cereri, 404 a fost creat la poziția 232 în pipeling, folosind filtrarea cererii, a fost creat la poziția 72 cu mult mai devreme și înainte ca stratul de aplicație să fie invocat.
Da, un firewall web în fața serverului tău IIS ar fi și mai bun, dar fără ca IIS să poată detecta aceste solicitări înainte de a ajunge la aplicația ta.
Asigurați-vă că paginile dvs. de eroare personalizate sunt configurate corect și nu spuneți altceva decât 404.
