I've started working on a private project which is on par with the type of programming I like to do. The basic premise is that the program acts as a man in the middle, routing traffic between client and server, occasionally altering or injecting data into the stream each way.
PyLoris is a scriptable tool for testing a service's level of vulnerability to a particular class of Denial of Service (DoS) attack. Any service that places restrictions on the total number of simultaneous TCP connections has the potential for vulnerability to PyLoris. Additionally, services that handle connections in independent threads, services that poorly manage concurrent connections, and services that have high memory footprint per connection are prone to this form of vulnerability.
I came across a wonderful idea on Hack a Day recently: a Denial of Service attack that overwhelms only the service under attack. After reading through RSnake's two writeups, I decided to take a swing at the code. Thus PyLoris was born.
Do you ever find yourself in a protocol sniffing situation where you wish you had the ability to sneak a peak at a TCP stream as it happens? Do you find Wireshark--while certainly a powerful and robust tool--too clunky for quick protocol analysis? Do you have a need to intercept, pause, modify, and resend TCP streams? If so, the folks from Matasano have released the perfect tool for you!
Introducing the Matasano Port Forwarding Interceptor! Simply run the tool from a command line and it builds you a lightweight proxy, allowing you to read, record, pause, intercept, and modify a TCP conversation mid-stream. The tool is simple to use; you picking your remote and local addresses and ports, the tool will bring up two windows--one for viewing and halting traffic, one for editing local and remote traffic. The tool is really simple to use, easy to understand, and it gets the job done.
You can read the full introduction to the tool from Matasano's website: http://www.matasano.com/log/1693/matasano-pfi-as-seen-on-tv/
I recently discovered a post on Hack a Day linking to a proof of concept how-to on setting up a software RAID on FTP servers. While the guide is a simple approach to running a network based RAID 5 configuration, a number of tools the original developer used are less than optimal. First, the set up requires both Windows and Linux, meaning you will either need two physical machines, or a virtualized machine in your configuration. The second, and larger problem is that it is restricted to RAID 5 and FTP servers. This article is my attempt to alleviate both of these issues.
All too often, while running the PHP forum on The Scripts, I see students working who are completely ignorant of the security concerns prevalent with the systems that they build. Worse, when alerted to the potential dangers associated with poor programming practices, these coders let loose a variety of excuses why their application doesn't need to implement a security policy. Ranging from "this is a low traffic/internal site" to "I'm doing this as a project for school, so security really isn't an issue." In my eyes all explanations are equally irrelevant. As leaders of the forums, my colleagues and I daily battle assertions about the validity of these concerns.
As my knowledge of Python continues to grow, I find myself using it more in my own systems. This is one of my more useful snippets of code; it allows a Python script to continue running as a daemon even if you log out or your session gets disconnected. A nice side effect of this is that the process is immediately run in the background, returning the user to a command prompt instantly.
I originally picked up the code to run a Python script as a daemon from the Python Cookbook on the ActiveState Programmer Network.
I took the plunge and, at the risk of bricking my Verdex, updated u-boot. I can only begin to describe the improvements! The process was not nearly as perilous as I anticipated (though I did hold my breath when I rebooted the first time). Noteworthy improvements are the ability to load the kernel directly into the U-Boot environment, and the inclusion of ymodem file transfers over the serial line. The former reduces my boot time to a breathtaking 23 seconds, while the latter reduces rootfs flash time via serial connection by more than half!