An attacker will probably be able to identify which OS and app architecture you're using irrespective of the cookie names. There are many ways to identify a .net app. Here are a few: object types are .aspx; div, span or parameter names contain "ctl"; application uses the viewstate parameter; the HTTP response Server header contains .net; the HTTP response contains an "X-Powered-By" header; the order of the response headers.
Here are a few posts and sites which describe different methods of identifying the OS and server type:
DC: Hide OS information (
Click here)
IIS Web Server Security - Mask Windows Web Server (
Click here)
OS fingerprinting using NMAP (
Click here)
With that said, you can make it more difficult to identify the server by elimininating or obfuscating some of these characteristics.
If you're not using the ASP session ID, you could disable it following the steps in MS KB306996 (
Click here).
You could also remove the Server, Date and X-* headers from responses using an iRule:
when HTTP_RESPONSE {
Remove server header
HTTP::header remove "Server"
Remove Date header
HTTP::header remove "Date"
Remove any header which starts with "X-"
for {set i 0} {$i < [HTTP::header count]} {incr i} {
Check if the current header name starts with X-
if {[string tolower [HTTP::header at $i]] starts_with "x-"}{
Remove the header
HTTP::header remove [HTTP::header at $i]
}
}
}
If you are using the ASP session ID cookie, but want to rename it, you could configure the name in the application. I tried to come up with an example iRule which renames the cookie, but there doesn't seem to be an easy way to handle this if there is a possibility of there being multiple ASP session ID cookies in the response. This is due to a bug (CR98328 - HTTP::header values removes colons in the header values it returns if there are multiple headers with the same name) and the fact that you cannot retrieve the value of multiple cookie names using a command like 'HTTP::cookie values Set-Cookie'.
Aaron