[Cerowrt-devel] cerowrt-3.10.32-12 released

Sat Mar 22 16:20:20 EDT 2014

Hi Dave,

On Mar 22, 2014, at 18:09 , Dave Taht <dave.taht at gmail.com> wrote:

> On Sat, Mar 22, 2014 at 11:08 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Sebastian Moeller <moeller0 at gmx.de> 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
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html