Memcached is just the tool for you. It is very easy to install and use and it will drastically speed up most PHP code that can be optimized with caching.

Caching simply means taking a piece of data that can be serialized (an SQL query for example) which is resource intensive and does not change extremely often, and storing the resulting data (as opposed to the query) in memory. Any time a matching query is attempted, the result does not need to be fetched from the database and is instead served directly from memory, drastically reducing the load on the server and latency for the resulting query data to be returned. We will cover a couple ways to avoid returning stale data later in this article.

Exactly what can be optimized with caching is a topic unto itself which I will not delve deeply into here. In general, any heavily used PHP code should at least be benchmarked (both before and after enabling memcached) to see exactly how much it will speed up your code.

I will say that I have seen drastic performance improvement with SQL query intensive code such as social network sites, forums, etc.  If your code makes many SQL queries (and let’s face it, what dynamic website doesn’t?), then it is definitely worth trying memcache to see what kind of gains you can achieve. Next, we will see how easy it is to install and use memcached…

Installation:

Note: this installation was performed on a VPS server (Hosted at RapidVPS)  running an updated CentOS 5.7 32-bit. Other platforms or OSs may vary but memcache is fairly easy to install on any platform.

First, make sure libevent is installed:

# yum install libevent

Since I am running CentOS 5.x 32-bit, I installed the appropriate RPM from pbone.net here:

# rpm -Uvh ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/memcached-1.4.5-1.el5.kb.i386.rpm
Retrieving ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/R                                                                                        PMS/memcached-1.4.5-1.el5.kb.i386.rpm
Preparing…                ########################################### [100%]
1:memcached              ########################################### [100%]


Pretty straightforward, huh?  Now we need to start mcached:

memcached -d -m 512 -l 127.0.0.1 -p 11211 -u nobody

(-d = daemonize  -m 512 = use 512m of RAM for caching  -l = IP to listen on*  -p = port to listen on  -u = user to run as**)

*If you are using memcache only on the same machine as the webserver that will be accessing it, specify 127.0.0.1 (localhost) here for security. Otherwise, specify a public IP on your server so the webserver(s) can reach it.

**It is a good idea to run as the same system user the Apache webserver is running as.

Now, verify memcached is running properly:

# telnet localhost 11211
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
stats
STAT pid 24214
STAT uptime 21
STAT time 1316571028
STAT version 1.4.5
STAT pointer_size 32
STAT rusage_user 0.000000
STAT rusage_system 0.001999 …. output truncated

Next, we install the php-memcache module and restart Apache:

# yum install php-pecl-memcache
# /etc/init.d/httpd restart

Now Memcached and php-memcache are installed and ready to use!

Using memcached in PHP:

Here is an example of an SQL query function prior to integrating memcache:

function get_users($db) {
    $query="SELECT * FROM users WHERE 1";
    $result = mysql_db_query("user_table", $query);
    return $result;
 }

Here is a drop in replacement function call for SQL queries that are frequently used to included them in the memcache:

function get_users($db) {
    $query="SELECT * FROM users WHERE 1";
    $key=MD5($query);
    /* first try the cache */
    $data = memcached_fetch($key);
    if (!$data) {
       /* not found : request database */
       $data = mysql_db_query("user_table", $query);
       /* then store the result in cache */
       memcached_add($key, $data);
    }
    return $data;
 }

Now the query result data is stored in the cache with an MD5 signature of the query as the key. So the next time we execute the same query, the memcached_fetch will return the result directly from memory instead of executing the SQL query.

What happens when the users table is updated and we re-run the memcached_fetch? We will be looking at the outdated result as it was when it was added to the cache, without the subsequent updates.

To solve this, we need to update the cache when we update the users table like so:

function update_users($db, $update_string) {
   /* first update database */
    $result=mysql_db_query("users",$update_string);
    if ($result) {
       /* database update successful : fetch data to be stored in cache */
       $query="SELECT * FROM users WHERE 1";
       $key=MD5($query);
       $data = mysql_db_query("user_table", $query);
       /* Now refresh the cache with the updated table */
       memcached_add($key, $data);
    }
 }

Voila. That is memcached in a nutshell. Enjoy the added performance of your busy website!

CSF is a handy, automated firewall script for securing your server against internet based attacks.

CSF can automatically block IP addresses which are trying to gain access to a server providing a first line of defense against internet attacks. This takes a significant workload off the server admin allowing him/her to be able to focus on further securing the server(s) rather than simply maintaining.

Installation:

Note: this installation was performed on a VPS server (Hosted at RapidVPS)  running an updated CentOS 5.7 32-bit.

If you are running a cPanel/WHM Server, please install CSF via the WHM interface.

For all non cPanel servers, start by downloading the tarball and running the install script:

