Hi Dave, On Mar 22, 2014, at 18:09 , Dave Taht <[email protected]> wrote:
> On Sat, Mar 22, 2014 at 11:08 AM, Toke Høiland-Jørgensen <[email protected]> wrote: >> Sebastian Moeller <[email protected]> writes: >> >>> I have a question about the reasoning behind the whole thing though. I >>> can see that not permitting source addresses that do not belong to >>> cerowrt's subnets makes a ton of sense. But what precisely is the >>> reasoning to not route the private addresses? >> >> Well, for IPv6, not permitting valid source addresses is exactly how >> this is implemented -- by having source-based routing for the assigned >> prefixes (I suppose you could do a similar private address blocking >> thing for IPv6, but I punted on that for now; and don't think it's as >> important). However, for IPv4 the question of "which addresses are >> valid" becomes harder to answer in anything but the simple case of "one >> network behind the router". I.e. for mesh networks etc. >> >> At the same time, in general, egress traffic from the home network could >> conceivably go anywhere, so blocking on destination is not viable >> either. Except, basically, for the networks being blocked by the current >> implementation; these are all defined by various RFCs (most well-known >> probably RFC1918) to be invalid on the internet, and so can be safely >> dropped. And since all sorts of equipment probe the default addresses >> (think users on a new net trying to find their home gateway at >> 192.168.1.1, devices that think they are on a VPN but are really not, >> etc), so packets leaking onto the internet can be quite common, and they >> can go a surprisingly long way before being dropped, I'm told. > > 0) I've seen 5 hops or more before they die. > > I have observed 3 use cases in the last couple years personally. > > 1) In the campground I have a primary dns server that frequently drops > off the (routed) network. 2 minutes later, all queries directed at that dns > server start going out the default gateway, with no reply. with this code > in place, they get stopped at the edge, with an appropriate reply, and when > the server comes back online they are responded to normally. win. This makes a lot of sense, thanks. > > 2) I have seen many worms banging away at everything in every subnet > they can find, and several that just arbitrarily bang away at 192.168.x.y. > in cero's case these not only eat external bandwidth but interact badly with > the > "fast queue" concept - as being sparse, they are optimized to go out the > router first, and never return…. "Automatic worm deprioritization", we should pass this onto the marketing department ;) Kidding aside, again makes a ton of sense. > > 3) In a data center I have seen multiple attempts by sources with > invalid return addresses to leverage dns reflection attacks. Dropping > totally invalid addresses is a win… And even more sense. I guess I am glad I posed the question, since I learned a lot... > > That said, the primary purpose of this code is to supply a tool and clue > to places that could do this sort of filtering better inside their network. > small corporate campuses, isps, etc. > >>> Or, asked differently what harm does it to route those except wasting >>> a bit of bandwidth; but since the src is correct it will be relatively >>> easy to pinpoint malicious sources that way? >> >> Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;) > > Lack of universal BCP38 has cost a lot of dns managers a lot of hair, > and more recently the ntp ddos was pretty bad. > >> Really, though, BCP38 (which, btw, is a Best Current Practice document >> From the IETF: http://tools.ietf.org/html/bcp38) should be implemented >> by ISPs to be really effective in DOS mitigation. I think implementing >> it in cerowrt (apart from the "be secure by default" goal) is to >> demonstrate that it's possible to do a workable solution (trough ipsets) >> that doesn't involve traversing a bunch of slow firewall rules, and so >> doesn't impact performance noticeably. You know, the old clue-bat ;) > > Perhaps this is a new logo idea for cero: A giant clue-bat. Is that bat as in micro/macrochiroptera ( http://en.wikipedia.org/wiki/Bat ) or as in http://en.wikipedia.org/wiki/Baseball_bat, I assume the latter but the former would allow more leeway for the potential logo ;) > >> >>> The point I wanted to make is that following >>> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit >>> more involved than what should be required from the typical home user. >> >> Yeah, I can see that. It would probably be possible to do some >> autodetection (perhaps by crowdsourcing a database of likely modem >> addresses), but I fear the implementation would be annoyingly complex. >> In the perfect world, you could just arping each of the addresses and >> see if they reply, but I have this nagging feeling that the kind of >> equipment we want to talk to will do things like refuse to reply to ARP >> unless the request comes from within its own (probably hard-coded) >> subnet. In which case we would have to assign a bunch of addresses on >> the upstream interface to do the probing, then remove them again, >> leaving to all sorts of annoying potential failure modes... :( > > Well, a brute force way would be to insert all these addresses with > say a one hour timeout to expire on a cold boot. I think requiring the user to add the specific address in the white-list is not a bad way, as long as it is prominently documented. I assume most users will not care anyway and those that are should not mind following simple easy instructions. Best Regards Sebastian > >>> Your implementation is so straight forward I could talk my siblings >>> though over the phone, so it passes my ad-hoc tests for viability in >>> the real world ;) >> >> Haha, great! Sometimes I think someone should write up a formal document >> on the "non-technical family member" test... > > +1 > >>> So on several other pages (like >>> https://gw.home.lan:81/cgi-bin/luci/;stok=e2041363b170e62aa756a4ee3e525f72/admin/network/hosts) >>> the GUI is used slightly different, there is one fixed add button and >>> each entry always comes with its own delete button. I have not looked >>> at the luci code for that though. >> >> Well I didn't do a lot of research on luci primitives for this, but did >> come across that one. That widget is a different one that mirrors a >> different configuration primitive (adding config *sections* rather than >> a list of config *entries*). I don't *think* there's a better widget for >> the lists, but would be happy to be proved wrong :) > > In terms of featureitus it might be nice to have a comment field shown > in the gui and in the config file. >> >> -Toke >> >> _______________________________________________ >> Cerowrt-devel mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
