Re: Altering "Server" HTTP Header Param
by dws (Chancellor) on Oct 15, 2002 at 00:03 UTC
|
I figure that netcraft.com is using the "Server" line from an HTTP header to determine the server software I'm using. So my thought is: perhaps I just muck aroung with the HTTP header and call it good.
gryphon, the situation you're in sucks, but it's a business problem, not a technical one.
The "let's just fake it" approach is really tempting, but it could expose your company to legal problems. The customer might be unhappy with your technology choices now, but I would expect them to be furious if they were to discover that you were intentionally deceiving them. Check with your legal people before you deploy a configuration that lies about what the underlying platform is (even if your customer has been caught pulling the same trick before).
When letting the contract, if your customer didn't specify constraints on technology (i.e., they didn't say "you must use ours"), then coming back to your company with an additional constraint at a late date should trigger a business-level renegotiation. They're asking you to build something else, after all.
Don't risk getting your company, and yourself, in a lot of hot water.
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by gryphon (Abbot) on Oct 14, 2002 at 21:59 UTC
|
Greetings all,
tye had a really interesting idea he told me via Chatterbox. He said I should try making the script a non-parsed headers script and feed in my own HTTP headers manually. I did so, and now all my HTTP headers appear to be "correct" (i.e. incorrect intentionally).
Problem is, it doesn't appear to work when I try this using CGI.pm, but only as a flat series of lines.
#!/usr/bin/perl
use strict;
use warnings;
=pod
use CGI;
my $cgi = new CGI;
print $cgi->header(
-nph => 1,
-type => 'text/html; charset=ISO-8859-1',
-cache_control => 'private',
-connection => 'close',
-server => 'Microsoft-IIS/6.0'
);
=cut
print <<ENDOFHTML;
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 14 Oct 2002 21:41:25 GMT
Server: Microsoft-IIS/6.0
Content-Length: 31000
Content-Type: text/html
Expires: Mon, 25 Oct 2010 21:21:21 GMT
P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo
+OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI'
<HTML><HEAD><!-- the rest of the html document -->
The problem is that NetCraft is still reporting me running Apache. However, after some reading on their site, I get the feeling (backed by no real evidence) that they query for new site data on a daily basis. So perhaps by tomorrow, my problems will be solved.
gryphon
code('Perl') || die;
| [reply] [Watch: Dir/Any] [d/l] |
|
As a faster means to confirming your headers and all the
other data transferred during an HTTP session, try using
Ethereal. It's a packet-sniffer; it's been ported to several
platforms, and has some very cool abilities.
After capturing an HTTP session or two, you can scroll
through all the sniffed packets and get a blow-by-blow
analysis of the session including (you guessed it) headers
sent by the browser and headers sent by the server, as well
as document text. Much faster than waiting for Netcraft to
recrawl your server.
I discovered Ethereal over this weekend, and it's now an
essential tool in my toolbox. I'll be using it for my own
CGI programming. Definitely. Find it here.
Good luck on satisfying your client.
-Shawn / (Ph) Phaysis
If idle hands are the tools of the devil, are idol tools the hands of god?
| [reply] [Watch: Dir/Any] |
|
You should be able to get that to work, but it may not fool Netcraft. For one thing, they report operating system based analysis of TCP/IP traffic. You would also have to have enough control over that server to make sure that every call to "/" will run your script. Without a dedicated server, you probably don't have that.
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by blakem (Monsignor) on Oct 14, 2002 at 20:59 UTC
|
I think you'll have to tweak the apache source and recompile.
The relevant file is src/main/http_main.c. Grep for 'server_version' and 'SERVER_BASEVERSION' to find the lines that deal with setting the server name.
The logic to create that value has gotten more complex since I looked at it ages ago, so it will take some work to figure out exactly how it gets set.
-Blake
| [reply] [Watch: Dir/Any] [d/l] |
|
Greetings blakem,
Yeah, I noticed that. Unfortunately, I can't recompile Apache since this all lives in an account on an ISP. I'm hoping that I can either find a Perl solution to force the "Server" header change, or use an ".htaccess" file to do something for me.
I'm getting discouraged, though. I think I'm screwed.
gryphon
code('Perl') || die;
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
To actually change the server tokens you need to recompile, but you can turn them off with the ServerTokens directive.
Unfortunately, “[the] setting[s] appl[y] to the entire server, and cannot be enabled or disabled on a virtualhost-by-virtualhost basis.” Which means it must be used in the main server configuration files. Some ISPs can be convinced to turn them off completely on a security basis — other than that you’re out of luck.
| [reply] [Watch: Dir/Any] |
|
|
|
I'm afraid you are screwed if you can't recompile Apache. There is no other way to do it.
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by Flexx (Pilgrim) on Oct 15, 2002 at 01:30 UTC
|
Somehow I had to giggle when I read your post... That's what comes from sleeping with the enemy. Weren't you courious when they asked you to sign the papers with blood? ;)
However, I'd have serious legal concerns about trying to deceive your client. What you try to do is, indeed, fraud. If they want you to port this to some other platform/system/language, you can't just pretend you do it. Do it, or leave it (my favorite choice), if your contract allows you to make that choice.
Update: BTW, wasn't it M$ who sued people for faking HTTP user agent strings? I think they acually won the case (a decision I can't understand).
Did they specify which system you must use when they gave you the contract?
Yes? Then you're framed -- since you actually didn't deliver.
No? Then they, AFAIB, cannot do anything about your choice. They might choose not to use your work, but they'll certainly have to pay for it, as long as it functionally provides what they ordered. If they insist on porting your work, they'd have to pay for that separately (since that would be another order/job).
Do you run the service? Is it a service you are paid to run? If yes, then it's just the typical manner of M$ in trying to put pressure on people, to force them into decisions they think are ok with them. Which is really none of their business. It's my eternal hope that the market one day will respond, and that such practice won't prevail. If they pay you for the service (not the implementation details), they can't touch you legally, I'd think.
Of course, the question is whether you'd want to meet M$ "lawyers" at high noon...
So long,
Flexx
| [reply] [Watch: Dir/Any] |
|
Load IIS and Apache... Change the port of apache to 81, and have an HTTP refresh on the IIS default page to the :81 port
;-)
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by valdez (Monsignor) on Oct 14, 2002 at 23:35 UTC
|
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by true (Pilgrim) on Oct 14, 2002 at 21:38 UTC
|
I love your 'solution', although devious, it's got moxy.
Do you have WebMin running (root access)? You can change the server info file with webmin (set a custom header file). Another even better trick would be to put a redirect in your dns which redirects the request from netcraft's ip to a special perl script. The perl script could output what looked like a server line.
You will then be running a Mucrosoft webserver.
Feel free to forward your boss lady the millions of complaints from IIS virus haters everywhere.
Da penguin's da bomb!
To clarify, redirect to a perl script which listens on
another socket locally. To mimic the http protocol.
It could be done but i wouldn't want to do it ;>
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by Jaap (Curate) on Oct 14, 2002 at 22:41 UTC
|
If the boss want you to use a IIS webserver, she will provide you with one. If she does, put a little redirect perl script on the IIS server to your current or some other LAMP (Linux, Apache, MySQL, Perl) server.
This would work unless this means you'd have to pay for the LAMP server yourself (raise a fund, every decent visitor here will donate ;-) | [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by cluka (Sexton) on Oct 14, 2002 at 21:38 UTC
|
See what happens when you sell your soul to the Devil??? ;) | [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by Jeppe (Monk) on Oct 15, 2002 at 15:43 UTC
|
What you do is insufficient. Have you ever played with nmap? It is capable of guessing the operating system by probing the TCP implementation.
If you really want to get away with this, besides the legal problems, you will want to make a windows machine proxy everything while doing the actual calls to the apache server.
However, I must agree with the other comments about legal issues.
If your client failed to specify acceptable platform software, you might get the money by legal moves and then your client will have to pay for a second copy that complies to their new, accurate specification.
In general, I consider proper specification and acceptance criteria vital to any code-for-hire development, and most development in general. | [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by Steve_p (Priest) on Oct 14, 2002 at 21:49 UTC
|
I'm getting discouraged, though. I think I'm screwed.
Looking at this documentation, you may be right.
The Header directives are processed just before the response is sent by its handler. These means that some headers that are added just before the response is sent cannot be unset or overridden. This includes headers such as "Date" and "Server".
| [reply] [Watch: Dir/Any] |
Re: Altering "Server" HTTP Header Param
by cluka (Sexton) on Oct 15, 2002 at 16:30 UTC
|
Gotta agree with the other comments on the business side of this
decision. You don't want to get caught "faking it" by Microsuck -
you think you're in trouble now!
Not to make it worse, but if you "fake it" you only give the
open-source community a bad name and ammo to the enemy. Your and our
integrity are (to some degree) on the line.
Check the contract - they're the Skulls, and your that wussy kid
Josh Something from Dawson's Creek, but you can beat them if you have an out
on paper. If they didn't specify which platform, server, etc to
use, you're in the sweet spot. Let them know you'll port your stuff
over, but for a fee.
That's the one great part of this deal - you might be able to stick
it to Redmond one more time. Sweet! | [reply] [Watch: Dir/Any] |