dd stands for data description and is used for copying data sources.

A simple command to do real-world disk write test in linux is:

This creates a file named ‘test’ with all zeroes in it. The flag conv=fdatasync tells dd to sync the write to disk before it exits. Without this flag, dd will perform the write but some of it will remain in memory, not giving you an accurate picture of the true write performance of the disk.

A sample of the run is below, with a simple SATA disk:

Now, there is a major caveat for using dd for disk benchmarking. The first is that it only tests filesystem access. Depending on your filesystem (I’m looking at your ZFS) the file write may itself just load into memory for writing later down the road. The same with a RAID controller on the system.

A much more accurate way of performing a disk benchmark is to use tools specifically geared towards this task. It will write much more data over a longer period of time. Bonnie++ is a particularly useful tool for this purpose.

Now don’t forget to remove that test file.

CIDR        Total number    Network             Description:
Notation:   of addresses:   Mask:
--------------------------------------------------------------
/0          4,294,967,296   0.0.0.0             Every Address
/1          2,147,483,648   128.0.0.0           128 /8 nets
/2          1,073,741,824   192.0.0.0           64 /8 nets
/3          536,870,912     224.0.0.0           32 /8 nets
/4          268,435,456     240.0.0.0           16 /8 nets
/5          134,217,728     248.0.0.0           8 /8 nets
/6          67,108,864      252.0.0.0           4 /8 nets
/7          33,554,432      254.0.0.0           2 /8 nets
/8          16,777,214      255.0.0.0           1 /8 net (Class A)
--------------------------------------------------------------
/9          8,388,608       255.128.0.0         128 /16 nets
/10         4,194,304       255.192.0.0         64 /16 nets
/11         2,097,152       255.224.0.0         32 /16 nets
/12         1,048,576       255.240.0.0         16 /16 nets
/13         524,288         255.248.0.0         8 /16 nets
/14         262,144         255.252.0.0         4 /16 nets
/15         131.072         255.254.0.0         2 /16 nets
/16         65,536          255.255.0.0         1 /16 (Class B)
--------------------------------------------------------------
/17         32,768          255.255.128.0       128 /24 nets
/19         16,384          255.255.192.0       64 /24 nets
/19         8,192           255.255.224.0       32 /24 nets
/20         4,096           255.255.240.0       16 /24 nets
/21         2,048           255.255.248.0       8 /24 nets
/22         1,024           255.255.252.0       4 /24 nets
/23         512             255.255.254.0       2 /24 nets
/24         256             255.255.255.0       1 /24 (Class C)
--------------------------------------------------------------
/25         128             255.255.255.128     Half of a /24
/26         64              255.255.255.192     Fourth of a /24
/27         32              255.255.255.224     Eighth of a /24
/28         16              255.255.255.240     1/16th of a /24
/29         8               255.255.255.248     5 Usable addresses
/30         4               255.255.255.252     1 Usable address
/31         2               255.255.255.254     Unusable
/32         1               255.255.255.255     Single host
--------------------------------------------------------------
Reserved Space:
	0.0.0.0/8
	127.0.0.0/8
	192.0.2.0/24
	10.0.0.0/8
	172.16.0.0/12
	192.168.0.0/16
	169.254.0.0/16

Of course I’m not the first one to come up with this. Modified based on the cheat sheet from Samat Jain.

Let me know if you have any improvements or suggestions.

The tools to become a certificate authority, and therefore to publish your own SSL certificates, is included in a wide variety of systems – chances are if you have an Ubuntu or CentOS install you already have the capability of becoming an SSL certificate authority via OpenSSL.

The security, and by that I mean trust, that SSL certificates provide in major modern browsers is that only certificates that are signed by a limited number of authorities are trusted. Currently there are about 50 trusted certificate authorities in the world. [Wikipedia] If the certificate that is presented to your browser is signed by one of those CAs, then your browser trusts that it is a legitimate certificate.

Unfortunately in the real world, no computer system should be assumed safe. I would presume that all of the major CAs – Thawte, Comodo, DigiNotar and others have their private key under lock stock and barrel, but simply put, no computer system is safe from intrusion.

The Difference Between Encryption and Trust

SSL certificates play two roles in a browsing session – encryption and trust.

When you visit an SSL site on the HTTPS protocol, you are encrypting your session between two places. In a typical situation, the connection between your browser and server is encrypted, therefore any party which is trying to sniff your data in-between the two endpoints can not see your data.

