lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1285347509.2503.357.camel@edumazet-laptop>
Date:	Fri, 24 Sep 2010 18:58:29 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ulrich Weber <uweber@...aro.com>
Cc:	Ulrich Weber <ulrich.weber@...glemail.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] dont create cached routes from ARP requests

Le vendredi 24 septembre 2010 à 18:40 +0200, Ulrich Weber a écrit :
> On 09/24/2010 06:05 PM, Eric Dumazet wrote:
> > Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
> >> steps to reproduce:
> >> server:
> >>  ip route add 1.0.0.0/8 dev dummy0
> >>
> >> client:
> >>  ip route add 1.0.0.0/8 dev eth0
> >>  nmap --min-rate 500 -sP 1.0.0.0/8
> >>
> > 
> > Great, you use nmap and fill 'client' neighbour cache.
> 
> Nope, I fills the 'server' neighbor cache too
> due cached routes in arp_process():
>         if (arp->ar_op == htons(ARPOP_REQUEST) &&
>             ip_route_input_noref(skb, tip, sip, 0, dev) == 0)

It fills the "server neighbor cache" because you specifically said it
has 2^24 ip addresses.

If using a normal route to gateway on eth0, it only fills route cache,
with a max of 65536 slots on your config, not 1024. When max is reached,
garbage collection takes place.




> 
> > Now, back to the _real_ problem, please ?
> > 
> > <quote>
> > 
> > Background: At home I have two Internet connections, DSL and Cable.
> > DSL is the primary uplink while Cable is the secondary.
> > My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
> > which creates routes via the primary uplink.
> > There are thousands of cached routes and after some time
> > I get "Neighbour table overflow" messages.
> > 
> > </quote>
> > 
> > You receive an ARP request on device eth1,
> > this creates a route on eth0 ?
> > 
> > Could you send your routing/address setup ?
> > 
> > ip addr
> > ip ro
> > 
> 
> ARP request flood comes in via eth2.
> 
> Have to correct myself: With configuration below only route cache
> increases but no "Neighbour table overflow".
> 
> By adding "ip route add 10.0.0.0/8 dev eth0" the Neighbor table overflow
> will occur.
> 

Because you want instead "ip route add 10.0.0.0/8 via gateway"
Or else you are vulnerable to an attack, as you discovered.


Here it works perfectly.

rtstat -c20 -i1|cut -c1-60
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cac
 entries|  in_hit|in_slow_|in_slow_|in_no_ro|  in_brd|in_mar
        |        |     tot|      mc|     ute|        |  an_d
  
    1984|       2|       1|       0|       0|       0|      
    1984|       2|       0|       0|       0|       0|      
    1984|       2|       0|       0|       0|       0|      
    1985|       4|       2|       0|       0|       0|      
    1988|       0|       4|       0|       0|       0|      
    2020|       1|      33|       0|       0|       0|      
    2042|       1|      23|       0|       0|       0|      
    2104|       0|      63|       0|       0|       0|      
    2117|       0|      14|       0|       0|       0|      
    2141|       0|      26|       0|       0|       0|      
    2159|       1|      19|       0|       0|       0|      
    2175|       0|      17|       0|       0|       0|      
    2221|       0|      48|       0|       0|       0|      
    2241|       0|      20|       0|       0|       0|      
    2256|       0|      17|       0|       0|       0|      
    2269|       3|      15|       0|       0|       0|      
    2286|       0|      17|       0|       0|       0|      
    2295|       1|      10|       0|       0|       0|      
    2326|       1|      33|       0|       0|       0|      



> 
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>     inet 127.0.0.1/8 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>     inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>     inet 78.43.x.x/22 brd 78.43.35.255 scope global eth2
> 12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc hfsc
> state UNKNOWN qlen 3
>     inet 95.114.x.x peer 213.20.56.129/32 scope global ppp0
> 
> 
> default via 213.20.56.129 dev ppp0
> 78.43.32.0/22 dev eth2  proto kernel  scope link  src 78.43.x.x
> 127.0.0.0/8 dev lo  scope link
> 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
> 213.20.56.129 dev ppp0  proto kernel  scope link  src 95.114.x.x
> 
> 

Thanks


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