What is this in my logs?

Repeated Odd HTTP GETs w/o CSS, Site Images, etc.

[rrdega]

I'm curious, and gett'n a li'l irritated by this... Over last weekend, I moved my sites to a new (bigger, badder, 'n faster) server. Ever since then, I have been seeing this kinda stuff in my access log:

219.165.81.239 - - [22/Aug/2003:11:05:20 -0500] "GET / HTTP/1.1" 200 10476 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
168.58.181.22 - - [22/Aug/2003:11:09:27 -0500] "GET / HTTP/1.1" 200 10476 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
209.47.20.140 - - [22/Aug/2003:11:14:11 -0500] "GET / HTTP/1.1" 200 13311 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
4.60.72.164 - - [22/Aug/2003:11:19:40 -0500] "GET / HTTP/1.1" 200 13136 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
35.11.220.72 - - [22/Aug/2003:11:24:56 -0500] "GET / HTTP/1.1" 200 10898 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
219.167.81.202 - - [22/Aug/2003:11:25:24 -0500] "GET / HTTP/1.1" 200 10476 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
67.72.205.160 - - [22/Aug/2003:11:32:17 -0500] "GET / HTTP/1.1" 200 13318 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
67.35.113.36 - - [22/Aug/2003:11:34:21 -0500] "GET / HTTP/1.1" 200 10898 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

It just goes on and on and on... Seemingly varying IPs, and no CSS or image GETs, so its not a real browser. I figure its something doing some sort of wget; Right?

Except, when *I* do a wget, this is what is logged...
67.65.136.57 - - [22/Aug/2003:11:39:46 -0500] "GET / HTTP/1.0" 200 13103 "-" "Wget/1.8.2"

Comments? Explanations? Any ideas how to stop it? Its suck'n bandwidth needlessly in my book!

Thanx!
-Bob

[starec]

> perhaps they hope this will just drown in the general traffic patterns

That's exactly my problem. I don't know what to look for in my logs. They are huge. Is there a way of identifying these requests without going manually through all the GET requests for /?

[Wasa1234]

The easiest way would be to grep for "get /" and then msie 5.5 / windows98 combination...

Trouble is there may be some real ones in there!

[rrdega]

Well, it looks like since the 18th, I've been polled by this "thing" approximately 3600 times!

[ses4j]

Here's a couple other guys talking about it elsewhere (although most haven't gotten very far - I found them with the same query natch used):

[aota.net...]
-and-
[aota.net...]
-and-
[forums.devshed.com...]

The first one discusses a possible link to 'NaverRobot':

I did some more digging, and noticed that the only cases of multiple probes across days were from two IP addresses that we had previously blocked as being used by a bad bot ("NaverRobot"). There were two other known NaverBot IP addresses among the rest.

And here's a webmasterworld complaint thread about that:

[webmasterworld.com...]

Why won't someone important tell us what it all means?! (and better, make it go away!)

Scott

[claus]

>> won't someone important tell us what it all means?!

Possibly they just don't know about this and other threads. OR, as the bot/virus/worm/whatever is a stealth one, it's more likely because they don't relly want people to know what it's doing and who is in fact doing it.

Here's a few more or less related threads from this forum and forum 11 (Search Engine Spider Identification) - it's not necessarily the same UA-string though:

1) "Multiple IP Access"
[webmasterworld.com...]

2) Fake Dynamic IP changing continusly
[webmasterworld.com...]

3) False agent-name and False IP
[webmasterworld.com...]

4) "Spider running as Trojan?"
[webmasterworld.com...]

5) "Repeated Requests At Fixed(ish) Interval"
[webmasterworld.com...]

/claus

[anallawalla]

I too have been hit at one site (where I cannot block by IP). Here are some examples (notice the delay in the revisits):

A visitor from cs242216-86.houston.rr.com (24.242.216.86) was logged twice,
starting at 8:43:26 on Wednesday, August 27, 2003.
The initial browser was Mozilla/4.0 (compatible; MSIE 5.5; Windows 98).

This visitor first arrived without a refering URL,
and visited www.x.com/index.shtml

20:28:39 and 1 day later, arrived without a refering URL,
and visited www.x.com/index.shtml

A visitor from cs242216-86.houston.rr.com (24.242.216.86) was logged twice,
starting at 8:43:26 on Wednesday, August 27, 2003.
The initial browser was Mozilla/4.0 (compatible; MSIE 5.5; Windows 98).

This visitor first arrived without a refering URL,
and visited www.x.com/index.shtml

