From 2c2527bdc4037e63563247477ef836a8477fb934 Mon Sep 17 00:00:00 2001 From: Jan Engelhardt Date: Wed, 9 Apr 2008 20:34:57 +0200 Subject: [PATCH] manpages: remove diff markers from CHAOS,TARIPT --- extensions/libxt_CHAOS.man | 36 ++++++++++---------- extensions/libxt_TARPIT.man | 66 ++++++++++++++++++------------------- 2 files changed, 51 insertions(+), 51 deletions(-) diff --git a/extensions/libxt_CHAOS.man b/extensions/libxt_CHAOS.man index 8e24482..302e69f 100644 --- a/extensions/libxt_CHAOS.man +++ b/extensions/libxt_CHAOS.man @@ -1,18 +1,18 @@ -+Causes confusion on the other end by doing odd things with incoming packets. -+CHAOS will randomly reply (or not) with one of its configurable subtargets: -+.TP -+\fB--delude\fR -+Use the REJECT and DELUDE targets as a base to do a sudden or deferred -+connection reset, fooling some network scanners to return non-deterministic -+(randomly open/closed) results, and in case it is deemed open, it is actually -+closed/filtered. -+.TP -+\fB--tarpit\fR -+Use the REJECT and TARPIT target as a base to hold the connection until it -+times out. This consumes conntrack entries when connection tracking is loaded -+(which usually is on most machines), and routers inbetween you and the Internet -+may fail to do their connection tracking if they have to handle more -+connections than they can. -+.PP -+The randomness factor of not replying vs. replying can be set during load-time -+of the xt_CHAOS module or during runtime in /sys/modules/xt_CHAOS/parameters. +Causes confusion on the other end by doing odd things with incoming packets. +CHAOS will randomly reply (or not) with one of its configurable subtargets: +.TP +\fB--delude\fP +Use the REJECT and DELUDE targets as a base to do a sudden or deferred +connection reset, fooling some network scanners to return non-deterministic +(randomly open/closed) results, and in case it is deemed open, it is actually +closed/filtered. +.TP +\fB--tarpit\fP +Use the REJECT and TARPIT target as a base to hold the connection until it +times out. This consumes conntrack entries when connection tracking is loaded +(which usually is on most machines), and routers inbetween you and the Internet +may fail to do their connection tracking if they have to handle more +connections than they can. +.PP +The randomness factor of not replying vs. replying can be set during load-time +of the xt_CHAOS module or during runtime in /sys/modules/xt_CHAOS/parameters. diff --git a/extensions/libxt_TARPIT.man b/extensions/libxt_TARPIT.man index 77b6c6e..a5cc727 100644 --- a/extensions/libxt_TARPIT.man +++ b/extensions/libxt_TARPIT.man @@ -1,33 +1,33 @@ -+Captures and holds incoming TCP connections using no local per-connection -+resources. Connections are accepted, but immediately switched to the persist -+state (0 byte window), in which the remote side stops sending data and asks to -+continue every 60-240 seconds. Attempts to close the connection are ignored, -+forcing the remote side to time out the connection in 12-24 minutes. -+ -+This offers similar functionality to LaBrea -+ but does not require dedicated hardware or -+IPs. Any TCP port that you would normally DROP or REJECT can instead become a -+tarpit. -+ -+To tarpit connections to TCP port 80 destined for the current machine: -+.IP -+-A INPUT -p tcp -m tcp --dport 80 -j TARPIT -+.P -+To significantly slow down Code Red/Nimda-style scans of unused address space, -+forward unused ip addresses to a Linux box not acting as a router (e.g. "ip -+route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding on -+the Linux box, and add: -+.IP -+-A FORWARD -p tcp -j TARPIT -+.IP -+-A FORWARD -j DROP -+.TP -+NOTE: -+If you use the conntrack module while you are using TARPIT, you should also use -+the NOTRACK target, or the kernel will unnecessarily allocate resources for -+each TARPITted connection. To TARPIT incoming connections to the standard IRC -+port while using conntrack, you could: -+.IP -+-t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK -+.IP -+-A INPUT -p tcp --dport 6667 -j TARPIT +Captures and holds incoming TCP connections using no local per-connection +resources. Connections are accepted, but immediately switched to the persist +state (0 byte window), in which the remote side stops sending data and asks to +continue every 60-240 seconds. Attempts to close the connection are ignored, +forcing the remote side to time out the connection in 12-24 minutes. + +This offers similar functionality to LaBrea + but does not require dedicated hardware or +IPs. Any TCP port that you would normally DROP or REJECT can instead become a +tarpit. + +To tarpit connections to TCP port 80 destined for the current machine: +.IP +-A INPUT -p tcp -m tcp --dport 80 -j TARPIT +.P +To significantly slow down Code Red/Nimda-style scans of unused address space, +forward unused ip addresses to a Linux box not acting as a router (e.g. "ip +route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding on +the Linux box, and add: +.IP +-A FORWARD -p tcp -j TARPIT +.IP +-A FORWARD -j DROP +.TP +NOTE: +If you use the conntrack module while you are using TARPIT, you should also use +the NOTRACK target, or the kernel will unnecessarily allocate resources for +each TARPITted connection. To TARPIT incoming connections to the standard IRC +port while using conntrack, you could: +.IP +-t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK +.IP +-A INPUT -p tcp --dport 6667 -j TARPIT