Dallas Network Maintenance Dec 13th 21:00 – 21:30 EST

On Friday, Dec 13th 21:00 – 21:30 EST we will be conducting maintenance on our network equipment at Dallas facility. This will include switching from our copper links to much faster and more stable fiber based links. The end result will be better scalable bandwidth and much better DDoS attack resilience.

These operations are expected to be fully transparent and they shouldn’t cause any noticeable downtime. If you notice any connections issues after this maintenance is done, please contact our Support department.

Leave a comment

Intro to Advanced Policy Firewall and Brute Force Detection


This guide is intended as a basic introduction of Advanced Policy Firewall (APF) and Brute Force Detection (BFD). For more detailed information, feel free to contact A Small Orange and we’ll be glad to help you. See the end of the article for links to the developers website.

Looking for more answers to your hosting-related questions?
Check out the whole A Small Orange Knowledgebase here.

What are APF and BFD?

Advanced Policy Firewall (APF) - simple and powerful manager of the iptables firewall built into Linux.

Brute Force Detection (BFD) –  shell script that tracks aucthentication failures and blocks the offending IP’s to ward off brute force attacks on system services such as mail, SSH, FTP, cPanel and any authenticated service.

The Basics

When you order a new VPS or Dedicated Server from A Small Orange it will come with APF and BFD pre-installed. Some folks prefer to rip it out and install ConFigServer Security and Firewall (CSF) simply because it has a cPanel module that makes it seemingly easier to control. It is our hope that you’ll give APF/BFD a chance! You’ll find it very easy to use once you know a few things about it.

If you use APF/BFD with cPanel do not enable cPHulk Brute Force Protection as it will conflict with BFD, and in the past has resulted in constant unnecessary email notifications.

APF, Advanced Policy Firewall

APF’s configuration files are stored in


and are just standard text files, as are most Linux configuration files. You are encouraged to open them and take a peek! Here are some common tasks, and how they can be accomplished with APF:

Basic Control

To start, stop, and refresh APF, use the following commands:

apf -s      ----- Start
apf -f       ----- Stop
apf -r       ----- Restart
apf -e      ----- Refresh APF rules

Opening an Inbound Port for a Specific IP

