Opening Ports In CSF Firewall

CSF can be configured in Web Host Manager (WHM) as well as over ssh. You need to open up the following file:


nano /etc/csf/csf.conf


and add the port you mean to open to the needed line:


# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,26"
# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,37,43,53,80,110,113,443,587,873"


CSF then needs to be restarted for the change to take effect:


csf -r

From Within WHM

In WHM, type configserver in the Find bar in the upper left hand corner. Click on ConfigServer Security&Firewall. On that page, click on the Firewall Configuration button:



That page will allow you to edit the exact same file you would if you were accessing it over ssh:



Like with the ssh instructions, add the necessary port to the list, then click Change at the bottom of the page to save your changes. After that is run, you will need to restart csf. Thankfully, the very next screen you will see has a button for that, Restart csf+lfd

Read More

How To Optimize Your Site With HTTP Caching

I’ve been on a web tweaking kick lately: how to speed up your javascript, gzip files with your server, and now how to set up caching. But the reason is simple: site performance is a feature.

For web sites, speed may be feature #1. Users hate waiting, we get frustrated by buffering videos and pages that pop together as images slowly load. It’s a jarring (aka bad) user experience. Time invested in site optimization is well worth it, so let’s dive in.

What is Caching?

Caching is a great example of the ubiquitous time-space tradeoff in programming. You cansave time by using space to store results.

In the case of websites, the browser can save a copy of images, stylesheets, javascript or the entire page. The next time the user needs that resource (such as a script or logo that appears on every page), the browser doesn’t have to download it again. Fewer downloads means a faster, happier site.

Here’s a quick refresher on how a web browser gets a page from the server:

1. Browser: Yo! You got index.html?
2. Server: (Looking it up…)
3. Sever: Totally, dude! It’s right here!
4. Browser: That’s rad, I’m downloading it now and showing the user.

(The actual HTTP protocol may have minor differences; see Live HTTP Headers for more details.)

Caching’s Ugly Secret: It Gets Stale

Caching seems fun and easy. The browser saves a copy of a file (like a logo image) and uses this cached (saved) copy on each page that needs the logo. This avoids having to download the image ever again and is perfect, right?

Wrongo. What happens when the company logo changes? Amazon.com becomes Nile.com? Google becomes Quadrillion?

We’ve got a problem. The shiny new logo needs to go with the shiny new site, caches be damned.

So even though the browser has the logo, it doesn’t know whether the image can be used. After all, the file may have changed on the server and there could be an updated version.

So why bother caching if we can’t be sure if the file is good? Luckily, there’s a few ways to fix this problem.

Caching Method 1: Last-Modified

One fix is for the server to tell the browser what version of the file it is sending. A server can return a Last-modified date along with the file (let’s call it logo.png), like this:

Last-modified: Fri, 16 Mar 2007 04:00:25 GMT
File Contents (could be an image, HTML, CSS, Javascript...)

Now the browser knows that the file it got (logo.png) was created on Mar 16 2007. The next time the browser needs logo.png, it can do a special check with the server:

1. Browser: Hey, give me logo.png, but only if it’s been modified since Mar 16, 2007.
2. Server: (Checking the modification date)
3. Server: Hey, you’re in luck! It was not modified since that date. You have the latest version.
4. Browser: Great! I’ll show the user the cached version.

Sending the short “Not Modified” message is a lot faster than needing to download the file again, especially for giant javascript or image files. Caching saves the day (err… the bandwidth).

Caching Method 2: ETag

Comparing versions with the modification time generally works, but could lead to problems. What if the server’s clock was originally wrong and then got fixed? What if daylight savings time comes early and the server isn’t updated? The caches could be inaccurate.

ETags to the rescue. An ETag is a unique identifier given to every file. It’s like a hash or fingerprint: every file gets a unique fingerprint, and if you change the file (even by one byte), the fingerprint changes as well.

Instead of sending back the modification time, the server can send back the ETag (fingerprint):

ETag: ead145f
File Contents (could be an image, HTML, CSS, Javascript...)

The ETag can be any string which uniquely identifies the file. The next time the browser needs logo.png, it can have a conversation like this:

1. Browser: Can I get logo.png, if nothing matches tag “ead145f”?
2. Server: (Checking fingerprint on logo.png)
3. Server: You’re in luck! The version here is “ead145f”. It was not modified.
4. Browser: Score! I’ll show the user my cached version.

Just like last-modifed, ETags solve the problem of comparing file versions, except that “if-none-match” is a bit harder to work into a sentence than “if-modified-since”. But that’s my problem, not yours. ETags work great.

Caching Method 3: Expires

Caching a file and checking with the server is nice, except for one thing: we are still checking with the server. It’s like analyzing your milk every time you make cereal to see whether it’s safe to drink. Sure, it’s better than buying a new gallon each time, but it’s not exactly wonderful.

