Yesterday, our Collage web servers began to show signs of another injection attack.  The attack was similar to the last one, where the attack attempted to use our website to push visitors a known attack website in China.  If successful, the attack would execute malicious java script to download more hostile software to the visitor’s PC.  This represents a newer form of attack, attempting to use a trusted source (in this case ALA), to refer web visitors to a hostile site.   We have identified a number of other external websites that were attacked by the same method.

We have located the malicious code that the attack inserted into some of our forms databases, and have removed it.  We have also added more rules to our filtering system on our two outward-facing Collage web servers to prevent this attack from occurring again.   If you experience any odd behavior related to online forms, please send a report to helpdesk@ala.org with as much detail as you can provide.

We will keep you updated by email and the ITTS Update blog as events require.

Matt Ivaliotes - ITTS

On the Tech support wiki, you will find an instruction document on how to make this migration (thanks to Stephanie Kuenn for putting this together after going through the migration process herself).  Please look the instructions over, and plan to move your weblog in the next several weeks. I of course will be happy to answer questions you may have about this process. Note that Stephanie references using an FTP site for uploading a blog theme. If your unit already has applications on Dreamhost, you should have a login and password for FTP-ing files. If not, when you request the new WordPress blog from me, I will send you the FTP information.

We have located the malicious code that the virus inserted into some of our forms databases, and have removed it.  We have also installed a new filter system on our two outward-facing Collage web servers, and are in the process of fine-tuning its performance.  This new filter should block any further attacks of this kind, which will give us the breathing room to take other measures to prevent more attacks in the future.  If you experience any odd behavior related to online forms, please send a report to helpdesk@ala.org with as much detail as you can provide.

We will keep you updated by email and the ITTS Update blog as events require.

Going forward, we will be posting information on how to migrate all blogs hosted on b2evolution at blogs.ala.org as well as all wikis hosted at wikis.ala.org to our outside hosting space. Expect both the blog and wiki instructions by early next week.

Q1. Will the new version be for ALA members only, or will it also have public-access communities?
A. ALA Connect will not be members-only, although there will be sections that will be set up that way. There will be a basic, “registered users” login for non-members who want to comment on blog posts, participate in discussion forums, and contribute to public-access communities (e.g., a community for library advocacy). However, all of the networking, member search, online résumé, and other pieces that connect you specifically with other members will be available for members only. The different types of permissions are outlined in the Requirements Document available at http://itts.ala.org/update/2008/05/08/online-communities-update-with-documents/ (section 6, page 9). It will be up to a community’s administrators to decide how they want to configure access for their community.

Q2. Will Google search ALA Connect communities and show results?
A. Google the web search engine will be able to index publicly-accessible pages in ALA Connect (AC), but those communities that have set permissions to member-only will not be searchable outside of the AC search engine. ALA does run its own version of Google to search our website, but it won’t be able to search members-only areas of ALA Connect because of those permissions, either. ALA units probably want to take this information into account when deciding how to configure their communities.

We’re moving forward (full speed ahead), but we’re happy to take a break to help everyone understand where we’re heading, so please use the Contact Us form or leave a comment if you have further questions.

I’d like to explain what happened to our mailing list server that caused the large temporary backlog of messages. We fell victim not to a focused spam attack, but to the collateral damage of a spammer, so to speak. A spammer pretended to be sending possibly millions of spam messages from one of our lists - by forging the mail they sent to make it look like it was coming from the list’s address. The result was thousands upon thousands of “bounce” messages that were sent from around the world to our Sympa server.

Spammers generally have many thousands of bad email addresses in their sneakily gathered lists, and any email to a bad address generates a bounce. That bounce is sent to the sender’s (or in this case, the faked sender’s) address. The huge number of incoming bounce messages had to be processed by the Sympa server as they arrived, and the volume of additional bounces bogged the server down terribly, causing a backlog to build up. We identified the list that had been impersonated, shut it off (so the server would no longer concern itself with bounces to that list), and began culling the bad messages from the queue.

We are investigating whether there is anything we can do in order to prevent this in the future. It is a problem plaguing many high volume list servers. The difficult part is that the bounces themselves are not spam to be filtered, and filtering all bounce messages would break an important function of email servers.

The Sympa list server is now operating as normal again, and will be caught up with its message backlog within a few hours.

Matthew Ivaliotes
Information Technology & Telecommunication Services
American Library Association
(312) 280-4266