RE: Real connection spoofing (Firewall Tester)

From: Henniges, Matthew (ISS) (MHennigesat_private)
Date: Mon Sep 24 2001 - 12:53:36 PDT

  • Next message: bluefur0r bluefur0r: "Re:FW: baby pen-test question"

    Perhaps you could address your syn to an ip address that's not bound to the interface.
    
    Publish an arp for an additional address so that the stack picks up the packet.
    
    Matthew B. Henniges
    Security Services
    Internet Support Services
    Merrill Lynch
    212.647.3090
    
    
    -----Original Message-----
    From: Andrea Barisani [mailto:lcarsat_private]
    Sent: Monday, September 24, 2001 8:02 AM
    To: pen-testat_private
    Subject: Real connection spoofing (Firewall Tester)
    
    
    Hi!
    
    I'm currently tring to implement real connection spoofing in my simple
    firewall testing scripts (ftester.sourceforge.net) in order to test
    stateful inspection firewalls like iptables and ipfilter. Currently my
    tool is useless with such firewalls when injecting packets like a Push/Ack
    response because they aren't related with any ongoing connection. So this
    is the idea (feel free to criticize ;) :
    
    Client (ftest.pl) ---> Firewall ---> Sniffer (ftestd.pl)
    
    1 - The client (ftest.pl) send a Syn packet with a custom payload
    (Question:  is inserting data in a Syn packet legal?)
    2 - The sniffer (ftestd.pl) sniff the packet and the stack response
    3 - The sniffer send a Syn packet to the client with the Seq number equal
    to the stack response
    4 - Based on this information the client send the correct response in
    order to complete the handshake
    5 - Now we can test some flags (like Push/Ack)
    
    The problem is that between step 2 and step 3 the spoofed address will
    send a valid RST back to the sniffer, the firewall will see it and we
    can't proceed. The only solutions to that problem are making the stack
    silent (patching the kernel in some way I suppose), or make sure that the
    stack responses are seen only by the firewall and not by the spoofed host,
    maybe setting a low TTL in /proc/sys/net/ipv4/ip_default_ttl. Another idea
    could be using a very low default TTL in order to 'hide' stack replies and
    entirely craft the right replies with the correct TTL, in this way I can
    simulate real responses even if the target port is a closed one (step 2
    implies a Syn/Ack response, so an open port).
    
    Anyone got a better idea?
    
    Thanks.
    
    ------------------------------------------------------------
    INFIS Network Administrator & Security Officer
    Department of Physics       - University of Trieste
    lcarsat_private - PGP Key 0x8E21FE82
    ------------------------------------------------------------
    "How would you know I'm mad?" said Alice.
    "You must be,'said the Cat,'or you wouldn't have come here."
    ------------------------------------------------------------
    
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
    Service. For more information on SecurityFocus' SIA service which
    automatically alerts you to the latest security vulnerabilities please see:
    https://alerts.securityfocus.com/
    
    
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
    Service. For more information on SecurityFocus' SIA service which
    automatically alerts you to the latest security vulnerabilities please see:
    https://alerts.securityfocus.com/
    



    This archive was generated by hypermail 2b30 : Mon Sep 24 2001 - 13:01:40 PDT