# FTester sample configuration rules v1.0
#
# A - flags
# 
# Command line flags can be overrided with the 'flags:' directive at any point 
# and any time, original flags can be restored with 'flags: restore'. See the 
# man page or `ftest -h` for available flags.
#
# examples:
#
flags: -d 0.01 -s 1 
flags: -e ttl1 -p 4
flags: restore
#
# 1 - basic form
#
# Source Address:Source Port:Destination Address:Destination Port:Flags:Protocol:Type of Service
# Source Address:Source Port:Destination Address:Destination Port:Flags:ICMP:icmp_type:icmp_code
#
# Destination Address must be the host where ftestd is sniffing (in this case 
# 10.7.0.1) or one which traffic can be sniffed.
#
# src ip, src port and dst port can be specified in 'low-high' form.
# src ip can also be specified in CIDR notation.
# 
# examples:
#
192.168.22.3:1025:10.7.0.1:80:AS:TCP:0
192.168.22.3:1025:10.7.0.1:21:A:TCP:0
192.168.22.3:20:10.7.0.1:1025:AP:TCP:10
192.168.22.3:20:10.7.0.1:1025:S:TCP:0
192.168.22.3:20:10.7.0.1:1022:AP:TCP:22
192.168.22.3:20:10.7.0.1:1022:S:TCP:0
192.168.22.3:666:10.7.0.1:443:U:TCP:0
192.168.22.3:53:10.7.0.1:53::UDP:0
192.168.22.3::10.7.0.1:::ICMP:3:5
192.168.0.1-255:1024:10.7.0.1:22:S:TCP:0
192.168.0.1:1-1024:10.7.0.1:20-25:S:TCP:22
192.168.0.23:666:10.7.0.1:1-65535:A:TCP:0
192.168.3.0/24:1024:10.7.0.1:22:S:TCP:0
192.168.3.128/25:1-1024:10.7.0.1:20-25:S:TCP:22
192.168.0.0/22:666:10.7.0.1:1-65535:A:TCP:0
#
# 2 - connection spoofing (use with ftest -s and ftestd -c flags)
#
# ftest and ftestd are capable of simulating a real connection, this is extremly useful
# when you are dealing with a stateful detection firewall (like netfilter) that blocks 
# packets unrelated to an ongoing connection. In such cases packets like 
#
# 192.168.22.3:1025:10.7.0.1:80:AS:TCP:0 
#
# are likely to be blocked by the firewall if their sequence numbers and flags aren't 
# syncronised with a previously started connection. In order to circumvent this problem 
# if the packets are specified with the 'connect=' prefix ftest and ftestd will act in 
# this way:
#
# a) ftest will send 192.168.22.3:1025:10.7.0.1:80:S:TCP:0 with a custom payload and 
#    sequence number set to $random, the payload size is 8 byte. Then it sleeps for a 
#    custom time waiting for the firewall to see the packet specified in b).
#
# b) ftestd will recognize this packet and will send 10.7.0.1:80:192.168.22.3:1025 with
#    sequence number $random+1024 and acknowledge number ($random+payload_size+1).
#
# c) ftest, after the sleep period, will complete the connection handshake sending
#    192.168.22.3:1025:10.7.0.1:80:A:TCP:0 with sequence number $random+payload_size+1 and 
#    acknowledge number $random+1024+1
#
# d) ftest will finally send the specified packet with sequence number $random+payload+size+1 
#    and acknowledge number $random+1024+1
#
# e) ftestd acknowledge packet d)
#
# now there is one great problem with this approach, the stack of the destination host will
# reply to the packet sent in a) and the spoofed host will reply to it resetting the connection.
# So we have to do two things, hiding the stack response to the spoofed host and to the firewall
# and make sure that ftestd reply will traverse the firewall by not reaching the spoofed host.
# Hiding the stack response could be done by setting a very low default TTL in
# /proc/sys/net/ipv4/ip_default_ttl (Linux only). Hiding to the spoofed host our reply ( b) ) is 
# done by setting its TTL to a low value equal to the hop delay between ftestd and the firewall. 
# For example use ./ftestd -c 0:3 for temporarly setting default stack ttl to 0 and ftestd reply 
# ttl to 3, the ip_default_ttl will be restored when a stop_signal is received.
#
# WARNING: if you interrupt ftestd execution and a stop_signal is not sniffed your default ttl will
# remain low! Manually restore the default value with 'echo 64 > /proc/sys/net/ipv4/ip_default_ttl'. 
#
# NOTE: you can avoid this ttl mess by firewalling the input chain of the host or using a 
# unallocated IP address published with a spoofed arp response. 
#
# Remember to specify different sport-dport pairs if you use this mode again with the same 
# saddr-daddr and you're not using the -r/-F flag.
#
# Packets a),b),c),e) are NOT logged.
#
connect=192.168.0.1:1025:10.7.0.1:22:AP:TCP:0
connect=192.168.0.1-255:1025-2000:10.7.0.1:53:AP:TCP:0
connect=192.168.0.0/24:1025:10.7.0.1:1-1024:AP:TCP:0
#
# 3 - stop signal 
#
# Terminate ftestd and close the log file, obviously only if the packet will pass the firewall.
#
stop_signal=192.168.0.1:666:10.7.0.1:666:S:TCP:0
#
# 4 - IDS testing
#
# ftest has an additional syntax, useful for test Intrusion Detection System, that permits the 
# definition of the payload. The support of ftestd is not necessary in this mode since mainly 
# you have to check your IDS logs, however there is an "ids-conn" option that works just like 
# the "connect" option, useful if your IDS is performing stateful inspection. 
#
# See also the evasion techniques command-line options (look man page for details). 
#
ids=192.168.0.1:1025:10.7.0.1:25:S:TCP:0:VRFY
ids=192.168.0.1::10.7.0.1:::ICMP:8:0:+++ath
ids-conn=192.168.0.1:23:10.7.0.1:1025:PA:TCP:0:to su root
ids-conn=192.168.0.1:1025:10.7.0.1:80:PA:TCP:0:cmd.exe
ids-conn=192.168.0.1:1026:10.7.0.1:80:PA:TCP:0:ftp.exe
#
# In addition you can use the following syntax to directly use a snort (www.snort.org) rule 
# definition file. The "insert-conn" option make ftest work as in the "connection spoofing" 
# mode for packets with flags different than SYN. Source, destination IP and ToS must be specified. 
#
# The following keywords are currently supported:
# 
# content - flags - offset - dsize
#
# source and destination port are randomly selected if specified as 'any', in the case that a 
# sport-dport pair is incidentally repeated connection spoofing mode wont work unless you're using 
# the -r/-F flag.
#
insert exploit.rules 192.168.0.1 10.7.0.1 0
insert-conn exploit.rules 192.168.0.1 10.7.0.1 0