Trust also occurs when you use an SSL certificate. When you visit mail.google.com, you assume that the certificate is only held by Google and therefore the data you are actually receiving is from mail.google.com, not mail.attacker.com.

The Man-In-The-Middle Attack

A man in the middle attack occurs when your internet connection has been intercepted and someone is playing an active role of sniffing your data in between the two connections. When traffic is unencrypted, this is trivial in nature. When it is encrypted, for example with an SSL certificate, it becomes much more difficult. If you are not planning on modifying the data and just want to see what is occurring between the two connections, it looks something like this:

MITM Intercepts traffic from legitimate HTTPS server -> MITM decodes the content and then re-encodes with its own SSL certificate -> MITM passes all traffic back and forth using the fake SSL certificate on the client’s side, while using the real SSL certificate on the server side.

This all relies on the client’s browser accepting the SSL certificate that the MITM presents. This is why the recent DigiNotar false SSL certificate in Iran for *.google.com is so troubling. Once you have a “legitimate” SSL certificate then a MITM can decode the data without the client even knowing. This violates both the trust and encryption aspects of SSL certificates.

What is being done to protect us against MITM attacks like this?

Google is using its massive number of web crawlers to take inventory of all SSL certificates it finds. It no doubt includes this in its search rankings as well (because if a web site bothers to get an SSL certificate, it indicates it is probably a higher value site), but it can be used to increase the security of sites as well when integrated into Chrome. EFF also runs the SSL Certificate Observatory which has a similar function. The way the *.google.com certificate was discovered was that Chrome gave an error when it noticed the serial number of the certificate did not match what Google had crawled previously. This is all well and good, but it does not work in all browsers and also still allows the site to load, and I doubt a non-technically savvy person would have caught it.

Revocation lists help to recall bad certificates, but by the time a certificate is discovered and revoked the damage has already been done.

The problem is that the whole CA system is flawed. Putting trust into 50 or so companies really is a disservice for end users. Let’s say the US government puts pressure on one of the CAs to issue a similar certificate. Not to mention any hacker gaining access to the CA’s root private certificate.

There are also some at work on a SSL certificate system mixed in with DNSSEC [Ed note: strangely enough, their certificate is currently expired]. The problem again is that the root DNS servers hold a lot of power, and traffic can be spoofed.

Convergence is another tool from @moxie__ which is currently available as a Firefox plugin. It allows you to specify trust authorities which can then tell you when a certificate is insecure. I wasn’t able to try it as I’ve upgraded to Firefox 6.0 and it wasn’t compatible, but it appears to have promise. My concern is that Joe user doesn’t have enough sense to run any security plugins that require any type of input. Any final solution to the SSL CA problem will need to be standards-based and not solved as a plugin.

What Can You Do To Help

Support the IETF and other research into alternatives to the current SSL Certificate Authority system. The SSL CA system is broke, and we need a replacement ASAP if we expect to keep our connections encrypted and private.

It all started after I backed the Kickstarter project for the isostick. Having never heard of a device before that would accept .iso images on a filesystem and then present them to the computer as a disc drive, I thought this was (and is) a pretty cool idea.

When browsing through the comments, I saw folks mentioning that this is just like the Zalman ZM-VE200 external hard drive enclosure. So of course I decided to do some research on this newly discovered gadget.

Overview

Size Comparison: ZM-VE200 on Lower Left, Normal External Drive on Top, External Disc Drive on Lower Right.

The Zalman ZM-VE200 at its core is an external sata hard drive enclosure. These have been around for a long time, allowing you to put your hard drive in an external enclosure and accessing the file system via a USB port. They are great for when you need to transfer a large amount of data and have an internet connection which isn’t up the the task in any reasonable amount of time.

This external enclosure can work just like that, an external USB drive. However, Zalman has added an extra layer of functionality on the enclosure by adding additional components which add features which I frankly haven’t seen anywhere else.

Zalman’s Additional Hardware Magic

The additional circuitry allows you to select an ISO which is present on the drive, and load it just as if it were a DVD or CDROM on the system. This means that instead of carrying around discs to install operating systems on, you simply put the ISOs on the drive and then select the correct ISO when you boot.

The Zalman ZM-VE200 Screen

When you boot/plug in the drive you actually have 3 modes available to you. Disc, Hard Drive or Dual. With Disc, files you place in the _ISO folder on the drive will be selectable via the wheel on the side of the device. As it was shipped the drive needs to be formatted as NTFS in order to show the ISO files, however with updated firmware you can actually use with FAT or NTFS.

