There is a third way to prevent browserconfig.xml
from filling your log files with 404 errors. You can return a null value (444) from the server and turn off logging for just that location. This is relevant because favicon.ico does the same thing ignoring the meta head tags and the browser calling it (also generating a 404). The problem is larger than just this one unwanted file.
To your specific question of preventing 404 errors in your logs on browser.xml - for NGINX, you can create a new file in /etc/nginx/snippets/
and then #include
that file in your /etc/nginx/sites-available/example.org
file inside of the server block.
Example: /etc/nginx/snippets/block-known-errors.conf
has the following contents:
location ~* /(favicon.ico|browserconfig.xml)$
{ access_log off; log_not_found off; return 444; }
Then in your config at /etc/nginx/sites-available/example.org
you would add:
include /etc/nginx/snippets/block-known-errors.conf;
Note in the location specification in NGINX is using a regular expression and is case insensitive. And because it is a location
is must be inside of the server
specification.
In practice, we actually nest our includes in the /etc/nginx/snippets/
folder and have one global include and other includes for specific sites depending on security/technology requirements. This allows our endpoints to fix a global issue almost immediately by adding one file or editing an existing file to manage our logs.
There is only so much cruft you can see through with OSSEC and an ELK stack.
I am sure mod_rewrite in Apache could do this as well.