Web Hosting Talk







View Full Version : Virus Attempts: Return to Sender


Website Rob
05-17-2002, 01:03 AM
Those of us that do not have to worry about Virus attempts designed for MS Servers still end up with lots of garbage Error logs. Now it wouldn't be that hard to send the connection attempts to a dead file, but I'm looking for a way to send the attempt back to the originating Server.

This, I believe, would serve two purposes:
for me - virus begone
for them - alerts somebody at the origin point they have a problem

Anyone know of some good Perl coding for this or working examples of alternatives? Something that does not require Root access and can be coded for any account (i.e., within an .htaccess file) would be just ace! :D

Website Rob
05-19-2002, 02:10 AM
I would have thought that with level of knowledge and experience available through WHT, this would not be a difficult question. A shame really.

RutRow
05-19-2002, 02:38 AM
Recently I've been looking at http://www.amavis.org/ and http://www.roaringpenguin.com/mimedefang/ . I haven't tried either.... yet, but looks interesting. There appear to be some commercial products out there too. Of course these require root access to install. If you don't have root, then I guess you are out of luck.

Website Rob
05-19-2002, 03:01 AM
MIMEDefang is for Email only, is it not? Similar to SpamAssassin provided within Cpanel. The "amavis" also looks like it's for Email.

I was hoping for something that works through Apache (.htaccess or otherwise) and will deflect certain HTTP requests back to where they came from.

RutRow
05-19-2002, 10:34 AM
Sorry, I had email virus checkers on the brain yesterday and misread your question.

ciam
05-24-2002, 02:47 AM
I use these in my httpd.conf myself to bounce back questionable HTTP attempts on a server-wide basis:

RedirectMatch Permanent ^/(.*cmd\.exe.*)$ http://127.0.0.1/$1
RedirectMatch Permanent ^/(.*root\.exe.*)$ http://127.0.0.1/$1
RedirectMatch Permanent ^/(.*default\.ida.*)$ http://127.0.0.1/$1

You could also put the code in the .htaccess file of your own site's document root directory.

Website Rob
05-24-2002, 03:18 AM
Hey, hey, now we're getting on the right track. Wasn't aware of the "Redirect" directive. :beer:

So, if wanting to setup for directories instead of specific files, which of these two would be correct?

RedirectMatch Permanent ^/(.*d/winnt/.*)$ http://127.0.0.1/$1

RedirectMatch Permanent ^/(d/winnt/.*)$ http://127.0.0.1/$1

I couldn't find where (http://httpd.apache.org/docs-2.0/mod/mod_alias.html#redirectmatch), there was an explaination for using 127.0.0.1 though, or the meaning of the $1 -- care to share? :)

ciam
05-24-2002, 04:31 AM
Any IP address that starts with 127 designates the local host, but conventionally 127.0.0.1 is used.

$1 is whatever matches between the parentheses in the regular expression on the same line. For a better understanding of regular expression, just search this term on the Internet.

What the directives do is to tell the HTTP requester to fetch from its own machine.

If you have a directory, say "forbidden", your directive could look like this:

RedirectMatch Permanent ^/(.*forbidden.*)$ http://127.0.0.1/$1

But you have to be careful though, it would redirect ALL directories--and their sub-directories--with the name "forbidden".

Website Rob
05-24-2002, 05:18 AM
So if I understand this correctly, instead of worring about directories being parsed (by the potential Virus which cannot affect a Linux system), I only have to worry about which files specifically, it would be looking for.

Even though it looks for things like:

/scripts/root.exe
/scripts/..%2f../winnt/system32/cmd.exe
/scripts/..Áœ../winnt/system32/cmd.exe
/scripts/..%252f../winnt/system32/cmd.exe?/c+dir
/msadc/..%5c../..%5c../..%5c/..Á../..Á../..Á../winnt/system32/cmd.exe

by using the 3 line code you provided, it automatically takes care of any/all directories it searches -- for those files. (cmd.exe, root.exe, default.ida)

ciam
05-24-2002, 05:30 AM
by using the 3 line code you provided, it automatically takes care of any/all directories it searches -- for those files. (cmd.exe, root.exe, default.ida)


You are correct!

NightMan
05-24-2002, 05:35 AM
We had the same problem on Linux servers, and asked the deidicated server provider for solution, now they are blocking these type of requests at router/switch level. So we do not need to use our CPU resource to block this, and the bandwdth usage also saved from these annoying request.

Website Rob
05-24-2002, 05:37 AM
Thank you much! :agree:

Exactly what I've been looking for. May others find this thread as useful as I have.

Edit: Hadn't realized you slipped a post in there Nightman. You make a good point and that is the best method of all. Not always provided though, but now all ways seemed to be covered!

NightMan
05-24-2002, 06:25 AM
Yes, I know not always provided. but if the provider already have Win servers, then they may blocking these virus requests already. so they can simply expand to the Linux servers as well. Our provider even asked us to send details of new annoying requests, if we find any in our log files. We also found this is the best solution. after these implemented, we never seen a single cmd.* request in our log files.