# wget http://www.configserver.com/free/csf.tgz
# tar -xzf csf.tgz
# cd csf
# sh install.sh

Next, test whether you have the required iptables modules:

# perl /etc/csf/csftest.pl

It is ok if some modules fail here as long as there are no FATAL errors.

You can not run any other iptables firewall scripts with CSF without conflicts. If you previously ran APF/PFD, you should uninstall it by running:

# sh /etc/csf/remove_apf_bfd.sh

Make sure klogd is enabled. Edit /etc/init.d/syslog and make sure all klogd lines are not commented out.
Restart syslog if you make any changes in that file:
# /etc/init.d/syslog restart

Configuration:

Add any IPs you wish to whitelist to “/etc/csf.allow” and any IPs you wish to blacklist to “/etc/csf.deny”

Now, edit “/etc/csf/csf.conf” and make any changes to the allowed in/out ports lists as necessary for your environment.
Leave “testing” set to 1 for now.

Restart CSF with:
# /etc/init.d/csf restart

Test all your daemons / applications and ensure everything is working correctly.

If everything is good, edit “/etc/csf/csf.conf” and change “TESTING” to 0 and restart again to go live with CSF:
/etc/init.d/csf restart

Now that CSF is running, to be truly useful we need to know how to easily whitelist/blacklist IPs on the fly and also how to find out if/why an IP has been automatically blacklisted.
(For the examples below, obviously you will need to substitute the target IP for X.X.X.X)

To Whitelist an IP:
# csf -a X.X.X.X

To Blacklist an IP:
# csf -d X.X.X.X

And to find out if an IP has been dropped and why:
# grep X.X.X.X /etc/csf.deny

If the IP in question is listed in this file, it will be accompanied by the reason the IP was added to the blacklist, such as too many SSH or FTP failed login attempts.

The purpose of this guide is to promote the education and use of Cisco’s Netflow Technology. Netflow allows network engineers and hobbyists to accurately and efficiently export network statistics for evaluation and report generation. A well written Netflow capture and scanner system permits one to analyze current network usage and plan for necessary network growth.

Netflow Technology is currently employed at universities, datacenters, and office networks.

What is Netflow  useful for?

What can questions can Netflow answer?

Note: this installation was performed on a VPS server (Hosted at RapidVPS)  running an updated CentOS 5.7 32-bit.

First, let’s make the directories netflow will store data:

# mkdir -p /var/netflow/flows
# mkdir -p /var/netflow/rrds
# mkdir -p /var/netflow/reports/scoreboard
# useradd netflow
# chown netflow.netflow /var/netflow/ -R

Add the RPMForge Repo:  (Note: if you are running a 64 bit system, you will need the 64 bit repo package instead of this one)

# rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm

Update system packages and install required packages via installed repos.

# yum -y update
# yum -y install httpd perl perl-HTML-Table perl-Net-Patricia perl-XML-Parser rrdtool pdksh

Install remaining Perl modules and Flow-Tools via 3rd party Repos

# rpm -Uvh http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/perl-ConfigReader-0.5-1.el5.rf.noarch.rpm

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/perl-Boulder-1.30-3.el5.noarch.rpm

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/perl-Cflow-1.053-6.el5.i386.rpm

# rpm -Uvh http://centos.alt.ru/repository/centos/5/i386/flow-tools-0.68.5-1.el5.i386.rpm

Install FlowScan:

# wget http://net.doit.wisc.edu/~plonka/FlowScan/FlowScan-1.006.tar.gz
# tar -zxvf FlowScan-1.006.tar.gz
# cd FlowScan-1.006
# ./configure –prefix=/var/netflow
# make install
# cp cf/* /var/netflow/bin

Install CUFlow:

# wget http://www.columbia.edu/acis/networks/advanced/CUFlow/CUFlow-1.7.tgz
# tar -zxvf CUFlow-1.7.tgz
# cd CUFlow-1.7
# cp CU* /var/netflow/bin/

Download start scripts for flow-capture and flowscan and an updated version of FlowScan.pm:

wget http://admincheats.com/files/support-files-1.0.tar.gz
tar -zxvf support-files-1.0.tar.gz
cd support-files-1.0
cp flow* /etc/init.d/
cp FlowScan.pm /var/netflow/bin

Configure Flow-Capture:
# vi /etc/sysconfig/flow-capture

OPTIONS=”-n 287 -N 0 -w /var/netflow/flows -S 5 0/0/8818″

Split flows into new files every 5 min and keep in one dir… they are deleted after processing.
The last number (8818 here) is the port flow-capture will listen for data on. This must match the port you configure in your router(s) for export data.

Configure CUFlow:

# vi /var/netflow/bin/CUFlow.cf

