ftester man page on Kali

Man page or keyword search:  
man Server   9211 pages
apropos Keyword Search (all sections)
Output format
Kali logo
[printable version]

FTester(8)							    FTester(8)

NAME
       FTester - Firewall and IDS testing tool

SYNOPSIS
       ftest  [	 -c sourceip:sourceport:destip:destport:flags:protocol:tos ] [
       -e evasion_method ] [ -d delay ] [ -f file ] [ -F ] [ -g fragments_num‐
       ber|fragments_size  ] [ -k cksum ] [ -p segments_number|segments_size ]
       [ -r ] [ -s time ] [ -t ttl ] [ -m marker ] [ -v ]

       ftestd [ -c ttl1:ttl2 ] [ -g ] [ -i interface ] [ -m marker ] [ -v ]

       freport ftest.log ftestd.log

DESCRIPTION
       FTester is a tool designed for testing firewalls filtering policies and
       Intrusion Detection System (IDS) capabilities.

       The  tool  consists  of two perl scripts, a packet injector (ftest) and
       the listening sniffer (ftestd).	The first script injects custom	 pack‐
       ets,  defined  in  ftest.conf , with a signature in the data part while
       the sniffer listens for such marked packets. The scripts both  write  a
       log file which is in the same form for both scripts. A 'diff -b' of the
       two produced files (ftest.log and ftestd.log) shows  the	 packets  that
       were  unable  to	 reach the sniffer due to filtering rules if these two
       scripts are ran on hosts placed on two different sides of  a  firewall.
       Stateful	 inspection  firewalls are handled with the 'connection spoof‐
       ing' option. A script called freport is also  available	for  automati‐
       cally parse the log files.

       Of  course this is not an automated process, ftest.conf must be crafted
       for every different situation. Examples and rules are included  in  the
       sample configuration file.

       The IDS (Intrusion Detection System) testing feature can be used either
       with ftest only or with the additional support of ftestd	 for  handling
       stateful	 inspection  IDS,  ftest can also use common IDS evasion tech‐
       niques. Instead of using the configuration syntax the script  can  also
       process snort rule definition file.

OPTIONS
   ftest:
       -c sourceip:sourceport:destip:destport:flags:protocol:tos
	      Injects a single packet (override -f option).

       -d delay (es. 0.25 = 250 ms)
	      Delay in milliseconds between each packet injection.

       -e evasion_method
	      See the IDS EVASION section.

       -f file
	      Read configuration from file.

       -F     When  in	connection spoofing mode terminate (FIN handshake) the
	      created connection, useful if you don't want to flood firewall's
	      connection  tracking  table  with	 established entries, requires
	      ftestd reply (see -s flag).

       -g fragments_number|fragments_size
	      Split TCP and UDP marked packets in the specified number	of  IP
	      fragments, useful for checking firewall's fragmentation handling
	      and IDS's fragmentation reassembly. In 'connection spoofing'  or
	      'evasion' mode only packets specified in configuration are frag‐
	      mented  and  not	connection  control  ones.  Obviously	'frag‐
	      ments_number' must be >= 2. If the specified number of fragments
	      is incompatible with payload length ftest will automatically set
	      the nearest right value.

	      Additionaly  you	can specify the fragments size in bytes if you
	      append the suffix 'b' to the value (es. -g 16b), fragments  size
	      must  be	a  multiple  of 8. If the specified fragment's size is
	      incompatible with payload lenght ftest  will  automatically  set
	      the nearest right value.

       -k checksum
	      Set  a  custom  checksum	instead	 of the right one when sending
	      packets, useful to detect if the firewall	 is  blocking  invalid
	      packets.

       -p segments_number|segments_size
	      Specify the number of TCP segments when splitting the tcp stream
	      in evasion mode, see IDS EVASION for details. If	the  specified
	      number  of  segments  is	incompatible with payload length ftest
	      will automatically set the nearest right value.

	      Additionaly you can specify the segments size in	bytes  if  you
	      append  the  suffix 'b' to the value (es. -p 16b). If the speci‐
	      fied segments's size is incompatible with payload	 lenght	 ftest
	      will automatically set the nearest right value.

	      If not specified ftest will use the default value of 2 segments.

       -r     When  in connection spoofing mode reset (RST packet) the created
	      connection, useful if you don't want to flood firewall's connec‐
	      tion  tracking  table  with established entries, requires ftestd
	      reply (see -s flag).

       -s time
	      Sleep time in seconds for waiting connection  spoofing  replies,
	      see 'connection spoofing' option.

       -t ttl Time  to	live  that  makes the ttl1/ttl2 evasion option packets
	      visible to the IDS but not to the target host.

       -m marker
	      Custom marker string that is appended to the standard  signature
	      in generated packets and logs' filenames. Using this option per‐
	      mits multiple instances of ftest/ftestd  to  run	simultaneously
	      without interfering with each other.

       -v     Prints to stdout injected packets and be verbose.

   ftestd:
       -c ttl1:ttl2
	      Define  TTL  settings  for the 'connection spoofing' option: set
	      default	 stack	  TTL	  executing	`echo	  "ttl1"     >
	      /proc/sys/net/ipv4/ip_default_ttl`  (Linux  only) and set ftestd
	      reply TTL to ttl2.

       -g     Enable fragments reassembly when sniffing packets, useful if you
	      are  using  ftest	 fragmentation option and your firewall is not
	      performing fragments reassembly.

       -i interface
	      Listen on interface, if not specified will default to the	 first
	      configured one (excluding loopback).

       -m marker
	      Custom  marker  string  that  is tested for in received packets.
	      Using this option permits multiple instances of ftest/ftestd  to
	      run simultaneously without interfering with each other.

       -v     Prints to stdout sniffed packets and be verbose.

