Re: Martian list of IP's to block???
I used the ones Cisco outlined in their document IOS Essentials every ISP Should Know. Here is a copy of the list I use for out clients: deny ip host 0.0.0.0 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip xxx.xxx.xxx.0 0.0.0.255 any log deny ip 224.0.0.0 31.255.255.255 any log We are denyingy anyone that claims that their IP address is 0.0.0.0, Loopback addresses, all of the RFC 1918 addresses, address coming into us claiming they belong to our subnet, and multicast addresses. It seems to work for us. I also turn of ip directed broadcasts to minimize smurf/DoS attacks. If you would like a copy of the document I used, let me know and I'll e-mail a copy to you. Ron Fuller, CCDP, CCNP-ATM, CCNP-Security, MCNE, MCP 3X Corporation rfuller@3x.com "John M. Brown" <jmbrown@ihighway.net>@merit.edu on 10/01/99 04:18:29 AM Sent by: owner-nanog@merit.edu To: nanog@merit.edu cc: Subject: Martian list of IP's to block??? working on a document and was wondering if people could provide the various versions of the Martian list that is used... thanks
deny ip host 0.0.0.0 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip xxx.xxx.xxx.0 0.0.0.255 any log deny ip 224.0.0.0 31.255.255.255 any log
Routing those networks to nul0 and turning 'ip verify unicast reverse-path' on CEF-enabled Cisco routers does this without CPU load or does not ? Rubens Kuhl Jr.
Most of us can't "ip verify unicast reverse-path" our upstreams. - Jared On Fri, Oct 01, 1999 at 12:42:40PM -0300, Rubens Kuhl Jr. wrote:
deny ip host 0.0.0.0 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip xxx.xxx.xxx.0 0.0.0.255 any log deny ip 224.0.0.0 31.255.255.255 any log
Routing those networks to nul0 and turning 'ip verify unicast reverse-path' on CEF-enabled Cisco routers does this without CPU load or does not ?
Rubens Kuhl Jr.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
Most of us can't "ip verify unicast reverse-path" our upstreams.
I think you can run it on low/mid-range Cisco routers with IOS 12, as CEF is not 75xx privilege any more, although I have not tested myself.
Routing those networks to nul0 and turning 'ip verify unicast reverse-path' on CEF-enabled Cisco routers does this without CPU load or does not ?
Rubens Kuhl Jr.
I used the ones Cisco outlined in their document IOS Essentials every ISP Should Know. Here is a copy of the list I use for out clients:
deny ip host 0.0.0.0 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip xxx.xxx.xxx.0 0.0.0.255 any log deny ip 224.0.0.0 31.255.255.255 any log
We are denyingy anyone that claims that their IP address is 0.0.0.0, Loopback addresses, all of the RFC 1918 addresses, address coming into us claiming they belong to our subnet, and multicast addresses. It seems to work for us. I also turn of ip directed broadcasts to minimize smurf/DoS attacks. If you would like a copy of the document I used, let me know and I'll e-mail a copy to you.
Its also useful to block 192.0.2.0/24 - the test network. so designated for documentation use 169.254.0.0/16 - the link-local network. I'm not convinced that blocking native multicast is a good idea. --bill
On Fri, Oct 01, 1999 at 08:49:23AM -0700, bmanning@vacation.karoshi.com wrote:
deny ip 224.0.0.0 31.255.255.255 any log
I'm not convinced that blocking native multicast is a good idea.
This is blocking packets sourced with a multicast ip, not destined for multicast. ex: when i source multicast traffic the src ip is the ip of the machine sending the traffic, and the dst is the ip of the multicast group. so traffic would go from (for example) puck.nether.net (204.42.254.5) to the multicast group for Places all over the World (224.2.172.238). This acl would prevent someone from sending a ping to your router, and faking the src ip to be something like all-routers.mcast.net, and having you start ping flooding all the multicast routers, or multicast hosts out on the internet. (Think semi smurf-attack like). - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
On Fri, 1 Oct 1999 bmanning@vacation.karoshi.com wrote: }> deny ip 224.0.0.0 31.255.255.255 any log ... } I'm not convinced that blocking native multicast is a good idea. I think it makes sense if you're using this list to block source addresses, or if you are applying this list to unicast routes only. We also block 224.0.0.0/4, but not on MBGP-learned routes. -andy -- Andy McConnell IP Operations Manager andym@ntt.net NTT America Network and IP Service Division +1 408 873 3757 真向練 安堵龍 NTTアメリカIPオペレーション担当課長 Always try to do things in chronological order; it's less confusing that way.
On Fri, Oct 01, 1999 at 08:02:23AM -0400, rfuller@3x.com wrote:
deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log
These three clauses will block things like ICMP would-fragment and ttl-expired messages, in the event that some transitory bit of network between your customer and someone else's customer is numbered using RFC1918 address space (and causes such messages to be sent). I know of several networks which use RFC1918 addresses like this, in the belief that since the elements with these numbers never need to receive a packet from anybody outside the operator's network, there is no need for the numbers to be globally unique. In my opinion, such RFC1918 visibility in the public network is misguided, and half of the disruption to service caused by rules like those above could be considered just punishment. Trouble is, the other half of the disruption is for your customers, and you know who they're going to blame if they can't reach their favourite repository of huge flesh-tone jpegs. Operational content: does anybody actually block packets inbound from off-net, in the case where they are sourced from an RFC1918 address? If so, do your customers complain? Joe
At 00:13 3-10-99 +1200, Joe Abley wrote:
Operational content: does anybody actually block packets inbound from off-net, in the case where they are sourced from an RFC1918 address? If so, do your customers complain?
AUCS (As3300) blocks incoming RFC 1918 addresses together with our own address space , to avoid spoofed ospf updates, at all our borders with other networks and have not received complaints of customers ever. Frank
Joe
participants (7)
-
Andy McConnell -
bmanning＠vacation.karoshi.com -
Frank Hellemink -
Jared Mauch -
Joe Abley -
rfuller＠3x.com -
Rubens Kuhl Jr.