Re: Deny IP spoof from 255.255.255.255

From: Vitaly Osipov (vosipovat_private)
Date: Fri Jul 06 2001 - 08:32:34 PDT

  • Next message: Aaron Silver: "Re: Abuse Complaint/Postmaster issue"

    this is a sample of your packet:
    
    #(1 - 29543) [2001-06-19 01:34:54] [arachNIDS/203]  BACKDOOR Q access
    IPv4: 255.255.255.255 -> x.x.x.x
          hlen=5 TOS=0 dlen=43 ID=0 flags=0 offset=0 TTL=13 chksum=45614
    TCP:  port=31337 -> dport: 515  flags=***A*R** seq=0
          ack=0 off=5 res=0 win=0 urp=0 chksum=25942
    Payload:  length = 3
    
    000 : 63 6B 6F                                          cko
    
    
    regards,
    Vitaly.
    
    Curt Wilson wrote:
    > 
    > Our PIX has detected an IP spoof from
    > 255.255.255.255 to one of our servers. Research
    > here on securityfocus reveals that some attackers
    > have used this technique with a destination port 515
    > (LPR) and source 31337 (eleet) in scanning
    > attempts. You can read about this at on the firewalls
    > list at
    > http://www.securityfocus.com/archive/19/187958
    > 
    > Our PIX does not indicate source or destination ports
    > perhaps because the "IP spoof" criteria was already
    > triggered in its logic chain, denying the packet and
    > making a syslog entry.
    > 
    > We don't have an IDS outside the firewall so I don't
    > have any more packet details which makes it very
    > hard to do proper analysis.
    > 
    > The only other references I've seen to something of
    > this nature can be found in Dragos Ruiu's
    > paper "Cautionary Tales: Stealth Coordinated Attack
    > HOWTO" at
    > http://www.dursec.com/articles/stealthhowto.html
    > when talking about DSLAM infrastructure issues
    > states:  "In easy cases, the equipment rack will
    > bridge broadcast traffic between the "marshmallow"
    > and the target, allowing use of address resolution
    > traffic such as ARP and DHCP to be used for system
    > attacks and control. For stealth, these kinds of attack
    > bases are excellent too, because the broadcast
    > traffic is largely repetitive, very voluminous, and
    > mostly uninteresting, which, combined with a great
    > immaturity among the security tools for this kind of
    > traffic, make it a ripe vulnerability area"
    > 
    > This quote is of interest because the server in
    > question uses DSL.
    > 
    > Another reference to traffic of this nature can be
    > found in the excellent paper "A stateful inspection of
    > Firewall-1" by Dug Song, Thomas Lopatic and  John
    > McDonald at
    > http://www.dataprotect.com/bh2000/blackhat-
    > fw1.html which states "Another possibility for evading
    > IP spoofing protection is to use the all-hosts multicast
    > address (224.0.0.1) as a mechanism for delivering
    > packets to the underlying operating system of the
    > firewall. For our demonstration, we used FWZ
    > encapsulation to spoof a packet from the multicast
    > address to our attack host, allowing us to respond
    > with a packet sent to the multicast address, passed
    > on to the firewall itself. This attack can also be
    > performed with broadcast addresses."
    > 
    > I realize that both of these references don't refer
    > directly to such a packet but I am curious about these
    > techniques.
    > 
    > Thank you,
    > Curt Wilson
    > Netw3
    > 
    > ----------------------------------------------------------------------------
    > 
    > This list is provided by the SecurityFocus ARIS analyzer service.
    > For more information on this free incident handling, management
    > and tracking system please see:
    > 
    > http://aris.securityfocus.com
    
    
    ----------------------------------------------------------------------------
    
    
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see:
    
    http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Fri Jul 06 2001 - 13:21:41 PDT