Discussion on:
View:
Show:
The article mentions, "There are no mechanisms built in to the Windows operating system or IIS that allow you to obscure the identity or version information of IIS." This is only partly true. A well known tool called URL Scan, written by Microsoft and a free download, allows you to remove the IIS Server header or even change it to whatever you would like the header to read. In the folder c:\winnt\system32\inetsrv\urlscan (assuming you have it installed), there is a file named "urlscan.ini". Within this file are many options that determine how your server responds to HTTP requests. In the [options] section is an entry named "RemoveServerHeader". Setting this value to 1 removes the server header from responses while 0 keeps it at the default level. However, if you choose to use "0" as the value, you can specify another entry named "AlternateServerName" that will replace IIS's built in server header. I've seen many just switch the platform type and enter in a value like "Apache/1.3.19 (Unix) PHP/4.0.4pl1".
Agree, it's very good for Win2000 Servers. But it doesn't support Win2003 Server, as far as I know. 
Also, if you run MS FTP, you can't modify it's headers.
/ Per
Also, if you run MS FTP, you can't modify it's headers.
/ Per
Not sure where you heard that from, but they lied to you.
Don't take my word for it, buy hacking exposed 2003 and or install Urlscan.
It works.
Don't take my word for it, buy hacking exposed 2003 and or install Urlscan.
It works.
About 2 years ago I found a flaw in the Remove Server Header option.
The wording of this option is a little misleading and if your not familiar with a tcp transmission you would not know that anything was wrong.
Basically, they take the wording literally, They remove not only the comments in the field, but the field all together. This actually violates the RFC.
By removing this field all togther from the transmission, you will break certain applications.
The most notable was that of an embedded windows media player inside of IE. Because IE was following the RFC and saw the server header field missing, it did not pass the url to the embedded player.
Essentially, you are not allowed to alter/remove the field. But you *CAN* put bogus data in it.
I prefer something really misleading like
"MAC Sun Sparc Http Server 1.2Beta"
It is published under
http://support.microsoft.com/default.aspx?scid=kb;en-us;327722
The wording of this option is a little misleading and if your not familiar with a tcp transmission you would not know that anything was wrong.
Basically, they take the wording literally, They remove not only the comments in the field, but the field all together. This actually violates the RFC.
By removing this field all togther from the transmission, you will break certain applications.
The most notable was that of an embedded windows media player inside of IE. Because IE was following the RFC and saw the server header field missing, it did not pass the url to the embedded player.
Essentially, you are not allowed to alter/remove the field. But you *CAN* put bogus data in it.
I prefer something really misleading like
"MAC Sun Sparc Http Server 1.2Beta"
It is published under
http://support.microsoft.com/default.aspx?scid=kb;en-us;327722
You could also try disabling mouse right click thereby disallowing the viewing of the web page source.
Sample code goes something like this
<!-- Disable Mouse Rightclick
/* */
var message="Right-Click?\n\n\n\n\nDid you mean to Right-Click?";
// Don't edit below!
function click(e) {
if (document.all) {
if (event.button == 2) {
alert(message);
return false;
}
}
if (document.layers) {
if (e.which == 3) {
alert(message);
return false;
}
}
}
if (document.layers) {
document.captureEvents(Event.MOUSEDOWN);
}
document.onmousedown=click;
// -->
Sample code goes something like this
<!-- Disable Mouse Rightclick
/* */
var message="Right-Click?\n\n\n\n\nDid you mean to Right-Click?";
// Don't edit below!
function click(e) {
if (document.all) {
if (event.button == 2) {
alert(message);
return false;
}
}
if (document.layers) {
if (e.which == 3) {
alert(message);
return false;
}
}
}
if (document.layers) {
document.captureEvents(Event.MOUSEDOWN);
}
document.onmousedown=click;
// -->
When you disable the right-click, it's only a sign to hackers that there may be something there they want.
All you have to do is go to the Temporary Internet folders, scroll down the until you locate the page you're on and send it to notepad, copy locally, etc and you can view it's content.
The disable right-click only foils the "non-hacker" types that really don't care anyway.
All you have to do is go to the Temporary Internet folders, scroll down the until you locate the page you're on and send it to notepad, copy locally, etc and you can view it's content.
The disable right-click only foils the "non-hacker" types that really don't care anyway.
That would be great if right-clicking were the only way to view the source. Unfortunately, you could just click view and page source from the tool bar.
I remember the first time I hit a web page that did not allow me to right-click. I turned off scripting, problem solved. Since then I discovered Mozilla which gives me some granular control over what scripting is permitted to do. It's great!
Essentially what is being recommended here is trying to show a fake server version in the line from the header but, ultimately, I'm not sure What's the point of that.
I have known cases where 3rd-party security scans of corporate networks have a problem with exposing software versions through headers, handshake strings, etc. Their solution often is to suggest completely hiding the web server version (although usually not being able to advise you how to do this), with maybe something like "GoAwayTeenageScriptKiddie WebServer v100.5 (with no buffer overflows)".
This is the essentially the old adage "security through obscurity", which hopefully isn't the only layer of "security" anyone uses? I won't go into any prolong discussion about the merits, or limitations of this.
To a certain extent, for Apache servers, this can be accomplished using ServerSignature and ServerTokens directives, although they do not completely prevent server information from being disclosed. See the Apache FAQ:
http://httpd.apache.org/docs/misc/FAQ-E.html#serverheader
Of note, and I quote:
"There are, however, two answers to this question: the correct answer, and the answer that you are probably looking for.
The correct answer to this question is that you should use the ServerTokens directive to alter the quantity of information which is passed in the headers. Setting this directive to Prod will pass the least possible amount of information:
Server: Apache
The answer you are probably looking for is how to make Apache lie
about what it is, i.e., send something like:
{Paul, this is what you are asking as per your response to a reply to
your OP]
Server: Bob's Happy HTTPd Server
In order to do this, you will need to modify the Apache source code
and rebuild Apache. This is not advised, as it is almost certain not
to provide you with the added security you think that you are gaining.
The exact method of doing this is left as an exercise for the reader,
as we are not keen on helping you do something that is intrinsically a
bad idea."
FWIW, this has been discussed by the Apache developers, as this issue arises every six months or so. Some of the comments were:
* As the FAQ suggested, "Frequently, people want to remove this
information, under the mistaken understanding that this will make the
system more secure. This is probably not the case, as the same
exploits will likely be attempted regardless of the header information
you provide."
* It could quite likely lead to more attempts on your server because
the cracker does not know which version it is and may try all types of
exploits, rather than those specifically targeted to the server type.
* A suggestion to use a "ServerToken None" was met with resistance
because "All the ServerTokens options that hide version numbers are
security by obscurity anyway... this simple obscuring scheme will
[not] block any serious attack."
* Similarly, the HTTP specifications call for a certain degree of
header details (whether valid or invalid). Start playing with them too
much and it could lead to confusion.
* Many web sites use these headers for statistics. If everyone tries
to obscure them, Apache then has >60+% market share according to
NetCraft when that is really inaccurate... [why] do we need to muck
with the Server header? Who cares? Attacks will be run regardless of
Server headers (and if not, they will as soon as we start removing
them). So, in the end, what good does it do? ... Apache is proud to be
Apache!
Hope this gives you some more background on this issue.
I have known cases where 3rd-party security scans of corporate networks have a problem with exposing software versions through headers, handshake strings, etc. Their solution often is to suggest completely hiding the web server version (although usually not being able to advise you how to do this), with maybe something like "GoAwayTeenageScriptKiddie WebServer v100.5 (with no buffer overflows)".
This is the essentially the old adage "security through obscurity", which hopefully isn't the only layer of "security" anyone uses? I won't go into any prolong discussion about the merits, or limitations of this.
To a certain extent, for Apache servers, this can be accomplished using ServerSignature and ServerTokens directives, although they do not completely prevent server information from being disclosed. See the Apache FAQ:
http://httpd.apache.org/docs/misc/FAQ-E.html#serverheader
Of note, and I quote:
"There are, however, two answers to this question: the correct answer, and the answer that you are probably looking for.
The correct answer to this question is that you should use the ServerTokens directive to alter the quantity of information which is passed in the headers. Setting this directive to Prod will pass the least possible amount of information:
Server: Apache
The answer you are probably looking for is how to make Apache lie
about what it is, i.e., send something like:
{Paul, this is what you are asking as per your response to a reply to
your OP]
Server: Bob's Happy HTTPd Server
In order to do this, you will need to modify the Apache source code
and rebuild Apache. This is not advised, as it is almost certain not
to provide you with the added security you think that you are gaining.
The exact method of doing this is left as an exercise for the reader,
as we are not keen on helping you do something that is intrinsically a
bad idea."
FWIW, this has been discussed by the Apache developers, as this issue arises every six months or so. Some of the comments were:
* As the FAQ suggested, "Frequently, people want to remove this
information, under the mistaken understanding that this will make the
system more secure. This is probably not the case, as the same
exploits will likely be attempted regardless of the header information
you provide."
* It could quite likely lead to more attempts on your server because
the cracker does not know which version it is and may try all types of
exploits, rather than those specifically targeted to the server type.
* A suggestion to use a "ServerToken None" was met with resistance
because "All the ServerTokens options that hide version numbers are
security by obscurity anyway... this simple obscuring scheme will
[not] block any serious attack."
* Similarly, the HTTP specifications call for a certain degree of
header details (whether valid or invalid). Start playing with them too
much and it could lead to confusion.
* Many web sites use these headers for statistics. If everyone tries
to obscure them, Apache then has >60+% market share according to
NetCraft when that is really inaccurate... [why] do we need to muck
with the Server header? Who cares? Attacks will be run regardless of
Server headers (and if not, they will as soon as we start removing
them). So, in the end, what good does it do? ... Apache is proud to be
Apache!
Hope this gives you some more background on this issue.
It may only obscure the information and cause the hacker to try different methods, but what it DOES do is give "Security Appliance" hardware/software a chance to catch those attempts, prevent more attacks and even block the attackers IP from accessing the system further!
For more background on this type of subterfuge look at a previous article
Lock IT Down: Increase Web server security via obscurity published on Oct 07, 2003.
Lock IT Down: Increase Web server security via obscurity published on Oct 07, 2003.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle









