Operation

Plugging in the hard drive

First thing you need to do is to install a SATA drive into the enclosure. This is pretty much a no-brainer, it only plugs in one direction. Slide the drive and circuitry back into the case and use the attached screws to secure the case to the drive/circuitboard. The screws are hidden by little rubber seals on the edge of the case.

The Menu Navigation Wheel

When plugging it into the system, you interact with the drive in a few ways. The initial scroll wheel position, when powered up, determines the mode:

• Hold Up to enter ODD or “Disc” mode
• Hold Center to enter Dual mode (both HDD and ODD modes)
• Hold Down to enter HDD only mode

eSATA Port on the ZM-VE200

An eSATA port and cable are also supplied. I did not use this mode in my testing. It requires that you still plug in the USB cable for power requirements, and I would assume you would see faster transfer rates while in eSATA mode.

Finally there is a small switch that enables write-protect mode. This makes it so that you won’t be able to accidentally change the data on the drive.

The only problem I had with the drive was when I first plugged it into my system via a USB extension cable. The drive did not even turn on, it actually just clicked a little bit. I changed USB ports and then it seemed to work fine. Also I’ve run into a situation where I plugged in the drive to a system that was off and then booted it, and the screen lit up but stayed blank. I believe this is because this drive requires more power than some USB ports can deliver, so if you have problems with it, try another USB port first to see if that fixes your problem.

I also had some problems occasionally mounting the ISO file, usually booting into ODD mode (hold the scroll wheel “up”) seemed to fix this problem.

Final Thoughts

When installing operating systems from this drive, the process is notably faster. Meaning, the transfer speed you see off of the “disc” on the drive is much faster than a normal CD or DVD drive. While there were some technical hiccups and gotchas, the drive works very well.

This “gadget” is a must-have tool for system technicians who find themselves constantly burning ISOs to discs. My co-worker who initially made fun of my fondness for new gadgets has since said I’ll have to pry this drive from his cold, dead hands. It is so useful that I am now recommending it to all of my sysadmin friends. At $50 it is a steal and you will even make your money back because you won’t be burning so many discs.

Official Zalman ZM-VE200 Product Site

Buy From Amazon

(Updated Amazon link to SE product on 5/12/2012 – Thanks Skip!)

After figuring out that I had 2 out of 3 of my 1TB Seagate Barracuda hard drives in the array fail, I had to give the entire array up for a loss and test out my backup strategy. Fortunately it worked and there was no data loss. After receiving the replacement drives in from Seagate, I rebuilt the ZFS array (using raidz again) and went along my merry way. After another 6 months or so, I started getting some funky results from my other drive. Thinking it might have some issue as with the others, I removed the drive and ran Seatools on it (by the way, Seatools doesn’t offer a 64-bit Windows version – what year is this?).

The drive didn’t show any signs of failure, so I decided to wipe it and add it back into the array to see what happens. That, of course, is easier said than done.

One of the problems I ran into is that I am using Ubuntu and fuse to run zfs. Ubuntu has this nasty habit of changing around drive identifiers when USB devices are plugged in. So now when this drive is plugged in, it is on /dev/sde instead of /dev/sdd, which is now a USB attached drive.

No problem, I figure, I’ll offline the bad drive in the zpool and replace it with the new drive location. No such luck.

First I offlined the drive using zpool offline media /dev/sdd:

Now that it’s offline, I thought you should be able to detach it. No such luck – since it is a ‘primary’ device of the zpool it does not allow you to remove it.

What they want you to do is replace the drive with another drive. This drive (the same drive, with all info wiped from it) is now on /dev/sde. I try to replace it:

Even with -f it doesn’t allow the replacement, because the system thinks that the drive is part of another pool.

So basically you are stuck if trying to test a replacement with a drive that already been used in the pool. I’m sure I could replace it with another 1TB disk but what is the point of that?

I ended up resolving the problem by removing the external USB drive, therefore putting the drive back into the original /dev/sdd slot. Without issuing any commands, the system now sees the drive as the old one, and starts resilvering the drive.

It is interesting to see what it looks like from an i/o perspective. The system reads from the two good drives and writes to the new (bad) one. Using iostat -x:

It seems that ZFS is able to identify a hard drive by GID somehow but doesn’t automatically use it in the pool. This makes it so that you can’t test a drive by removing it, formatting it, and putting it into a new location. Basically, zfs assumes that your drives are always going to be in the same /dev location, which isn’t always true. As soon as you attach a USB drive in Ubuntu things are going to shift around.

