[Cerowrt-devel] cerowrt-3.10.32-12 released

[Dave Taht]

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.

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....

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...

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.

>
>> 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.

>> 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