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”, “123456”, your username, your domain, 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.

How to change your password for: Web accounts, Mail users or administrators, Groups subscribers or administrators

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.

2. Maintenance
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.

4. Upgrade
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:

1. 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.
2. 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 infected files by other means. Here are some options:
     • • The ClamAV virus scanner is installed on our systems, and you can run it eg. on a directory named public_html with “clamscan -ri public_html“. It takes a minute to get going, and then a few minutes more (or longer) to churn out a list of infected files; keep in mind this is still in no way guaranteed to be a comprehensive list, but we are seeing pretty good results from it. You may want to run it on your entire home directory (“clamscan -ri .“) to be sure you haven’t missed scanning any vulnerable files.
     • 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.

3. 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. Our clients have had good experiences with Sucuri.net.
4. Now that your site is clean, if you were triggering a Google Safe Browsing alert, you can submit a blocklist review on Google to get your site de-listed.
5. At this point, you may want to change your account’s SSH/SFTP password and/or its MySQL password (being sure to change it both on the database server and in any CMS configuration files).
6. But don’t stop there! To prevent almost certain reinfection, you must now deal with the original cause of the exploit that allowed the intrusion, which in almost all cases means: Update your CMS software and all themes and plugins, and fully remove any themes or plugins that are not needed, in order to reduce your potential attack surface. Successful hacks are almost always against older versions of the software, because security exploits are found and patched quickly in updates.
7. To prevent future reinfections, you must also begin a practice of keeping your site up to date with the latest software versions. If you sign up for Sucuri.net or another such service, they will provide a CMS plugin to help with that. Otherwise, it is up to you to stay on top of this critical task.
8. You should look into installing a plugin module that blocks login access after a certain number of failures, and/or implements other simple measures to harden your CMS. Refer to the developers’ web site for specifics; searching their docs for “limit login” or “hardening” will probably be fruitful. If you use WordPress, the “iThemes Security” plugin will give you a broad range of easy improvements to your site’s security (But note: Please do not use it to enable automated site backups, as we already do that for you.)
9. If your site is compromised again despite having kept its software updated, it’s likely that the first cleanup was incomplete, and leftovers from the original infection remain active on your site. Now would be the time to restore the site from a clean EE backup copy or to do a fresh CMS install from scratch.

There are many other resources on understanding, cleaning, and preventing CMS infections. A search for the name of your CMS + “malware infection” + “clean” should reveal them.

The two Internet standards for how your email client (app) communicates with an email server are POP (Post Office Protocol) and IMAP (Internet Message Access Protocol). Webmail is just a special kind of IMAP client. All three are supported by EE Mail service, so you get to decide how you want to connect to your account. 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 box: your email software fetches new messages from the server (i.e., goes to the post office) at which point the mail is usually removed from the server. All of your mail and folders are stored locally in the client/app, and if you look at your account on the server (via Webmail or another IMAP client) you’ll see that it’s mostly empty.

IMAP is a more modern standard where everything is primarily stored on the server rather than on the client (though IMAP clients can “sync” with the server and have local copies of all your mail). When an email client connects via IMAP, it shows you the mail server’s version of your email account. Multiple IMAP clients will all display the same things, Webmail included.

Pros and cons

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 worry about going over your mailbox quota. POP’s disadvantage is that you can only access your mail from the one device where all that mail is stored. To address this disadvantage, many POP clients allow you to leave copies of messages on the server for some period of time. Whatever is left on the server (say two weeks’ worth) is then still visible if you happen to be away from that POP client computer and use Webmail to peek in.

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. And we do constant and careful backups of the servers, so if/when your computer dies you don’t lose all your mail. These days, since people tend to use multiple devices (a computer, a laptop, a phone, a tablet, Webmail on someone else’s computer, etc.), IMAP is the more fitting protocol to use everywhere.

Things get more complicated when protocols interact

Multiple devices and protocols make things  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-only 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 is too! That’s why our advice is designed to keep things as simple as possible given your needs.

• If you will access your email exclusively from one device or computer, it’s okay to use POP.
• If you will access your email from more than one device or computer, it’s best to use IMAP on all computers/devices. Configure all devices to use the Sent, Drafts, Trash, and Spam folders on the server.

This tutorial graciously provided by Jonathan Kissam, formerly of Webskillet Cooperative.

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:

cd /home/localuser/yourproject

9. Add a remote source that references the server and repository we set up in the previous steps:

git remote add production ssh://youruser@web.electricembers.net: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://youruser@web.electricembers.net: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://youruser@web.electricembers.net: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