After the resilver is complete, the zpool status is:

You can now clear the error with:

Zpool status now shows no errors:

So now the question I have is this: Are you able to manually update or remove the drive status somewhere in your system? How did zfs know that this drive already had a pool installed on it? I zeroed the drive and verified with fdisk there were no partition on it. Is there a file somewhere on the system that stores this information, or is it written somewhere on the drive?

ZFS is great, but it still has some little issues like this that give me pause before using it in a production system. Then again, I suppose all massive disk array systems have their little quirks!

You might see it running on your system as follows:

If your system is static and the devices do not change, you can actually disable this service using a policy entry.

Create a file in your policy directory, for example /etc/hal/fdi/policy/99-custom.fdi. Add the text:

Save and reload the hald using /etc/init.d/haldaemon restart.

And you will find that service no longer is polling your hardware.

Of course to turn it back on, remove that policy entry and restart the haldaemon again, it will be back in service.

Solution Credit: Linuxforums User cn77

The goal of this is to add a little quote, at random, every time you log into your system. My thoughts were to do it not only as a little source of inspiration but also to add perspective to what I’m doing sitting in front of the computer all of the time.

Originally I was going to try to write the script solely in bash since it is so flexible (and just as a proof of concept) but dealing with RSS in bash isn’t exactly pretty and I just wanted to get this together as quick as possible. PHP makes parsing XML easy, there are a number of ways to accomplish it. I chose to use the ready-made script at rssphp.net to do this, if you are curious about how you can handle this yourself using SimpleXML check out this tutorial over at Pixel2Life. The end result of my solution is a bash script calling a php script to grab the quote.

The Code

First create a file named /etc/update-motd.d/10-quote. The name does not matter much – the number will decide what order the script is called in of all the scripts in /etc/update-motd.d. Do an ls on that directory to see what all is being called when you log in. Add the following lines to this file, assuming you are placing your scripts in /etc/scripts/:

Download v1 of rssphp and extract it to the /etc/scripts/ directory. We will require that file in our php code.

Create the file /etc/scripts/getquote.php and add the following:

I am using the RSS source from QuoteDB as the source of my quotes. Of all the places I checked (and I checked a lot) they seemed to have the most appropriate ones for this use. Feel free to use any source you wish – as long as the XML fields title/description hold the quote you will be able to use it. The RSS url was not obvious from the site and I had to do some digging to find it, in the end I am using http://www.quotedb.com/quote/quote.php?action=random_quote_rss.

We also add the if statement to allow it to degrade nicely in case you have no network connectivity to the server. After a short period – a second or two – it will time out and let you log in.

The end result is a pretty quote in our motd:

It should be pretty strait forward; let me know if you run into any problems!

1. Sniffs data on unencrypted Wireless Networks
2. Looks for unencrypted login cookies sent to known popular insecure sites
3. Allows you to login to that account with ‘One Click’

So what sites are impacted by default? Amazon.com, Basecamp, bit.ly, Cisco, CNET, Dropbox, Enom, Evernote, Facebook, Flickr, Github, Google, HackerNews, Harvest, Windows Live, NY Times, Pivotal Tracker, Slicehost, tumblr, Twitter, WordPress, Yahoo, and Yelp are among the few. A plugin system allows anyone to add their own sites (and cookie styles) to the plugin.

Yikes! It goes without saying that this is a major security problem for anyone who uses unencrypted wireless networks. Includes on this list are many universities and companies such as Starbucks.

It is a bit funny, because just last night I was talking with my friend Jorge Sierra about this very problem. My university in fact is one of those which uses unencrypted wifi. I installed the unencrypted password extension for Chrome to let me know when I am submitted an unencrypted password to a site. I was surprised how often this little box was popping up!

Why Open WiFi?

I am not sure – my undergrad university requires that any traffic going over wifi goes through their VPN which encrypts the traffic and prevents this program from working. Is open wifi still the ‘poison of choice’ for network admins because setting up a VPN-style system is too much for some organizations? Maybe – but it is clearly the wrong answer.

The other clear reason is that it is easier to use, and this is a valid complaint from a user experience perspective. I’ve seen plenty of folks have a hard time even with a simple WPA password. A shared password makes it even harder for a user to sign in. Hotels and coffee houses across the world opt for open wifi because it is simply the easiest for consumers to use. This is a problem us tech people need to solve.

