Summary

Many popular web applications such as wikis, bulletin boards, and blogs rely on commenting, editing, and adding content by users. In almost all circumstances, these applications should be configured to prevent unauthenticated users from posting content, as well as prevent the creation of arbitrary unvetted accounts.

The Problem

Commenting on blogs and modifying wikis is now a very popular target of spammers and hackers. LBNL is a particularly likely target because links from us reflect well in search engines, and because very few .gov sites permit these kinds of activities.

Comment spam may not seem like a big problem, but outsiders are more intolerant of this kind of spam on .gov websites than in other places. Further, these kinds of attacks may also be used to lead users to malicious sites or to host malware (for instance, via attached content in a wiki). It goes without saying that the content typically reflects poorly on the Lab/University as well.

The Solution: Authentication / Moderation

If at all possible, tools should be configured to

Disable Anonymous Posting: Blog software and other web applications typically have the option to moderate comments and changes. Ensure this option is turned on. Do not allow unauthenticated users to post any kind of content.

Ensure Vetting of New Accounts: In the early days of blog and wiki spam, it was sufficient to merely force a captcha/complicated password during self-registration (since this stopped comment-spam-bots). This is no longer the case. Human attackers have and will continue to target servers at LBNL, will register for accounts, and will post content for the reasons we listed above. Unless your research absolutely requires unauthenticated user creation, ensure each user is vetted. Typically, this is done by configuring the system to send an email to a human (LBNL) reviewer for approval before the account is activated.

The Implication: Blocking

The Computer Protection Program will block servers which host inappropriate content without prior notice, even if that content is user-created within a collaborative application. Remember that blocking will impact all websites hosted by the server in question and that the blocked server will no longer have network connectivity of any form (that is, blocking disables internet access, not just the website). Consider carefully the implication of this risk weighed against the need for anonymous posting. There is information here about how to clean up the caches of major search engines if they reflect unacceptable content.