BOGON attacks?

cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
Any network security guru out there want to tell me how exactly you can use BOGON addresses in an attack on a network. The reason I ask is that I recently implemented some BOGON filtering at the enterprise edge and some of those ACLs have actually been hit. What I don't get is how the heck someone carries out such an attack since those addresses are not going to be routeable.

Check it out:

250 deny ip 5.0.0.0 0.255.255.255 any log (40 matches)
300 deny ip 10.0.0.0 0.255.255.255 any log (235 matches)
1150 deny ip 172.16.0.0 0.15.255.255 any log (4 matches)

icon_scratch.gif

Comments

  • ClaymooreClaymoore Member Posts: 1,637
    It's probably not an attack, just a misconfiguration on a router somewhere.

    Edit - somewhere else, I mean. Not on your network.
  • AhriakinAhriakin Member Posts: 1,799 ■■■■■■■■□□
    They are not supposed to be routable but they can be. one thing they try to exploit is if the firewall is terminating VPNs and it needs ACL entries for remote private address pools. With a Cisco ASA/PIX that's why you have the Sysopt permit to only allow VPN terminating traffic access (traditional thinking was this was a weakness since it allowed all traffic from your remote sites through even those you want blocked there aswellso some folks still prefer manual ACLs, but with 7.x up you can place a filter into the tunnel itself, or outbound on your inside interfaces etc. so you have the best of both worlds). Besides the 1918 addresses you listed (dont forget 192.168.x.x/16) Team Cymru, The Bogon Reference - Team Cymru , maintain a great list aswell, easy to import to your router or Firewall (I place them into an object group on my ASAs and just update the group when needed). The spamhaus list is also good to add.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    Yeah, the Team Cymru bogon list is the list I use. I like their BGP implementation using a BGP community to automatically null route BOGON traffic. I plan on using it once my 2nd border router comes in from Cisco and I get my 2nd ISP up.

    It would be interesting to see how many people use this method of BOGON filtering at the edge.
  • darkuserdarkuser Member Posts: 620 ■■■□□□□□□□
    http://www.icann.org/en/committees/security/sac004.txt

    SECSAC Paul Vixie, ISC
    SAC 004 October 17, 2002

    Securing the Edge

    Abstract

    At every edge of the global Internet are the hosts who generate and
    consume the packet flows which, together, form the overall Internet
    traffic load. By number, most of these hosts are not secure, leading
    to dangerous, untraceable traffic flows which can be used to attack
    other hosts. This memo describes some of the security problems "at
    the edge" and makes some recommendations for improvement.

    1 - Connection Taxonomy

    1.1. The Internet is a "network of networks", where the component
    networks are called Autonomous Systems (AS), each having a unique AS
    Number (ASN).

    1.2. Connections inside an AS are called "Interior" (or sometimes
    "backbone"), and their security policies are set according to local
    needs, usually based on business or technical requirements.

    1.3. Connections between ASs are called "Border" (or sometimes
    "peering"), and their security policies are set bilaterally according to
    the joint needs of the interconnecting parties.

    1.4. Connections between an AS and its traffic sources (generators) and
    traffic sinks (consumers) are called "Edge" (or sometimes "customer"),
    and their security policies are generally, by long standing tradition,
    inconsistent.

    2 - DDoS Vulnerability

    2.1. The most common attack on Internet hosts or infrastructure at the
    time of this writing is to cause the receipt of too much traffic,
    consuming all available resources on a victim's host or Internet
    connection. This is often called a "Denial of Service" (DoS) attack.

    2.2. For a DoS attack to succeed, the source or "launch point" must not
    be trivially detectable. Therefore, successful attacks employ large
    numbers of weak attackers. An attack launched from ten thousand hosts
    who each sent ten packets per second would be called a Distributed
    Denial of Service (DDoS) attack.



    SECSAC SAC 004 [Page 1]

    SAC 004 Securing the Edge October 17, 2002


    2.3. For a DDoS attack to succeed more than once, the launch points must
    remain anonymous. Therefore, forged IP source addresses are used. From
    the victim's point of view, a DDoS attack seems to come from everywhere
    at once, even from many IP addresses that are unallocated or otherwise
    invalid.

    2.4. A successful DDoS can last for minutes or weeks. Because there is
    no way to determine who launched it, because the process of identifying
    and correcting each compromised host cannot be practically undertaken as
    a means of mitigating the attack, and because filtering out "attack
    flows" invariably has the side effect of damaging valid traffic, every
    "cure" is nearly as expensive as just "waiting it out."

    2.5. While most DDoS attacks are by bad actors against other bad actors,
    it is quite common to select a high profile victim for no better reason
    than bragging rights. At the time of this writing there is virtually
    always an attack in progress somewhere, and in the foreseeable future
    these attacks will represent a large permanent share of the global
    Internet's traffic.

    3 - DDoS Vector

    3.1. The typical vector for DDoS launches is a personal computer (PC)
    running operating system and application software that purposely trades
    off security for convenience. These computers are usually poorly
    managed, such that there are weak passwords or no passwords, known
    security "holes" that are never patched or closed, and services offered
    to the global Internet that the owner has no knowledge and no use for.

    3.2. From the point of view of almost any single purveyor -- or consumer
    -- of operating system and application software, convenience will almost
    always have more perceived value than security. It is only when viewed
    in the aggregate that the value of security becomes obviously higher
    than the value of convenience.

    3.3. With the advent of high speed "always on" connections, these PCs
    add up to either an enormous global threat, or a bonanza of freely
    retargetable resources, depending upon one's point of view.

    3.4. Bad actors, in teams or acting alone, exert constant background
    effort to locate these hosts, probe them for known weaknesses, and
    subvert them in any way possible. There are software "kits" available
    that make all of this trivially easy, so no actual technical skill is
    needed to locate, subvert, and direct an army of thousands of high
    performance drones.



    SECSAC SAC 004 [Page 2]

    SAC 004 Securing the Edge October 17, 2002


    4 - Remediation

    4.1. The foundation of DDoS is anonymity. Even if thousands of hosts
    are involved, it is both desirable and possible to filter them out,
    report them to their owners, and repair them, one by one -- if and only
    if it is possible to learn their identities.

    4.2. Source addresses that appear at Border or Interior connections are
    nonrepudiable by nature, since flows from an alleged source could
    validly occur in either direction at any Border or Interior connection.

    4.3. Source addresses that appear on ingress flows from the edge are
    generally repudiable, since a typical edge host has no valid reason to
    use any source address other than one from the pool assigned by the
    "upstream" or "transit" provider.

    4.4. Edge source address repudiation -- the dropping of packets with
    invalid source addresses upon their ingress across a network edge -- has
    more immediate beneficial impact than improving PC security. In
    addition to the difference in complexity and variety, PCs outnumber
    network edges by at least three orders of magnitude.

    5 - Corner Cases

    5.1. Multihomed networks who use address space from multiple upstream
    providers will occasionally emit packets into upstream "A" using source
    addresses that were assigned by upstream "B". In this case, upstream
    "A" must be prepared to accept source addresses in address space "B",
    and vice versa. This is only a slight complication and does not
    invalidate the approach.

    5.2. Networks who have their own address space and ASN, and who speak a
    dynamic routing protocol such as BGP4, should have their offered routes
    filtered by their upstream provider(s) where practical in order to
    prevent bad actors from injecting temporary routes to unassigned or
    contested address space, from which to launch untraceable attacks.

    6 - References

    [BCP38]
    D. Ferguson, D. Senie, ``Network Ingress Filtering: Defeating Denial
    of Service Attacks which employ IP Source Address Spoofing,'' BCP 38
    and RFC 2827, IETF Best Current Practice, May 2000. 6.1.





    SECSAC SAC 004 [Page 3]

    SAC 004 Securing the Edge October 17, 2002


    7 - Author's Address

    Paul Vixie
    Internet Software Consortium
    950 Charter Street
    Redwood City, CA 94063
    +1 650 779 7000
    vixie@isc.org
    rm -rf /
Sign In or Register to comment.