Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

[Sebastian Moeller <moeller0@gmx.de>]

Hi Toke,

On Mar 22, 2014, at 12:08 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@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.

	Ah, thanks for the information.

> 
>> 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"... ;)

	I had not looked at it from that perspective, makes a lot of sense...

> 
> 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 ;)
> 
> 
>> 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... :(
> 
>> 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...
> 
>> 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 :)

	I thought a bit about this, and I think there might be a way to use the available widgets in a way that emulates consistency ;) (well at least in theory)
If the first entry would not hog the singleton entry field with the add button, but would spawn a new empty field with an add button, while the just entered (and saved & applied) entry would be followed by the delete button, he whole thing would be consistent enough to not confuse the user. I will see whether I can implement that in the luci code.

Best Regards
	Sebastian

> 
> -Toke