network/sockstress: Added (tcp socket stress).

Signed-off-by: Matteo Bernardini <ponce@slackbuilds.org>

1 files changed, 261 insertions, 0 deletions

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.