On Thursday 17 January 2008 03:23, Michael T?nzer (vid,smtp2) wrote: > Matthew Toseland schrieb: > | It would be good to solve the verification problem without having to have > | permanent connections from the seed server to the seed nodes. The > problem is > | the below doesn't do this: it only verifies that the attacker is > listening on > | the stipulated port, and that he runs one freenet node somewhere, it does > | *not* verify that there is a connectible node on the given node reference. > > Okay, so the only way to ensure that is to test it by trying to fetch a > noderef (maybe our own to prevent that it only delivers refs of a > honeynet run by the attacker - if that's possible (e.g. by requesting a > key that matches our location and answer to that request). I don't know > whether I have understood the Opennet ref swapping process properly) > through the new Seednode.
Fetching a noderef wouldn't help. > As we probably don't want to run a node on our server itself (we could, > but would it have enough ressources to serve the important things like > web pages, SVN and stuff even if we are /.ed?) the Seedserver has to > have a connection to a node somewhere and as we have some Nodes which > should be available anyway, why not use them? This also balances the > load between the Seednodes, avoids another single point of failure and > makes sure they're online so we don't have to recheck apart from that. > We don't have to be connected to all of our Seednodes all the time. Just > if we want to verify a new Seednode we establish a new connection to one > of our Seednodes on the Port which on which the Seedservice runs and > verify that it's us. You mean for the seed server to connect to the seednodes (easily spoofed), or for the seednodes to connect to each other (somewhat less easily spoofed)? > Doh, just reread the original proposal, that's something which I had on > my mind but didn't write down: > Each SeedNode runs a SeedService on a random Port and reports that Port > to the SeedServer on the initiation process and keeps it up to date if > it changes. The SeedService listens to requests of the SeedServer so if > the Seedserver has to verify a new SeedNode it can ask the SeedService > of an alredy established SeedNode (of course we recheck the identity of > each other). Verify by connecting to it? > This should also be portscanproof as the connection only can be > initiated from the IP of our Server, so we can ignore the others. > > So the following attacks are left: > - manipulated installer > - DoS the Seedserver > - DoS SeedNodes (not a problem if one SeedNode is DoSed but if they're > all down - attacker needs some power to do this (e.g. big botnet) as > there (hopefully) are quite a few SeedNodes) > - Attacker as Seednode It's all about attacker as seednode. The trivial attack is to send in completely bogus noderefs. If we beat that, the attack is to send in noderefs to your own nodes, which only respond to the seed server, or the other seednodes. Or to let anyone connect but never do anything useful after that. And so on. > - Honeynet (the attacker could turn the honeynet off when we check him > and turn it back on once the check is done - maybe SeedNodes should > check each others functionality from time to time without announcing it, > but don't they have enough load to carry? Another solution is, that a > new Client always tries to get refs from at least 3 SeedNodes and check > whether the peers are connected (trying to get the refs of peers he got > from one SeedNode through peers he got from another one)) A client tries lots of seednodes. The main thing we want to defend against is an attacker swamping the seednode collector with many useless or nonexistent nodes. If he has access to enough IPs, he can swamp it with his own, functional but malicious nodes, there's not much we can do about that. :| > > regards > Neo at NHNG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080117/08c96402/attachment.pgp>