[qyn]

Can someone remind me how to set the default (404) page in apache on X?

I'm getting sick of getting these stupid MS IIS hack requests (GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0), so I think I want to serve up my entire MP3 collection when they ask for something like that.

[MrBS]

make a file in your root web directory called .htaccess,
and in that file have this line:

ErrorDocument 404 /relative_path_to_your_404.html

~BS

[ratlater]

You also need to set 'AllowOveride ALL' in the httpd.conf which is found in /etc/httpd/

-matt

[MrBS]

Originally posted by ratlater:
You also need to set 'AllowOveride ALL' in the httpd.conf which is found in /etc/httpd/

-matt

Ah. Yes. Quite. I should have mentioned that.
~BS

[MrBS]

Originally posted by qyn:

I'm getting sick of getting these stupid MS IIS hack requests (GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0), so I think I want to serve up my entire MP3 collection when they ask for something like that.

Sorry, I didn't read your full request...
That's an odd idea... you're going to be sending infected computers (not evil hackers) information they didn't want... and pillaging your own upstream in the process...

at any rate, a default 404 wouldn't do anything like that. If you want the path /scripts/..%c1%1c../winnt/system32/cmd.exe to resolve to something else, you'd put this in the afformentioned .htaccess file:

Redirect /scripts/..%c1%1c../winnt/system32/cmd.exe http://thefullyqualifiedpath.com/blah/blah.html

~BS

[qyn]

Originally posted by MrBS:

That's an odd idea... you're going to be sending infected computers (not evil hackers) information they didn't want... and pillaging your own upstream in the process...

at any rate, a default 404 wouldn't do anything like that. If you want the path /scripts/..%c1%1c../winnt/system32/cmd.exe to resolve to something else, you'd put this in the afformentioned .htaccess file:

Redirect /scripts/..%c1%1c../winnt/system32/cmd.exe http://thefullyqualifiedpath.com/blah/blah.html

~BS

The point was not to send anyone info they didn't want, it was to tie up the GET so that it couldn't then GET something else. But you're right; sending a big file is not the best way. A better way is to have a cgi that never finishes. Which still uses some of my resources of course, but I think it's worth the annoyance.

I want my default 404 to do that since not all requests are for the same thing exactly. I have a fairly extensive list of attempted "hacks" that all got a 404 response from my server. Since all I am using this for is as a file-sharing server for my friends, the only mistakes that get a 404 will be these bogus requests.

[MrBS]

Originally posted by qyn:


The point was not to send anyone info they didn't want, it was to tie up the GET so that it couldn't then GET something else. But you're right; sending a big file is not the best way. A better way is to have a cgi that never finishes. Which still uses some of my resources of course, but I think it's worth the annoyance.

I still don't think that will do what you want. A Get request doesn't sit around waiting for you. It gets to your server. Then (if everything works out) your server will send out however many packets are needed to fulfill that request, addressed to the IP specified in the get. You won't be "tying up" the get request. If you sent back large files, you'd just be trying to DOS him, and my money's on his downstream over your upstream. And let's not forget this is most likely just an infected computer, as opposed to someone with malicious intent. As for the cgi that never ends, I don't think it will ever make it to an interpreter.

Correct me if I'm wrong.
~BS

[Mactoid]

A redirect directive will not work for a worm. Redirects tell the client to fetch the new page, so they would require cooperation with the worm to work properly. What you want to do is use an alias instead. These are the directives I have in my own config file:

AliasMatch /.*cmd.exe.* "/Library/WebServer/Sites/worm_counter.shtml"
AliasMatch /.*root.exe.* "/Library/WebServer/Sites/worm_counter.shtml"
AliasMatch /default.ida.* "/Library/WebServer/Sites/worm_counter.shtml"
AliasMatch /MSADC/.* "/Library/WebServer/Sites/worm_counter.shtml"
AliasMatch /c/winnt/.* "/Library/WebServer/Sites/worm_counter.shtml"

Those redirect most IIS vulnerabilities to my counter page so I can keep a running total of worm hits on my page

[qyn]

Originally posted by MrBS:


I still don't think that will do what you want. A Get request doesn't sit around waiting for you. It gets to your server. Then (if everything works out) your server will send out however many packets are needed to fulfill that request, addressed to the IP specified in the get. You won't be "tying up" the get request. If you sent back large files, you'd just be trying to DOS him, and my money's on his downstream over your upstream. And let's not forget this is most likely just an infected computer, as opposed to someone with malicious intent. As for the cgi that never ends, I don't think it will ever make it to an interpreter.

Correct me if I'm wrong.
~BS

Actually, my technique does work as expected (mostly). I redirected all bogus GETs (as Mactoid suggested) to a cgi that I wrote. My cgi records what they attempted to do, and then just hangs.

If I don't do anything about the attempts, I see a bogus request in my access_log about once every second, for 10-15 seconds (as they try all the various combinations).

With my modifications, I see absolutely nothing in the access_log showing these requests. However, in my cgi log, I see a bogus request show up once every 90 seconds or so. This tells me that I'm actually redirecting their requests to my cgi and that they give up after 90 seconds, presumably due to timeout. So I'd say we're about even on annoying each other, plus my access_log is kept clean. And they spend 20 minutes trying to figure out my system, rather than probing 90 other people.

I don't actually have any sympathy for a compromised victim, if that's what you're suggesting. They're as much a part of the problem as anyone.

[MrBS]

Originally posted by qyn:


Actually, my technique does work as expected (mostly). I redirected all bogus GETs (as Mactoid suggested) to a cgi that I wrote. My cgi records what they attempted to do, and then just hangs.

If I don't do anything about the attempts, I see a bogus request in my access_log about once every second, for 10-15 seconds (as they try all the various combinations).

With my modifications, I see absolutely nothing in the access_log showing these requests. However, in my cgi log, I see a bogus request show up once every 90 seconds or so. This tells me that I'm actually redirecting their requests to my cgi and that they give up after 90 seconds, presumably due to timeout. So I'd say we're about even on annoying each other, plus my access_log is kept clean. And they spend 20 minutes trying to figure out my system, rather than probing 90 other people.

I don't actually have any sympathy for a compromised victim, if that's what you're suggesting. They're as much a part of the problem as anyone.

Glad to hear it work for you. I'm surprised that the cgi runs. Could anyone with more knowledge of how this works explain?

Rickster?

~BS