Moodle Security

Moodle Security

by Marc Grober -
Number of replies: 74
While I am not perhaps as strident as "He-Who-Must-Not-Be-Named" (I have even recommended a Moodle Partner to a client from time to time) I was struck with this posting (should there be a warning about graphic images?):
http://www.moodleus.org/blog/?p=442

I want to assume that this mess resulted from the client's decision to undo the security with which the site was provided, and I will assume that this was the result not of a coding flaw but of negligence in managing enrollment, but the Partner makes some rather dramatic claims about security, as well as the support the Partner provides, and if a Moodle Partner, with the expertise required to obtain that designation, has clients in such circumstances, one has to inquire about the details.

So, while it is arguably none of our business as far as the antecedents to the defacing of the site above, the community perhaps has a duty to ask:

  • Do partners provide moodle sites to clients in secure locked down states?
  • Are clients fully advised of the potential security breaches inherent in any changes to the Moodle?
  • Do Partners provide consultation regarding security or security assessments of clients sites?
  • In this case was the site delivered in such a condition that the defacing was possible, and if so, was the client advised what had to be done to secure it?
  • If the site was delivered in a condition that would not secure it from such attacks, were clients specifically advised that the site was insecure, considering the representations the Partner makes on their website about Moodle security?
  • While the incident cited arguably did not threaten the security of the sites data, are there other vulnerabilities that such sites may be subject to that clients have not been fully advised of?
This is not an attack on the Partner in question as I have no data which would support any claims at this point. In other words, representations that "your site is secure" could be identified as mere puffing, the client could have unilaterally acted to sustain the damage, or the damage could be regarded as injuries outside the realm of site security.....

If I refer someone who is largely clueless to a Moodle Partner because the person is clueless, and the referral then finds his Moodle site in the condition seen in the site identified, what does thast say about my credibility, Moodle's viability or Moodle.com's efficacy?


from
http://www.moodlerooms.com/moodleuses/governmentandnonprofit/
Information Security

Moodlerooms has taken great lengths to ensure that all data
hosted on our servers is completely secure. In addition,
Moodle was created with information security as a top
priority. By default, access to information is controlled
through logins and enrollment keys giving administrators the
access control they need. SSL certificates are available for
organizations looking for a higher level of security.
Average of ratings: Useful (1)
In reply to Marc Grober

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I can only answer for myself ...

The answer is, as ever, it depends. This post was about email based self registration. Surprisingly, this used to be a perfectly reasonable way to run a site. It certainly is not now as the low life's are on to it.

Unlike "He who must not be named", I don't really think that this is a per se security matter. It's more of a bad decision. If you want to have this option then you should expect to have to do some cleaning up. The knock on from this is the inability to (AFAIK) completely remove user's profiles and pictures (MDL-17065 et. al.) if you do find "bad" accounts. That needs fixed I guess.

Other than that we provide hosting and technical support and do our very best to provide a secure environment as far as it is under our control. We cannot control what the user chooses to do with their Moodle site but if something bad happens we are there to help fix it. That's what they pay for. New sites are set up, again as far as possible, in what we feel is the most sensible and secure manner. We provide upgrades when security releases are made (clients can opt out if they wish though).

We also provide administrator training and running a secure site is part of that. That is additional to basic hosting of course.

The quote you make above is true. They keep your data safe - there is no implication they have done anything other than that. Unfortunately, a user who has legitimately entered the Moodle site has misused the site. This really depends on your point of view but how much can you lock down Moodle before it restricts its use? Bottom line for me - if you let people interact on your Moodle site (and you should), how upset should you get if one posts something inappropriate?

I don't know if this answers your question.
Average of ratings: Useful (5)
In reply to Howard Miller

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Just an additional note. I noticed the gentleman we may not mention big grin stated that Email based self registration is on by default. This is, happily, no longer the case. (as of 1.9.3 I think).

Captcha being added (1.9.2?) gives some additional security. To my mind it makes Moodle no less secure (in this respect) than any other web based application that allows self-registration (e.g., all those online forums).

Also, and I think I've said this before, security is not an absolute it's a balance. If you want a completely 100% secure site then switch off your servers and lock them up. That might limit functionality a little however!
Average of ratings: Useful (1)
In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
Howard,

I agree with a good deal of what you have said (and my initial posting assumes your argument), however......

The question remains, especially in as much as the issue has been known for longer than the site has been hacked, what the Moodle Partner in question did vis-a-vis this particular site. If, as HWSNBN notes, self-enrollment was on by default when the site was created and turned over to the client, did the Partner warn the client about the possibility of such abuses?

You take the technical view that I listed as one way to look at this, i. e. the site's structure is not "data". However, if I am a XNC consultant prior to the election and have advised the client that their site is safe and secure, but it is then subjected to such abuse, I can guarantee you that I would only work again for a group that socializes losses, but not gains ;=}

My guess is that most folk getting their feet wet with Moodle have no clue about that kind of distinction. If they choose to pay someone so that they don't have to worry, it makes little sense for the vendor to then argue that their client was not sophisticated enough to enter into the contract ..... arguably that renders the contract illusory.

And yes, I have lectured at length to my students that security IS relative and purely a matter of weighing the cost to the hacker versus the cost to the enterprise..... But, when the cost to both is nominal you are simply a dead man walking.

What is most intriguing so far is the minimal response to my posting (a point of dispute between me and He and is not meant to diminish the fact that you stepped forward to at least argue the ostensible MP position) which I think argues His point that a security forum should be created.....

By way of illustration, lots of web apps have their mysql host exposed, but that does not make such practice acceptable any more than calling someone a urban terrorist on national news makes that true. If I write a bot to search for, crack and then corrupt mysql hosts, that makes me a criminal, but also puts my picture with egg on my face all over the next morning's tech news..... How about a poll, Howard, on Moodle.org asking folks if they have secured their mysql host, or even understand what that might entail? Iñaki might argue that password cracking is endemic to life on the web (which is of course true), but that wouldn't excuse someone from setting their mysql host accessible from any ip address with a username of admin and a password of admin..... virtually no cost to the enterprise while presenting a bit of a loss ot the hacker. Assuming that you won't be hacked because there is no "value" in someone hacking you is flawed as it understates the intangibles for the hacker..... and it also understates the cost to you if your data includes FERPA protected data, which in the U.S makes you subject to OCR litigation, and as corrupt as the US Justice Dept, may be, you certainly don't want to be behind that ball.....


In reply to Marc Grober

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
To briefly answer your first point, we do not check our sites for possible issues like this once we have set it up. I honestly don't see it as part of the service. If the users decide to set up self-enrolment and get some unpleasantness in a profile as a result then we wouldn't know. Of course, if it was brought to our attention we would tell them and if we asked for help we would.

If there was some way that you could regularly scan sites for pornographic content, then we'd look at it, but I don't think such a thing exists.

My going to a Moodle Partner you are (hopefully) assured of a proper initial setup and help there if and when you need it, but I don't see how we can police peoples content on an ongoing basis. I don't think we should. Moodle is a complex product, if you (as a user) pay for a basic hosting contract with *techincal* support then you get high quality technical support. If you want us to completely build the site and worry about all these content issues in detail then we can... but it will be a *lot* more expensive.

I would *never* promise a client that nothing bad could ever happen - just that we would do all we can within the bounds of the contract they have paid for to do so. MPs are business after all, not magicians or mind readers.

The gentleman of whom we may not speak is, effectively, making a political point. Just because HE says it's a security matter doesn't make it one. There's shades of grey here.

I'll leave your final point to somebody in a position to decide and/or organise such a poll. I have no problem with discussing or highlighting security issues but it's not my decision.
In reply to Howard Miller

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I shouldn't do this...

http://www.moodleus.org/blog/?p=463

...however, this time, I think he makes more of a fool of himself than he does of me.

To use a Steve-ism... you decide wink

Last word.
In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
Can't resist having the last word, Howard evil but won't hold you to it big grin.... LOL

Your comment (excerpted here) poses some dilemmas for me.