-Define your Subnets, one per line  e.g., “Subnet 10.0.0.0/24″
-Update OutputDir to /var/netflow/rrds
-Update ScoreBoard and AggregateScore paths.  i.e.
Scoreboard 30 /var/netflow/reports/scoreboard /var/www/html/toptalkers.php
AggregateScore 30 /var/netflow/reports/scoreboard/agg.dat /var/www/html/overall.php

Configure Flowscan:
   vi /var/netflow/bin/flowscan.cf
-change the “FlowFileGlob” line to “FlowFileGlob /var/netflow/flows/ft-v05.*”
-change the ReportClasses variable to “CUFlow”

Next, we will configure our Cisco 6500 routers running IOS 12.2 to export the Netflow data to our collector.
The syntax may be slightly different for other versions or platforms.

Global config commands:
Router(config)#ip flow-export source Loopback0
You can change the source interface to suit your needs.
Router(config)#ip flow-export version 5 peer-as
Router(config)#ip flow-export destination x.x.x.x yyy

x.x.x.x is the IP address of our collector server and yyy is the port to send the data to.

Router(config)#ip flow-cache timeout active 1
Now, on each edge interface, enable accouting collection:
Router(config)#ip route-cache flow

If you are running a software or hardware firewall in front of your collector box, don’t forget to open the UDP port you specified above to allow the netflow data to reach the server.

To verify you are receiving netflow packets from your router(s), run this command (assuming you configured port 8818 for your router export above)
# tcpdump -n udp port 8818
You should see packets from each router you configured to export netflow data.

Start flow-capture:
# /etc/init.d/flow-capture start

Now you should see a tmp file created in /var/netflow/flows/ and after 5 minutes, this file will be renamed to something like ft-v05.2011-09-17.232001-0400

Now that the flow file has been finalize (and a new tmp file created for collecting new data), it can be processed by flowscan.
Initially, we will start flowscan manually to verify everything is working properly:
# cd /var/netflow
# bin/flowscan

Assuming there are no errors here, the flow file should be processed and the RRD files updated. You should also notice a new file /var/www/html/toptalkers.php
You can view this page by visiting your servers DocRoot page. i.e. http://192.168.2.23/toptalkers.php (obviously you will have to substitute your own IP in the URL).
Lastly, start flowscan via the init script so it runs continuously:
# /etc/init.d/flowscan start

As a network consultant, I design and implement computer networks of all sizes for clients on a regular basis. All too often, the clients request that their servers utilize a NAT setup.

I always ask why they think they need NAT, and I am always surprised at the answer. Either the client has been told (by someone, at some time in the past) that NAT “is just better” for some reason, or they cite “security” concerns. This always makes me chuckle as NAT was never intended to provide security.

The fact is, NAT can actually make public facing servers LESS secure in a couple ways.

First, when NAT is used in place of a thorough and well-planned security policy (as is usually the case) it leaves machines open to malware which is downloaded by someone directly on the machine. Perhaps a sysadmin uses Internet Explorer to download some utility to the server but visits a site with hidden malware (this happens more than you would believe). Now once the malware executes, it “phones home” to the attackers server, opening a path back through the stateful NAT device to the compromised server. Now the attacker has total control of the server and the server owner is none the wiser. If you think this attack vector is unlikely, think again. I have personally seen this type of intrusion several times in the last month alone, on multiple different networks. This is due to server admins incorrectly believing NAT provides some mythical level of security and not having an adequate additional security policy in place. The best policy when setting up a firewall is to explicitly open only the necessary ports for a server BOTH inbound AND outbound. Outbound is often overlooked, but that is how this attack vector works in the wild. The oubound connection is the first step to gaining control of the machine. Without that, the attack is dead.

The other way NAT can make servers less secure is it is terribly complicated and can lead to simple human error. It is very easy for novice network administrators to have a working NAT policy at one point and need to make a change. This can be much more complicated with a NAT setup than with a regular public IP scheme. When the change does not work as expected, firewall rules and access lists may be “temporarily” disabled to allow for troubleshooting of the NAT setup. All too often, these rules are left “open” once the underlying problem is resolved and the servers are left partially or completely unprotected. Likewise, with a complex NAT setup, it can also be difficult to verify all rules are correctly back in place and everything is secure again. It goes back to the old mantra, “Keep It Simple, Stupid”. Complexity should be avoided whenever possible and NAT falls neatly into that category.

The truth of the matter is that NAT was never intended to provide security at all. It was intended to reduce the need for public IPs on devices which do not need full end-to-end connectivity. Internet servers do NOT fall into this category unless they do not need ANY access to the internet (i.e. Database servers which are only accessed by a webserver directly on private IPs). For all other servers, a sane public IP numbering scheme along with an intelligent inbound AND outbound security policy is much more secure and easier to maintain than NAT ever could be.

Friends don’t let friends NAT their servers.