http://www.nukescripts.net/modules.php? ... t&lid=1043

That is a link for the Nuke Sentinel. My question here is why don't we have any security for Joomla like that? I am willing to drop some of my own money to help get this project started. Why? Because this is something way more important to the Life of 3PD (third party development) in Joomla. Sites are getting hacked more and more everyday do the bad scripting or holes in bad web hosting (and many more things that I missed here). We spend more time trying to secure products than trying to move forward with them like we want to. I know from personal experience

Is anyone out there willing to help take this on? I have a support forum ready for you and can assist with the graphics and support forums.

Thanks,

I've only had a quick look at sentinel but it would appear to me that all it is offering is a way to manage access to your website based on ip addresses. there are some good things that Joomla! should look at perhaps such as the ability to restrict admin access to a specific ip address (although this can be achieved at a server evel). I cantg see how something like sentinel would have prevented some sloppy 3pd programming or 3pd not following exisiting guidelines and recommendations of things to have to their code to prevent hacks.

of course i may have misread the functions of sentinel

My Joomla was hit today too

Hacked BY Dengesiz Team - TiT
Warning: main(/includes/version.php): failed to open stream: No such file or directory in /backup/maguro/public_html/includes/joomla.php on line 71

Fatal error: main(): Failed opening required '/includes/version.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /backup/maguro/public_html/includes/joomla.php on line 71

brian wrote:I've only had a quick look at sentinel but it would appear to me that all it is offering is a way to manage access to your website based on ip addresses. there are some good things that Joomla! should look at perhaps such as the ability to restrict admin access to a specific ip address (although this can be achieved at a server evel). I cantg see how something like sentinel would have prevented some sloppy 3pd programming or 3pd not following exisiting guidelines and recommendations of things to have to their code to prevent hacks.

of course i may have misread the functions of sentinel

Actually it does more than that. If it detects an intrustion it will automatcially blocked you from the site. It has a lot of functions and can really help with code that might be executed on the server side.