23:37:40 and 1 day later, arrived without a refering URL,
and visited www.x.com/index.shtml

A visitor from adsl-67-113-42-169.dsl.scrm01.pacbell.net (67.113.42.169) was logged twice,
starting at 5:04:10 on Wednesday, August 27, 2003.
The initial browser was Mozilla/4.0 (compatible; MSIE 5.5; Windows 98).

This visitor first arrived without a refering URL,
and visited www.x.com/index.shtml

00:16:48 and 1 day later, arrived without a refering URL,
and visited www.x.com/index.shtml

A visitor from ip64-48-186-230.z186-48-64.customer.algx.net (64.48.186.230) was logged twice,
starting at 5:02:14 on Wednesday, August 27, 2003.
The initial browser was Mozilla/4.0 (compatible; MSIE 5.5; Windows 98).

This visitor first arrived without a refering URL,
and visited www.x.com/index.shtml

21:11:00 and 1 day later, arrived without a refering URL,
and visited www.x.com/index.shtml

A visitor from d51i226.bbx.ad.jp (218.40.51.226) was logged twice,
starting at 0:03:01 on Monday, August 25, 2003.
The initial browser was Mozilla/4.0 (compatible; MSIE 5.5; Windows 98).

This visitor first arrived without a refering URL,
and visited www.x.com/index.shtml

09:33:58 and 2 days later, arrived without a refering URL,
and visited www.x.com/index.shtml

NAI info about Naver i-worm [vil.nai.com]

Always two visits, always Win98 UA.

[ses4j]

I was looking at my logs (again), and I noticed (perhaps not surprisingly) that the IPs that the strange hits are coming from are similar to ones I've had visits from.

For example:
The most I've been worm-hit from a single host is 7 times, from 220.73.165.208. Looking back at my logs for all 220.73 hits, I see this (normal=regular user found my page and viewed it; worm=you know):

normal 220.73.165.11 - - [05/Aug/2003:22:10:02 -0400]
worm 220.73.165.139 - - [18/Aug/2003:07:58:20 -0400]
worm 220.73.165.79 - - [18/Aug/2003:11:25:41 -0400]
worm 220.73.165.208 - - [19/Aug/2003:10:26:22 -0400]
worm 220.73.165.208 - - [20/Aug/2003:00:58:06 -0400]
worm 220.73.165.208 - - [20/Aug/2003:14:08:22 -0400]
worm 220.73.165.208 - - [21/Aug/2003:01:50:12 -0400]
worm 220.73.165.11 - - [23/Aug/2003:13:26:32 -0400]
normal 220.73.165.79 - - [26/Aug/2003:09:26:02 -0400]
worm 220.73.165.208 - - [26/Aug/2003:23:21:45 -0400]
normal 220.73.165.139 - - [27/Aug/2003:08:52:49 -0400]
worm 220.73.165.139 - - [28/Aug/2003:23:53:31 -0400]
and some more worms from .208 after this..

So a wild hypothesis is this worm found my IP in the cache there or something, propagated over their network, and did all that just to bug me all the way from Seoul, Korea.

Scott

[ses4j]

I noticed one other thing too, some of my hits are

220.73.165.139 - - [18/Aug/2003:07:58:20 -0400] "GET / HTTP/1.0" 200 9952 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

and some are:

220.73.165.208 - - [19/Aug/2003:10:26:22 -0400] "GET / HTTP/1.1" 200 9979 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

ie some have HTTP/1.0 and some HTTP/1.1.

Scott

[sharman]

I've been seeing the pattern described by rrdega & ses4j on my personal site. Between 8/18 and 8/31, there were around 4,200 anomalous visits to the index page. No other files were loaded (including the stylesheet and images), IP addresses were never reused, user agent="Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)".

I've searched my logs for some of the IP addresses in the log excerpts posted by the others & have only found a couple that matched IPs in my logs (including ses4j's first visitor, 218.63.191.199).