To briefly answer your first point, we do not check our sites for possible issues like this once we have set it up. I honestly don't see it as part of the service. If the users decide to set up self-enrolment and get some unpleasantness in a profile as a result then we wouldn't know. Of course, if it was brought to our attention we would tell them and if we asked for help we would.

I don't know that I don't see your conclusion (which in this case is your first statement). Its the premise (regarding the state of the siter as delivered) that troubles me. The initial point I see YKW making is that an MP client may have an expectation that the services purchased include more than just web hosting from folks who know how to fix your site once it has been hacked (perhaps hyperbolic, but posited for argument's sake). I think I could make a fairly good argument to that effect based on some Moodle Partner promotional materials (obviously those materials are somewhat different from Partner to Partner.)

The problem with such contractual relationships is that the clients invariably believe they are getting more than the contractors are giving, and in legal terminology that raises the specter that the agreement is illusory (no meeting of the minds, as it were).

Your premise fails to resolve for me a pre-requisite to the analysis; how are such sites delivered. If the site were delivered with self enrollment turned on, I would compare this (again, perhaps hyperbolic but demonstrative) to handing a kid a loaded pistol, subsequently discharged with unfortunate results, and then claiming one didn't pull the trigger.... Some might even argue that such action with respect to a new site should be viewed as 21st Century attractive nuisance, especially where the failure to close this option or advise against opening it might be regarded as inviting public nuisance (i.e. creating or knowingly allowing a situation which will likely result in a crime.)

On the other hand, having litigated legal ethics (yes, there is such a beastie) I could also see a claim of professional malpractice, the argument being that the professional (MP) had a duty to act, not in remediation, but ab initio, knowing of the risk and arguably (as you note) intending to benefit financially in the subsequent remediation.

I am not trying to egg anyone on to litigation. But the analysis I think is valuable. While I sometimes get a kick out of your relationship with YKW, the focus for me in this instance is not who is the bigger horse's ass (I wouldn't even know how to compute horse ass volume unless we did had access to Archimedes bath...) but the extent to which any element of the Moodle community has a pro active duty with respect to the overall health of Moodle, including the infections that YKW has documented. And that is most critically true I think of MPs, who are afterall "certified" to be knowledgeable and therefore, arguably fully informed of the various risks to their clients.


In reply to Marc Grober

Re: Moodle Security

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Marc, I understood very little of your post, perhaps it requires more understanding of the background context (the big post not the follow up to mine)

One point from the initial post interested me...

"Are clients fully advised of the potential security breaches inherent in any changes to the Moodle?"

It would probably make sense for anyone offering such hosting to give some indication of the implications of changes to enrollment systems.

So far in all of this discussion I have not recognized anything that I would view as a security flaw in the Moodle code.


In reply to Marcus Green

Re: Moodle Security

by Marc Grober -
Marc, I understood very little of your post, perhaps it requires more understanding of the background context (the big post not the follow up to mine)

I just know you are a Sauron kind of guy wink, Marcus.

But you are absolutely right that this discussion is not focused so much on code flaws but on expectations regarding usage and the security implications of such usage..... though the I have had many a chat regarding what code allows a user to do versus what the coder intended to accomplish, etc with students - LOL.

By way of example, this post is in a discussion from January of this year, long before the profile spam I referenced.
http://moodle.org/mod/forum/discuss.php?d=89061&parent=393719
Are these suggestions documented somewhere in Moodle Docs as far as risks to be anticipated, measures to undertake to address potential risks? How did the MP involved turn the site over to the client and with what information or instruction?

Bottom line here is that there has been continued discussion that setting up a Moodle is a no-brainer. This in part is based on what I would call a similar analysis, i. e. externalizing elements. In other words, since you technically do not need to know php to install Moodle no programming skills are required. Likewise, you need to have no informatin about net security to get Moodle up and running, but that externalizes major issues that anyone using Moodle really needs to address.
In reply to Marc Grober

Re: Moodle Security

by A. T. Wyatt -
There is a section of the moodle docs with quite a bit of information on security (server side and moodle side).

http://docs.moodle.org/en/Security

Also in the FERPA pages.
http://docs.moodle.org/en/FERPA

Of course, I expect you could always add some new content. With respect to the security page, new content should be discussed on the "talk pages" and then someone else will enter the information when it has been vetted.

atw


Average of ratings: Useful (1)
In reply to Howard Miller

Re: Moodle Security

by Julian Ridden -
Ohh no...I see us sliding again. I must admit I find "he-who-must-not-be-named" a complete enigma. If anything it has become a "boy who cries wolf" sydnrome to me. While I find most of his stuff utter non-sense, the issue is he sometimes raises good points to. The problem now is that I shut him down purely down to his nonsense nuisance posts and have issues seeing th trully valuable content.

Ohh well, I try to avoid the site now, but like a car crash, I cannot avoid heading back tongueout

But, back to the post at hand (I hate when I get distracted), I agree with most of what has been said..Moodle is really about options..and these days a lot of them. Yes, email based registration can be abused and should only be enabled if you know what you are doing. And that is the crux of it. Moodle administration, like any website administration, cannot be leaped into blindly.

It is disabled by default and that is great. Users are hopefully now only turning it on as long as they are aware of the risks. Remember it can be used in conjunction with domain black/white listing for addresses and with Captcha for some security controls.

Maybe one more feature to add (as an option) might be the ability to only allow the subscription process to be initiated from certain IP ranges. That would allow admins the option of telling users they can only create their account at the college, but then could use it anywhere. Is it worth adding to the tracker?
Average of ratings: Useful (1)
In reply to Julian Ridden

Re: Moodle Security

by A. T. Wyatt -
Humble contribution (sorry if you think off topic--skip directly to the end for email based user creation comments):

I recollect (but have no idea how to find said conversations) that there are a number of places in moodle where the option to use "presets" would be helpful. Presents for forum settings (including roles), presets for common gradebook setups, etc.

Maybe we need a preset in the installation process to be "most paranoid" security, "medium" security, or "I will set it all myself" security levels?? Most of the security measures we take at our institution affect many areas of the site; they are not limited to user account creation. This makes creating any kind of a preset problematic, so naturally there would have to be a disclaimer that indicated that there might be other adjustments that an admin might care to make.

Naturally, no "preset" solution would make everyone happy, because I am sure there are as many ways to set up moodle as there are moodle instances. But maybe you could target a couple of common levels of user needs (while making sure there was one that really let the admin just set it up without "interference") and make those available?

I agree with you and Marc (and many others over the years). While you *can* run "a moodle" with little to moderate effort, there are a huge number of issues that revolve around the deployment of any sophisticated software system (and an LMS is very sophisticated). It requires careful thought and study, and desires for new features often outstrip abilities to install and use the same. We were happy with a plain vanilla moodle for about 60 seconds before I was installing new blocks, hacks, and altering themes. . .

And if you run your own server(s), your responsibility level multiples. That isn't moodle per se, but it would certainly be required for a good experience. I am fortunate to be at an institution where we have IT resources and work together to create a useful learning space to serve the academic community. We knew what we were getting into, and we were willing to put in the effort and resources to make it work. I don't want to discourage people from giving it a try, but they need to have their eyes wide open.

With respect to email registration, I am intrigued by the idea of creating the account on campus but then being able to use it anywhere. But aren't there a lot of moodle instances where this wouldn't be useful at all? I should think that most established academic institutions (brick and mortar or otherwise) will use other methods of account creation.

atw

Average of ratings: Useful (1)
In reply to A. T. Wyatt

Re: Moodle Security

by Marc Grober -
off-topic at moodle.org is a bit of an oxymoron - LOL
Your points are well taken (not to mention devoid of sarcasm big grin )

