Re: [sqlite] Abuse of the SQLite website

[Jay Sprenkle]

On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Last night, a single user (or, at least, a single IP address)
in China that self-identified as running windows98 and
Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
24980 times and  sqlite-source-3_3_12.zip 25044 times
over about a 5 hour period, sucking up significant
bandwidth in the process.

I've seen this type of thing before and have on occasion
banned specific IP addresses from the website using

   iptables -A INPUT -s  -j DROP



I created a script that scanned my site logs for such things and it
automates dropping them
into the iptables bit bucket. I'm sure you could come up with something
workable fairly quickly

Re: [sqlite] Abuse of the SQLite website

[Robert L Cochran]

Peter James wrote:

On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?



A couple of people here mentioned CAPTCHA's.  This is sort of the 
standard
for preventing automated abuse (intentional or unintentional), and 
there are

lots of example implementations out there, maybe even in whatever "custom
software" you use. :-)

http://en.wikipedia.org/wiki/Captcha

Even if you don't go the CAPTCHA route, just forcing an HTTP POST to 
begin a

download will probably filter out a large proportion of errant traffic or
web bots.  I see your robots.txt file is in order for the downloads area,
but of course that's just a gentleman's agreement...

I would be really careful about using these. A significant number of 
people are visually impaired -- I work directly with one person who is 
(he uses powerful magnifiers to read normal sized 10-12 point text) and 
a second person who sits across from me in the office is blind. I don't 
know how they deal with captcha verification, I will have to ask. Notice 
what the wikipedia text has to say on accessibility issues. A maptcha is 
probably a better solution but if you don't understand you are looking 
at a math problem, you are also blocked out.


Bob Cochran


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[emilia12]

hello drh, list

 I used to think that only in my country they can forbid
knives and forks because someone can misuse them, but
obviously it is true for other countries too.

Regards,
Emily

-

Спортни залагания!
bg.sportingbet.com


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Peter James]

On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?



A couple of people here mentioned CAPTCHA's.  This is sort of the standard
for preventing automated abuse (intentional or unintentional), and there are
lots of example implementations out there, maybe even in whatever "custom
software" you use. :-)

http://en.wikipedia.org/wiki/Captcha

Even if you don't go the CAPTCHA route, just forcing an HTTP POST to begin a
download will probably filter out a large proportion of errant traffic or
web bots.  I see your robots.txt file is in order for the downloads area,
but of course that's just a gentleman's agreement...

Re: [sqlite] Abuse of the SQLite website

[Roger Binns]

[EMAIL PROTECTED] wrote:
> Thoughts anyone?  Are there less drastic measures that might
> be taken to prevent this kind of abuse?

It will take a little bit of work, but one solution is to start
throttling traffic for the relevant parties, increasing the throttling
the more they seem to abuse your site.

If it is a legitimate user then their downloads etc will eventually
complete, and if not they will consume smaller and smaller amounts of
bandwidth.

Roger

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Michael Iatrou]

When the date was Tuesday 30 January 2007 16:53, [EMAIL PROTECTED] wrote:

> So my question is really more like this:  Who will get upset
> if www.sqlite.org ceases to function for win98 users?

You can definitely answer this question based on server's logs but still, 
banning users based on OS/UA string is much much less "politically correct" 
than banning based on IP/requests per minute.

Just my 2 cents.

-- 
 Michael Iatrou


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Robert L Cochran]

I fix computers for customers during evenings and weekends and I have 
only have 2 customers (so far) using Windows 98. Nearly everyone, even 
the many seniors among my clients, use Windowx XP and/or OS X.


I feel that banning Win 98 machines is therefore appropriate. Serious 
developers wouldn't be using or developing on Windows 98 any more than 
Windows 3.1. If someone truly needs to download from your site, that 
person can contact you or post to this list and I'm sure some happy 
arrangement can be made. Give them the dump. That's what I would do.


I'm still the only Linux user in my circle of associates but then...the 
Linux folks would probably fix their machines themselves rather than pay 
me to do it. So they'd never think of contacting me to begin with.


Bob Cochran
Greenbelt, Maryland, USA

[EMAIL PROTECTED] wrote:

