==================================================== countertrace, a traceroute faker http://michael.toren.net/code/countertrace/ (c) Copyright 2002 Michael C. Toren ==================================================== Released under the terms of the GNU General Public License, version 2. Alternate licensing may be available if you have a specific need; please send mail to mct@toren.net with details describing you unique situation. Updates are available from About ----- countertrace 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 module, available from , 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
[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. Other things you should be aware of, and security concerns ------------------------------- Please keep in mind that this is just a toy -- I don't recommend using countertrace for anything mission critical, or for anything more involved than simple gag. The illusion that countertrace projects is just that, an illusion, and if someone is looking hard enough they stand a good chance of being able to see through it. It should also be noted that if countertrace is passed a packet with a large enough TTL such that it would be passed through without generating a bogus ICMP time-exceeded message, countertrace will accept the packet, even if there were additional iptables rules farther down the chain which would have resulted in a different action. Put simply, you could be introducing a security risk if the number of hops you tell countertrace to project and the maximum TTL of a packet you tell iptables to pass to countertrace differs. Ofcourse, if you're also interested in faking latency, you'll want all packets, even those with a large TTL, to pass through countertrace so that the latency will appear to be uniform for both traceroutes as well as data transfers. This means that simulating latency with countertrace and using iptables as a firewall solution is possibly incompatible, unless extreme care is taken when writing the chain. To be done safely, the iptables TTL match support should be used to pass packets to countertrace when the received TTL is less than or equal to the number of hops being simulated, to drop packets which normally would have been firewalled when the received TTL is larger than the number of hops being simulated, and passing any reamining packets to countertrace rather than permitting them directly. This complexity could be avoided if libipq provided a method of indicating that a packet should be returned to iptables for further processing rather than only allowing the userland program to either accept or drop the packet, but unfortunately that feature doesn't appear to exist. Perhaps one day. Porting to BSD operating systems -------------------------------- While the current version of countertrace requires a Linux kernel, it would not be difficult to port it to a BSD operating system using divert sockets rather than libipq to process packets in userspace. I'll gladly accept a patch which uses either divert sockets or libipq, depending upon which is available. Paying homage to earlier works ------------------------------ The idea behind countertrace isn't original, and other programs to fake traceroutes have existed for some time. However as far as I know, all of them work by listening for connections on a large number of high UDP ports, which only works if the traceroute is performed using a traditional unix implementation, and fails when the traceroute implementation instead sends probes using ICMP echo-request or TCP packets, or even UDP packets with a low destination port. By utilizing iptables to match all IP packets with a low TTL, countertrace is able to maintain the illusion no matter what IP protocol the traceroute implementation is using.