diff options
author | Robert E. Lee <robert_at_loveathome.us> | 2013-01-05 22:53:31 +0100 |
---|---|---|
committer | dsomero <xgizzmo@slackbuilds.org> | 2013-01-09 18:52:22 -0500 |
commit | 07f99225a7b0b0d0184e3ecb1a65ee8abb76e33c (patch) | |
tree | f0f7a9d8fb3a55ace577696673b51a300f554b26 | |
parent | fc4b2788286ad4eec15f0067e14742cd0a9c346a (diff) | |
download | slackbuilds-07f99225a7b0b0d0184e3ecb1a65ee8abb76e33c.tar.gz |
network/sockstress: Added (tcp socket stress).
Signed-off-by: Matteo Bernardini <ponce@slackbuilds.org>
-rw-r--r-- | network/sockstress/README | 6 | ||||
-rw-r--r-- | network/sockstress/README-NEW | 261 | ||||
-rw-r--r-- | network/sockstress/slack-desc | 19 | ||||
-rw-r--r-- | network/sockstress/sockstress.SlackBuild | 103 | ||||
-rw-r--r-- | network/sockstress/sockstress.info | 10 |
5 files changed, 399 insertions, 0 deletions
diff --git a/network/sockstress/README b/network/sockstress/README new file mode 100644 index 0000000000..6907fcc507 --- /dev/null +++ b/network/sockstress/README @@ -0,0 +1,6 @@ +sockstress is a collection of TCP socket stress methods +that attempt to deplete limited kernel resources. + +After installation, the source code is placed in +/usr/src/sockstress-0.0.1 +You can modify payloads there. diff --git a/network/sockstress/README-NEW b/network/sockstress/README-NEW new file mode 100644 index 0000000000..5211db5fe5 --- /dev/null +++ b/network/sockstress/README-NEW @@ -0,0 +1,261 @@ +=-=-=-=-=-= + +Sockstress is a user-land TCP socket stress framework that can +complete arbitrary numbers of open sockets without incurring the +typical overhead of tracking state. Once the socket is established, +it is capable of sending TCP attacks that target specific types of +kernel and system resources such as Counters, Timers, and Memory +Pools. Obviously, some of the attacks described here are considered +"well known". However, the full effects of these attacks is less +known. Further, there are more attacks yet to be +discovered/documented. As researchers document ways of depleting +specific resources, attack modules could be added into the sockstress +framework. + +The sockstress attack tool consists of two main parts: + +1) Fantaip: Fantaip is a "Phantom IP" program that performs ARP for +IP addresses. Fantaip is provided by the unicornscan package. +To use fantaip, type 'fantaip -i interface CIDR', +Ex., 'fantaip -i eth0 192.168.0.128/25'. +This ARP/Layer 2 function could optionally be provided by other means +depending on the requirements of the local network topology. Since +sockstress completes TCP sockets in user-land, it is not advisable +to use sockstress with an IP address configured for use by the kernel, +as the kernel would then RST the sockets. Fantaip is not strictly +required as the use of a firewall to drop incoming packets with rst +flag can be used to achieve the same goal and prevent the kernel from +interfering with the attack vector. However, you may end up DoSing +yourself using the local firewall method. + +2) Sockstress: In its most basic use, sockstress simply opens TCP +sockets and sends a specified TCP stress test. It can optionally send +an application specific TCP payload (i.e. 'GET / HTTP/1.0' request). +By default, post attack it ignores subsequent communications on the +established socket. It can optionally ACK probes for active sockets. +The attacks take advantage of the exposed resources the target makes +available post handshake. + +The client side cookies, heavily discussed in blogs, news and +discussion lists, is an implementation detail of sockstress, and not +strictly necessary for carrying out these attacks. + +=-=-=-=-=-= + +The attack scenarios + +Every attack in the sockstress framework has some impact on the +system/service it is attacking. However, some attacks are more +effective than others against a specific system/service combination. + +=-=-=-=-=-= + +Connection flood stress +Sockstress does not have a special attack module for performing a +simple connection flood attack, but any of the attack modules can be +used as such if the -c-1 (max connections unlimited) and -m-1 +(max syn unlimited) options are used. This would approximate the +naptha attack by performing a connection flood, exhausting all +available TCB's as described in the CPNI document in section 3.1.1 + +Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Zero window connection stress +Create a connection to a listening socket and upon 3 way handshake +(inside last ack) send 0 window. + + syn -> (4k window) + <- syn+ack (32k window) + ack -> (0 window) + +Now the server will have to "probe" the client until the zero window +opens up. This is the most simple of the attack types to understand. +The result is similar to a connection flood, except that the sockets +remain open potentially indefinitely (when -A/ACK is enabled). This +is described in the CPNI document in section 2.2. A variation here +would be to PSH a client payload (i.e. 'GET / HTTP/1.0') prior to +setting the window to 0. This variation would be similar to what is +described in the CPNI document section 5.1.1. A further variation +would be to occasionally advertise a TCP window larger than 0, then +go back to 0-window. + +Good against: + +services that have long timeouts Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mz -p22,80 -r300 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Small window stress +Create a connection to a listening socket and upon 3 way handshake +(inside last ack) set window size of 4 bytes, then create an ack/psh +packet with a tcp payload (into a window that is hopefully large +enough to accept it) with a window still set to 4 bytes. This will +potentially cause kernel memory to be consumed as it takes the +response and splits it into tiny 4 byte chunks. This is unlike a +connection flood in that memory is now consumed for every request +made. This has reliably put Linux/Apache and Linux/sendmail systems +into defunct states. It is also effective against other systems. +We expect this has similar effects to what is described in the CPNI +document in the second to last paragraph of page 17. + +Look at the payload.c file in the sockstress source. Look for the +hport switch statement. In that section you can specify payloads to +be sent to specific ports. It is most effective to send a payload +that will generate as large of a response as possible +(i.e. 'GET /largefile.zip'). + +Good against: + +services that contain initial connection banners services that accept +an initial request and send a large response (for example a GET +request against a large web page, or file download) Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -Mw -p22,80 -r300 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Segment hole stress +Create a connection to a listening socket and upon 3 way handshake +(inside last ack) send 4 bytes to the beginning of a window, as +advertised by the remote system. Then send 4 bytes to end of window. +Then 0-window the connection. Depending on the stack, this could cause +the remote system to allocate multiple pages of kernel memory per +connection. This is unlike a connection flood in that memory is now +consumed for every connection made. This attack was originally created +to target Linux. It is also quite effective against windows. This is +the attack we used in our sec-t and T2 demos. We expect this has +similar effects to what is described in the CPNI document in section +5.2.2 5th paragraph and section 5.3. + +Good against: + +Stacks that allocate multiple pages of kernel memory in response to +this stimulus Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -Ms -p22,80 -r300 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Req fin pause stress +Create a connection to a listening socket. PSH an application payload +(i.e. 'GET / HTTP/1.0'). FIN the connection and 0-window it. This +attack will have very different results depending on the +stack/application you are targeting. Using this against a Cisco 1700 +(IOS) web server, we observed sockets left in FIN_WAIT_1 indefinitely. +After enough of such sockets, the router could no longer communicate +TCP correctly. + +Look at the payload.c file in the sockstress source. Look for the +hport switch statement. In that section you can specify payloads to be +sent to specific ports. It is important that you send a payload that +will look like a normal client to the application you are interacting +with. Against our cisco 1700, while using this attack it was important +to attack at a very slow rate. + +Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -MS -p80 -r10 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Activate reno pressure stress +Create a connection to a listening socket. PSH an application payload +(i.e. 'GET / HTTP/1.0'). Triple duplicate ACK. + +Look at the payload.c file in the sockstress source. Look for the +hport switch statement. In that section you can specify payloads to +be sent to specific ports. It is important that you send a payload +that will look like a normal client to the application you are +interacting with. + +Good against: + +Stacks that support this method of activating reno or similar +scheduler functionality Example commands: + + fantaip -i eth0 192.168.1.128/25 -vvv + sockstress -A -c-1 -d 192.168.1.100 -m-1 -MR -p22,80 -r300 \ + -s192.168.1.128/25 -vv + +=-=-=-=-=-= + +Other Ideas + + fin_wait_2 stress + Create a connection to a listening socket. + PSH an application payload that will likely cause the + application on the other side to close the socket (Target + sends a FIN). ACK the FIN. Good against: Stacks that don't + have a FIN_WAIT_2 timeout. large congestion window stress + shrink path mtu stress + md5 stress + +Effects of the attacks + +If the attacks are successful in initiating perpetually stalled +connections, the connection table of the server can quickly be filled, +effectively creating a denial of service condition for a specific +service. In many cases we have also seen the attacks consume +significant amounts of event queues and system memory, which +intensifies the effects of the attacks. The result of which has been +systems that no longer have event timers for TCP communication, frozen +systems, and system reboots. +The attacks do not require significant bandwidth. + +While it is trivial to get a single service to become unavailable in +a matter of seconds, to make an entire system become defunct can take +many minutes, and in some cases hours. As a general rule, the more +services a system has, the faster it will succumb to the devastating +(broken TCP, system lock, reboot, etc.) effects of the attacks. +Alternatively, attack amplification can be achieved by attacking from +a larger number of IP addresses. We typically attack from a /29 +through a /25 in our labs. Attacking from a /32 is typically less +effective at causing the system wide faults. +Exploitation caveats + +The attack requires a successful TCP 3 way handshake to effectively +fill the victims connection tables. This limits the attack's +effectiveness as an attacker cannot spoof the client IP address to +avoid traceability. + +A sockstress style exploit also needs access to raw sockets on the +attacking machine because the packets must be handled in userspace +rather than with the OS's connect() API. Raw sockets are disabled +on Windows XP SP2 and above, but device drivers are readily available +to put this facility back into Windows. The exploit is able to be +executed as-is on other platforms with raw sockets such as *nix and +requires root (superuser) privileges. + +=-=-=-=-=-= + +Mitigation + +Since an attacker must be able to establish TCP sockets to affect the +target, white-listing access to TCP services on critical systems and +routers is the currently most effective means for mitigation. +Using IPsec is also an effective mitigation. + +According to the Cisco Response the current mitigation advice is to +only allow trusted sources to access TCP-based services. +This mitigation is particularly important for critical infrastructure +devices. Red Hat has stated that "Due to upstream's decision not to +release updates, Red Hat do not plan to release updates to resolve +these issues; however, the effects of these attacks can be reduced." +On Linux using iptables with connection tracking and rate limiting +can limit the impact of exploitation significantly. diff --git a/network/sockstress/slack-desc b/network/sockstress/slack-desc new file mode 100644 index 0000000000..df47847f01 --- /dev/null +++ b/network/sockstress/slack-desc @@ -0,0 +1,19 @@ +# HOW TO EDIT THIS FILE: +# The "handy ruler" below makes it easier to edit a package description. +# Line up the first '|' above the ':' following the base package name, and +# the '|' on the right side marks the last column you can put a character in. +# You must make exactly 11 lines for the formatting to be correct. It's also +# customary to leave one space after the ':' except on otherwise blank lines. + + |-----handy-ruler------------------------------------------------------| +sockstress: sockstress (tcp socket stress) +sockstress: +sockstress: sockstress is a collection of TCP socket stress methods +sockstress: that attempt to deplete limited kernel resources. +sockstress: +sockstress: http://en.wikipedia.org/wiki/Sockstress +sockstress: +sockstress: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4609 +sockstress: +sockstress: +sockstress: diff --git a/network/sockstress/sockstress.SlackBuild b/network/sockstress/sockstress.SlackBuild new file mode 100644 index 0000000000..027df9f8b7 --- /dev/null +++ b/network/sockstress/sockstress.SlackBuild @@ -0,0 +1,103 @@ +#!/bin/sh + +# Slackware build script for sockstress +# Happy Birthday Jack! :) + +# Copyright Jan 5, 2013 Robert E. Lee, USA +# All rights reserved. +# +# Redistribution and use of this script, with or without modification, is +# permitted provided that the following conditions are met: +# +# 1. Redistributions of this script must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# +# THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED +# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO +# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; +# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF +# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +PRGNAM=sockstress +VERSION=${VERSION:-0.0.1} +BUILD=${BUILD:-1} +TAG=${TAG:-_SBo} + +if [ -z "$ARCH" ]; then + case "$( uname -m )" in + i?86) ARCH=i486 ;; + arm*) ARCH=arm ;; + *) ARCH=$( uname -m ) ;; + esac +fi + +CWD=$(pwd) +TMP=${TMP:-/tmp/SBo} +PKG=$TMP/package-$PRGNAM +OUTPUT=${OUTPUT:-/tmp} + +if [ "$ARCH" = "i486" ]; then + SLKCFLAGS="-O2 -march=i486 -mtune=i686" + LIBDIRSUFFIX="" +elif [ "$ARCH" = "i686" ]; then + SLKCFLAGS="-O2 -march=i686 -mtune=i686" + LIBDIRSUFFIX="" +elif [ "$ARCH" = "x86_64" ]; then + SLKCFLAGS="-O2 -fPIC" + LIBDIRSUFFIX="64" +else + SLKCFLAGS="-O2" + LIBDIRSUFFIX="" +fi + +set -e + +rm -rf $PKG +mkdir -p $TMP $PKG $OUTPUT +cd $TMP +rm -rf $PRGNAM-$VERSION ._${PRGNAM} +tar xvf $CWD/$PRGNAM.tar.gz +mv $PRGNAM $PRGNAM-$VERSION +cd $PRGNAM-$VERSION +rm -fr ._* */._* */*/._* +chown -R root:root . +find . \ + \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \ + -exec chmod 755 {} \; -o \ + \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \ + -exec chmod 644 {} \; + +CFLAGS="$SLKCFLAGS" \ +CXXFLAGS="$SLKCFLAGS" \ +./configure \ + CFLAGS=-D_GNU_SOURCE \ + --prefix=/usr \ + --libdir=/usr/lib${LIBDIRSUFFIX} \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --mandir=/usr/man \ + --docdir=/usr/doc/$PRGNAM-$VERSION \ + --build=$ARCH-slackware-linux + +make +mkdir -p $PKG/usr/bin +ln -s /usr/src/$PRGNAM-$VERSION/sockstress $PKG/usr/bin/sockstress + +mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION $PKG/usr/src/$PRGNAM-$VERSION +cp -a * $PKG/usr/src/$PRGNAM-$VERSION/ +( cd $PKG/usr/src/$PRGNAM-$VERSION + mv IOS_NOTES NOTES README doc/* wiki $PKG/usr/doc/$PRGNAM-$VERSION ) +rm -fr $PKG/usr/src/$PRGNAM-$VERSION/doc +cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild +cat $CWD/README-NEW > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.README-NEW + +mkdir -p $PKG/install +cat $CWD/slack-desc > $PKG/install/slack-desc + +cd $PKG +/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz} diff --git a/network/sockstress/sockstress.info b/network/sockstress/sockstress.info new file mode 100644 index 0000000000..21b95ce174 --- /dev/null +++ b/network/sockstress/sockstress.info @@ -0,0 +1,10 @@ +PRGNAM="sockstress" +VERSION="0.0.1" +HOMEPAGE="http://en.wikipedia.org/wiki/Sockstress" +DOWNLOAD="http://downloads.sourceforge.net/osace/sockstress.tar.gz" +MD5SUM="292ad9f40a472883b34e4dbefe5f6c35" +DOWNLOAD_x86_64="" +MD5SUM_x86_64="" +REQUIRES="unicornscan" +MAINTAINER="Robert E. Lee" +EMAIL="robert_at_loveathome.us" |