Last night, a single user (or, at least, a single IP address)
in China that self-identified as running windows98 and
Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
24980 times and  sqlite-source-3_3_12.zip 25044 times
over about a 5 hour period, sucking up significant
bandwidth in the process.

I've seen this type of thing before and have on occasion
banned specific IP addresses from the website using

   iptables -A INPUT -s  -j DROP

But lately, there have been so many problems coming from
win98 and moz4 that I'm thinking of banning all traffic
that self-identifies as such in the User-Agent string of
the HTTP header.

Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-



  



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Florian Weimer]

* Terry Jones:

> Given 50K attempts in 5 hours, this is either a bug somewhere or it's
> automated, likely the latter.

I've seen broken proxies which acted as accidental traffic amplifiers.
It's not necessarily a deliberate attack.

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[G. Roderick Singleton]

On Tue, 2007-01-30 at 12:58 +, [EMAIL PROTECTED] wrote:
> Last night, a single user (or, at least, a single IP address)
> in China that self-identified as running windows98 and
> Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
> 24980 times and  sqlite-source-3_3_12.zip 25044 times
> over about a 5 hour period, sucking up significant
> bandwidth in the process.
> 
> I've seen this type of thing before and have on occasion
> banned specific IP addresses from the website using
> 
>iptables -A INPUT -s  -j DROP
> 
> But lately, there have been so many problems coming from
> win98 and moz4 that I'm thinking of banning all traffic
> that self-identifies as such in the User-Agent string of
> the HTTP header.
> 
> Thoughts anyone?  Are there less drastic measures that might
> be taken to prevent this kind of abuse?
> 

Richard,

You might like to explore using mod_security with some custom rules to
help eliminate problems like this. See http://www.modsecurity.org/

-- 
G. Roderick Singleton <[EMAIL PROTECTED]>
PATH tech



smime.p7s
Description: S/MIME cryptographic signature

Re: [sqlite] Abuse of the SQLite website

[Dennis Cote]

[EMAIL PROTECTED] wrote:


Everybody seems to assume that the problem is an attack.  I
say that you should never attribute to malice what can be
explained by simple stupidity.  

I agree, it is quite probably an unintentional "attack".


So my question is really more like this:  Who will get upset
if www.sqlite.org ceases to function for win98 users?


Well... Win98 users obviously.

You should be able to summarize your logs and determine how many win98 
based clients are accessing the site. That should give you an idea of 
how many users you are likely to upset. I suspect the number is small 
relative to all the other clients, but you might be surprised.


Dennis Cote

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Martin Jenkins]

[EMAIL PROTECTED] wrote:

Something stupid like that.  Maybe somebody can have a look
at the HTTP reply headers that www.sqlite.org issues and point
out any problems.

http://validator.w3.org/ reports a couple of minor problems (missing character 
encoding, no DOCTYPE and a couple of spurious  tags) but I don't know if 
it's clever enough to report header incompatibilities.


So my question is really more like this:  Who will get upset
if www.sqlite.org ceases to function for win98 users?
I only found one mention of win98 clients in a quick scan of my local 
message base (which only goes back to August '06) so I guess not too 
many people. Presumably your server logs could be checked for non moz4 
win98 users, if any. If that's the simplest solution then I'd go for it 
and look again when if the attack reappears or if someone complains.


Bl**dy vandals. :(

Martin


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Lloyd Thomas]

Would not adding verification cause a problem for those include the 
downloading of sqlite in bash/make files of certain apps.


Lloydie T

- Original Message - 
From: "Rich Shepard" <[EMAIL PROTECTED]>

To: <sqlite-users@sqlite.org>
Sent: Tuesday, January 30, 2007 2:50 PM
Subject: Re: [sqlite] Abuse of the SQLite website



On Tue, 30 Jan 2007, Mark Richards wrote:


Returning a link that expires in an email to the requester is a method
that works nicely. It does require some programming and maintenance, but
would be a nice gatekeeper.


  Rather than this, I support the idea of an image with letters and digits
in various fonts or colors (so they cannot be readily harvested by OCR
methods) that are to be manually copied to a text entry field.

  I've no idea of the relative amounts of effort required by these 
different
approaches, but I suspect that such images are readily available on the 
Web

and a sufficiently large collection could be used with each presentation
being arbitrary. Perhaps once this is done -- and hidden from page source
view -- it would not need much maintenance.

  The inconvenience to us who access the site is the price we need to pay
given the abuse of the 'Net and the Web.

Rich

--
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517  Fax: 
503-667-8863


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Rich Shepard]

