Lab Testing - Slow and Low DDoS Attack using Switchblade4

A typical Disributed Denial-of-Service (DDoS) attack requires the direct control of a massive amount resources (usually bot-infected machines of unsuspecting victims) in order to create resource exhaustion issues on a victim machine by initiating a large number of connection or file upload/download requests to that machine from all of the hosts.

When referring to a DoS attack using a single machine and the desired end result being the same there is a more stealth-like tactic utilizing a "low-and-slow" or "slow-rate" method.  This method is preferred over other approaches such as a SYN-Flood because it requires EXTREMELY LITTLE RESOURCES from the host.

The DDoS approach described above is analogous to a teacher being asked a unique question by a million students simultaneously.  The teacher would not able to answer all of those questions or any new student questions that came in.

The DOS approach is analogous to a person being told that a single person will ask them a hundred questions and the answers will have to wait until all questions are asked.  The catch being that each question is being asked slooooooowly.  Again, the teacher would be tied up waiting for the questions to finish so the answers can be given so no new students will be able their questions asked until all one hundred are asked and answered.

A low and slow tool that's come out recently and I've been wanting to try out on my lab servers is Switchblade4.  I finally have some free time to check it out and found within just minutes that it does what it says it does.  It took down both my windows 2008 server running IIS as well as my CentOS 6.5 server running apache.  Next I'll be researching and implementing mitigating controls to monitor and protect the servers.

The Beauty of Simplicity - Arch Linux | ARM

After years of working with Red Hat/CentOS, Ubuntu/Debian and BSD I've found myself in a situation that warranted a different type of Linux - one built for the "ARM hobbyist".  As CPU and Memory increase exponentially (Moore's Law), Operating System minimum requirements (especially Linux) stay relatively small in comparison leaving us with smaller and smaller form factor computing devices, such as the Cubox-i and Raspberry Pi, with which we can run full-featured Operating Systems and applications on with little to no lag.

The requirement began a few months back with a packet generator and tester that could be deployed easily by technicians in the field.  It would be lightweight and low cost ($99, 2oz, 2"x2" cube) but we had one problem...there would be no monitor/keyboard/mouse to determine 1) if the local device actually could see the far-end IP/Device, 2) if the test started or hung/died and 3) when the test ended and what the results of the test were.  We solved the results question by writing the results to a micro-USB (small form-factor) plug.  The other 3 would involve coming up with some sort of visual cue for the tech.  We found a System-on-Chip LED next to the RF receiver on the little box.  Problem was Ubuntu could not access it.  Only ARM could!

Once we figured out how to get the ARM built on top of the micro-SD card in the Cubox we were up and running and found the folder/file that controlled the LED.  Created a bash script containing a do-loop and sleep commands in between turning the LED on and off and wallah...we had morse-code-like capabilities!  We could signal information to the techs now.  Arch is similar to other Linux ditros but I like the simplicity and minimal environment in which to build what you want and need.  More to come!