Here's a sample from my access log:
218.69.28.222 - - [18/Aug/2003:00:10:41 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
61.48.4.27 - - [18/Aug/2003:00:21:34 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
210.21.72.17 - - [18/Aug/2003:00:47:31 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.63.191.199 - - [18/Aug/2003:00:57:59 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.88.3.68 - - [18/Aug/2003:01:27:30 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
219.133.12.176 - - [18/Aug/2003:01:38:45 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
220.73.165.216 - - [18/Aug/2003:01:42:06 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
220.113.11.42 - - [18/Aug/2003:01:46:09 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
219.154.202.176 - - [18/Aug/2003:02:01:15 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.109.54.203 - - [18/Aug/2003:02:37:45 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.109.73.45 - - [18/Aug/2003:02:42:58 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
61.171.31.94 - - [18/Aug/2003:02:48:51 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.29.193.186 - - [18/Aug/2003:02:51:35 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.109.41.11 - - [18/Aug/2003:02:56:49 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.16.77.185 - - [18/Aug/2003:03:03:17 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
61.50.157.160 - - [18/Aug/2003:03:03:30 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.109.40.124 - - [18/Aug/2003:03:13:05 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
218.79.90.24 - - [18/Aug/2003:03:31:55 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
61.178.177.14 - - [18/Aug/2003:03:54:03 -0400] "GET / HTTP/1.1" 200 5049 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

[jdMorgan]

I'm still waiting to get hit by this thing, so I can test to see if it's using a proxy connection. But, I was thinking about what might be done if it wasn't - if it's just some massively-distributed agent that sucks bandwidth.

Here's one thing I'd try:

Detect the user-agent and if it is Mozilla/4.0 (compatible; MSIE 5.5; Windows 98), redirect requests for "/" to some other (fake) filename using a 302-Moved Temporarily redirect.
If the user-agent follows that redirect, it will issue a subsequent HTTP request for for the fake filename.
Then .htaccess can transparently redirect (rewrite) the fake filename back to the actual name of the file normally served for "/" requests.

If this thing is just a pest-bot, it won't follow the redirect, and you'll at least save a ton of bandwidth.
If a real person visits using the MSIE 5.5/Win 98 client, it will just follow the redirect, and no real harm done.

So, for Apache .htaccess use, it'd look like:

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible\;\ MSIE\ 5\.5\;\ Windows\ 98\)$
RewriteRule ^$ /temp.html [R=302,L]
RewriteRule ^temp\.html /index.html [L]

Maybe someone would like to try the code I posted in msg#5 to see if the troublemaker is using open or anonymous proxies. I haven't seen any results posted, so I assume no-one's tried it. It could be just one machine distributing its requests through several proxies. If that's the case, you could block the actual client IP address in the case of open proxies, or just ban all anonymous proxies. If the troublemaker is using stealthing proxies, you'll be stuck with banning all the individual proxy IP addresses. But, better the devil you know...

If you're not interested in writing the small logging scripts, you can just change the last line of each ruleset to

RewriteRule .* - [F]

and then check your logs manually for 403 responses for the signature requests.

I'm not proposing any of the code here or in msg#5 as "fixes," but rather as information-gathering techniques.

Jim

[ses4j]

jdMorgan -

I'm more than willing to try to get more info on this thing with your techniques. Unfortunately, I've never written a perl script (well I edited one once. hehe) so I dunno how to write your anon_proxy.pl logger. Also I'm not sure what the RewriteCond's do (I know what they ARE, and where they go, but I wouldn't mind some info on their workings). But if you can post/sticky me code for the .pl I'll put it on my site and see what I catch.

Scott

[jdMorgan]

Scott,

Just change the last line in each block of code to

RewriteRule .* - [F]

and then watch your logs.

I'd recommend trying them one at a time, the first one first. With the modified RewriteRule, if you get a request from the described type of proxy, then you'll see a 403-Forbidden response in your logs.

I'll see if I can dig up or modify a workable script tomorrow, but it's 1 AM local time, and I'm not up to it right now, especially since I can't fully test it unless I get attacked by this thing first! :o

Jim

[Wasa1234]

From my end here it looks like the last couple days the hits are starting to die down.

In august from the 18th to the 27th was 500+ hits per day; Stats for late aug/september so far are
28th aug : 337 hits
29th aug: 114 hits
31st aug: 90 hits
1st sep : 112 hits
2nd sep : 84 hits (so far)

It could just be the weekend in action (as people turn machines off maybe?) but this trend didn't show up on the 23rd/24th august...

Still no idea what is causing it , but I'll drop another note if things start ramping up ;)

[ses4j]

Here's my prelim results:

Your second script (msg #40) did indeed slow the bad guys down. Requests that served 11225 bytes and returned a 200 became 302's that served 238 bytes. They didn't follow the redirect.

The first script (msg #5) I (think I) had problems with. When the entire script is in there (all Cond lines):
the worm ignored it and merrily GETted (GOT?) my index page every 5 mins or so.

When just the first line was in there (like so):

RewriteCond %{HTTP:Via}!^$ [OR]
RewriteRule .* - [F]

then I got 403s when _I_ looked at my page. Did I do that wrong? If it blocks me, it blocks lots of people, so I had to take it off.

The one line that DIDN'T block me was X-Forwarded, and that didn't stop the worm either.

So what does that all mean? I am gonna leave the temp.html trap in, though... Thanks.

Scott

[rrdega]

G'Morning all,

First, jdMorgan, I did try the Rewrites you suggested back in #5. They did not seem to have an effect, as far as I could tell... Good try though! And made me learn a lot more about mod_rewrite, for sure! :)

Now, though, with the new month/stats upon us, I decided to cop out, and take an offer made by my host to change my IP. Sure enough! My last log entry last night from this thing was:

220.67.249.84 - - [02/Sep/2003:02:48:51 -0500] "GET / HTTP/1.1" 200 15024 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

I reckon that's when my host made the change, 'cause I have not heard from this thing since...

My best theory? I believe this is some kind of worm, or virus, that is trolling for Open Proxies to use. And that perhaps a previous occupant of my IP Address had a proxy server running, or something.

I do not know... All I know is that in this case I opted to cop out, and change IPs. That made it go away... :)

[jdMorgan]

rrdega,
Well, your theory ties in well with the observation that it is "newer sites" that are having this problem.

Scott,
I would expect problems with any of those code lines removed. Basically, the first block of code in msg#5 says, "If the request is from a proxy, and no client IP address information is forwarded, then call the script (or return a 403-Forbidden response if patched per msg#40 or msg#42). I run this exact piece of code on live sites, and use it to call key_master's bad-bot script previously posted here on WebmasterWorld.

The second chunk of code in msg#5 says to log all proxied requests where client IP address is provided. As such, I shouldn't have proposed patching it to return a 403. Rather, this would be a good place to test for the suspect user-agent and then redirect, as in msg#40.

I'm not sure which block of msg#5 code you used, or if you used both, so I can't draw any more conclusions, except to say that it sounds like you yourself are behind a proxy (which is why you blocked yourself from your own site when you modified the code). I guess I need to put more priority on hacking up a script that will just log proxied requests to a file...

Really, the idea is just to collect some proxy-related information that *is* available at the server, but is not usually available in the standard server log formats.

Anyway, the fact that the requestor did not follow a 302 redirect means that this is definitely not a regular browser, and neither is it a smart robot - it is just blindly working off a list of things to do without any adaptation to the server response.

Jim

[sharman]

Some more information: I hacked together a PHP script to log proxy information when the problem user-agent was used. Of the 45 suspect users that I logged in 9 1/2 hours, only one used a proxy.

[johnquest]

I'm seeing the same pattern in my log file for one of my sites. Started yesterday. Any idea what this is yet?

[sharman]

I've worked out that the worm(?) can be identified by it's http headers. They send a null value for "accept-encoding", while MSIE 5.5 indicates "gzip,deflate". I assume this can be leveraged in .htaccess to block the offending traffic?

[claus]

Interesting, so it doesn't accept zipfiles. Perhaps this will work.

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible\;\ MSIE\ 5\.5\;\ Windows\ 98\)$ 
RewriteCond %{HTTP_ACCEPT_ENCODING}!^gzip,\s?deflate$
RewriteRule .* - [F]

There's no OR between conditions, so they're "and". I've made an optional whitespace between the comma and "deflate".

If the whitespace shorthand "\s" can't be used in RewriteConditions, this will do it:

RewriteCond %{HTTP_ACCEPT_ENCODING}!^gzip,[\ ]?deflate$

/claus

---

Edit:

This might be better, as i'm not sure all versions of the IE 5.5 UA has exactly this setting for accept encoding, so test for nothing or just whitespace in stead:

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible\;\ MSIE\ 5\.5\;\ Windows\ 98\)$ 
RewriteCond %{HTTP_ACCEPT_ENCODING} ^[\ ]*$
RewriteRule .* - [F]

[Mean_Man]

Hi All,

I have the same issue and it appears to have started around the 18th as well, My site is over 2 years old and has gone from about 500 hits a month to over 1600 in the last 3 days alone. Each from an unique ip address.

anjy53eqy30oh.bc.hsia.telus.net - - [04/Sep/2003:12:48:38 +1000] "GET / HTTP/1.1" 200 12469 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
211.75.138.190 - - [04/Sep/2003:12:50:39 +1000] "GET / HTTP/1.1" 200 12469 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
adsl-68-73-137-214.dsl.wotnoh.ameritech.net - - [04/Sep/2003:12:57:55 +1000] "GET / HTTP/1.1" 200 13361 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
notes.isc.ih.dk - - [04/Sep/2003:13:00:30 +1000] "GET / HTTP/1.1" 200 12181 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

It appears to be out of control whatever it is!

[sharman]

I tried the htaccess directives that claus posted in the update to his post and it served up 403s for both worm/robot/no-encoding traffic and legit MSIE/Win98 traffic. I haven't been able to work out a variation that distinguishes between the two.

I wonder if HTTP_ACCEPT_ENCODE is supported for RewriteCond, the Apache documentation [httpd.apache.org] doesn't list it with the other supported variables.

[wkitty42]

sharman,

i note that you reference the v2.x apache docs... some servers are still running v1.3.x code... however, from an initial browse, i see little to no difference between them...

in both cases, specific to HTTP_REQUEST_ENCODE, i believe that i'd see about using the %{HTTP:header} format described in those manual pages...

ie: RewriteCond %{HTTP:ACCEPT-ENCODING}

( note the : instead of the _ and use the proper header verbiage... i can't verify what it is supposed to be, ATM )

[claus]

Sharman, wkitty42, you're both right. It isn't supported as a standard variable, but it can be retrieved with the HTTP command in stead:

"There is the special format: %{HTTP:header} where header can be any HTTP MIME-header name. This is looked-up from the HTTP request. Example: %{HTTP:Proxy-Connection} is the value of the HTTP header ``Proxy-Connection:''.
(Apache doc, sharman's link, special note 3, under the table)

So, i'll just try again in another way:

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible\;\ MSIE\ 5\.5\;\ Windows\ 98\)$ 
RewriteCond %{HTTP:Accept-Encoding} ^[\ ]*$ 
RewriteRule .* - [F]

Hope it does the trick this time.
/claus

[martyt]

Maybe it's restating the obvious, but the problem is almost certainly the Welchia worm trying to exploit a known vulnerability in IIS 5.0.

Apparently it tries to do an HTTP GET on some broad range of IP addresses, looking for an IIS server to exploit.

The good news (if you can call it that) is that it'll go away in January of 2004:

"This worm has a built-in expiration date. After January 1st, 2004, the worm will uninstall and remove itself from infected systems. Users can use this feature to easily remove the worm: change the date to 2004 and reboot the system. After this the date can be set back."

(from [f-secure.com...]

I noticed the exact same symptoms everyone else is reporting, starting on August 18. And since my site has normally 100 to 200 visits per day, it really stood out as a problem when that number hit 500+ per day, every day since then.

Basically my site statistics are worthless at this point -- or else my site really *does* suck, as the stats suggest 88% of my visitors are on the site for less than 30 seconds...

[johnquest]

"Maybe it's restating the obvious, but the problem is almost certainly the Welchia worm trying to exploit a known vulnerability in IIS 5.0.
Apparently it tries to do an HTTP GET on some broad range of IP addresses, looking for an IIS server to exploit.

The good news (if you can call it that) is that it'll go away in January of 2004:"

So do you think it's possibly one infected machine generating this traffic or several machines"

[martyt]

*Every* machine infected with the Welchia virus is generating those bogus web hits. How the virus comes up with the IP addresses to probe isn't clear - maybe it's random.

Obviously there are thousands and thousands of home users infected with the virus who haven't a clue about virus protection but leave their PCs connected to always-on broadband anyway. And as long as there are idiots with computers, there will be this kind of problem.

I'm pretty much giving up on trying to gather any useful stats from my site until January when this thing goes away.

[berli]

Has anyone gotten claus' last version to work?

I have many legit IE 5.5/Win 98 visitors (I checked) and don't want to accidently block them. I haven't gotten worm traffic yet, but considering the fact that a lot of my visitors are idiots computer-wise (AOL...etc) it's probably only a matter of time before I get hit as well.

[berli]

If this is really the Welchia worm, why does Symantec

[symantec.com ]

Ports: TCP 135(RPC DCOM), TCP 80(WebDav)

say that it uses different ports from the one mentioned earlier in this thread [webmasterworld.com]?

The machines doing this have one common factor- they are all running win2k or above as they have ldap port 389 open. (msg #22)

(Unless I misunderstood something?)

[Wasa1234]

Berli - those are the ports it tries to infect outbound on. My scans on some of the source IP's showed they had port 389 open inbound - this normally means there is a win2000 machine or above sitting on the source IP.