On Tue, 30 Jan 2007, [EMAIL PROTECTED] wrote:


Everybody seems to assume that the problem is an attack. I say that you
should never attribute to malice what can be explained by simple
stupidity.


  In this context, Richard, I think your original idea of blocking the OS
and/or antique version of browsers requires the least amount of effort. If
that fails, then other measures can be considered.


So my question is really more like this: Who will get upset if
www.sqlite.org ceases to function for win98 users?


  Possibly both of them.

Rich

--
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
 Voice: 503-667-4517  Fax: 503-667-8863

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[John Stanton]

It may not be as innocent as you suspect.  There are well organized 
hacking schemes in China, with Chinese Government support in some cases. 
 One of these may have been practising on your site.  The header is not 
conclusive evidence of its origin.


[EMAIL PROTECTED] wrote:

Mark Richards <[EMAIL PROTECTED]> wrote:

Headers can always be forged as to browser and OS.  Attackers will 
eventually figure it out and then you're back to the drawing board 
again. 



Everybody seems to assume that the problem is an attack.  I
say that you should never attribute to malice what can be
explained by simple stupidity.  Sqlite.org is a (relatively)
low-bandwidth site on an underpowered server.  If somebody
really wanted to attack it and take it down, they would
not have much trouble.  A botnet could bring sqlite.org to
its knees very, very quickly.  I think the problem here is
bugs in archiac versions of Mozilla and/or windows that get
stuck in a loop issuing the same HTTP request over and
over again.  The user is probably unaware of the problem if
they aren't looking at the modem light flashing.

I'm guessing that the browser doesn't like something in the
reply header coming back from sqlite.org (perhaps it is looking
for a chineses character set or something) and so it reissues
the requesting hoping for a better result the next time.
Something stupid like that.  Maybe somebody can have a look
at the HTTP reply headers that www.sqlite.org issues and point
out any problems.  (Www.sqlite.org is driven by custom software
used nowhere else on the planet, as far as I am aware, so there
could be some subtle compatibility bugs.)

So my question is really more like this:  Who will get upset
if www.sqlite.org ceases to function for win98 users?

--
D. Richard Hipp  <[EMAIL PROTECTED]>



-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[John Stanton]

My server has been under heavy attack in the past few hours and I am 
also looking for a way to lock out abusers.  I am thinking of making a 
change to tcpwrappers to identify abusers and place them on the deny 
list.  I want to permit mobile users to access services like POP3 but to 
deny an untrusted IP after it is identified as hammering the port.


The download case could be handled by logging the IP of a downloader and 
denying that IP access for a grace period, perhaps 5 or 10 minutes. 
that would not seriously impinge the capabilities of legitimate users 
but would greatly reduce the capability of abusers to create havoc.


A persistent trier could be placed on an IP deny list after a certain 
number of attempts in a specified time window.


If your HTTP server is launched bu inetd you could use the tcpwrappers 
approach.


The check could be placed in the web server.

[EMAIL PROTECTED] wrote:

Last night, a single user (or, at least, a single IP address)
in China that self-identified as running windows98 and
Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
24980 times and  sqlite-source-3_3_12.zip 25044 times
over about a 5 hour period, sucking up significant
bandwidth in the process.

I've seen this type of thing before and have on occasion
banned specific IP addresses from the website using

   iptables -A INPUT -s  -j DROP

But lately, there have been so many problems coming from
win98 and moz4 that I'm thinking of banning all traffic
that self-identifies as such in the User-Agent string of
the HTTP header.

Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[drh]

Mark Richards <[EMAIL PROTECTED]> wrote:
> 
> Headers can always be forged as to browser and OS.  Attackers will 
> eventually figure it out and then you're back to the drawing board 
> again. 

