4 Simple Ways to Protect your WordPress Site from Viruses, Malware and Hackers

Almost all of our clients have been tar­get­ed by a mali­cious attack on their Word­Press site. When they first come to us, they are in utter pan­ic, stressed and quite con­fused on what to do. Only after we do our job and restore their site to its for­mer virus-free glo­ry, does col­or return to their face and they begin to calm down.

It pains us to see our clients go through so much wor­ry, when they could have avoid­ed the dis­as­ter by tak­ing only a few pre­ven­ta­tive steps. You can save your­self from a major fias­co if fol­low some of the steps we’ve out­lined below to help pro­tect your Word­Press site from virus­es, mal­ware and hack­er attacks:

1. Update your site’s theme & plu­g­ins

Updates for Word­Press and its plu­g­ins are fre­quent­ly released by their offi­cial teams. These updates con­tain fix­es for fresh­ly dis­cov­ered secu­ri­ty loop­holes to pre­vent pos­si­ble attacks. So make sure you reg­u­lar­ly update your site.


2. Back­up

An extreme­ly impor­tant task in man­ag­ing your site is reg­u­lar­ly back­ing it up, espe­cial­ly before mak­ing new changes. You can use a plu­g­in or do it man­u­al­ly. So if your site does unfor­tu­nate­ly get com­pro­mised, then with the help of your back­up files you can switch hosts and be back up and run­ning in no time.


3. Change the login and pass­word from admin

By default the user­name for Word­Press is admin. Cre­ate a unique user­name which isn’t too obvi­ous nor easy to guess; includ­ing num­bers would be good. The same goes for the pass­word. Set a long pass­word with a mix of upper and low­er keys, num­bers and sym­bols.


4. Hide or secure wp-config.php 

The wp-config.php file holds all sen­si­tive data and the con­fig­u­ra­tion of your web­site, and is quite vul­ner­a­ble to attacks. You can secure it by adding the fol­low­ing code to the .htacess file in the root direc­to­ry — chang­ing the cod­ing denies any­one access to the file:

# pro­tect wp-config.php
<files wp-config.php>
Order deny,allow
Deny from all

You can also have it moved to the root direc­to­ry — your_host/wp-config.php — from its default loca­tion at host/wordpress/wp-config.php for added pro­tec­tion.

Preventing Microsoft Word Macro Viruses

Although our focus is on Word­Press… we often get ques­tions from our clients about non-Word­Press virus and hack issues.

Here are some thoughts on com­mon ques­tions we get about MS Word virus­es.

Microsoft Word mal­ware rarely makes the news these days but unfor­tu­nate­ly it exists. Word files received from oth­er com­put­ers or a net­work car­ry a risk. Just because you have an anti-virus pro­gram installed on your com­put­er does­n’t mean you’re a 100% safe. They can’t do any­thing until an update comes with a patch to fix the prob­lem.

To pro­tect your­self from a Word macro virus you first need to know what is.

What is a Word Macro Virus?

Word has a pow­er­ful fea­ture which lets you cre­ate Visu­al Basic for Appli­ca­tions (VBA) pro­grams– also known as macros. Macro virus­es use this fea­ture to copy the virus’s code to oth­er files. VBA pro­grams are stored in the Word doc­u­ment and tem­plate files.

The virus dupli­cates the code auto­mat­i­cal­ly to anoth­er file, usu­al­ly Normal.dot, which is what Word loads with every file. So when­ev­er you open or close the Word file or Microsoft Word itself, the virus copies itself.

Microsoft Word Macro Virus


  • Doc­u­ment all files in the Word file’s start­up fold­er and macros (if you don’t know how to find Word’s start­up fold­er, use this quick tuto­r­i­al). Write down the list of files and macros some­where or take a screen­shot and save it in a mem­o­rable place on your hard dri­ve.
  • If you think you’ve caught a macro virus, then you can then check for virus­es man­u­al­ly. Go to Tools> Macro> Macros in Word’s menu and a list of macros will be dis­played. Com­pare these against the list you cre­at­ed ear­li­er. Pay extra atten­tion to any macros named AutoEx­ec, AutoOpen, Auto­Close, File­Ex­it, File­New, FileOpen, File­Save, File­SaveAs, and Tools­Macro.
  • In Word 97, you need to man­u­al­ly enable virus pro­tec­tion against macros. In the Word menu, go to Tools> Options, click on the Gen­er­al tab, and check the box for Macro virus pro­tec­tion (it might already by checked).
  • In Word 2000, you can set the secu­ri­ty set­ting by going to Tools> Macro> Secu­ri­ty and set­ting the secu­ri­ty lev­el to medi­um. It will auto­mat­i­cal­ly warn you if you are open­ing a file that con­tains a macro.