First, the distraction ;=} I think it would be easy enough to cobble the e-mail bit to only accept registrations from specific domain(s); just a regex and someplace to put the domains (which makes it MUCH more complex if that will, as we would hope, be in the db though you could just jam them in a flat file or in the php...) I may have gotten lost in the php but it looks like there is a can_signup function in auth/e-mail/auth.php that could be used to that end as it is called when the user tries to signup and I wonder if it would be simple enough to instead of just returning true, return true if the parsed e-mail address from mform is matched to approved domains?? I suppose you could extend that concept to say allow e-mail registration if the user is in this ip range, or has an e-mail in this domain, or the ip address and hostname agree and is not on a blacklist, or whatever..... Maybe one of the developers has a simpler way to do this but I don't think it should be major surgery.... A teacher I help out would have benefitted by an external app that simply collected the signup data for his students so he could populate a bulk upload as he didn't want to hassle with trying to manually get all the kids e-mail addresses etc. One could also render e-mail registration available only through moderation....

Of course, it would be easier to do this kind of thing by authenticating to an external source, but for those without the benefit of a useful IT department, this would be a possible quick fix....

But back to the "topic" - call them pre-sets, templates or themes, a handy dandy set of configurations identified by "experts" as a starting point is the way to go..... I remember the first time I had to set up CiviCRM without presets.... that was a killer.... but the very flexibility of Moodle makes it difficult to support.........
In reply to A. T. Wyatt

Re: Moodle Security

by Marc Grober -
A T,
Your contribution here has been deliberate than most (he says, perhaps a bit guiltily), what would you suggest as far as Ron's comments?
In reply to Marc Grober

Re: Moodle Security

by A. T. Wyatt -
I think there is a great deal of wisdom in Ron's post, and perhaps it should be added to the docs. There are certainly people who need to negotiate with "full-service" hosts, and those hosts are not necessarily Moodle Partners. As people have pointed out in this discussion, there are many grey areas and it might be useful to have a document that outlines some things that might otherwise be overlooked for various reasons--including lack of knowledge.

If I were a school district or a non-profit organization trying to choose a hosting company, I would like my RFQ to be well thought out and cover all the bases. It helps to have some boiler plate with which to start!

I might just head on over to the docs and see where such a document might be appropriately placed. Certainly once we get started on the text, others are free to assist in the expansion of the information and the fine tuning of the language.

Any objections? Have I overlooked something?

atw



In reply to A. T. Wyatt

Re: Moodle Security

by Marc Grober -
AT,
I think that is a good idea as long as it is, well, non-partisan (Howard?)
The point about district RFQs, RFPs, RFTs is excellent (especially reference by recent discussion of a non-MP soaking a district - well, I suppose soaking is a bit pointed, but I wanted to make sure that the MPs see that I am not tageting them (your gracious acknowledgement is humbly appreciated....)
I think a discussion of such issues should include a discussion of opposites and correlatives (rights vs duties, etc), i.e. if A has a duty to do such and such then B has a right to expect yadayada and vice versa.....
It would also be helpful to have MPs offer some boilerplate for dissection/consideration

And I will promise, if you are going to undertake this, that I will act with restraint in discussing your suggestions on the Talk pages as I am sure everyone else will.....

In reply to Marc Grober

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think that is a good idea as long as it is, well, non-partisan (Howard?)

I'm not entirely sure what you mean. However, I don't see how anybody can object to a list of points to consider (or indeed questions to ask) when choosing a "partner" (small 'p') company.

I would, personally, prefer to see "you should consider" rather than "you should expect" as there just isn't one size fits all out there.
In reply to Howard Miller

Re: Moodle Security

by Mauno Korpelainen -

Dear Partners and Moodlers,

if we are talking about commercial quality service I think Marc is just trying to point out that old saying: "The customer is king in our business":
things are as our customers see, feel and experience them, and as a service provider, we must be able to operate in such a way that our customers can rely on us totally. Something like in

http://thebusinessexpert.blogspot.com/2007/12/is-customer-king.html

On the other hand many default security settings were changed just some months ago and a huge number of old moodle sites still allow abuse of user profiles because "Force users to login for profiles" is off and once (mostly russian) spammers have created even one account they can use programs like XRumer to create links to open forums and blogs with link lists including moodle user profiles.

Here's an example from pandalabs how it goes

http://pandalabs.pandasecurity.com/archive/XRumer.aspx

http://blogs.pandasoftware.com/blogs/images/PandaLabs/2007/07/24/xrumer.swf

Bryan, Steve can definitely provoke (Partners) but he has hardly not made it his mission in life to denigrate all things about the free open source Moodle LMS. Like Marc said, "Let's focus on the message, not the messenger"...

In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
By non=partisan I mean without regard to one's affiliations.

I think a punch list would be nice. By task with multiple columns so that a user could identify various parties (as in themselves, the web host, their Moodle Partner, etc) so that a user could identify whose responsibility an item was, and whether that item has been addressed. Then discussion in prose can be footnoted in the docs to specific punch list items......

And I think it would be helpful to show how contracts or SLAs translate to such a punch list and vice versa as nitty gritty often gets lost in prose.

A section on puffing... A local vendor here in Alaska claims that they guranatee such and such cable bandwidth. When asked how they can guarantee bandwidth on cable and what the client is entitled to upon breach of the guarantee, the client is informed that the guarantee is that the vendor will take steps .... in others, there is no remedy, and therefore arguably no right.....

Frankly, I think it behooves AT to do this as a private business and offer such services for a nominal fee; like a harmony.com for moodlers.... $10 via paypal and you have our guide for putting your Moodle on the web......
Average of ratings: Useful (1)
In reply to Howard Miller

Re: Moodle Security

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
If you run a web site that allows people to change the content common sense says you need to keep an eye on that content.

To give some of my own experience, for some reason the posters of links to porn (most memorably horse porn) seem to have got bored with putting the links on my site or realised it was pointless.

It had got quite pointless because
a) You needed to be logged in to see the porn so it was not being picked up by search engines.

b) I changed the size of the description field to 1 character so they still put up the links but it got silently truncated anyway.

There are a couple of things that could be done at the code level to minimize the profile spam issue

