|
Hi,
> >
> >Hmm, maybe I'm misunderstanding the question. What's being sent out over
> >the wire unencrypted is simply which sources go to which real servers,
> >right? How is that going to be exploited, once you have the knowledge?
This would be extremely hard unless you're root on
the director itself. IMHO it's safe enough to make
a new dedicated net (192.168.100.0/30 [has anyone
more than 4 nodes?]) for syncing. Put on some ipchains
rulez if you're paranoid and there we go. And spoofing
attack is also not possible because on the incoming
interface you deny all packets with source from a
dedicated net. There is still a lot more possibilities
to go. But just to tell: it will certainly be safe
enought for its purpose. Of course, if your director
is compromised, this security is over, but then you've
got bigger problems then somebody injecting bogus
packets into the sync flow.
> >You can't hijack a TCP session based on that -- you don't see the actual
> >TCP packets to find out the sequence numbers, unless it's going to include
> >that in the updates. Will it include that? I don't see any reason for it
> >to include any data other than source/destination pairs.
> >
> >You can do funny stuff with ICMP/UDP, but you can do that stuff anyway
> >just by forging the source address and sending it through the director.
most of this can be prevented by carefully set
ipchains rulez.
> >32 bits for source IP, 32 bits for destination IP, 16 for source port, 16
> >for destination port. 96 bits per message, at minimum. Last I checked,
> >serial's fastest speed was 115200 bits per second. That's only 1200
> >updates per second. How many new connections do you want to allow, per
> >second? How many old ones do you want to expire per second? Probably
> >more than that...
rethink again, you've to pass the whole template,
and you could only save some bits calculating the
hash value for the template.
regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
