BOGON attacks?

cisco_trooper

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)

Claymoore

It's probably not an attack, just a misconfiguration on a router somewhere.

Edit - somewhere else, I mean. Not on your network.

Ahriakin

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.

cisco_trooper

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.

darkuser

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