a) A toggle to clean out any img links tags (or other tags you don't want) in the profile field.

b) A simple toggle to simple turn off that field (that second item might exist but I couldn't find it).

And finally
Voldemort aieeeeeee


Average of ratings: Useful (1)
In reply to Marcus Green

Re: Moodle Security

by Marc Grober -
Thank you, Marcus, for the substantive contribution.
I particularly got a kick out of your change to the description field; that is worth a column on child development in my local newspaper...

And I guess it is perhaps a token of change that for my peers it was always Sauron, but even with the movies release the Red Eye has been trumped by Ms. Rowley. It was tough when Fred and Barnie passed, but I can still put my feet through the floor boards of my old Ford and dream of olden days.....

In reply to Marc Grober

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Eh?

(Is Sauron something you spread on toast?)

big grin
In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
Eh? (Is Sauron something you spread on toast?)
Well done, Howard, especially the grin wink
But I will take the Tolkeins' prose (son and all) over Rowley's loquacious and hackneyed fretting over the Valley of Death any day...... tongueout
I always like to see a reader rise to the book, as opposed to the author writing down to the audience..... and now to segue -> much Moodlers should be expected in some sense to step up; a point I think you are making for MPs and that has been discussed at length here with respect to getting newbees to pursue their inquiry themselves BEFORE putting their question..... smile
In reply to Marc Grober

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You expect much too much of me. This is the only fictional reading I do...

http://www.viz.co.uk/
In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
Well Howard,

I have Crumb's sketchbooks and wear a belt buckle showing Mr. Natural on snow shows "Just Mushing Through Alaska" but still have time to read The Ten Cent Plague and The Amazing Adventures of Kavalier and Klay, not to mention smoke and consume a fresh PACIFIC salmon from time to time .... LOL

Don't know if this tops walnuts in a condom (which leads me to ask Marcus what the same author would say now... when you start life as a singing raisin thats one thing, but does anyone else think Arnold should quit wearing Speedos?), but it is certainly lounge fare

Maybe this MP business is inconsistent with a healthy lifestyle - Take a walk on the wild side, Howard.. ("and the colored girls sing, doo da doo da doo ......") big grin
In reply to Howard Miller

Re: Moodle Security

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Rogers profanosaurus is one of the finest contributions to English literature in my lifetime. I have purchased every version so far.
In reply to Marcus Green

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
As some know, I play bass guitar in a pub band. The band is called "The Barking Spiders". I'll leave that one with you.... evil
In reply to Marcus Green

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
If you run a web site that allows people to change the content common sense says you need to keep an eye on that content.

...and there the Devil lies in the detail. *Who* should be responsible for keeping an eye on the content?

To get way back to the original question, we are talking about a business relationship between a hosting provider (a Moodle Partner in this case) and their client. That relationship will generally be governed by contracts, SLAs and "all that other stuff you make me go around with.." (answers on a postcard). We go to enormous trouble to make sure the servers are secure, your data is safe and backed up and the bits that should be locked down are locked down. It also needs to run fast enough and there to be help when you want it. Site content creation/policing etc. is a *much* more grey area and - depending on the contract - will vary between no intervention whatsoever and complete collaboration.

That contractual situation is, typically, a private matter between the MP and their client. If you are going to buy hosting from a MP or anybody else then it is sensible, like with any other purchase, to make sure you understand what you are getting and to decide if you are happy before signing on the dotted. Nobody is trying to deceive or pull the wool but *any* contract has boundaries and limits of scope. Common sense?
In reply to Howard Miller

Re: Moodle Security

by Ron Meske -
Hope no one minds me chiming in here.

To make this easy, I see it as there are basically two types of individuals when it comes to wanting to set up a Moodle site. Ignoring for now, the techies that have experience with application and server security.

There are those individuals that will assume that they can just host Moodle, either on their own or through someone else, and that they do not need to worry about someone posting offensive material or even hacking their site. Typically, when something happens they will point the finger at anyone but themselves. They will blame the Moodle application for allowing this to happen or their hosting company for allowing it to happen.

Then, there are those users that are concerned about security and privacy and want to know how to make Moodle secure. They will either try to research this themselves or rely on a "techie".

So either way, there needs to be some good documentation about Moodle security, privacy, and managing content that may be deemed offensive.
It would be in the best interest for all supporters of Moodle to create this documentation in a fashion that someone with no technical background can understand or at least in a manner that they understand the importance and that they need to get a "techie" to help them.

Though managing (censoring) content is not really a responsibility of Moodle as an applicaiton, it is its responsibility to provide tools that can be used to monitor and completely remove the objectionable material. The filter for censoring text is a step in the right direction. An easy to use administrator tool for deleting images from any location in Moodle, is definately needed.

Now as to the responsibility of a Moodle Hosting Partner that is contracted to host a site, here is a simple list that I see as their responsibility.
  • Ensure the servers and network is secure. This is mandatory, if they can not ensure a secure host system, then they should not be a Hosting Partner.
  • Provide the customer with their SLA and a list of what they do provide as part of the package being purchased. If there is optional support services, then those should be detailed out.
  • Ask the customer how they are going to use their Moodle site, who will be accessing it, and who will be the administrator for maintaining it.
  • Based on those answers the Partner can then properly install Moodle to be as secure as possible. If the customer wants anyone in the world to access it, the Partner should point out the potential risks, like offensive material being posted and how to monitor for it and remove it.
  • Provide training/documentation to the designated Moodle Administrator on how to keep the site secure and monitor content.
  • If there is no designated admin, then the Partner should inform the customer as to the importance of this role and offer to provide the service for them or some other alternative.
  • Constantly monitor for security issue with Moodle and either install them or inform the customer of the security issue and that it needs to be installed.
If the Moodle Hosting Partner provides all the above, then, as I see it, they have fulfilled their basic obligations as a Moodle Hosting Partner. I personally have researched some of the partners and found that they are not currently offering all of the above automatically. I had to request it and then only one so far has provide most of what I requested.

The bar needs to be raised at least for the Moodle Hosting Partners, if not for the Moodle Community at large, to look seriously at the issue of security, privacy and content monitoring. Let me give you an example of what could happen, at least in the US.

A teacher decides to set up a Moodle site to supplement their classroom teaching. A spammer finds the site and is able to post porn on it. A student sees it and informs their parents. The parents file a lawsuit against the school and the teacher gets fired. Now what would have happened if the teacher had used a Hosting Partner? If the partner had not provided the teacher with the necessary information, the teacher could turn around and file a lawsuit against the Hosting Partner and possibly even Moodle. What would the outcome be? It would depend a lot on what was provided to the teacher when setting up Moodle.

So is this Moodle's responsibility that the porn was posted, not really, but it definately is not good publicity. Could it have been prevented? Absolutely, but only if the teacher was aware of the risk and understood how to prevent it. That is why the documentation is so critical and that Hosting Partners take this seriously and be proactive about educating and informing their customers about all the risks.

My 2cents.


Average of ratings: Useful (2)
In reply to Ron Meske

Re: Moodle Security

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I mostly agree. Stuff like training is optional of course but access to the abundant documentation is free. It's all about communication with clients.

In reply to Ron Meske

Re: Moodle Security

by Marc Grober -
Good points Ron....
I would add that there are also those who are clueless to your types of Moodlers.

So the list would be something like this:
  • knowledgeable
  • concerned
  • blameless
  • clueless

And I think that they create more of a matrix than a list; here's a rough out....

Whose duty:
mine
others
To know


To act



I think what I am suggesting, and I think you largely agree, is that a MP client will believe the duties to act and know are duties of the MP (others), while it would seem that the MPs might argue the other way around. Very simplistic, but a decision model could be built along these lines which would evidence the failure to have a meeting of the minds.

In reply to Howard Miller

Re: Moodle Security

by Marc Grober -
Yes, Howard, there have to be boundaries..... but there is no such thing as common sense. Yes, once upon a time eyewitnesses were thought to be reliable and English law sat squarely upon the maxim "the mind of man runneth not to the contrary". However, homo sapiens discovered by the 20th Century that eyewitnesses are often the least reliable and that oral traditions are rarely accurate. indeed, the focal point of the text I use for my Social Psychology class is just that; there is no such thing as common sense. And I will add, not because of your perspective but because its the political season and Halloween, that invitations to rely on common sense are typically made when rational argument seems to be getting the upper hand wink. Hence the arrival of Joe the Plumber (is Joe in the audience somewhere?)

One reason people find lawyers so upsetting (and I grant you, there is quite a list) is that lawyers typically require parties to set out ALL the details of client contracts, which distresses parties because such full disclosure often ends with a failure to agree. From the lawyers perspective he just saved his client bags o bucks in subsequent litigation, but the clients (on both sides) most often see it as a missed opportunity. The Ogre, in effect, is best left under the bed, unmentioned, in the hopeshe will never be seen..... Not best practice.

And, yes, this is a "private matter", and would remain same if we didn't see by defacement of Moodle sites (which embarrasses the entire community) and we didn't have persons certified to provide Moodle solutions hosting those sites. Again, I hope all realize that you are serving in a general MP advocacy position here (we are not talking about a site your firm hosts) but you (and You as in MPs) have to be careful about pronouns (as in we or We, MPs); if there is standard MP contractual boilerplate supporting a "We do" assertion, I think it would be helpful to review it and compare it to the points Ron makes.
In reply to Marc Grober

Re: Moodle Security

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Talking of Moodle security how does the current incident compare to this one http://news.bbc.co.uk/2/hi/technology/7701227.stm ?
In reply to Visvanath Ratnaweera

Re: Moodle Security

by Marc Grober -
The event that set off this discussion is not based on exploitation via a code flaw but via administrative practice (though the code obviously provides this option as a feature) and involves neither a virus nor a trojan methodology. SInowal is a trojan virus.

The argument can be made that the admin in the current situation invited the defacement (much as it has been argued that some women "invite" rape) because the admin created what could be seen as an attractive nuisance; i.e. the admin arguably invited the defacing user to enroll in their site and then provided the user with the tools to obtain the results seen.
In reply to Marc Grober

Re: Moodle Security

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
In that case, how about looking at the size of the FOSS ecosystem http://moodle.org/mod/forum/discuss.php?d=108596#p477646 and the role Moodle plays in it and then comparing that with this feature which could be abused, most probably manually?
In reply to Visvanath Ratnaweera

Re: Moodle Security

by Marc Grober -
Maybe I am missing the thrust of your comment VR, but I think that is what is underlying the discussion. With the huge value added market in "openness"
while value added vendors may help support an open project, they can also have a negative impact where there is a perception of impropriety, negligence, sharp dealing, etc. That lash back will impact not only the specific value added retailer, but the entire community, especially where the buyers are not sophisticated. I think Ron is suggesting that the more sophisticated the purchaser, the less likely there will be foreseeble and avoidable problems.





In reply to Marc Grober

Re: Moodle Security

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
This "issue" fails to impress me. It is neither about a security breech not even about the software Moodle at all, rather a complaint about the service of a Moodle partner.

So I don't understand why the whole Moodle ecosystem should get upset and run PR campaigns or crisis management operations or what not. Moodle is GPL, and the warranty is "AS IS" (para 11 of GPL 2) for its "customers".

Now to the problem of the Moodle partner involved. I'm convinced that they can take care of themselves. From what I've seen in moodle.org and their site, they've done and are still doing a great service to Moodle.

Now about this "message without a messenger". It is very kind of him to provide the world with this information. That being done, now it is the turn of the listeners to react, if at all. As I said at the beginning, _I_ am not impressed.
Average of ratings: Useful (2)
In reply to Marc Grober

Re: Moodle Security

by Bryan Williams -
Mark,

The blog in question where this was reported is, as you know, a vanity site operated by someone who doesn't like Moodle (or Moodle partners) and has made it his mission in life to denigrate all things about the free open source Moodle LMS. This is made very clear with the deprecating language used in most posts he makes. Who actually uses this type of language other than politicians (those desperate for empowerment) or someone with an ax to grind.

Since you brought this up as a security issue it might be useful for readers of this post to have some way of putting things into context, in terms of what is being reported. I offer the following response. Other knowledgeable people may offer their comments, or correct anything I will say.
  • Sometime around Fall of 2006 a "bot" e-mail exploit appeared in the wild. The original intent of this exploit seemed to be to harvest email addressess off certain web sites for use by spammers. The script targeted sites that allowed users to create their own login account (social sites and portals). Moodle was not the only web application affected by this exploit.
  • The exploit was limited to creation of a bogus user account, and attempts to gain access to other account email addresses. Only an individual Profile (page display) in Moodle on the bogus account, not site or course pages, were part of the exploit.
  • The bot would only work on sites using the default "Email authentication" scheme in Moodle. The bot would visit a site, create a user account and then attempt to harvest email addresses.
  • When script kiddies discovered this could be useful for other things, sometime in 2007, they reasoned why not also populate the individual Profile with a message (porn, ads for pharm etc.). That is what aforementioned blog is very belatedly reporting on.
  • These bogus accounts, populated with ugly stuff, are only viewable by the Moodle admin who can access all users accounts. This has largely been a nuisance for Moodle admins to clean these out while putting the "fix" in place.
  • The fix involves using the reCAPTCHA anti-bot service (free, but registration required) and enabling this for Moodle's Email authentication plugin. Registration is something a local Moodle admin must do, as it works something like purchasing an SSL certificate (they must know you are who you say you are before issuing an encrpytion key).
No software is 100% invincible or invulnerable to attacks like the email bot. The information age brings different risks to the table and experienced IT people are well aware of this. Security is something that is an ongoing job as new nasties are released into the wild almost every day. Thankfully, Moodle has a full-time security expert working from Moodle HQ who stays on top of what is being reported in the wild. Martin has always issued security alerts to all registered sites when a serious exploit has been identified and fixed. Moodle admin's should register their sites and pay attention to these alerts when issued.

Moodle partner's contribute fixes and report vulnerabilities they or their clients find. Security is taken very seriously and we get advance notice from Martin when something shows up on the radar. I want to mention this also includes (especially) server security, which I believe was the intent of the comments made by the MP referenced. Recently one of our large bank clients did a deep security scan on Moodle and reported a few smaller security problems (fixed in core), but commented that Moodle was a VERY secure application on the whole.
In reply to Bryan Williams

Re: Moodle Security

by Marc Grober -
First, as to the substance of your post, Bryan:

This "ugly stuff" is viewable by everyone, not just admins, which is one reason why its so publicly embarrasing. I am clueless why you would argue this point when it is obviously untrue.

And, I don't know how a Moodle Partner can wax so rhapsodic over Captcha in this forum while the tech press acknowledges Captcha exploits. Security, as you finally acknowledge, is relative.....

Which brings us to the point of the thread; that there are a number of varieties of "data" that a Moodle site is composed of, some of that data being the look and feel if you will of the site, that an "innocent" relying on an MP to secure their website may have expectations that such security goes beyond the contents of the mysql db, that MPs know there are exploits available and arguably take no action to ensure that the sites are secure from such abuse (whether by their own action or by their education of their clients.)

The point is made very well by Ron in a very professional manner....

<rant>
As to the vitriole, I think this is where my daughter is wont to explode with an "OMG!" LOL My apologies in advance for what may follow.

Vanity, vanity, thy name is MP.... The person you are poking at, Bryan, is not welcome here, so, though I am without brief in the matter and certainly would not suggest that I speak for anyone, I would have everyone be free to speak here without ad hominem (even MPs). If you want to vent your spleen, get a blog ;=} Let's focus on the message, not the messenger.