Everybody seems to assume that the problem is an attack.  I
say that you should never attribute to malice what can be
explained by simple stupidity.  Sqlite.org is a (relatively)
low-bandwidth site on an underpowered server.  If somebody
really wanted to attack it and take it down, they would
not have much trouble.  A botnet could bring sqlite.org to
its knees very, very quickly.  I think the problem here is
bugs in archiac versions of Mozilla and/or windows that get
stuck in a loop issuing the same HTTP request over and
over again.  The user is probably unaware of the problem if
they aren't looking at the modem light flashing.

I'm guessing that the browser doesn't like something in the
reply header coming back from sqlite.org (perhaps it is looking
for a chineses character set or something) and so it reissues
the requesting hoping for a better result the next time.
Something stupid like that.  Maybe somebody can have a look
at the HTTP reply headers that www.sqlite.org issues and point
out any problems.  (Www.sqlite.org is driven by custom software
used nowhere else on the planet, as far as I am aware, so there
could be some subtle compatibility bugs.)

So my question is really more like this:  Who will get upset
if www.sqlite.org ceases to function for win98 users?

--
D. Richard Hipp  <[EMAIL PROTECTED]>



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Rich Shepard]

On Tue, 30 Jan 2007, Mark Richards wrote:


Returning a link that expires in an email to the requester is a method
that works nicely. It does require some programming and maintenance, but
would be a nice gatekeeper.


  Rather than this, I support the idea of an image with letters and digits
in various fonts or colors (so they cannot be readily harvested by OCR
methods) that are to be manually copied to a text entry field.

  I've no idea of the relative amounts of effort required by these different
approaches, but I suspect that such images are readily available on the Web
and a sufficiently large collection could be used with each presentation
being arbitrary. Perhaps once this is done -- and hidden from page source
view -- it would not need much maintenance.

  The inconvenience to us who access the site is the price we need to pay
given the abuse of the 'Net and the Web.

Rich

--
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
 Voice: 503-667-4517  Fax: 503-667-8863

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Mark Richards]

[EMAIL PROTECTED] wrote:


Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?


Headers can always be forged as to browser and OS.  Attackers will 
eventually figure it out and then you're back to the drawing board 
again.  As tempting as this solution is, it probably won't help in the 
longer term.


Cutting off access to a specific IP requires manual maintenance.  There 
are automated solutions as were pointed out, but these can become 
cumbersome to maintain and I have read somewhere (sorry, can't give you 
a reference to it) that piles of iptables rules can cause a slow-down in 
iptables processing.


Returning a link that expires in an email to the requester is a method 
that works nicely.  It does require some programming and maintenance, 
but would be a nice gatekeeper.


I doubt that there would be any privacy concerns.  The email address 
would be used to simply route the url and then be discarded.



/m


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[David Pitcher]

You could adapt this ruleset used to block ssh bruteforce attacks:

( quoting from http://www.la-samhna.de/library/brutessh.html )
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set \
--name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 
60 --hitcount 4 --rttl \

--name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
--hitcount 4 --rttl --name SSH -j DROP
For whitelisting, a possible variation (also described by Andrew Pollock) 
would be:


(1) Create a custom chain for whitelisting first:

iptables -N SSH_WHITELIST
(2) Whitelist any host(s) that you like:

iptables -A SSH_WHITELIST -s TRUSTED_HOST_IP -m recent --remove --name 
SSH -j ACCEPT

(3) Add the blocking rules:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set \
--name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
\
--seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix 
SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
\

--seconds 60 --hitcount 4 --rttl --name SSH -j DROP
David. 



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[C.Peachment]

On Tue, 30 Jan 2007 12:58:01 +, [EMAIL PROTECTED] wrote:

>Last night, a single user (or, at least, a single IP address)
>in China that self-identified as running windows98 and
>Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
>24980 times and  sqlite-source-3_3_12.zip 25044 times
>over about a 5 hour period, sucking up significant
>bandwidth in the process.

>I've seen this type of thing before and have on occasion
>banned specific IP addresses from the website using

>   iptables -A INPUT -s  -j DROP

>But lately, there have been so many problems coming from
>win98 and moz4 that I'm thinking of banning all traffic
>that self-identifies as such in the User-Agent string of
>the HTTP header.

>Thoughts anyone?  Are there less drastic measures that might
>be taken to prevent this kind of abuse?


No human could click fast enough and long enough to request

(24980 + 25044) / (5 * 60) = 166.75 downloads per minute

so it is probably safe to assume that a virus or spambot is
making the requests. As such, the putative agent identifiers
are likely faked and could be changed easily to report
something more modern. This would circumvent your trap
based on User-Agent.

I think you need to place a general limit on requests from ANY
ip address using some form of throttling in the web server.





-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Markus Hoenicka]