And how do we handle this milk situation? With an expiration date!

If we know when the milk (logo.png) expires, we keep using it until that date (and maybe a few days longer, if you’re a college student). As soon as it goes expires, we contact the server for a fresh copy, with a new expiration date. The header looks like this:

Expires: Tue, 20 Mar 2007 04:00:25 GMT
File Contents (could be an image, HTML, CSS, Javascript...)

In the meantime, we avoid even talking to the server if we’re in the expiration period:

There isn’t a conversation here; the browser has a monologue.

1. Browser: Self, is it before the expiration date of Mar 20, 2007? (Assume it is).
2. Browser: Verily, I will show the user the cached version.

And that’s that. The web server didn’t have to do anything. The user sees the file instantly.

Caching Method 4: Max-Age

Oh, we’re not done yet. Expires is great, but it has to be computed for every date. The max-age header lets us say “This file expires 1 week from today”, which is simpler than setting an explicit date.

Max-Age is measured in seconds. Here’s a few quick second conversions:

• 1 day in seconds = 86400
• 1 week in seconds = 604800
• 1 month in seconds = 2629000
• 1 year in seconds = 31536000 (effectively infinite on internet time)

Bonus Header: Public and Private

The cache headers never cease. Sometimes a server needs to control when certain resources are cached.

• Cache-control: public means the cached version can be saved by proxies and other intermediate servers, where everyone can see it.
• Cache-control: private means the file is different for different users (such as their personal homepage). The user’s private browser can cache it, but not public proxies.
• Cache-control: no-cache means the file should not be cached. This is useful for things like search results where the URL appears the same but the content may change.

However, be wary that some cache directives only work on newer HTTP 1.1 browsers. If you are doing special caching of authenticated pages then read more about caching.

Ok, I’m Sold: Enable Caching

First, make sure Apache has mod_headers and mod_expires enabled:

... list your current modules...
apachectl -t -D DUMP_MODULES

... enable headers and expires if not in the list above...
a2enmod headers
a2enmod expires

The general format for setting headers is

• File types to match
• Header / Expiration to set

A general tip: the less a resource changes (images, pdfs, etc.) the longer you should cache it. If it never changes (every version has a different URL) then cache it for as long as you can (i.e. a year)!

One technique: Have a loader file (index.html) which is not cached, but that knows the locations of the items which are cached permanently. The user will always get the loader file, but may have already cached the resources it points to.

The following config settings are based on the ones at AskApache.

Seconds Calculator

All the times are given in seconds (A0 = Access + 0 seconds).

Using Expires Headers

ExpiresActive On
ExpiresDefault A0
 
# 1 YEAR - doesn't change often
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
ExpiresDefault A29030400
</FilesMatch>
 
# 1 WEEK - possible to be changed, unlikely
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
ExpiresDefault A604800
</FilesMatch>
 
# 3 HOUR - core content, changes quickly
<FilesMatch "\.(txt|xml|js|css)$">
ExpiresDefault A10800
</FilesMatch>

Again, if you know certain content (like javascript) won’t be changing often, have “js” files expire after a week.

Using max-age headers:

# 1 YEAR
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
 
# 1 WEEK
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
 
# 3 HOUR
<FilesMatch "\.(txt|xml|js|css)$">
Header set Cache-Control "max-age=10800"
</FilesMatch>
 
# NEVER CACHE - notice the extra directives
<FilesMatch "\.(html|htm|php|cgi|pl)$">
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
</FilesMatch>

Final Step: Check Your Caching

To see whether your files are cached, do the following:

• Online: Examine your site in Redbot (You’ll see the headers returned, and a cache summary on the side)
• In Browser: Use FireBug or Live HTTP Headers to see the HTTP response (304 Not Modified, Cache-Control, etc.). In particular, I’ll load a page and use Live HTTPHeaders to make sure no packets are being sent to load images, logos, and other cached files. If you press ctrl+refresh the browser will force a reload of all files.

Read more about caching, or the HTTP header fields. Caching doesn’t help with the initial download (that’s what gzip is for), but it makes the overall site experience much better.

Remember: Creating unique URLs is the simplest way to caching heaven. Have fun streamlining your site!

Read More

How to check if your Linux server is under DDOS Attack?

Login to your server as root and fire the following command, using  which you can check if your server is under DDOS attack or not:
netstat -anp |grep ‘tcp\|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort –n
This command will show you the list of IP’s which have logged in is maximum number of connections to your server.

ddos becomes more complex as attackers  use fewer connections with more number of attacking IP’s.In such cases, you should get less number of connections even when your server is under ddos.One important thing that you should check is the number of active connections that your server currently has.For that execute the following command:
netstat -n | grep :80 |wc –l
The above command will show the active connections that are open to your server.