That being said, you confuse Moodle with Moodle Partners, a major faux pas if you ask me and suggest that critical analysis is denigration, a comment I might expect to hear from a Neandethal (whoops, apologies to the GEICO guys). You have created fictive straw men and appear to "protest too much".

And if you responding to me, even an MP could note that my name is not Mark, just as yours is not Brian. While I typically ignore such matters as there are Marks in these fora, I saw no other Mar_ in this discussion and as long as we are being gratiutiously rude to some people, I had to assume that your spite was addressed to all who were critical..... especially in as much as you appear to denigrate my posts. I have made it clear that this is not a code flaw, so your help in saving poor innocents from concern while implying I am somehow misleading folk is misplaced. My apologies if I am reading too much into your post, but thats what happens when things turn poisonous.

As I have opined elsewhere, a typical tactic in engendering orthodoxy is the creation of a heretic and his/her heresy which is tantamount to closing a community and a canon and is anathema to an philosophy holding the idea of "openess" as a central tenet.
</rant>
In reply to Marc Grober

Re: Moodle Security

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
"And, I don't know how a Moodle Partner can wax so rhapsodic over Captcha in this forum while the tech press acknowledges Captcha exploits. Security, as you finally acknowledge, is relative..... "

My understanding is that a Captcha can potentially protect from programs that automatically create accounts. However I have a very strong suspicion that creating moodle profile spam is a task that some people are quite happy to do by hand, the only automated bit would be detecting the site in the first place.
In reply to Marcus Green

Re: Moodle Security

by Marc Grober -
Absolutely, Marcus, and my guess is that much of what we are seeing is manual hooliganism..... But, the 500 or so accounts discussed here?
http://moodle.org/mod/forum/discuss.php?d=109507#p480866
(all of which could apparently be seen by the Pope, let alone MPs.....)

Of course, DARPA is producing quite a bit of software that could be used to address recognition of captcha images (the kind of stuff now being used to detect painting forgeries) and combined with a little AI..... but why go to the trouble if you can speak the captcha phrase to your dictation software and have that pass the results back to your bot.... LOL Gonna go out and find me one great big condom and crawl up inside.....
In reply to Marc Grober

Re: Moodle Security

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Clive James once described the young Arnold Scwartznegger as having a body like "a brown condom full of walnuts". (Now that really IS off topic)
In reply to Marc Grober

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Marc.

Enjoyable as it is, let's bring this conversation back to some facts ... smile

