countertrace 1.0 review
Downloadcountertrace project is a userland, iptables QUEUE target handler for Linux 2.4 kernels running Netfilter, which attempts to give the
|
|
countertrace project is a userland, iptables QUEUE target handler for Linux 2.4 kernels running Netfilter, which attempts to give the illusion that there are multiple, imaginary IP hops between itself and the rest of the world.
The imaginary hops that countertrace projects also have the ability to introduce accumulative, imaginary latency.
How it works:
Netfilter provides a mechanism for passing packets for processing to a userland program, which can examine the packet and determine if it should be permitted through or dropped on the floor. countertrace utilizes this mechanism to drop received packets which have a TTL less than the number of hops it's attempting to project, and then generates ICMP time-exceeded messages for those dropped packets with the source address of the bogus hop. If latency is also being simulated, the generated time-exceeded messages are queued for the specified period of time before being sent.
Requirements:
countertrace requires the NetPacket, Time::HiRes, and IPTables::IPv4::IPQueue perl modules, available from CPAN, the Net::RawSock and a Linux 2.4 kernel with iptables (CONFIG_IP_NF_IPTABLES) and QUEUE target (CONFIG_IP_NF_QUEUE) support. If latency is not being simulated, iptables TTL match support (CONFIG_IP_NF_MATCH_TTL) may also be useful.
Configuration:
The countertrace program takes only one command line argument, the name of it's configuration file. To get started, the only configuration file command you need to know about is the "hop" command, which takes the form of "hop < address > [latency]". Hops must be added in the order in which they are to be simulated. Latency is accumulative -- at run time, the latency for each hop is determined by calculating the sum of all previously specified latency values. Additional configuration commands are available for specifying how much information is logged for each received packet; see the example-hops-configuration file for more information.
In addition to configuring countertrace itself, iptables must also be configured to pass packets to countertrace for processing using the iptables QUEUE target. If latency is not being simulated, the iptables TTL match support can be used to only pass packets to countertrace which have a TTL less than or equal to the number of hops being simulated. Otherwise, more than likely you'll want all received packets to pass through countertrace, so that the latency will appear to be uniform when tracerouting, in addition to when transferring data. However, the danger is that if the countertrace program dies for any reason, iptables will drop any packets which would have been queued for userland processing, rendering the box unreachable to the outside world. To avoid the problem, it may be wise to specify at least one "backdoor" address from which packets will be accepted without passing through countertrace.
For an example startup script, see the example-startup-script.sh file.
countertrace 1.0 keywords