Re: DoS/DDoS Attack

From: Rogan Dawes (discard_at_dawes.za.net)
Date: 01/17/05

  • Next message: lists: "Re: priviledge escalation techniques"
    Date: Mon, 17 Jan 2005 17:33:24 +0100
    To: Steven <steven@lovebug.org>
    
    

    Steven wrote:
    > Would it not be safe to say that a large amount of this issue could be
    > mitigated if ISPs and/or those links above them took a more responsible
    > approach to packet handling? Wouldn't the whole issue (problem) of
    > spoofed packets be handled if they were quashed at the start instead of
    > the end? Perhaps I don't understand enough here, but it seems that
    > initially routers/switches should have the capability to drop packets
    > that could not have originated from their own network. If new equipment
    > had the option to enforce this or had it automatically built in, would
    > this not severely mitigate some of this issue? Is there a reason why
    > spoofed packets should be able to make their way off a LAN and across
    > the world?
    >
    > Perhaps this would only hold up so long until someone decided to make
    > all DDoS spoof the packet from the same network but just a different
    > host address. Then maybe it would be possible to have the first router
    > check if the source address of the packet exactly matches where it is
    > actually coming from some how and not just that the network is valid.
    >
    > Perhaps I just have a weak understanding of how this works and it cannot
    > be solved so easily, but it appears that if that "some" of this is not
    > so hard to stop. If what I have proposed is possibly and not being
    > implemented on a wide scale, then why isn't it?
    >
    > Steven
    >

    What you are talking about is called (in Cisco terms, anyway) Reverse
    Path Forwarding, and, in my opinion, should be used by ALL ISP's on
    their access routers. Basically, if the router receives a packet, and
    its routing tables do not show a return path going out the same
    interface it came in on, it drops the packet.

    Unfortunately, it is not feasible to use something like this on internal
    routers, because it fails wherever asymmetric routing is being used. But
    for the first hop from the customer to the ISP, I think that it is
    entirely feasible to enable something like this.

    For details, see http://www.cisco.com/warp/public/707/21.html#anti_spoofing

    Rogan

    -- 
    Rogan Dawes
    *ALL* messages to discard@dawes.za.net will be dropped, and added
    to my blacklist. Please respond to "lists AT dawes DOT za DOT net"
    

  • Next message: lists: "Re: priviledge escalation techniques"

    Relevant Pages

    • Re: UPNP/SSDP
      ... otherwise it's just a glorified packet filter with a set of rules. ... neither a NAT nor a router are referred to as packet filters. ... a NAT router for broadband internet does not do this, ... router to route traffic b/w two or more private networks and the internet. ...
      (microsoft.public.windowsxp.general)
    • Re: Nmap questions concering my router
      ... has only one interface, ... as having a chunk of space in the computer much like a hotel room. ... >is) directly connected to my router, which i dont set up a NAT yet. ... Which IP address is the packet addressed to? ...
      (comp.security.firewalls)
    • Re: IIS5 Passive FTP Networking problem (long)
      ... or do away with the router entirely (and the hardware based ... > had the ability to run an FTP server behind it without changing the IP ... The NAT changes the PASV response ... translate the address fields of a packet. ...
      (microsoft.public.inetserver.iis.security)
    • Re: MSS on router, why?
      ... The proper way to describe the ICMP packet which is supposed to be ... returned by a router which cannot forward the IP packet which is too ... Because ICMP was defined before Path MTU Discovery (1981 and 1990 ... fragmentation and try to use path MTU discovery, ...
      (comp.dcom.sys.cisco)
    • Re: Nmap questions concering my router
      ... Ah, but the packet is being sent to an application running on the router, ... not the web server on your LAN. ... we separate LAN from LAN as well as ...
      (comp.security.firewalls)