To report a botnet PRIVATELY please email: [EMAIL PROTECTED]
----------
My suggestion doesn't break those PERL tools as long as you change the
UA with a
single simple line of PERL such as:
$ua->agent("MyWebTools");
Then you can use everything you have.
My whole point was that the script kiddies appear to lazy to do this and it's
something people can take advantage of at the moment.
As far as web hosting companies blocking things, many have been filtering
certain things for years, nothing new. The work around for real software which
is one line of code (above) which should already be there in the first place.
Sloppy and lazy programming is never an excuse for allowing a default
user agent
from a toolkit access to your server. If the programmer isn't bright enough to
change it then whatever he/she wrote probably shouldn't be hitting the web in
the first place, not my server anyway.
FWIW, I'm jaded and bitter too which is why I use a sledgehammer approach to
fixing internet problems these days.
--
Bill Atchison
http://www.crawlwall.com
Quoting jonathan <[EMAIL PROTECTED]>:
> On 5/9/07, William Atchison <[EMAIL PROTECTED]> wrote:
>
>> [clip]
>>
>> Knowing this you can protect most websites from the most common automated
>> website vulnerability attackers by simply blocking all "libwww-perl"
>> access and
>> any QUERY_STRING that contains "=http:" in the parameter list.
>>
>> Most software that does permit the upload files uses a POST so filtering out
>> "=http:" in the QUERY_STRING should have almost no effect on any
>> sites, except
>> possibly stopping them from being hacked.
>
> For what its worth, lots of very useful web site management and
> auditing tools are written in perl, and most sites I build end up
> using some sort of query string backtracking (login handlers are one
> of the most common) and often want full Uris. As for POST versus
> remote referral for file upload, they solve two totally different use
> cases.
>
>> FWIW, if I were running a shared hosting company I would block these
>> 2 things by
>> default server wide just to help keep it clean.
>
> If I found out that a hosting provider was doing this sort of
> screening and not documenting it somewhere as blatant as their home
> page, in 18 point red type, I'd sit on their 800 line until they paid
> me for however many hours of time I'd spent discovering their
> "security".
>
> I know that I'm jaded and bitter -- maybe the world would be better if
> all hosting providers prevented you from posting CGI until you explain
> the meaning of the term input validation to them -- but no bulk
> hosting provider support person I've ever met could provide an
> accurate answer to the question "what filtering and/or lockdowns are
> applied to your hosted web sites". Kudos to you if you were running a
> hosting company and your front-line support had a cheat sheet with a
> complete, accurate spec. Of course, acquiring a complete, accurate
> spec would be the first step to getting around your security measures.
> ;)
>
> No offense intended, hopefully none taken,
>
> ~monk
>
_______________________________________________
To report a botnet PRIVATELY please email: [EMAIL PROTECTED]
All list and server information are public and available to law enforcement
upon request.
http://www.whitestar.linuxbox.org/mailman/listinfo/botnets