Malware & Virus Cleanup: Why?

One of the most impor­tant aspects of what WPSOS does is to clean up mal­ware, virus­es, and hacked web­sites.

In case you’re won­der­ing why we do this, it’s because we’re com­mit­ted to our mis­sion: to remove all Word­Press mal­ware and virus­es from Word­Press web­sites.

It is a tall order — but some­one needs to do it. If not, the bad guys win.

In oth­er words: this is more than a job or a com­pa­ny for us. It is a call­ing. Good vs evil. We are ded­i­cat­ing our­selves to the good guys win­ning.

What is so bad about mal­ware, virus­es, and hack­ers? A few things.

First, they put soft­ware on your serv­er with­out your per­mis­sion. Any­thing on your serv­er should have your per­mis­sion!

Sec­ond­ly, almost always, these are used for nefar­i­ous pur­pos­es — such as, send­ing out spam.

Third, since Google among oth­ers tracks how healthy your serv­er is, if it is doing some­thing bad such as send­ing out spam, Google will pun­ish your serv­er. Hence the famous “This site may be hacked” warn­ing on some search results.

Fourth, the hacks could lead to you los­ing infor­ma­tion on your serv­er.

Con­clu­sion: for not only prac­ti­cal rea­sons, but for pro­found­ly moral ones — it is your serv­er so you should do what you want with it! — we are lead­ing the fight against the bad guys.

I feel like some inspi­ra­tional music should be play­ing in the back­ground while you are read­ing this!


Security Warning: Increased Brute Force Login Attempts

There’s been a lot of noise in the Word­Press secu­ri­ty com­mu­ni­ty the last days about the increased XML-RPC attacks. Here at WPSOS we’ve noticed the same and can con­firm the var­i­ous reports on it.

How­ev­er, we’ve also noticed an increase in brute force login attempts. These are robot­ic algo­rithms that every x sec­onds guess a user­name (often ‘admin’ or just the user­name that post­ed a blog post) and then cycles through com­mon pass­words (“12345678”, “asdf1234”, etc) until it even­tu­al­ly gets a hit… or is banned.

Although Word­Press itself is tak­ing var­i­ous mea­sures to try to lim­it this — the lat­est ver­sion, for exam­ple, forces the cre­ation of sub­stan­tial­ly hard­er to guess pass­words — the hack­ers are often one step ahead.

The brute force attacks are get­ting increas­ing­ly bru­tal. We’d def­i­nite­ly rec­om­mend stronger mea­sures to pro­tect your login pages.

But what mea­sures in par­tic­u­lar?

Our two favorite meth­ods are:

  • Use the .htac­cess file to pro­tect the login pages
  • Change the URL of the login pages

This is in addi­tion to — obvi­ous­ly — the more basic anti-brute force pro­tec­tions that are essen­tial: long, com­plex, unique pass­words that you don’t write on paper or email or share open­ly with any­one and don’t re-use, for exam­ple.

But more on that com­mon sense in anoth­er post. As they say: com­mon sense isn’t that com­mon!


WordPress Emergency Support — Here We Are!

If you need Word­Press tech sup­port in an emer­gency, if a crises aris­es and you need your Word­Press fixed as soon as you can snap your fin­gers — here we are!

Well, slight­ly longer than “snap­ping your fin­gers” — but not much.

We pride our­selves not only on our high qual­i­ty (plus rea­son­able cost) but, above all, our speed. We’re obsessed. Mid­dle of the night? There. The wee hours before sun­rise? We’re there. Some crazy time­zone on the oth­er side of the world you’re in? We’re dou­bly there.

Of course, we can’t promise 24/7 solu­tions because we’re bru­tal­ly hon­est: some­times, we just can’t solve the prob­lem that quick­ly. Some­times, unin­stalling this, re-installing that, chang­ing this whole oth­er thing around, just takes time.

Time, and a lot of cof­fee!