Even if it is encrypted via WEP or WPA (1) these are very insecure protocols and still can be hacked with relative ease. This plugin could in fact be modified to include the cracking as well and cover an even wider range of wireless networks. This brings me to my second point.

Web Developers Must Encrypt All Login Forms

If you run ANY consumer facing app you should be passing any and all login information via an SSL secured website.

For hosts on a static IP address you simply need to purchase an SSL certificate. They are seriously under $20 these days (my cost as a reseller is $12) and are simple to install. Your code should be set up to always use this site and to never allow username and password to be sent unencrypted over the network. This is important not only at the end user’s connection (possibly over open wifi) but also for end-to-end encryption of this data.

Let’s say you are running a site on a shared IP address. You usually still have options. Most hosts I know of offer on SSL connection via the shared site – eg: https://server.name/~username/. This URL can be used to access your site’s information via an SSL certificate and it is normally included with the service.

Ideally every site would have an SSL certificate. But we need a few things for that to happen. People who buy web hosting are almost always looking for the cheapest deal. They will not be getting SSL at these bottom level prices. Hosting needs to have a paradigm shift so that people who run websites need to know that it is better to have people who know what they are doing from a security standpoint have configured and are running their servers, and that paying $10 a year for hosting isn’t sustainable. Some say that there is a significant overhead to running SSL on websites. It will, in fact, add some processing and bandwidth overhead. However this is necessary to provide security of services to the end users.

In my opinion, you either host your website on a large provider who use set up to have a secure infrastructure, or you pay more for an expert to host your website in a secure manner.

Another roadblock is the end of the free source of IPv4 address blocks. Web hosts need to move to IPv6 to free up IP addresses, and every website should be on its own IP address. That will allow SSL certificate installations much easier.

Back to Reality

What can you do, right now, about this problem? If you have to use an unencrypted wireless network, you should be running some sort of VPN to encrypt your traffic over the air as this is the most likely place it would be sniffed. You can get a cheap VPS at < $10 a month and proxy all of your traffic over SSH. Not the fastest method, but it will secure your data.

You can also install the Chrome Extension to warn you if you are about to submit form information via an unencrypted website. It isn’t the prettiest extension but it does get the job done.

Hopefully network, web and system administrators will get their acts together and push for a solution to this problem. It is a big one and one that isn’t apparent to the end user until their data, financial details and/or identity is stolen. We can fix this.

/via TechMeme

I manage a server which has a sole purpose: serving DNS requests. We use PowerDNS, which has been great. It is a DNS server whose backend is SQL, making administration of large numbers of records very easy. It is also fast, easy to use, open source and did I mention it is free?

The server has been humming along for years now. The traffic graphs don’t show a lot of data moving through it because it only serves DNS requests (plus MySQL replication) in the form of tiny UDP packets.

We started seeing these spikes in traffic but everything on the server seemed to be working properly. Test connections with dig proved that the server was accurately responding to requests, but external tests showed the server going up and down.

The First Clue

I started going through logs to see if we were being DoSed or if it was some sort of configuration problem. Everything seemed to be running properly and the requests, while voluminous, seemed to be legit. Within the flood of messages I spied error messages such as this:

Ah ha! A clue! Let’s check the current numbers of ip_conntrack, which is a kernel function for the firewall which keeps tabs on packets heading into the system.

Continuing this line of logic, lets check our current value for this setting:

So it looks like we are hitting up against this limit. After the number of connections reaches this number, the kernel will simply drop the packet. It does this so that it will not overload and freeze up due to too many packets coming into it at once.

This system is running on CentOS 4.8, and since then newer versions of RHEL5 have the default set at 65536. For maximum efficiency we keep this number at multiples of 2. The top size depends on your memory, so just be careful as overloading it may cause you to run out of it.

Fixing The ip_conntrack Bottleneck

In my case I decided to go up 2 steps to 131072. To temporarily set it, use sysctl:

Test everything out, if you have some problems with your network or system crashing, a reboot will set the value back to normal. To make the setting permanent on reboot, add the following line to your /etc/sysctl.conf file:

My theory is that since the server was dropping packets, remote hosts were re-sending their DNS requests causing a ‘flood’ of traffic to the server and the spikes you see in the traffic graph above whenever traffic was mildly elevated. The bandwidth spikes were caused by amplification of traffic due to resending of the requests. After increasing ip_conntrack_max I immediately saw the bandwidth resume to normal levels.

