I will agree with you here. Nuke has had a history of security mishaps, and that flow of steady faults being found every now and then would suggest to me there is something not good the way the site was designed. <paranoia> every time a bug is published, we are consequently defaced with it even before a patch would be available, it does seem that clug is very high on someone's list of to-do list </paranoia> And from here stems the suggestion, that we should create our own cms, with only the functionality we actually need, and with security in the top-most position in our minds. I think, this could be a good task for prog-sig, but this is a question to be decided yet. And i would also agree with Shawn, that yes we are able to create a functional and secure active website with adequate and secure content management without the need for pre-fabricated. The other option , is to go completely static, with a decent server, that should be next-to-impossible to deface, bar a few very difficult tricks. The drawback is, no active content, and maintenance would be cumbersome at best. Naturally, if the admin password is lost or guessed, the site would be open.
I would also look at what Roy is saying. The Monoculture is an issue, only made worse by the poor security model of Nuke. my $0.02 CAD Cheers Szemir On September 6, 2004 10:46, Curtis Sloan wrote: > On Mon September 6 2004 10:24, Roy Souther wrote: > <snip> > > > many more steps then I have listed here. I would like to point out that, > > yes PHP-Nuke is near the top of the list of most frequent sites > > compromised but that I believe is more do to the fact that it is the > > number one most popular Open Source CMS. > > I'm in no position to compare (I don't even know what the other offerings > are, let alone have data to back any conclusions) but I would like to point > out, as food for thought, two fundamental issues central to security in > general: > > 1) Design with security in mind. I can't analyze PHP-Nuke because I'm not > familiar with it's code or development process, but the feeling I've gotten > from others over the years is that its poor security history stems at least > partly from poor design. Feel free to refute. > > 2) Monoculture. Yes, ubiquity makes for more prominent targets and > increased activity. But it is only part of any explanation behind rampant > security breaches. That being said, if one's site experiences multiple > breaches in only a few months time, moving away from that monoculture is a > wisely added layer of security. No breach is ever acceptable, no matter > what product is being used. > > <snip> > > > running PHP-Nuke. Does that make them anymore secure? The fact that the > > PHP-Nuke security holes are exposed faster then other CMS's is not a > > comfort but a benefit. > > Not if you're being hacked in the wild. :-P > > > I have stopped upgrading PHP-Nuke in favor of adding my own security > > changes and watching what new changes become available. The author of > > PHP-Nuke tends to be less interested in security with his changes and > > more reliant on others to fix his mistakes. Only human. > > On the other hand, if security is important to you and not the vendor, why > use their product? > > > Just my $0.02. I am no expert in security. I am learning as I go. > > I'll second that for myself. :-) > > I will take this opportunity to voice my appreciation for the Executive's > continued dedication to protecting current investments in CLUG and > improving beyond what we have. I am also sympathetic to the additional > effort it takes to act on that as opposed to maintaining status quo, and > the work required to rectify this particular situation. Thank you very > much for working on our behalf! > > Sincerely, > Curtis > > _______________________________________________ > clug-talk mailing list > [EMAIL PROTECTED] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca _______________________________________________ clug-talk mailing list [EMAIL PROTECTED] http://clug.ca/mailman/listinfo/clug-talk_clug.ca