Here’s one tip. Call us any time — but if we don’t answer, it does­n’t mean we’re sleep­ing. We’re like­ly focused and it’s 3am here and Miina’s try­ing to solve this prob­lem, Jesmin anoth­er prob­lem, Kristi a third prob­lem — and so we don’t even have the vir­tu­al phone turned on! Just leave a mes­sage or send us an email. When we come up to breathe soon, we’ll call you back or send you a note.

There’s an obvi­ous ques­tion: “don’t you ever sleep?”.

Well, glad you asked! A few things. First, we drink a lot of cof­fee. Sec­ond­ly, we do sneak in naps. Third — more seri­ous­ly (although the cof­fee point was indeed seri­ous!) — this is an advan­tage we have to being par­tial­ly dis­trib­uted. Although our home base is in Palo Alto, in Sil­i­con Val­ley, few of us are based on in Tallinn, Esto­nia — which posi­tions us per­fect­ly so that, at most times, some­one is like­ly focus­ing.

Con­clu­sion: you need a Word­Press fix in a pinch. Well, here we are. Just call. Or email.


How Come WordPress Isn’t More Secure?

A ques­tion we get a lot is, Why Isn’t Word­Press more secure?

Excel­lent ques­tions. We used to won­der this our­selves, when we got start­ed!

A few rea­sons:

First, due to his­tor­i­cal lega­cy rea­sons. Word­Press was built the way it was built, using great tech­nol­o­gy of the time. PHP was the coolest thing ever! Per­haps today, it is eas­i­er to build a safer sys­tem from scratch, but it was­n’t when it was first devel­oped. Tech­nolo­gies change, but soft­ware remains in the lan­guage it was writ­ten.

Sec­ond­ly, there is a trade-off between “flex­i­bil­i­ty / easy of devel­op­ment” and “secu­ri­ty.” Said dif­fer­ent­ly: What makes Word­Press so amaz­ing is that it is sooooo easy to work with: you can quick­ly, triv­ial­ly, change the source, change a design, add a wid­get — do almost any­thing. We love it because, it lets us make any changes we want with­out much effort. But with great pow­er comes great respon­si­bil­i­ty: the ease of devel­op­ment has its cost, and that cost is in secu­ri­ty (and per­for­mance — but that’s a top­ic for anoth­er day). To imple­ment so many ide­al secu­ri­ty mea­sures would slow down the core dev… and no one wants that. Well, “no one” except for us!

Third, shock­ing­ly, many of the secu­ri­ty mea­sure are con­tro­ver­sial. Incred­i­ble to believe, I know! Take, for exam­ple, ban­ning IP address­es that hit too many 404‑s. Let me explain. A com­mon tac­tic to break into a site is to just try lots and lots of URLs, that con­tain plu­g­ins with known vul­ner­a­bil­i­ties, to see if the user hap­pens to have it or not. If they do — hack! If they don’t — a “file not found” (404) error. But there’s a down­side to this: log­ging every 404, could bloat the data­base to be huge — thus slow­ing down the site. Plus, dur­ing stages like devel­op­ing the site, the devel­op­ers often to to URLs that may not exist — thus acci­den­tal­ly lock­ing them­selves out. (No, that’s nev­er hap­pened to me, no, nev­er, and espe­cial­ly not two days ago, which served as the inspi­ra­tion for this blog post — no, of course not, this is mere­ly hypo­thet­i­cal.) As a result, the core Word­Press devel­op­ment team has made a trade-off on pur­pose: lets leave Word­Press with the min­i­mum con­fig­u­ra­tions pos­si­ble, and then let each site admin­is­tra­tor decide for him­self which trade-off‑s he/she’s will­ing to make. As a man who loves flex­i­bil­i­ty, I sup­port this phi­los­o­phy.

These are the three core rea­sons. Per­haps there are more, but it’s too ear­ly in the morn­ing for me to think of now!

Any ques­tions? Bueller, Bueller? Just ask!


Client Questions: Where Are Your Developers?

A com­mon ques­tion clients and poten­tial clients ask us is, where are your devel­op­ers?

Excel­lent ques­tion: many peo­ple pre­fer work­ing with peo­ple in a sim­i­lar time-zone, or who speak the same lan­guage — or who are next door, so they can go knock on the door and have a cof­fee (or beat them over the head!).