Your server should now be set against an onslaught of tiny packets, legitimate or not. If you have even more connections than what you can safely track with ip_conntrack you may need to move to the next level which involves hardware firewalls and other methods for packet inspection off-server on dedicated hardware.

Some resources used in my investigation of this problem:
[1] http://wiki.khnet.info/index.php/Conntrack_tuning
[2] http://serverfault.com/questions/111034/increasing-ip-conntrack-max-safely
[3] http://www.linuxquestions.org/questions/red-hat-31/ip_conntrack-table-full-dropping-packet-615436/

The image of the kittens used for the featured image has nothing to do with this post. There are no known good photos of a “UDP Packet”, and I thought that everyone likes kittens, so there it is. Credit flickr user mathias-erhart.

My initial thought was that a site on my server was getting Slashdotted or encountering the Digg or Reddit effect. I run Chartbeat on several sites where this occasionally happens and I will usually get an alert from them first. A quick look at the Extended status page from Apache showed that I had a much different kind of problem.

If a site is getting a lot of “good” natural traffic you will see a few things:

• clients will be requesting all kinds of files from your site as a normal web browser would, and
• the referring agent will show the link of the sending site, which you can verify.

In my case I had about 400 or so IP addresses requesting “/” from a little trafficked site of mine. Fortunately my Apache is well-tuned enough that it did not take the server down, which was crucial for diagnosing this problem. Otherwise the entire server may down and your only option is to reboot and stop apache from starting on boot. My apache logs showed the requests:

I found out this is from a type of DoS called a sloworis attack. In this attack, a HTTP request is made to the server and the connection is ‘held open’, making multiple requests. A compromised botnet is used to hammer the server from all over the world on many different connections and IP addresses. From the standpoint of Apache, these are legitimate connections despite the frequency of them. It simulates someone sitting at a browser and hitting the refresh command a few times a second. While not a devastating attack with regards to bandwidth, it ties up your server and rejects legitimate connections.

Fortunately after some asking around I found the mod_evasive Apache module. This module is a very basic one that has a simple function: it will keep a hash table of IPs and pages requested and when a threshold is reached on a page or site it will “block” the IP with a 403 “Forbidden” error.

Installing the module is easy:

1. Download the module onto your server:

   1	# wget http://www.zdziarski.com/blog/wp-content/uploads/2010/02/mod_evasive_1.10.1.tar.gz

2. Run the apache apxs command on the module which will compile it install it into your httpd.conf file (for Apache 2.0 – you are running 2.0 aren’t you?):

   1	# apxs -cia mod_evasive20.c

3. Set up the configuration file. You can enter the following into your httpd.conf main server configuration (for Apache 2.0 again)

   1 2 3 4 5 6 7 8 9 10

   <IfModule mod_evasive20.c> DOSHashTableSize 3097 DOSPageCount 3 DOSSiteCount 100 DOSPageInterval 3 DOSSiteInterval 5 DOSBlockingPeriod 300 DOSLogDir "/var/log/httpd/modevasive/" DOSEmailNotify your@emailaddress.com </IfModule>

Now this works great to throw a forbidden page to the client, but that client is still taking up a slot on your server. Once all of your slots are filled up, other requests are queue and therefore your server is lethargic to non-responsive to real requests.

To fix this problem the mod_evasive module has a DOSSystemCommand option. Using this option you can have your server execute a command when a client trips the mod_evasive triggers. I use ConfigServerFirewall (csf) on my server, so I added the following command which specifies a 1 hour firewall ban on the IP, which effectively drops all of its traffic to the server:

But wait a second! Apache doesn’t have access to the firewall normally. This is my one reservation about this proceedure. You need to give Apache access to the firewall programs (as root) via sudo so that it can execute this firewall block. This has other security implications, especially if you are on a multitenant server. We use visudo to do this.

Add the following to the file:

Where apache is the apache user (typically web, www, apache or httpd – this depends on the system) and the FIREWALL binaries are the ones used in the csf script.

Now my system watches for 3 or more connections to the same page in 3 seconds and not only serves a forbidden response to them but will drop their traffic completely via iptables. Within about 30 seconds my server load was back to normal, serving connections faithfully just like any other time.

This module worked great in my situation, but DDoS attacks come in many flavors and sizes. You may have luck with the mod_qos Apache module, where you can fine tune connections to certain pages. If an attack is bad enough, it is possible you will need to move to a hardware based solution because you can only do so much at the server level. A hardware firewall mixed with load balancers, caches like varnish, and other tricks can help to mitigate these DoS attacks.