From what I can see this is a matter of one (possibly very old, I don't know) site that had email authentication on as well as profiles visible, allowing a spammer to add some public junk to a profile page. With those two settings off (or any one of them) it would not be possible.

No existing accounts were compromised and at no time was the existing information in the site stolen or threatened. Right? The information on the site was indeed secure as described in the excerpt you posted (I'm not trying to be picky, just accurate).

So if you're truly investigating this incident to look where improvements need to be made (and I'm not sure this forum is appropriate at all) it comes down to who was responsible for opening those settings.

Is it Moodle software? It's true in the more innocent past that the defaults for these were on, which could very well be the problem for this site. We relied on the admin to switch them off, but that is no longer the case in current versions of Moodle - they are off with big warnings attached. Some other troublesome defaults have been changed as well in reponse to community feedback in the tracker. This helps EVERYONE installing a new Moodle. So if the fault lies with Moodle software then it's largely been fixed since then, though I know we can do even more about usability and user education. Further development is underway regarding this, and more suggestions are always very welcome in the tracker.

Is it the hosting company? One could surely argue that they should provide new sites in the most locked-down configuration possible, which may not always be exactly the same as the default install configuration of a standard Moodle. Security is surely one important factor of a new installation, I think we can all agree, but I can also see that sometimes it's not always wise to force all clients to turn every feature on. That's really up to each individual company to implement with their clients, but I hope the companies I'm associated with (Moodle Partners) will always use feedback like yours to review their SLAs and procedures to further improve quality all around. You may want to call them directly and ask about it if you're interested. A willingness to improve such things is what makes Moodle partners different to your average schmoe selling server space because they just worked out how to use Cpanel (and there are many of these out there). Every time we issue new security fixes (such as the ones on the Moodle Security page http://moodle.org/security) these guys have to update many hundreds of sites (and boy do they love it smile ).

Is it the client? Well, no, the client is always right, of course. Luckily clients never change settings they don't understand properly and always read the context help and documentation (as far as we can tell). That makes our life so much easier. smile
Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: spam found on site

by Marc Grober -
I think my posts are having the desired effect, that being that there were some excellent posts regarding the focus of my concern and a decision by some to pursue additions to the docs to help users make intelligent decisions about hosting Moodle.

I am a bit perturbed by what I thought might be an intimation that I have posted for some unstated evil purpose and that further discussion should be curtailed because it has strayed "the facts". I will chalk that up to a paranoia. Though I am no longer visited by the business end of a yard stick (much to the chagrin of some), I learned long ago that "thank you for your contribution" may sometimes mean "do that again and you will rue the day you were born" and teacher-voice still gives me the heebiejeebies as my teaching sigoth can attest. Let me point out, though, that the only straying from the facts was done by one MP who piped up and then was not heard from further. Was that a big deal? People make mistakes all the time; nature of the beastie - but as an Emersonian (maybe just a fancy label for someone who shoots their mouth off, but who knows) I would argue that the correlative to making assertions is having the composure to admit one's errors. And I raise this not as some attack on MPs but to suggest that hubris serves no one and just stirs resentment in various quarters.

Unfortunately, I don't think I ever did hear from anyone specifically involved as to how the site was delivered and what if any warnings or advice the specific MP tendered to the client. Nor am I aware of anything yet in the docs that addresses how to completely and effectively undo such SPAM damage once it is inflicted (whether your favorite blogger is blogging a dead horse or not, his point here seems to be well-taken.)

I posted in this forum because this is the "place for comparisons, advocacy, reflections, experiences, and thoughtful general discussions of the playing field that Moodle is part of" as as a place in which the Moodle "Decision" and the "Case for Moodle" are discussed. While not an absolute, oftentimes COTS squarely addresses questions such as posed here, while, as the discussion evidence, hosting by Moodle Partners can raise quite a few questions as to responsibilities (and as evidence in the discussion with respect to the Anchorage School District, such questions are not limited to Moodle Partners, though the conduct of Moodle Partners is of geater concern for a variety of reasons, not the least of which is the use of the Moodle trademarks.)

My last word (though I may reneg) is that we have seen here quite a few discussions promoting to the unsophisticated the ease with which one can set up and use Moodle. I think in part this creates unreasonable expectations in those who come to Moodle clueless. I prefer Hillel's approach over St. Augustine's vis-a-vis evangelism.....




In reply to Marc Grober

Re: spam found on site

by Trevor McGreggor -
Thank you for starting this discussion. I am a "schmoe" who has been hosting my own site with Cpanel for over 2 years. I am not an expert web administrator so I rely heavily on what I learn from these discussions. Had you not started this discussion and given me a link to the site of "He-Who-Must-Not-Be-Named" I would not know my site is potentially still hosting these profiles. I have deleted many of these SPAM profiles in the past; however, I am now concerned I have not done enough to completely remove them from my site.
In reply to Trevor McGreggor

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi, Steve. wink

Start with this link to learn how to secure your sites: http://docs.moodle.org/en/Reducing_spam_in_Moodle

We'll also look at creating some sort of detection tool soon to help you clean up your profiles after a spammer attack.
In reply to Martin Dougiamas

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Here is the first version of a script that will help admins delete spammer profiles:

http://cvs.moodle.org/contrib/tools/spamcleaner/spamcleaner.php?view=co

Please use MDL-17144 to report results and help it evolve.
Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: spam found on site

by ETH Zürich -
Hi,
I changed the above script:

1- removed the rs_fetch_next_record($users) because it cause this error: Call to a member function FetchRow() on a non-object in C:\xampp\htdocs\vle\lib\dmllib.php on line 827

2- Added image search, because some spammers add images such as Ads and p0rn0

3- enhanced sql queries, joining all conditions rather than making a query in loop

4- removing all redundunt queries and make them in one function to avoid any future mess if you want work on this script

5- showing one record for the user who meets more than 1 keyword.. the previous script was showing more than 1 record for any user who has more than 1 keyword in his profile.

hope this helps..

it can be downloaded from here: http://tracker.moodle.org/browse/MDL-17144  until anthony or someone uploads it to CVS.

Cheers
Amr!
In reply to ETH Zürich

Re: spam found on site

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers
Amr - I'm working to catch up on old issues now that classes are finished for the semester. As you know, the spamcleaner.php file attached above was reviewed and worked into the latest version for Moodle 2.0. I'm not sure how what is in CVS for 2.0 would (or would not work for 2.0). I thought it might be helpful to follow up here and let other users know that the above version is not recommended. If you would like to create a plugin for the file in CONTRIB we could do so for folks that might want the file for Moodle 1.9 (or earlier). If so, just create an issue in the tracker and attach a working version for Moodle 1.9 and I will happily work to add it to CVS. Let me know how I might be of help. Peace - Anthony
In reply to Marc Grober

Re: spam found on site

by Ron Meske -
Let me just say, this is probably one of the best discussions on Moodle Security I have read.

I would like to make clear what my desired outcome from this discussion is:
  • Documenting best practices for setting up Moodle to block spammers and identity theft
  • Moodle Partners taking responsibility for informing their customers about how to prevent spammers, hackers, etc. from infiltrating the Moodle site they set up
  • The Moodle Community at large, understand the impact that just one bad piece of publicity can have on an application regardless of whose fault it really is
I think everyone understands that Email Registrations is probably the most vulnerable form of registration availabe for Moodle, other then no enrollement, yet that was not clear when I first installed Moodle. However, I did notice that you can now limit this type of registration to known email domains. This helps, but is not perfect for educational inistutions as thei students can have email accounts from any domian. I do not feel IP based limitation is practical as it would not only limit the easy of registration for educational instituations for their students and parents, but also limit online business use of Moodle email registrations. A more practical approach would be an approval process for self-registration. Prior to access, an emai registration would need to be approved by someone. The actual implementation of this can be done in several manners:
  • Prior to the user's account, and profile, becoming active an adiminstrator would need to approve and activate the account.
  • Grant the newly registered account limited access until an administrator approves the account. If the account is not approved within a given timeframe then it is automatically deleted.
Overall, the ultimate outcome will be a better Moodle experience for all.


In reply to Ron Meske

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Ron,

Generally we recommend that educational institutions don't use email authentication at all, because they generally have other sources of authentication available (like LDAP, an external database, IMS enterprise, or a text file that they can bulk upload to create accounts manually). In fact most institutions that I know of do exactly this, so never have a spammer problem caused by leaving their sites open to all comers.

If they do have to use email authentication, then your idea sounds pretty good at first (I found it here too: MDL-9624), but doesn't it suppose that the admin will be able to tell in advance who is a spammer and who isn't? I'm not sure that will be possible ... what do you think?

Thanks for actually proposing solutions, though, that's what we need.

Another idea I'm having is some sort of filter that can detect common spam and blank it out.
In reply to Martin Dougiamas

Re: spam found on site

by Ron Meske -
Hi Martin,

It is to my benefit to offer solutions when I can, as I will ultimately benefit if the solution works.

As I am sure you know, there is no perfect solution to prevent spam except to disconnect from the outside world and isolate oneself.

Though an administrator may not know if an email address is from a spammer or not, it can deter some spammers if they can not get instant access. If there is doubt about the validity of the email, an admin can certainly decide to contact the person to see if there is a response or not.

Consider this, a spammer does not want to get caught and therefore is not going to use an email account for longer then needed to register an account on one site or many. If they have to wait for approval from an admin, they more than likely either will not bother, or by the time the admin authorizes the account they won't be using that email address anymore and therefore will never get the authorization.

Certainly this is not a perfect solution, but it is one more tool that can be made available to those that decided to use email authorization. Not that this validates this solution, but many other LMS applications provide this as an option.

Instead of trying to create your own spam detection for Moodle, I would recommend you look at what email providers are doing about the fight against spam first. Perhaps there is a way to leverage what is already being done. I believe Moodle should focus on it's core purpose as an LMS and not get bloated like other applicatons have. Now, a tool that allowed an admin to completely delete a profile would be extremely beneficial for Moodle, since not all users acting as admins have the ability to use other system tools to do this.

Again, I recommend first and foremost educating Moodle users on how to protect their installation from spammers and security breaches. This alone will prevent most problems. It could be as simple as a document that highlights the importance of making sound decisions on configuring Moodle and make it a part of the installation instructions. Even adding more information on the setting descriptions themselves can help users understand the impact of changing a setting.

An after thought, if a tool could be created to test a Moodle installation for potential weaknesses, that would be extremely helpful to admins setting up Moodle for the first time.


In reply to Martin Dougiamas

Re: spam found on site

by Julian Ridden -
Is there any way that we could possiby adapt moodle to filter comment areas and blog fields against akismet as many do with blog comments.

Akismet has a pretty good success rate, and while not as ideal as locking systems down entireley, it could provide Admins with another tool in their arsenal,
Average of ratings: Useful (1)
In reply to Ron Meske

Re: spam found on site

by A. T. Wyatt -
I am certainly not a programmer, but it seems to me that some sort of check for course enrollment, and/or forum or assignment activity might help. I would think that this would differentiate between a spammer (who will likely ONLY have profile activity) and a real participant.

atw
Average of ratings: Useful (1)
In reply to A. T. Wyatt

Re: spam found on site

by Mauno Korpelainen -

Maybe we should reconsider that Security forum http://tracker.moodle.org/browse/MDL-15464

I made that suggestion on July purely because I thought people are not aware of these issues but "cancelled the request of new feature" for Disclosure policy. And Steve took the missing security forum issue to another striking weapon against Martin.

I was wrong. We need that forum. Talking about security (of moodle) - not only spam - should not be a tabu. We need people like you, A.T. to look things from objective viewpoint. It is easy to understand why developers (Martin), sellers (Partners) and users may see things differently.

We need also critique and sometimes censure but not censure of critique. I don't like blaming people for such things that they could not prevent or did not know. For example those stories that Steve wrote about Chardelles site (hacked) were totally mispresented and tactless. The questions that Marc asked are reasonable IF some Partner(s) are selling complete security of data - nobody should be able to provide that - and at the same time several (forgotten?) sites of the same Partner were open to abuse.

People like STEVE can open our eyes to communicate more - not meaning to hurt feelings but ready to make things better and to warn sites of possible risks.smile

Average of ratings: Useful (1)
In reply to Mauno Korpelainen

Re: spam found on site

by Ron Meske -
The idea of a Security forum is a nice thought, but it really doesn't address the real issue. That is, Moodle is installed by a rather large demographic of people, many of which just doesn't understand the impact of not worrying about security. And those are the users who will still post their issues in the General problems when they do encounter something because that forum is at the top of the list. If you don't believe me, look at the number of issues that are reported in the General problems forum and really should be posted in a different forum that already exists. For example, SCORM. I mean no offense to anyone, just stating the facts.

I am not opposing open discussion about security, but it does need to be moderated to ensure that nothing is publicly posted that could be used to compromise Moodle's security until it can be addressed by a patch. I may not have found this yet, but I do not see an Announcement of when patches are available and what issues they address. Is there one?

As I am sure everyone knows, people simply don't read and that is backed up even in the Moodle forums with questions that could be easily answered by reading the available documentation. However, the documentation is still needed for those that do read and are willing to put in the effort.

To address the installation of a secure Moodle site, best practices need to be documented so that even the non-technical can follow it and understand. Make these a part of the installation instructions and set the default settings for Moodle to be secure is still the best course of action. Then if you enhance the settings descriptions so that it is clear of the consequences of changing them, that will further help with keeping a Moodle site secure. Another addition could be a warning that pops-up when a setting is changed and could compromise Moodles security. And the final step, a utility that scans a Moodle installation for security issues and provides a warning and recommendations.

My 2 cents.
In reply to Ron Meske

Re: spam found on site

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
I see a lot of value in Rons last post, particualarly the last two paragraphs. I didn't see any comment on my idea/suggestion of a switch to filter certain tag tags (a href and img for instance) out of the user profile field? Would it be easy and helpful?

Also a trivial way of scannning someones site to see if they have been the victim of smut mongers it to do a Google advanced search based just on the site URL and look for the likely words such as v 1agra or whatever.... It wouldn't be rocket science to automate that.
In reply to Marcus Green

Re: spam found on site

by Ron Meske -
Filters can be both helpful and sometimes decremental. Take for instance the Censor filter. It can block obscure words that are perfectly valid, like peacock.

A search that focuses on Profiles and includes searching even the HTML code, could highlight potential problems that the admin would then have to review. I would see this as a cron job that posts its findings in the Notifications block or at least a link to the results. However, once you find it you need an easy way to completely remove it as well.
In reply to Ron Meske

Re: spam found on site

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

And my how we laughed at the misfortune of the good folk of Scunthorpe when the council installed email filtering.

But I was not suggesting a word filter, more an image and link filter. I believe one of the main reasons people put in profile spam is so it gets picked up by search engines and they get better ranking. By filtering out the ability to put in images or links people could still include information about themselves but not get any search engine ranking advantage for actual links.

They might still get some slight advantage in terms of keywords but it would be wildly diminished, plus you would remove the chance of the appearance of offensive images. You might get some offensive words of course.

In reply to Ron Meske

Re: spam found on site

by Nicolas Martignoni -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
Hi Ron,
I think this forum could be what you're looking for: http://moodle.org/mod/forum/view.php?id=7128.
Cheers.
In reply to Nicolas Martignoni

Re: spam found on site

by Mauno Korpelainen -

Ron, Nicolas,...

- Current forum "Moodle Security" is in fact a list of found vulnerabilities, it's not a real forum where people can freely ask, comment, discuss: in 27 "discussions" Peter gives a short description of the vulnerability, versions affected, security level etc but readers are not permitted to see details in tracker even when the issue is solved. In most cases bugs remain classified as a "Serious security issue" and will be hidden from the general public even when the security team (led by Petr) had been able to resolve it and publish fixes to registered Moodle sites.

- Responsible policy of disclosing security issues (=bugs) after they have been solved is OK. It does not mean that all security related issues must be hidden from public. As a teacher and former headmaster of comprehensive school I have seen several cases where protecting privacy of students or their families have prevented public discussions. Still if some student or a member of his/her family has some dangerous infectious disease or even if some students have lice or several overcoats, wallets or bicycles have been stolen headmaster and teachers are responsible for warning students and parents and giving information how to protect them selves and their property. And students should always have the possibility to discuss questions if they are worried...

- We need security forum mainly for those people who can read documentation but don't find or understand the info they are looking for from docs

- Security itself is so large and rapidly changing topic that nobody can handle it all, we should update not only documents, sites and programs but also our knowledge daily and still we miss some things.

- as a moderator of General problems, Installation problems and Mathematics Tools I have read roughly 2000 security related posts during the last few years. Ron, stating the facts http://moodle.org/course/view.php?id=5 General problems is not at the top of the forums list and people post to wrong forums every day - that's one reason why we have moderators - I believe people post mostly to General forums if they can't find/have no time to search a proper place for their posts. There are quite many security or spam posts already...

- STEVE, if you can read my previous posts this is not the first time I want to warn sites or administrators of possible risks, Martin has done nothing to change my mind so you are twisting the meaning of my words (again). I cancelled the tracker request for Disclosure policy as I said - because I though it was wise and reasonable in some cases. On the other hand from this discussion I noticed that people don't really care what happens to those sites that are not registered, upgraded and never get warnings - nowhere. I thought Partners sell service that include taking care of updates and settings of sites but Howard confirmed this is not the case. I have been reading you blog "with sunglasses" because you always tell the partial truth. You just "forget" to tell something like in Chardelles case I sent a post to your blog right after you posted the first "news" because it was very easy to find from the net that Chardelles site was hacked through Joomla using a vulnerability that she had no way to know. Even the main site of Joomla was hacked with the same vulnerability. Still you had to revel in "hacked moodle site"... does this explain why I called your stories totally mispresented and tactless. You just wanted to hurt - not tell the facts.

In reply to Mauno Korpelainen

Re: spam found on site

by Ron Meske -
Mauno,

As I mentioned, I am not opposed to open discussion about security, I am simply stating that just adding a Security forum is not the only answer. When a forum to talk about security is eventually added, it will need close monitoring because you can easily end up with individuals unknowingly posting a vulnerability before it can be fixed and distributed. This is especially important to address with Moodle, as students will look for any way to breach security just for the bragging rights. And that is only one small population of individuals you have to look at.

I do apologize for saying General problems is at the top of the list, better wording would be that it is one of the first forums on the list and since the issues of security typically come up after Moodle is installed, that will be the forum they go to first if they don't want to read documentation.

Suggestion
It would appear that there are multiple issues being addressed in this discussion. Instead of adding just a forum to discuss Security, look at what the real need is based on the questions being asked. I see a lot about how to set-up registration, setting roles and permissions, how to remove spam, and problems with sites being hacked. So why stop at just adding a Security forum, why not looking at creating/naming forums that are intuitive to help direct users to the correct location to find the help they need. I could see a forum dedicated to addressing configuration, one dedicated to handling spam, and finally one on understanding and handling security updates.

For those admins that need even more details about a security breach and need to understand how to address it, a better solution would be to create a group something like Moodle Developers, perhaps call it Moodle Administrators, that an admin can enroll in and be screened. This forum can then be secured from the public and address any fears of vulnerabilities getting out.
In reply to Ron Meske

Securing Moodle

by Marc Grober -
Which (discussion of the 'proliferation' of fora) brings me back an old argument.
  • Fora are not the best place to find solutions, but are resources to explore undocumented issues
  • the Docs are the places to document solutions
  • Use of Docs by users needs to be more effective and more efficient
  • The Docs are ad hoc, the nature of a wiki
From this I argued that an active search feature that would allow those most sophisticated to meet their communal obligations by building a map that help parse "natural language" Moodle questions to effective doc entries as a precursor to posting in the forum (i.e. an attempt to post in the forum for those 'not' sophisticated would result in an active search first)

That is to say the paradigm would work so: If a Doc search does not result in an answer the matter is addressed in the forum at which point the matter is documented, map updated and if appropriate a tracker item is created (and referenced in the docs).

This is not to suggest that narrower forums are not appropriate (although the typical problem with forum apps is, "When is it [not] appropriate to cross post?" The content and function of the current Security forum is essentially a forum by virtue of underlying app only, and arguably should be moved to the Docs, and the forum retitled "Securing Moodle Usage" or some such so that the technocrati will agree that discussions that don't address code "features" are welcome wink
In reply to Marc Grober

Re: Securing Moodle

by Ron Meske -
I like the idea of having the search create a document to link to the forum topic, but couldn't that get messy? Or did I misunderstand what you are suggesting.

If we are going to address modifying actual functionality, or process, of users locating answers to their questions regardless of the source of those answers, then why not further enhance the search by incorporating the type of functionality that is being used in Knowledge Bases. Based on an inquiry it will either suggest topics that relate, or ask for additional information to further refine the inquiry.
In reply to Marc Grober

Re: Securing Moodle

by Martín Langhoff -
Hi Marc,

people usually open a discussion on the forum, and towards the end of the thread someone can summarise it in a wikipage. From that point onwards, content updates can happen in the wiki, sometimes preceded (or followed) by discussion in the forum.

This forum is about comparisons and advocacy so not the most natural place. I'd discuss security practices in the dev forum perhaps, as developers are highly aware of security practices, and the best-of-breed administrators that also know a ton about it lurk there too (Julian, I'm looking at you smile ). And I'd post a or mention in the "installation problems" forum so interested parties can join -- still, GDF is the most fertile ground for this kind of discussion, all the "advanced hosting tricks" are also discussed there.
In reply to Mauno Korpelainen

Re: spam found on site

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I thought Partners sell service that include taking care of updates and settings of sites but Howard confirmed this is not the case

Mauno,

With all due respect... but just where did I say that?? If you are going to quote what I said, I would *really* appreciate if you could get your facts straight. That sort of misinformation hurts in more ways than one.

To be completely clear, we diligently apply all security patches to all customers hosted sites and other sites that we support (excepting where the customer has expressly asked us not to). We check all settings at installation and also check for incorrect settings at intervals after that (we plan to automate and improve on this too - yes, a positive thing to come from this discussion). What is not part of our standard hosting services is manually trawling through the customer's data looking for spam. However, if drawn to our attention we will sort it. I think that's what I said.
In reply to A. T. Wyatt

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
ATW, this is a brilliant and elegant idea. I've added it to MDL-17107.
In reply to Martin Dougiamas

Re: spam found on site

by Mauno Korpelainen -

Great ideas!

This really solves many spam issues, THANK YOU Martin and A.T.

What I'm still worried about is that spammers just search new weak points that are more and more difficult to recognize, prevent or control.

A couple of examples from themes:

http://moodle.org/mod/forum/discuss.php?d=100632

http://moodle.org/mod/forum/discuss.php?d=100303

http://moodle.org/mod/forum/discuss.php?d=88645

Or suppose some spammer sends normal post to any forum we have with one link to a file (any file!) outside the site and the link is working ok when we first read it and reply to that post. After a month he can change the file and trap is set (for example for viruses or malware). It is not a problem if we know our students but on large sites like moodle.org we simply can't check all links daily and can't promise 100% secure data or sites.

In the near future we will have more and more 3rd party activities that may be vulnerable, more and more intelligent crackers who may find their way to edit even core code and so on...you never know what happens tomorrow...

In reply to Mauno Korpelainen

Re: spam found on site

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Welcome to the internet, Mauno! smile

http://secunia.com/advisories/

Perfect security is never possible, we can only strive for it.

Regarding contributed Moodle code, one of the plans rolling along is to replace the Modules and Plugins database with something with more management capability, plus formal review/certification processes by dedicated staff.