CONFIGURATION FILE
       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

       The  main  configuration	 file defines which packets ftest will send to
       ftestd, the basic syntax is the following:

       Source	  Address:Source     Port:Destination	   Address:Destination
       Port:Flags:Protocol:Type of Service

       for TCP and UDP packets

       Source	   Address:Source     Port:Destination	   Address:Destination
       Port:Flags:ICMP:icmp_type:icmp_code

       for ICMP packets

       The Source Address can be specified as a single IP address, a range  of
       addresses, or a CIDR block.
       Source Port and Destination Port can also be specified in ranges.

       Valid Flags are A (ACK), F (FIN), P (PUSH), R (RST), S (SYN), U (URG).

       Destination  Address  must  be the host where ftestd is sniffing or one
       which traffic can be sniffed.

       Line beginning with a # are comments and ignored by ftest.

       Examples:
       192.168.22.3:1025:10.7.0.1:80:AP: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:53:10.7.0.1:53::UDP:0
       192.168.22.3:1025:10.7.0.1:80::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

       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  connec‐
       tion. In such cases packets like 192.168.22.3:1025:10.7.0.1:80:AP: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_1, 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_2+1024  and  acknowledge  number	($ran‐
       dom_1+payload_size+1).

	c)  ftest,  after the sleep period, will complete the connection hand‐
       shake sending
	   192.168.22.3:1025:10.7.0.1:80:A:TCP:0 with  sequence	 number	 $ran‐
       dom_1+payload_size+1 and
	   acknowledge number $random_2+1024+1

	d)  ftest  will finally send the specified packet with sequence number
       $random_1+payload+size+1 and
	   acknowledge number $random_2+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 real host
       we've spoofed 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 set‐
       ting  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.
       Use the -s flag for setting the sleep time duration.

       Packets a),b),c),e) are NOT logged.

       Examples:
       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

       The  stop  signal tells ftestd to close the log file and die, obviously
       you must ensure that this packet will reach the sniffer.

       Examples:
       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 IDS EVASION section.

       Examples:
       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
       (http://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 speci‐
       fied.

       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 won't work unless you're using the -r/-F flag.

       Examples:
       insert /etc/snort/exploit.rules 192.168.0.1 10.7.0.1 0
       insert-conn /etc/snort/exploit.rules 192.168.0.1 10.7.0.1 0

IDS EVASION
       A  number  of  IDS evasion techniques are implemented, you can activate
       them with the -e flag when using 'ids-conn'  and	 'insert-conn'	modes.
       TCP splitting can be controlled with the -p flag (see OPTIONS).

       -e stream

	      packet => [packet1(ATT) + packet2(ACK)]

	      Simple splitting of the tcp stream

       -e stream1

	      packet  =>  [packet1(ATT) + packet(GARBAGE) [invalid checksum] +
	      packet2(ACK)]

	      The IDS will see 'ATTGARBAGEACK' instead of 'ATTACK' if it's not
	      performing checksum analysis

       -e ttl1

	      packet  =>  [packet1(ATT)	 [ttl  n]  + packet(GARBAGE) [ttl p] +
	      packet2(ATT) [ttl n]]

	      The IDS will see 'ATTGARBAGEACK' if p is	a  TTL	sufficient  to
	      reach  the IDS but not the target host. The ttl can be specified
	      with the -t flag (see OPTIONS)

       -e rst1

	      packet => [packet1(ATT) + rst [invalid checksum] + packet2(ACK)]

	      If the IDS is performing a poor connection tracking and it's not
	      performing checksum analysis it will close the connection ignor‐
	      ing subsequent packets

       -e rst2

	      packet => [packet1(ATT) [ttl n] + rst  [ttl  p]  +  packet2(ACK)
	      [ttl n]]

	      The  IDS	will  close the connection if p is a TTL sufficient to
	      reach the IDS but not the target host. The ttl can be  specified
	      with the -t flag (see OPTIONS)

       -e desync1

	      packet => [packet1(ATT) + syn [wrong ack] + packet2(ACK)]

	      If  the  IDS  is	performing  a poor connection tracking it will
	      resynchronize the connection against the wrong sequence  numbers
	      of the post-connection SYN

       -e desync2

	      packet => [syn [wrong ack+invalid checksum] + syn + packet1(ATT)
	      + packet2(ACK)]

	      If the IDS is performing connection tracking  with  no  checksum
	      analysis	it  will  synchronize the connection against the wrong
	      sequence numbers of the pre-connection SYN

       -e frag1

	      packet => [fragment3(C) + fragment2(TA) + fragment1(AT) +	 frag‐
	      ment4(K)]

	      If  the  IDS can't correctly handle out of order IP fragments it
	      won't reassemble the packet

       -e frag2

	      packet => [fragment4(K) + fragment3(C) + fragment2(TA)  +	 frag‐
	      ment1(AT)]

	      Like frag1 but send the last fragment first

       -e frag3

	      packet  => [fragment1(AT) + fragment2(TA) + fragment3(C) + frag‐
	      ment3(C) + fragment4(K)]

	      Duplicate the penultimate fragment

       -e frag4

	      packet => [fragment1(AT) + fragment1(OO) + fragment3(TACK)]

	      Duplicate the first fragment with garbage data.  Overlap	attack
	      effective	 if  the  IDS  favors new data and the host favors old
	      data.

       -e frag5

	      packet => [fragment1(OO) + fragment1(AT) + fragment3(TACK)]

	      Send the first fragment with garbage data then duplicate it with
	      correct  payload. Overlap attack effective if the IDS favors old
	      data and the host favors new data.

       A detailed explanation can be find in the following documents:

	      Phrack Magazine, Volume 8, Issue 54 Dec 25th, 1998,  article  10
	      (P54-10)
	      Insertion,  Evasion,  and	 Denial	 of  Service:  Eluding Network
	      Intrusion Detection  -  Thomas  H.  Ptacek,  Timothy  N.Newsham.
	      (http://www.nai.com/media/ps/nai_labs/ids.ps)

FILES
       ftest.conf
	      Main configuration file.

       ftest.log
	      Log file generated by ftest.

       ftestd.log
	      Log file generated by ftestd.

EXAMPLES
       See the included ftest.conf.

REQUIREMENTS
       Net::RawIP,  Net::PcapUtils,  NetPacket are required, you can grab them
       at www.cpan.org or using your CPAN shell (`perl -e shell -MCPAN`).

BUGS
       Snort rules parsing is far from perfect, multiple content  rules	 won't
       work  and  non-content rules are skipped as well as ip only ones. Addi‐
       tionally variables such as $HTTP_PORTS are currently not recognized and
       will  create  problems (fix is coming soon, in the meantime sed is your
       friend ;) ).

       ftestd -c flag works only on Linux.

       Please report any bugs you find to <andrea@inversepath.com>

TODO
       - add an option for sending fragments with splitted TCP/UDP header
       - add a	OSSTMM	(http://www.isecom.org/projects/osstmm.htm)  compliant
       configuration template (in progress)
       - implement other evasion techniques (suggestions?)
       - throughput test and report
       - improve snort conf parsing
       - make ftestd -c flag compatible with other platforms
       - perl-tk graphic frontend (in progress)
       - use warnings

       Any volounteers ? ;)

LICENSE
       The  FTester is free software; you can redistribute it and/or modify it
       under the terms of the GNU General Public License  version  2  as  pub‐
       lished by the Free Software Foundation.

AUTHOR
       Andrea Barisani <andrea@inversepath.com>

       The     latest	  version    of	   FTester    can    be	   found    at
       http://dev.inversepath.com/trac/ftester

NOTES
       The IDS testing option that injects packets reading snort configuration
       files  is  designed  to	test the IDS engine and NOT it's efficiency in
       detecting real world attacks, the detection of an attack involve multi‐
       ple  events  and often human intervention to do proper correlation. The
       ftester can only be useful to verify things  like  the  IDS  placement,
       stateful	 inspection,  fragmention  handling,  overall speed and so on.
       Keep this in mind when using this tool.

SEE ALSO
       A very similiar tool is the filterrules package, you  can  find	it  at
       http://www.hsc.fr/ressources/outils/filterrules/index.html.en

       Another	snort  false positive generator is sneeze , you can find it at
       http://snort.sourceforge.net/sneeze-1.0.tar

       Fragrouter, http://www.anzen.com/research/nidsbench

       Fragroute, http://www.monkey.org/~dugsong/fragroute

       Stevens, W.Richard. TCP/IP  Illustrated,	 Volume	 One:  The  Protocols.
       Reading, MA: Addison-Wesley. 1994.

version 1.0			  13 Feb 2006			    FTester(8)
[top]

List of man pages available for Kali

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net