Analyze URLScan That Doesn't Affect Web Site

Q: We run URLScan on several Windows 2000 internal and public Web servers. As we examine the URLScan logs, we commonly see rejected requests that read Client at : Received a malformed request which resulted in error 50 while modifying the 'Server' header. Request will be rejected with a 400 response. Strangely, these entries don't appear in the IIS log files. Despite these errors messages, the Web sites seem to be running fine and we don't receive reports of clients who can’t reach their sites. Could these rejected requests be some sort of random automated attack that doesn't generate the usual attack signatures?

A: The URLScan log-file entry you quoted can appear any time URLScan or another filter attempts to parse, modify, add, or delete a response header for a Simple HTTP request (i.e., http .9). Because such a client header doesn't contain all the content that IIS expects, URLScan rejects the request and makes an entry in the log file. For example, a spider can send this kind of HTTP request as the result of a port scanner or monitoring system that isn't using a fully formed HTTP request to contact the server. Alternatively, as you say, these entries in the URLScan log might also be the result of a script looking for particular kinds of servers or otherwise trying to garner information from the server by sending malformed requests. Finally, this error is probably not caused by a typical Web browser, which is why you aren't getting customer complaints. IIS doesn't log the request because it can't properly parse the client header and probably doesn't know which Web site the malformed HTTP request is directed to.