Your password is your responsibility, and you should always use something strong. A good way to make a strong password is to use a multi-word passphrase. These passphrases can be easier to remember and even type (see this xkcd) while simultaneously increasing security by making it much more difficult for humans or software to crack!
Your EE services are provided by free open source software and protected by cryptographically secure encryption technologies and tight security policies. However, all the careful programming, system administration, and advanced mathematics in the world are useless if you pick a weak password, or give it out to the wrong people! Maintaining your password is how you protect your data and prevent abuse of your account. Please do not use weak, easy to guess passwords like password, 1234, your username, any single word from any dictionary, etc.
After we send your initial passwords via email, it would be wise to reset your passwords to something (strong) only you know.
The advent of open-source Content Management Systems (CMS) like WordPress, Drupal, and Joomla! has made it much easier for the average organization to get a capable and beautiful web site, but we would caution strongly against concluding that a CMS eliminates all need for technical expertise. Just like a car, no matter how well it’s built, a web site still needs regular maintenance and attention in order to avoid breakdowns, and it will require knowledgeable technical assistance when something does eventually go wrong despite all preventive efforts. And there are some critical differences in the technology too:
- A web site is an almost infinitely customizable and flexible piece of technology that doesn’t simply work “out of the box”, probably requiring some technical expertise in the setup phase no matter how much the complex wiring inside is hidden by the CMS
- It will perpetually be the target of random malicious attacks from around the globe, of which you will see no indications until they succeed, i.e. until your site has been compromised
- It is subject to much more frequent updates (like recalls to replace faulty pieces), many of which deal with vulnerabilities to those ever-present attacks.
Following is a summary of stages in the standard life cycle of a CMS-built web site, and of the associated roles required to keep it effective and secure
1. Site Creation
Roles: Designer, Developer, Content manager
You will need an overall design (colors, large graphical elements, subtle graphical elements), a layout (what blocks of content go where, how they link to each other, menu navigation), and a selection and possibly creation of content — and these three elements tend to interrelate and feed back into each other in unexpected ways. You will also need to find, install, configure, and perhaps modify the plugins or modules that add any functionality that arises out of the design but is not provided by the base install. Some functionality may not be available anywhere and may need to be programmed from scratch — no CMS is infinitely capable, and each one has different strengths and weaknesses relative to others.
Roles: Content manager, Software manager
The content will need to be kept current, which should require minimal technical knowledge but can benefit from at least basic knowledge of HTML, and may require some familiarity with complex elements of the CMS interface. More critically from a security standpoint, the software itself needs to be kept current, which means being aware of and applying all updates as they become available, or on a reasonably frequent basis. CMS projects may release scheduled updates every 3 or 6 or 12 months, but bug fixes and security updates are released as needed, and each module or plugin will have its own separate release schedule and security patches. You can therefore expect to have updates to apply much more frequently, perhaps on a weekly basis. Since the “bad guys” are aggressive in following the news of these updates and exploiting the issues they reveal, you need to be too. We recommend always staying within one month, and preferably one week (or one day if you can!), of the most recent updates to all elements of your site software.
3. Disaster response
Roles: Software manager
As careful as you may be, at some point something will go wrong with the site. It can be that a software update contains a bug that causes the update to fail and perhaps breaks a portion of the site, or even takes the entire site offline. Or it can be that a hacker manages to crack a password or exploit an unknown or unpatched vulnerability, gains access to your account, and either alters your site or uses it to start blasting out spam messages to the world. When any of these things happen, you will need someone on board (and preferably already familiar with the site) to respond to the incident and manage the process of fixing the problem and taking any preventative measures against a recurrence.
Roles: Developer and/or Designer
It is quite possible that your chosen CMS will eventually go through a transition in which the version you’re using reaches end-of-life and is replaced by a new version for which there is no simple or one-click upgrade from the old one. If that happens, you will need to have the design and content from the old version migrated element-by-element into a fresh install of the new version, which should be much easier than the initial development of the site but will still require some time and expertise.
Here then are the roles that generally need filling:
- Designer and Developer: maybe two people (or groups) or maybe one and the same, but generally they are outside specialists hired to do the work of first designing the site and then implementing the design.
- Content manager: the person within the org who has access to, training in, and responsibility for creating and updating everything seen on the site. They don’t need to be very technical, but should be web-savvy and comfortable learning and working within a complex piece of software.
- Software manager: the person tasked with tracking and applying software updates for the life of the site, and with handling any failures, technical glitches, or intrusions. It can be someone within the org with at least a moderate level of technical proficiency and interest in continually learning more, or an outside contractor, preferably one connected with the site’s original developer. If this role is held internally by a moderately technical person, we still recommend maintaining a relationship with an expert who can be hired on short notice when difficult problems require escalation.
Of course we realize that many of our clients are working with both limited budgets and limited tech skills, and some will have to make do with less than the recommended level of technical involvement. But in our experience, skimping too much on the above needs is almost certain to lead, sooner or later, to a situation in which your organization’s most public asset is broken or abused, and your overworked staff suddenly faced with an urgent and confusing technical situation without the knowledge or resources to address it. We hate to see that happen, so we hope you’ll take our advice to heart and staff your web site adequately. Good luck!
If your CMS-driven web site (e.g., WordPress, Joomla!, Drupal) has been attacked and either disabled, used to distribute malware, or to send malicious email, there is no need to panic. Such intrusions happen with surprising frequency to one or another of our clients, and you need only follow the right steps carefully and methodically to clean things up.
You will have a much easier time here and a much higher likelihood of success if you have some technical chops, meaning familiarity with the administration of your CMS, the Web hosting environment, database concepts, and possibly Unix shell commands. If you don’t have that, you may still be able to proceed by paying a small fee to a third-party cleaning service like Sucuri.net (see below) to handle all the technical details. But that may not be sufficient, and in any case we highly recommend bringing in a tech consultant to manage the job; refer to our Resources page if you need to find one.
Here are the steps we recommend:
- Change your CMS admin password, and make sure it’s a good one. (We recommend 3 or 4-word passphrases, which can be easy to remember while being much harder to crack than a standard shorter password.) Also check any other users with administrative rights: be sure their passwords are also changed and very strong, and delete any that are unused or unfamiliar to you–the attackers may have created their own admin accounts.
- Identify the malicious software that was installed or added to your site in the compromise:
- If the site does not load properly or if it has been altered to distribute malware (you may see a Google Safe Browsing alert when you try to access the site), you should scan your site for known malware. There are many free Web-based scans available from providers who will then give you the option to pay them to clean the infection off your site, including: Sucuri SiteCheck, Unmask Parasites, VirusTotal, and PhishTank.
- If the malware does not show up on any of these Web-based scanners, you will need to find the malware manually. Search the CMS directory for any recently modified or malicious files that may constitute a backdoor that they’re using to continue gaining access. (If you use Joomla, http://myjoomla.com can perform this service for you.) In a shell session, a command like “find public_html -newermt ‘1 week ago'” will find all files under public_html/ modified in the last week. (See “man find” for more.) If you can’t be sure you’ve found everything, you may need to start over with a fresh CMS install, or else restore the account from backups from well before the intrusion.
- Once you’ve identified the malware, remove it as soon as possible, using one or more of these three methods:
- If the date of infection can be identified (we may be able to help here), you can ask us to restore a copy of the entire site’s files, and if necessary database, from the most recent clean backup.
- If you or your designated helper are technically proficient, you can do very careful & thorough manual cleaning of the CMS software installation, removing all malicious files and all malicious code from legitimate files, and from any content stored in the database.
- Finally, if the infection is detected by one of the specialized third-party services whose malware scanners are listed above, you can pay them to clean the site for you. We know that our clients have had good experiences with Sucuri.net, which starts at $90 including one year of ongoing protection and cleanings.
There are many other resources on understanding, cleaning, and preventing CMS infections. One of the most comprehensive pages we’ve seen is this one about WordPress from October 2012:
The two Internet standards for how your email client (the program or app on your desktop, laptop, phone, or tablet) communicates with an email server are POP (Post Office Protocol) and IMAP (Internet Message Access Protocol). Webmail is a special kind of IMAP client. All three are supported by Mail, so when you’re setting up your software there’s no one correct choice—you get to decide how you want to connect to your account based on how you want to use it. There’s some advice at the end of this tutorial, but to understand more, read on!
A little background
POP is the oldest and simplest of the two standards. It was designed to work like its namesake, a post office: your email software sends out a request to the server (i.e., goes to the post office), asks if any mail has come in, and retrieves it for you to open and read, at which point the mail is removed from the server. In this way of working, the client and server are pretty much independent worlds: all of your mail and folders are stored on the client, and if you look at your account on the server (via Webmail or another IMAP client) you’ll see that it’s usually empty, holding only a few messages at a time and only for the brief time between when they arrive and when your email client connects to download them.
IMAP is a newer standard built around a different way of working where everything is stored on the server rather than on the client. When an email client connects via IMAP, it never downloads anything, just gives you a live view of everything that’s stored on the server, which includes all your mail and folders. There’s no longer a client world and a server world; everything is on the server, and every client you use (desktop program, phone app, Webmail) is just a different window onto the same messages and folders.
Pros and cons (and workarounds)
POP has the advantage that it’s very simple. Interactions between client and server are quick and infrequent. You don’t save mail on the server, so you don’t have to pay to use that space. POP’s disadvantage is that you can only access your mail from the one device where your mail is stored. (To address this disadvantage, many POP clients allow you to alter the normal mode of operation and leave a copy of messages on the server after your client downloads them, either for a fixed time period or forever. This setting may even attempt to mirror your Inbox on the server by deleting those server copies when you delete the client copy. Whatever’s left on the server is then visible to another POP or IMAP client. This works for many people, but for Outlook/Entourage users it can fail spectacularly.)
IMAP has the advantage that every view of your email account, no matter which device you use (including Webmail) is exactly the same. No matter where you are or how you access your account, you’re always working with the same messages and folders. IMAP’s disadvantages stem from the fact that all your mail is stored remotely: client-server interactions are more complex, reading email may be a bit slower, you may need to pay for server data storage, and if you don’t have Internet access you won’t be able to read any of your email. (To address this disadvantage, many IMAP clients feature an “offline mode” which is like the POP workaround in reverse: it saves a copy of messages on the client for reading even when you can’t access the server. Like the POP workaround, this can get messy.)
Things get more complicated when protocols interact
So: both protocols have limitations, and though workarounds exist to overcome them, the cure is often worse than the disease. As smartphones and other tiny computers gain popularity, multiple devices and protocols get involved, which makes things even more complicated:
- Multiple POP clients: If you connect to one account from multiple devices all using POP, the devices will “compete” to download messages, and your email will end up scattered across the devices with no rhyme or reason. If one of the devices saves copies of messages on the server and another does not, both will initially download all the same messages, but the first device’s internal representation of the server will be constantly confused and the two Inboxes will not stay in sync. If all of the devices save copies on the server, their rules for when to delete messages will conflict and confuse all of them. Sent messages, Drafts, and Trashed messages will only be available on the client where they were sent, drafted, or trashed.
- POP with IMAP: If you use both protocols, the POP client will constantly “steal” messages from the IMAP clients by downloading and removing them from the server, so the IMAP clients will only be useful for reading messages that haven’t yet been seen by the POP client. If the POP client leaves copies on the server, all clients will see the same messages initially but will then get out of sync, and the IMAP clients may confuse the POP client’s memory of the server’s state. Sent/Drafts/Trash folders will be shared between IMAP clients, but the POP client will have its own different versions of these.
- Multiple IMAP clients: No problems here! IMAP was designed to work well when many devices access the same account.
Our best advice
Is your head spinning? Ours too! That’s why our advice is designed to keep things as simple as possible given your needs.
First off, we strongly recommend consulting with a techie helper when you’re first deciding how to connect to your email account. Depending on how you want to use your email—Will you check it from one device or five? Will you use Webmail? What is your email workflow? How often will you have Internet access? Do you need to save and refer to a lot of mail in your Inbox or folders?—they may suggest different combinations of options.
Saving that, we can offer these brief best-practice generalizations:
- If you will access your email exclusively from one device, it’s usually best to use POP. If possible, configure your device to not save messages on the server. This is especially important if you use Microsoft Outlook or Entourage, which are known to fail spectacularly in this situation.
- If you will access your email from multiple devices, it’s usually best to use IMAP. Configure all devices to use the Sent, Drafts, Trash, and Spam folders on the server and turn off local data caching.
Set up ssh key access
Otherwise, you will have to enter a password every time you want to connect.
1. Open a terminal on your local machine, and check to see if you already have SSH keys:
ls -al ~/.ssh
The public-key file should be one of the following:
id_dsa.pub id_ecdsa.pub id_ed25519.pub id_rsa.pub
If you do not see any of these files, or if (more likely), you get an error that ~/.ssh doesn’t exist, that’s ok, you’ll just need to generate a new key
2. If necessary, generate a new key. In your terminal, type:
ssh-keygen -t rsa
Press enter to accept defaults. If you create a passphrase (which gives an additional layer of security), make sure to write it down somewhere.
3. Copy your public key from the ~/.ssh/id_rsa.pub file, ssh into the Electric Embers servers using the account password, and add your public key as a new line in the ~/.ssh/authorized_keys file (if it doesn’t exist, you may need to create the .ssh directory and/or the authorized_keys file, and make sure that the authorized_keys file is only writable by you:
chmod 600 authorized_keys
You will now be able to ssh, as well as use git, from your local machine without using a password
Set up git repository
1. Make (or download) a copy of whatever directory (the whole webroot, a particular theme/module/plugin, etc.) to your local machine. This will assume /home/youruser/public_html/yourproject
2. In that directory, run the command “git init” to create it as a git repository
3. ssh to web.electricembers.net
4. In your home directory (/home/youruser), create a directory called yourproject.git:
mkdir -p /home/youruser/yourproject.git cd /home/youruser/yourproject.git
5. Create a bare (empty) git repository here:
git init --bare
6. Create a post-receive hook:
cat > hooks/post-receive #!/bin/sh GIT_WORK_TREE=/home/youruser/public_html/yourproject git checkout -f
7. Make your post-receive hook executable:
chmod +x hooks/post-receive
8. On your local machine, navigate to where the git repository is located:
9. Add a remote source that references the server and repository we set up in the previous steps:
git remote add production ssh://email@example.com:yourport/home/youruser/yourproject.git
10. Do an initial push to the server, to set up the master branch:
git add . git commit -am "Initialization" git push production +master:refs/heads/master
11. Other people can now clone it using:
git clone ssh://firstname.lastname@example.org:yourport/home/youruser/yourproject.git
(note: they will have to enter the password every time they clone, pull or push using git unless they have set up ssh keys per the first section)
Cloning and working with the git repository
1. Make sure you have git installed on your local machine (directions here), and, for ease of use, set up ssh keys (per the first section) so you don’t have to enter a password each time you clone, pull or push code.
2. In your terminal, navigate to the directory where you want your local git version to live. It will create its own directory, so you can use something like /home/localuser/mywebsite.org-projects to hold multiple git repositories.
3. Clone the project with this command:
git clone ssh://email@example.com:yourport/home/youruser/yourproject.git
4. You can now work on the local files using your text editor (or copy and paste images or other assets). When you are ready to upload to the server, use the following commands:
git add --all . git commit -am "[some note about update]" git push production
5. If multiple people are working on the same repository, every time you start work you will want to pull the latest version down from the server to your local machine:
git pull production