brad I was not saying that Joomla was not secure (trust me I love it and I know you guys kick A#@ at it  ), I just wanted to find someone who might want to help get a project like this going.

gocchin: your site was hacked? Trust me I know this oh too well, it seems to happen as Brad said best, 3PD code that was written correctly or they forgot to add the famous "defined('_VALID_MOS') or die('Direct access to this location is not allowed.');" tag to the top of the file in that component, mambot or module. Check your access logs to see what strings were passed and what they hacked. YOu will typlically see a POST (the GETs you can typically ignore) and some being passed. Here is an example from a site I found:

IP_ADDRESS_HERE - - [11/Jul/2006:01:38:16 -0700] "POST /JOOMLA/absolute_path=SOMETHING_PASS_HERE? HTTP/1.0" 200 25010 "http://YOUR_SITE.com/JOOMLA/absolute_path=SOMETHING_PASS_HERE?" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7"

Edited so this will not look exactly like that.

If this does not make sense let me know and I can try to help.

Good Luck,

Josh, I haven't really looked into Nuke Sentinel, so I might be wrong. But from what I guess after reading the page on the link you provided, it does work inside the framework, but not for pages outside of the CMS? This would not have helped in 95% of the lately discovered security holes in 3PD software.

friesengeist wrote:Josh, I haven't really looked into Nuke Sentinel, so I might be wrong. But from what I guess after reading the page on the link you provided, it does work inside the framework, but not for pages outside of the CMS? This would not have helped in 95% of the lately discovered security holes in 3PD software.

That is how the component is described in the summary and I have to agree, it would have done nothing for almost all of the recent security issues.  Only two or three of the components that were recently discovered to have security vulnerabilities would have been protected by a security vulnerability like this.  I think it is extremely important to make this clear... it is not possible for a security component to deal with all or even most security issues.  A security component could do some things... it could check for defined(_VALID_MOS) or die... statements, it might even be able to check for GLOBALS usage, it could check things like that but those are still bandaid things.  The most important thing anyone can do is make good decisions regarding the extensions they choose to use on your site.  Once an insecure or malicious extension is installed you should consider your entire site compromised.  There is NO POSSIBLE WAY to protect or stop a component from accessing database tables it should not be accessing.  There is no possible way to stop a component from sending all of the information it found back to a cracker website.  There is just no possible way to stop this and there is a serious reality and mentality change required if any of you are serious about security.  Once an insecure or malicious component is installed, your entire site is insecure.  Furthermore, a security component would do nothing to protect you from a well written but malicious extension that you installed on your site.

With all of that said, I would like to provide some pretty easy tips for making better choices regarding the extensions you install.  In no particular order (except as I could think of them):

1. When was the last version released?
If it has been over a year, consider the project abandoned and find something else.  Do not install these components.

2. What kind of release is it?  (Stable, Release Candidate (RC), Beta, Alpha)
For production sites you should be sticking to Stable releases as much as possible.  If you cannot wait until a Stable release has been made available, Release Candidates are the only other option you should consider.  I would not suggest anyone install any Beta or Alpha extensions on a production site.  This means they still have bugs, they have not been tested enough, and could have any number of inconvenient bugs or security issues that have not been fixed or worse, found.

3. Does the extension have a history of good security practices? 
This is obviously a bit more subjective but it is still a very valid gauge of future trustworthiness.  It requires a bit of investigation and research.  Look around their download pages and archives, are there many security release or patches?  Are there a lot of reports of cracking activity through this extension?  Are the developers experienced and security conscious?  What do other community members think of this extension?  One example that comes to mind that has little to do with Joomla itself (which makes it a fair example) is phpBB.  This script has had more security issues than I could get my head around and there routinely seems to be newly disclosed issues.  Because of this, I would never use phpBB.  In my opinion its is not trustworthy and there is a high probability that there will be more major security issues. 

4. Is there a support community for this extension? 
This is very important for usability and security awareness.  If there is a support community for an extension there is a better chance of security issues being known and dealt with.  A support community means that people would like to continue using the extension and that they care about the extension.  This furthers the chance that security issues will be found, disclosed, and dealt with promptly.

5. Is there only a Mambo version of this extension?
While this does not in itself make an extension insecure but is rather a gauge of support, how recently the last realease was, and future support.  There is a pretty narrow chance that Mambo components will be supported in 1.5 so save yourself the trouble and find a component made to work with Joomla.  It will make your life easier.

6. Is the extension generally bug free?
I hinted on this a little bit in number three but I think it is worth discussing in more depth.  While it is almost impossible for an extension to be completely bug free, the smaller the number of bugs, the better.  If there are bugs in the software it means there are mistakes in the software.  The more mistakes, the higher risk of usability issues and security issues.  Security issues are often a result of not one bug, but several bugs or bad practices.  For example, the recent 3rd party vulnerabilities that allow for remote file inclusion are a result of:

Bad Practices:
1. Having PHP's Register Globals enabled.
2. Using out of date or abandoned extension.
3. No other security checks enabled for PHP. (url_fopen off, open_basedir restrictions, disabled PHP functions)
4. Poorly configured file permissions.
5. No request filtering or software "firewall". (such as mod_rewrite rules or mod_security Apache modules)

Bugs:
1. Not including defined('_VALID_MOS') or die... statements
2. Poorly constructed include() statements.

Many, MANY of the cracks could have been prevented by taking any one of those issues out of the equation.  Please notice that most of the issues fall into bad practices, which means they were done by the site administrator.  We have no control over how your server is configured.  Do not blame us for having your sever configured poorly.  People need to think about that for a while before they jump down our throat and accuse Joomla! of being insecure.

This is by no means a comprehensive list but it should at least give you some idea how to make better decisions regarding the extensions that you choose to use on your website.

I was jumping at Joomla about this. Trust me! Joomla rocks dude. I was just seeing what can be done to setup something to autoblock attacks like this. i.e. start banning those users based upon certain criteria, like, is there IP a known offender, how many hits they are putting to the site, are they in a certain order, are they spidering the site and ignoring the robots.txt file etc...

Either way I talked to a friend that is actually working on a component to start performing security checks for you automatically. Wether this is intented to be fully released I dont know. If it is I will post a link for the community here and on the forge.

Folks

Hope nobody minds the "non-Joomla core" person entry here, but it seems to me that we are all after the same thing, but there are a number of different apparoaches in play.

From RobS's assessment and my own look at the posted script, it would appear that while it is a useful and innovative idea, it still "closing the barn door after the horse has bolted"

The Security posts in this forum by RobS, Hackwar and rliskey are more than adaquate, very eliguant and extremely useful.

For those that are more experienced with hosting, administration and Joomla! many of these are second nature and well understood. However, for many new-starters or those converting from other similar packages, these posts might actually be unknown at time of installation.

The "Pro-Active" aproach of the Joomla develoment/security teams during the installation process of displaying the recommended settings and known security hole messages is an excellent start, but with the variety of server configurations and end-user requirements out there, the Joomla team alone cannot be made responsible to satisfy all web-facing application security or integrity issues. Users need to be sure that they are aware of what they are getting in to, we do this everyday in our normal lives, we assess the risks and read up on items we purchase or use ourselves, then decide whether or not it suits us and if we are going to use or buy the item. the same rules apply here.


Seeing as the following posts are stickies, might I make a suggestion,

Potentially the installation wizard is a good place to provide an additional page or links to posts be made available from the menu to display very user- /new-starter friendly versions of the three specific posts.  (not necessarily an active page that checks for anything, but an informational page)

Hackwars' Excellent description of the Security Messages
  http://forum.joomla.org/index.php/topic,93640.0.html

RobS's .htaccess post
  http://forum.joomla.org/index.php/topic,75376.0.html

rliskey's Joomla Security Checklist
  http://forum.joomla.org/index.php/topic,81058.0.html

  * Potentially the 3PD bad-list also.


May I also suggest that these additions would again be "Pro-Active" rather than re-active, in assisting with Joomla Security from the outset, making potential users aware from the outset of the Administration and Security responsibilities that they must undertake when using Joomla! (or any web-facing application for that matter)

This would also serve the dual purpose of highlighting that fact that a Security (and other) forums exist to new users that might not be as aware of the big-wide-world as the rest of us are.

I beleive that this would at least, in part, answer the intial post and go along way to helping new-starters appreciate the dev team's commitment to security and good administration practices.

Again, I hope this is taken in the vain it is intended, as I am sure all the post respondents would agree, the Joomla! teams commitment to its community is second to none, but those who are not as experienced in these things always need a little more "Pro-Active" assitance.

Agree better to be pro-active than re-active

I would like to see a prominent "warning message" displayed each time you use an extension installer

hey Brian

to describe our experience, what we have seen from many newbie posts in the forums and from some of our own customers, is that they get a recommendation of Joomla!, go to the site, download it and in many cases get a clean install quite quickly, they start to use it, add 3rdPD add-ons and it is generally not until they talk to us or something happens do they find their way to the forums.

Many hosts are not as "end-user" or "newbie" friendly as we would all like and again, the horse has bolted and the cleanup is messy, the user now has a bad taste in thier mouth of Joomla! (when actually, it is normally their own lack of knowledge or the hosts in-security) that has caused the situation.

I do beleive that the current Joomla! notices and warnings are great, but again we have found that the lack of knowledge of what some of these warnings mean causes issues. Thus the though of actually including some additional "explainantional" information regarding what the settings are, the exposures and maybe even suggestions on how to resolve them would be useful at install time. Not to the degree that it stops the install though, that would just become frustrating for many new users.

Just look through the forums for RG_EMAULATION and register_globals questions, it comes up again, and again, and again and (unfortunately) alot of the time, only after an expoit attempt or actual crack of a site.


Hopefully, this would releive some of the burden on the forum teams, development teams and educate the end users to a higer degree. We have found, in general, that "smarter customers, are happier customers"

Spot on

Spent too muchtime recently working on sites for people that are using extensions that are 99 versions out of date

Did anything ever come of this discussion regarding a security feature similar to Sentinel?  I've been using Nuke for several years, and along with that Sentinel.  I'm actually moving sites over to Joomla now, heck of a lot easier to do just about anything, but I have to say that having experienced as many as 100 security hack attempts a day over several years it worries me a bit to not have the same capabilities that Sentinel has (auto-sensing of hacking attempts, and autoblocking).  Does anyone know of anything in the works related to this, or of alternatives that accomplish the same thing?

I just saw this topic and thought lets give my thoughts on this.I do know sentinel very well for years also and followed its development.I do feel that sentinel is designed for nuke and can never work with any other cms.Personally i believe joomla is secure enough.Its poorly written 3D stuff that makes a cms vulnerable.And another point i want to mention is,is that sentinel cannot be fully trusted as it can ban everybody randomly if it believes or thinks a visitor/member did something wrong (for example it doesnt like a.o.l users that much).Another negative part of it is that while the security is strict so is the freedom to be creative.With joomla you can create what you want and use any content what you want.With sentinel that freedom is taken away from you.A hard fact is also that the majority of sentinel users stopped upgrading after a certain point.Thats understandable as it looks like it in a constant beta version.

A nice admin component would be something that writes any ip , range or block that we wanna ban.

For those picking this old thread up again, here are some of the current locations for tools and information regarding Security and Risk Mitigation.  There are now several "Pre~" and "Post~" security and integrity tools available for Joomla! as observed below;


  Security & Performance FAQ

The above mentioned FAQ will provide with more than enough information to assist you in further securing your sites.

Particular entries of note and to pay attention to, are;

  Joomla! Administrator's Security Checklist

  Help! My site's been compromised. Now what?

  Vulnerable Extension List


Other useful posts and tools;

  Joomla! Tools Suite
  How can I check my Joomla! installation's overall security and health?

  What does Joomla! have to do with file permissions?

  How do I find exploits using the *NIX shell?

  Potential Exploit Checking Script

  Auto-Change, Admin Password Script