Answer: the co-founders split between two offices, in Palo Alto and in Tallinn, Esto­nia. We’re a small team, so when we say “office”, think about 6 peo­ple sit­ting around at table — not the Google­plex. (Yet!). Most of our sup­port­ing devel­op­ment team is in Esto­nia.

Esto­nia is an inter­est­ing and unique place. The birth­place of Skype, it’s also a core Euro­pean coun­try — but it’s always been a bit on the out­skirts. Their lan­guage just isn’t relat­ed to any oth­er known lan­guage (except Finnish and Hun­gar­i­an, odd­ly enough) — and the cul­ture is one of Nordic, north­ern Euro­pean pro­fes­sion­al­i­ty, seri­ous­ness, and prob­lem-solv­ing.

But the best part of work­ing with Esto­ni­ans is this: their almost-native com­mand of the Eng­lish lan­guage. The edu­ca­tion and entire cul­ture there is, effec­tive­ly, bilin­gual in Eston­ian and Eng­lish. As a result, the com­mu­ni­ca­tion is as smooth as our team is pro­fes­sion­al.

But with the oth­er part of our team in Palo Alto, we have a strong Amer­i­can face as well. Half the team is Amer­i­can, and we under­stand deeply both the Amer­i­can cul­ture, and the unique dynam­ics of the tech space and Sil­i­con Val­ley.

Have any ques­tions? Just ask — we love to talk!

Password Protecting WordPress wp-admin Folder

Pro­tect­ing wp-admin fold­er with HTTP authen­ti­ca­tion adds an addi­tion­al pro­tec­tion lay­er for your serv­er. Pass­word pro­tect­ing the admin area makes it hard­er to brute-force access (it’s also pos­si­ble to pass­word pro­tect only wp-login.php).

For hard­en­ing the wp-admin fold­er, cre­ate a .htpass­wds file for stor­ing the pass­word of the addi­tion­al authen­ti­ca­tion (for cre­at­ing the file man­u­al­ly, you can use this htpass­wds gen­er­a­tor for exam­ple).

Cre­ate a .htac­cess file to the wp-admin fold­er. Note that pass­word pro­tect­ing the whole wp-admin fold­er breaks any code that uses ajax on front-end, there­fore make sure to allow /wp-admin/ad­min-ajax.

The con­tent of the .htac­cess file:

AuthUser­File /path/to/.htpasswd
AuthType basic
Auth­Name “Restrict­ed”
require valid-user

<Files admin-ajax.php>
Order allow,deny
Allow from all
Sat­is­fy any

Hiding the WordPress Version

If a weak­ness is found in the Word­Press ver­sion 4.2 and it’s patched in the ver­sion 4.2.2, the sites deter­mined to be run­ning on the old­er ver­sion can be tar­gets for attacks.

There are a few places from where the Word­Press ver­sion can be detect­ed:

- gen­er­a­tor meta tag in the head­er (<meta name=“generator” content=“WordPress 4.2.2” />)
— RSS feed
— Stylesheets and scripts with­out spec­i­fied ver­sion will add the WP ver­sion as default (stylesheet.css?ver=4.2.2)
— default readme file

# For hid­ing the Word­Press ver­sion from the head­er and from the RSS feed, all you need to do is add the fol­low­ing code to your functions.php

function wpsos_remove_wp_version() {
    return '';
add_filter('the_generator', 'wpsos_remove_wp_version');

# For hid­ing the Word­Press ver­sion from the stylesheet and script links, you can mod­i­fy links and remove the ver­sion, before dis­play­ing them in brows­er by adding the fol­low­ing lines to functions.php

function wpsos_remove_wp_version_links( $src ) {
    global $wp_version;
    //If the version is set in the link and equals the current WP version
    if ( strpos( $src, 'ver=' . $wp_version ) ) {
        //Remove the version arg from the link
        $src = remove_query_arg( 'ver', $src );
    return $src;
add_filter( 'script_loader_src', 'wpsos_remove_wp_version_links' );
add_filter( 'style_loader_src', 'wpsos_remove_wp_version_links' );

# The default readme.html with infor­ma­tion about the Word­Press ver­sion can be found in http://yoursitename.com/readme.html. In case the file is there, remove it.

Note: it’s still high­ly rec­om­mend­ed to always update to the lat­est ver­sion of Word­Press!