You can also fire the following command :
netstat -n | grep :80 | grep SYN |wc –l
Result of active connections from the first command will vary but if it shows connections more than 500, then you will be definitely having problems. If the result after you fire second command is 100 or above then you are having problems with sync attack.

Once you get an idea of the ip attacking your server, you can easily block it.

Fire the following command to block that ip or any other specific ip:

route add ipaddress reject

Once you block a paricular IP on the server, you can even crosscheck if the IP is blocked or not

by using the following command:

route -n |grep IPaddress

You can also block a IP with iptables on the server by using the following command.

iptables -A INPUT 1 -s IPADRESS -j DROP/REJECT

service iptables restart

service iptables save

After firing the above command, KILL all httpd connection and than restart httpd service by

using following command:

killall -KILL httpd

service httpd startssl

Read More

What's in the wp-config.php File?

The items that come with the default wp-config-sample.php file are in blue.

All extra items that you can add are in black, as normal (only add these if you're going to use them).

Database Settings

• DB_NAME : Database Name used by WordPress
• DB_USER : Username used to access Database
• DB_PASSWORD : Password used by Username to access Database
• DB_HOST : The hostname of your Database Server. This is normally localhost, but if you're not sure you can either ask your hosting company, or use a neat little trick of replacing the line withdefine('DB_HOST', $_ENV{DATABASE_SERVER});

If your hosting provider installed WordPress for you, they will be able to provide this information. If you manage your own hosting, you should already have this information as a result of creating the database and user.

• $table_prefix : These are the letters that are attached to the beginning of all your WordPress table names, within your WordPress database. If you didn't change this as part of your WordPress install, then the likelihood is that you're using the default of wp_ . From a security perspective, this is very insecure (as hackers will know to target database table names starting with wp_) and should be changed as soon as possible. If you're an advanced user, and you know what you're doing, you can change it manually by replacing wp_ with something random like pahfh_ and then updating your database tables (and some elements within those tables) with the same change. If you're not an advanced user, get yourself a good security plugin such as Better WP Security, which can easily do it for you.

Security Settings

• AUTH_KEY: Added to ensure better encryption of information stored in the user's cookies.  Do notleave these set to the default values.  See the instructions below.
• SECURE_AUTH_KEY: Added to ensure better encryption of information stored in the user's cookies.  Do not leave these set to the default values.  See the instructions below.
• LOGGED_IN_KEY: Added to ensure better encryption of information stored in the user's cookies.  Donot leave these set to the default values.  See the instructions below.
• NONCE_KEY: Added to ensure better encryption of information stored in the user's cookies.  Do notleave these set to the default values.  See the instructions below.
• AUTH_SALT: Used to make the AUTH_KEY more secure.
• SECURE_AUTH_SALT: Used to make the SECURE_AUTH_KEY more secure.
• LOGGED_IN_SALT: Used to make the LOGGED_IN_KEY more secure.
• NONCE_SALT: Used to make the NONCE_KEY more secure.

From a security perspective, one of the absolute basics is to replace the put your unique phrase here items with some unique phrases, and pronto.
The easy way to do this, is go to https://api.wordpress.org/secret-key/1.1/salt/ and copy the randomly generated lines into your wp-config.php file.

You don't need to remember these, just set them up once, and then you can forget about them.
You can change them at any point (especially if you get hacked), and if you do it will invalidate all existing user cookies, which will just mean that all users have to log in again.

Some of you may remember that WordPress used to have an area where you could define where your media uploads went to. It may have disappeared from the WordPress administrator, but you can still make the change using the wp-config.php file.
If you don’t want to use the ‘wp-content’ directory then you can use this code instead:

• DISALLOW_FILE_EDIT: In the WordPress Administrator area (Appearance -> Editor), it is possible to edit a range of your WordPress files (mainly Theme related). Most users will never use this area (it's for advanced users only), and leaving it open for hackers is a security risk. You can lock down this area with the value set to true and open it again by changing the value to false.

If you have SSL enabled on your website, then it's an awful shame to waste it. Enable SSL on your Administrator area with these two settings

• FORCE_SSL_LOGIN: Forces WordPress to use a secure connection when logging in. Set to true to enable.
• FORCE_SSL_ADMIN: Forces WordPress to use a secure connection when browsing any page in your Administrator area. Set to true to enable.

File Permissions of wp-config.php

Really, this is part of the security of your website, however this is such an important aspect, that it earned its own little section.
Nobody (apart from you) would ever need to access this file, so it's best to lock it away as much as you can. The final padlock on the security of your wp-config.php file is to change the access permissions. You can do this through FTP by right-clicking on the file, selecting File Permissions and then changing the permissions by unchecking the relevant boxes (ideally the Numeric value at the bottom should be 400, but this may need to be 440 depending on your hosting provider).
(Side note - don't forget to protect your wp-config.php file using your .htaccess file.)

Language Settings

These two items were added in WordPress v2.2.
WARNING: If you have just upgraded from a version earlier than 2.2, please refer to the upgrades section below, as these two items should not be added to your wp-config.php without some additional work first.

• DB_CHARSET: Used for the database character set. The default is utf8 which supports any language, so this should not be altered unless absolutely necessary. DB_COLLATE should be used for your language value instead.
• DB_COLLATE: Used to define the sort order of the database character set. Normally this is left blank, which allows MySQL to automatically assign the value for you, based on the value of DB_CHARSET. If you do decide to change this value, make sure it is set to a UTF-8 character set, such as utf8_general_ci or utf8_spanish_ci.

English is the default language of WordPress, but it can easily be changed using these two settings:

• WPLANG : Name of the language translation (.mo) file that you want to use. If you're working in English, you can leave this blank. If you're working in a language other than English, you can look up your language code here: http://codex.wordpress.org/WordPress_in_Your_Language. For Spanish, this would become define('WPLANG', 'es_ES');
• WP_LANG_DIR : WordPress will look for your language translation files (.mo) in two places: firstly wp-content/languages and (if no luck) then wp-includes/languages. If you want to store your language translation files somewhere else, you can define that location here.

Performance Settings

• WP_HOME : This overrides the wp_options table value for home, reducing calls to the WordPress database and therefore increasing performance. Set the value to your full website domain, including thehttp:// and leaving out any trailing slash " / ".
• WP_SITEURL : This overrides the wp_options table value for siteurl (reducing calls to the WordPress database and therefore increasing performance) and disables the WordPress address (URL) field inSettings -> General. Set the value to your full website domain, including the http:// and leaving out any trailing slash " / ".

• WP_POST_REVISIONS : By default, WordPress autosaves all the previous versions of your posts, just in case you decide that you'd like to go back to a version you wrote last week, or last year. Most people don't use this feature, in fact most people don't know this feature exists. As you can imagine, having this on by default creates a lot of extra load on the database. Give your poor database a rest, and either set this definition to false, or if you really like the revisions feature just replace false with the number of revisions you'd like to keep (between 2 and 5 is normally a good number).

• WP_MEMORY_LIMIT : Used to increase the maximum memory that can be used by PHP A popular fix for "fatal memory exhaustion" errors. 64M is a good starting point, but you can increase this if needed.

It's important to note that some hosting companies have an overriding limit on the PHP memory available to you. If this addition doesn't fix the problem, you may have to ask your hosting company very nicely to see if they'll increase the limit in their php.ini file for you.

Debug Settings

• WP_DEBUG : Controls the display of certain errors and warnings (for developer use). Default is false, but any developers wishing to debug code should set this to true.
• CONCATENATE_SCRIPTS : For a faster Administrator area, WordPress concatenates all Javascript files into one URL. The default for this parameter is true, but if Javascript is failing to work in your administration area, you can disable this feature by setting it to false.

Multisite Settings

• WP_ALLOW_MULTISITE : To enable WordPress Multisite (previously done through WordPress MU), you have to add this definition to your wp-config.php file. The setting must be true to be enabled.

Once you add this definition you will see a new “Network” page pop up in your wp-admin, which you can find inTools -> Network.
Follow the directions on this new page to continue the setup.

Site Settings

This is basically detailing the absolute path to the WordPress directory, and then setting up the WordPress variables and files that need to be included.
There should be no need to change this code, but it comes as part of the standard wp-config-sample.php file, so I'm just popping it in in case someone says "Hey, where's that bit of code at the end?"

Upgrades

wp-config.php is one of the few files that is left untouched during normal WordPress upgrades (if you use Fantastico, see note below), so you don't need to worry about it being overwritten.

Why No Closing PHP Tag?

The observant amongst you will have noticed that whilst there's an opening php tag, there's no closing php tag.
This is not a mistake, and your wp-config.php file can be happily left without a closing tag.
Why?
Well, believe it or not a very simple issue of "spaces after closing PHP tags" are known to cause a range of various issues including "headers already sent" errors, and breaking other bits and bobs within perfectly well behaved websites.
Several years ago, WordPress decided to make life a little bit easier for everyone by removing the ending PHP tag from the wp-config.php file.
More recently, they did the same with several other core files.

Final Tip

Hopefully this has provided an insight on the numerous things you can do with the wp-config.php file.
The most commonly used definitions are here, however if you're looking for something very bespoke, you can find a full list of definitions in the WordPress Codex here: http://codex.wordpress.org/Editing_wp-config.php.
Happy coding!

Read More