[EMAIL PROTECTED] was heard to say:

> Thoughts anyone?  Are there less drastic measures that might
> be taken to prevent this kind of abuse?

Frankly, I can't imagine someone sitting in China in front of a Win98 box and
hitting the download button 25044 times. I guess this is scripted, and they
will change the identifier as soon as they notice they're being blocked. I'm
afraid this is not going to work.

What about the spamblockers used by blogs and guestbooks, where you have to read
letters or numbers from a jpeg image before proceeding. I know this is going to
create an accessibility issue, but it seems to work fairly well.

just my 2c,

Markus

-- 
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Terry Jones]

| Last night, a single user (or, at least, a single IP address)
| in China that self-identified as running windows98 and
| Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
| 24980 times and  sqlite-source-3_3_12.zip 25044 times
| over about a 5 hour period, sucking up significant
| bandwidth in the process.
| 
| I've seen this type of thing before and have on occasion
| banned specific IP addresses from the website using
| 
|iptables -A INPUT -s  -j DROP
| 
| But lately, there have been so many problems coming from
| win98 and moz4 that I'm thinking of banning all traffic
| that self-identifies as such in the User-Agent string of
| the HTTP header.

Given 50K attempts in 5 hours, this is either a bug somewhere or it's
automated, likely the latter. In that case, dropping packets based on the
User-Agent isn't going to fix the problem - especially if it's mentioned
here...

It's more work, but something that monitors your log file and selectively
bans IP addresses and/or throttles download speed (keeping the connection
open), might serve you better.

Terry

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Clay Dowling]

[EMAIL PROTECTED] wrote:

> But lately, there have been so many problems coming from
> win98 and moz4 that I'm thinking of banning all traffic
> that self-identifies as such in the User-Agent string of
> the HTTP header.
>
> Thoughts anyone?  Are there less drastic measures that might
> be taken to prevent this kind of abuse?

It seems unlikely that any legitimate client would be visiting with such
characteristics.  With SQLite being primarily of interest to developers,
and win98 being not the most pleasant platform to develop on, I would
think that the number of legitimate requests from these machines would be
vanishingly small.

Clay Dowling
-- 
Simple Content Management
http://www.ceamus.com


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Abuse of the SQLite website

[Marco Bambini]

Maybe you can limit the times per hour that a single IP address can  
download something from your web site.

For example max 50 download per file per hour for a single IP address.
This prevents current and future abuses...

---
Marco Bambini
http://www.sqlabs.net
http://www.sqlabs.net/blog/
http://www.sqlabs.net/realsqlserver/



On Jan 30, 2007, at 1:58 PM, [EMAIL PROTECTED] wrote:


Last night, a single user (or, at least, a single IP address)
in China that self-identified as running windows98 and
Mozilla 4.0 attempted to download sqlite-3.3.12.tar.gz
24980 times and  sqlite-source-3_3_12.zip 25044 times
over about a 5 hour period, sucking up significant
bandwidth in the process.

I've seen this type of thing before and have on occasion
banned specific IP addresses from the website using

   iptables -A INPUT -s  -j DROP

But lately, there have been so many problems coming from
win98 and moz4 that I'm thinking of banning all traffic
that self-identifies as such in the User-Agent string of
the HTTP header.

Thoughts anyone?  Are there less drastic measures that might
be taken to prevent this kind of abuse?

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-- 
---

To unsubscribe, send email to [EMAIL PROTECTED]
-- 
---





-
To unsubscribe, send email to [EMAIL PROTECTED]
-