In this case we want to allow a remote MySQL connection through the firewall. We know the IP of the remote computer ( and the port for MySQL is 3306.

So, we add the following line to /etc/apf/allow_hosts.rules:

Then refresh the firewall rules with the command by typing:

apf -e

You can do this all on one line:

echo “tcp:in:d=3306:s=” >> /etc/apf/allow_hosts.rules && apf -e

You can substitute any port and any IP. You can also use Classless Inter-Domain Routing (CIDR) notation if you are so inclined, in case you need to allow IP’s in a whole subnet or range to be allowed. For example:


Opening an Outbound Port for a Specific IP

The same steps apply for outgoing as for incoming, but with a different pattern slightly.


This would allow an outbound port 22 connection to

Opening Inbound and Outbound Ports

Maybe you’d like to run a game server, or move SSH to another port. In that case you don’t want to use


, but rather you’ll want to add those in


. Open up


and look for the following line:

Note: the example has been shortened for brevity.


On that line you’ll see some pretty familiar ports, such as 22, 25, 110. Let’s say that you wanted to move SSH to port 2345. All you’d have to do is change 22 to 2345:


Save the file, and refresh APF rules with :

apf -e

This will apply for any port you want to open to the world on your server. If you were going to run a Minecraft server on port 25565, you’d use:


Again, use the following to refresh the firewall rules:

apf -e

Outbound Ports and UDP

If you need outbound ports opened up use the same procedure as above, but instead edit the line for EGress:


The same rules also apply for UDP with the entries




. As always, when done with any edits, use:

apf -e

Whitelisting IP Addresses

Note: whitelisting IP addresses is not recommended because it allows unfettered access to all ports on the server. If you’re having issues with BFD blocking somebody’s IP address, see the BFD section below for information on how to resolve that.

An IP address can be whitelisted with the following command:

apf -a && apf -e

To remove the whitelist:

sed -i '/' /etc/apf/allow_hosts.rules && apf -e

Blocking and Unblocking IP Addresses

You might run into a situation where BFD (described below) automatically blocks an address and you need to unblock it manually. You also may wish to block an IP manually. If the IP in question were ’′ then you would use the following commands:

To Deny, or Block:
apf -d

To remove a blockage:
apf -u

To check why the IP was blocked to begin with, you can look in /var/log/bfd_log. It is easiest to search by IP:

root@server [~]# fgrep /var/log/bfd_log
Nov 28 00:06:01 shiny bfd(21191): {dovecot} exceeded login failures; executed ban command '/etc/apf/apf -d {bfd.dovecot}'.

The above command, and the resulting entry from the log, show that ’′ was blocked because of login failures on the dovecot service.Dovecot handles POP and IMAP email, so its safe to assume that somebody at ’′ was either trying to break in or simply forgot their password and tried the wrong one too many times.

BFD, the Brute Force Detector

If your server were a dance club, BFD would be the bouncer. Its basic function is simple: if an authentication request fails too many times from the same IP it will be blocked for 10 minutes. This is very good for keeping out brute force attacks, where attackers try different username/password combinations over and over again. Too many, and they’ll be blocked.

The downside to this is that it can cause unwanted lockouts for things as basic as a user trying to login with webmail, and not typing their password correctly. Unless BFD is causing issues, we recommend leaving the configuration alone.

BFD Configuration

This is not meant to be exhaustive. We’re just going to look at some basic settings that you can tweak and give you an idea how easy it is to work with BFD. A cron job runs every three minutes that activates BFD, and so it is not a service that is started or stopped.

BFD’s main configuration file is /usr/local/bfd/conf.bfd. Only the first few lines should be edited. The main one we’re concerned with is this:


We recommend leaving this at the default value (which may not match the example above). If you want to change the trigger points, you should do so for individual rules. A popular one to change is:


You can change the ‘TRIG’ value to be whatever you want. This can help to prevent mail users from getting locked out due to too many password attempts. If you’re not having this problem then you’re better of leaving it alone.

If you need to disable a rule altogether you can do so by creating a directory such as ‘rules.disabled’ and moving the rule into it.

mkdir /usr/local/bfd/rules.disabled/
mv /usr/local/bfd/rules/ruleyoudontwant /usr/local/bfd/rules.disabled

I hope you’ve found this article useful. If you have any issues, please don’t hesitate to contact Support for assistance. We’ll be glad to help you with any issues with APF or BFD.

For further reading on APF or BFD, please visit the following URLs:



icon_planicon-dedicatedSome other Knowledgebase articles to help simplify your hosting experience:

Click here to learn how to get started with SiteLock.

Learn how to set up an email address.

Click here to learn all about Nameservers.

Leave a comment

WordPress Security 101

...to a WordPress site...

Keep tabs on your plugins and themes!

Keeping tabs on what plugins and themes you have installed is a very important step to keeping a secure WordPress site. Every theme and plugin you have installed can serve as a possible entry point to your site, so you should make sure you have uninstalled every theme and plugin that you do not currently use. Simply disabling them is not sufficient for security purposes, as the files are still present on your server and accessible to a clever hacker attempting to compromise your site.

Ditch the default admin account!

Every WordPress install by default has the “admin” username when you start out. Because of this, it makes it much easier for somebody with a password cracker to force their way into your admin panel. You should be able to follow these steps to remove the admin user:

1. Login into your WordPress admin panel using your admin account.

2. Select ”users” from your dashboard, then click on “Add New User”.

3. Fill out the required fields and make sure under the “Role” drop-down menu you select “administrator”. Be sure to use a strong password for this account, using a password generator and password manager is advised.

4. Log out of WordPress, then log in again using your new admin username.

5. Go to the “users” page, select the default “admin” user and choose “Delete” from the drop-down menu.

6. You should be asked about the articles that were originally posted under the default ”admin” username. Select the option “attribute all posts and links to” and select your new admin user.

7. Make sure the display name of your new admin user is different from the username. If the actual username is used also as display name of the author, a hacker can quickly identify the admin user and brute force their way into the account.

Help protect against SQL injections, change your database prefix!

This is another setting that hackers will often assume is set to the default wp_ prefix, since not enough people change it. When making a fresh installation this is a simple task since it asks you what you want your prefix to be, although once the site has been installed this can be a bit tricky. Thankfully you can use phpMyAdmin to make this process a little easier.

1. Backups! This is the most important step, so you can quickly and easily revert if there are any issues. You will want to make a backup of your entire database, as well as the wp-config.php file.

2. Open up the wp-config.php file (either by using your favorite text editor via SSH, or using an FTP program to retrieve the file) and find the line that looks like this:

$table_prefix = ‘wp_’;

You want to change the ‘wp_’ portion to whatever new prefix you decided on, making sure to keep the single quotes intact. Ex. $table_prefix = ‘hG759_’;

3. Open phpMyAdmin and select your WordPress database. You will want to change all of the tables that start with wp_ to your new prefix using the following steps:
3a. Click on the table, then click Operations.
3b. Under the “Table options” box you will see a “Rename table to” field, change the prefix in there to your new prefix. Click “Go” to save.
3c. Repeat for every table starting with wp_.

4. Once you have changed the table prefixes, select the *_options table (where * is your new prefix), and find the “wp_user_roles” in the options_name column and click edit. Change the prefix to *_user_roles (again where * is the new prefix). Click “Go” once completed.

5. Open the *_usermeta table and change all rows that start with wp_ to your new prefix, there should only be a few of them.

6. You should be all set at this point! Go through your entire site making sure every function still works. If anything isn’t working properly, and doesn’t look like there’s an easy fix, you can always revert to your backups.

Keep the wp-config.php file out of reach!

The wp-config.php file contains your incredibly valuable database connection information. There are many things you can do to secure this, most commonly you can use .htaccess tricks to stop people from accessing the file, but I personally think the best security is keeping it out of reach from the hacker’s browser. By default, WordPress will search one directory above your webroot (the webroot is generally public_html) if it is unable to find your wp-config.php file. If you move your wp-config.php file above your public_html directory, it will no longer be accessible through a browser no matter what tricks the hacker has up his sleeves.

So instead of: /path/to/public_html/wp-config.php

you will have /path/to/wp-config.php 

Now the only way to access the file is via SSH or FTP, keeping your database information safe. If you do not have access to the folder above public_html, ask your webhost to assist you with this.

Proper file permissions go a long way in keeping things safe!

Often times permissions are changed due to recommendations of certain plugins or for ease of use by the user, but they don’t always recommend the most secure permissions.

If set correctly, the user/plugins should have no issues accessing the files, without compromising security.

If a directory is set to 777 anybody has access to read, execute, and worst of all write to files in that directory. What I consider safest permissions for a directory is 755, this gives the user full control (read, write, execute), while the group and anonymous only have access to view and execute files within that directory (both required for PHP based web content managers such as WordPress). Within the directory you will also need to make sure each file also has correct permissions. The files should be set to 644, this gives you (the user) the ability to read and write to the files, but the group and anonymous users can only view the files. This is important because if anonymous users can’t view the files, they won’t be able to see the content on your pages. You can get a full breakdown of the Linux permission system here.

Take additional steps to restrict access to wp-admin login!

A major step you can take in securing your WordPress admin panel is only allowing specific people to access the wp-admin login page. This is best set up by putting an .htaccess file within your wp-admin directory. Using this .htaccess file you can restrict people from seeing the page without the proper username/password, or require their IP to be in a whitelist (or both!).

Here is an example .htaccess file you could use within your /wp-admin/ directory. This setup will give you access if your IP is on the list, but if it’s not on the list you will be prompted for a username and password.

AuthType Basic
AuthName “Please Log In”
AuthUserFile /path/to/password/file/.htpasswd
Require valid-user
Order deny,allow
Deny from all
Allow from
Allow from
Satisfy any

If you’d like to be even more secure, you can change “Satisfy any” to “Satisfy all” and it will require both your IP to be in the whitelist and the username and password. You can also use plugins to limit the amount of login attempts coming from a certain IP address, so if somebody fails to supply a proper username/password to log in they get banned for a certain amount of time.

Keep your admin pages out of view from search engines!

By default search engines will crawl over your site and find all URLs, including your wp-admin url which you do not necessarily want put out to the public. You can help prevent this by adding the following line to your robots.txt file, preventing your admin page from showing up on search engines:

Disallow: */wp-admin/

You can’t exploit plugins you can’t find!

Often times sites will be exploited by accessing a plugin directly, and depending on your hosting environment you may be able to go to domain.com/wp-plugins and see a list of all installed plugins (another reason you will want to uninstall plugins you don’t use, instead of just disabling them). If you hide this list, then the hacker won’t be able to get an idea of what he’s working with and can’t easily rely on common plugin exploits. You can prevent people from viewing this directory simply by placing a blank index.html file within your /wp-plugins/ directory. This way anybody who tries to view that folder just sees a white screen.

How long has it been since you updated?!

This is the most common step you will see in any blog post about securing your WordPress site. WordPress is one of the most common content management systems (CMS) in use right now (roughly 59.6% of all sites using a known CMS are running on WordPress, which is roughly 20% of all websites on the internet as of Nov 1st, 2013). That being said, WordPress sites are some of the most targeted by hackers due to the amounts of sites it would allow a hacker to access if they found a way in. WordPress sends out updates often that can patch security holes that people have found and exploited, which is why it’s so important to update as soon as WordPress has a new stable release out. Plugins and themes also must update to keep up with the latest security changes, so you will want to update those whenever possible as well. The older your WordPress/plugin/theme version, the more time hackers have had to find a way in.

Don’t rely on other people’s backups!

While most hosting companies do supply backup services that they can restore from in case your site gets compromised, it’s a smart move to save a copy of your verified clean site (both files and database) on your local computer as well as a cloud storage if available. This way if your site was hacked longer than the hosting company has backups, you can provide them with a clean version to bring your site back online. Make sure you verify your site is clean often, and replace your backups accordingly to try and keep your content as current as possible.

There are also several plugins that can also assist with keeping your site clean, I personally use the Sucuri Security plugin to watch for malware so I don’t feel like I have to manually scan the site as often.

Never forget that your home or office computer is an access point!

If your home or office computer gets infected, it could lead to the hacker gaining login information for your website or corrupting files that you might later upload to your site. Uploading corrupted files will allow a hacker quick and easy access to your site, potentially without you noticing right away. For this reason you want to make sure you have a good anti-virus program running on any computer you use to work on the website, as well as the other computers on the network.

Never forget that hackers are clever!

Unfortunately it is impossible to completely safeguard a site from being compromised. Hackers are generally intelligent people who can be good at finding ways in even with proper prevention methods in place, but these prevention methods will be able to stop a great deal of them in their tracks. If somebody does find their way into your site, you at least you can be up and running shortly with minimal content loss with regular scanning and backups.

icon_planicon-dedicatedNeed hosting?

Take a look at all our hosting plans right here.

1 Comment

A Small Orange Community Newsletter November ’13


Two days, and a whole bunch of discounts. Check it out:

A Small Orange Homegrown HostingGet 50% off your 1st invoice on Shared, Business, and Reseller Hosting plans!
Use the code GOBBLE13!
Click here to see all our plans.

Get 35% off your 1st invoice on Hybrid Plans and Dedicated Plans.
Use the code CHEER13!
Click here to see our Hybrid plans.
Click here to see our Dedicated plans.

Get 50% off your 1st invoice on all add-on products.
Use the code TREAT13!
Get Double the RAM and bandwidth on ALL Cloud VPS plans!
No code needed!
Click here to see our Cloud VPS plans.

1 year free domain with purchase of any annual plan (excluding $35 Tiny Plan)

2 Days Only!

Remember, ASO Black Friday/Cyber Monday deals are only valid
Friday, November 29th + Monday, December 2nd.

4684047177_f4227a6bbc_zWork at ASO!

If you’re interested in hosting and want to start a career with a sharp, fast-growing team of ninjas, look no further than A Small Orange. Think you’re a good fit? Look at what our culture and benefits are all about here, and apply today!

Thanks for reading. See you next month!

The ASO Team


Leave a comment

Dallas Cloud VPS SAN9 Emergency Maintenance

We wanted to let you know that we will be conducting emergency maintenance on the Dallas Cloud VPS infrastructure for customers hosted on SAN unit 9 to perform preventative maintenance on a failing member disk. Unfortunately, the maintenance process will require a temporary outage in which we must switch-over from the SAN primary replication unit to the standby secondary unit.

This will take place on Nov 27th 10:00 – 10:30 PM EST

In doing so, we will place all affected virtual machines into an in-memory paused state and then un-pause them once the switch-over has successfully taken place to ensure that there are no complications or data corruption due to the switch. This is the safest method to perform the required maintenance, as in-memory pausing of virtual machines will temporarily suspend disk I/O ensuring data integrity is not affected.

The switch-over process is expected to last no more than 15 minutes during which time virtual machines affected will be inaccessible while in a paused state. Once the virtual machine is un-paused, the server will resume from its last state, uninterrupted, with no reboot or loss of uptime visible to the virtual machines OS or applications.

Customers directly affected by this maintenance will be receiving an email shortly outlining this information. If you do not receive an email by 3pm this afternoon, this emergency maintenance does not affect your instance.

If you have any questions about this maintenance, please let us know.

Leave a comment