|
> For those of us have dedicate Internet connection, that might not
> be a big deal of security issue. However, for those use LVS in
> the hosting services, that could be a problem. Being able to see
> the data passing over the wire will allow others to fake data packet
> send over from other system. I think that is a security hole.
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?
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.
The question is: How, exactly, can one take advantage of the fact that
they know which real server the data is being sent to?
Again, the only real issue I see is being able to inject bogus data into
the backup real servers -- so we _do_ need to authenticate the sent
packets somehow.
> Slow is a relative term, it depends on how much data going
> through it.
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...
Thanks,
Kyle Sparger - Senior System Administrator
Dialtone Internet - Extremely Fast Web Systems
(954) 581-0097 - Voice (954) 581-7629 - Fax
ksparger@xxxxxxxxxxxxxxxxxxxx
http://www.dialtoneinternet.net
On Mon, 7 Aug 2000, Wayne wrote:
> At 12:55 PM 8/7/00 -0400, Kyle Sparger wrote:
> >> Would this cause any security concerns? Any critical
> >> data cross the network should be encrypted to protect
> >> the integrity, but that will be a lot of overhead.
> >
> >What exactly can you do with the information? I can't think of anything
> >-- okay, so you know which real server the data is getting sent to. What
> >are you gonna do about it?
> >
> >Is this data so sensitive that we need to worry about the data itself
> >being sniffed? Definately we need some kind of authentication method to
> >make sure that your random trouble maker can't inject associativity at
> >will (possibly creating a denial of service, or worse), but this
> >application probably doesn't call for encrypting the _entire_ message.
> >(imho)
> >
> >Mind you, doing the authentication right might _require_ encryption, but
> >it might not; I'm just saying that I think that encryption of the data
> >for the sake of maintaining the secrecy of the data probably isn't a
> >concern.
>
> For those of us have dedicate Internet connection, that might not
> be a big deal of security issue. However, for those use LVS in
> the hosting services, that could be a problem. Being able to see
> the data passing over the wire will allow others to fake data packet
> send over from other system. I think that is a security hole.
>
>
> >> Why don't use serial port? It seems easier than
> >> parallel port.
> >
> >Serial port seems way, way slow to me, and is point-to-point only.
>
> You are right, that is point to point. If you have more than 2
> LVS boxes, that will not fit. But the data going back and forth
> over the communication port should not be that much. Are
> we sure how much data we need to send back and forth?
> Slow is a relative term, it depends on how much data going
> through it.
>
>
> >Thanks,
> >
> >Kyle Sparger - Senior System Administrator
> >Dialtone Internet - Extremely Fast Web Systems
> >(954) 581-0097 - Voice (954) 581-7629 - Fax
> >ksparger@xxxxxxxxxxxxxxxxxxxx
> >http://www.dialtoneinternet.net
> >
> >On Mon, 7 Aug 2000, Wayne wrote:
> >
> >> At 08:22 PM 8/6/00 +0200, Ratz wrote:
> >> >Hi Wensong,
> >> >
> >> >I've been thinking about our talk at OLS on a possible
> >> >kernel-2-kernel masq table syncing (kmasqsd) design.
> >> >
> >> >To recall:
> >> >We decided to implement a kernel daemon like
> >> >kflushd that would periodically send new connection
> >> >template entries from the master director to the
> >> >backup (blaster) over a dedicated heartbeat based
> >> >on UDP packets. This is a good basic concept, however,
> >>
> >> Would this cause any security concerns? Any critical
> >> data cross the network should be encrypted to protect
> >> the integrity, but that will be a lot of overhead.
> >>
> >> >I'suggest not to send the updates via UDP but rather
> >> >define a own easy protocoll and run it over the
> >> >parallel port, since this needs no IP-stack
> >>
> >> Why don't use serial port? It seems easier than
> >> parallel port.
> >>
> >> >processing and will also work if there is a stack
> >> >problem. And in case of a failover and a shutdown
> >> >of the interfaces, the daemon could still sync
> >> >without being interupted and so providing to
> >> >best syncing state. The amount of lost connections
> >> >would definitely very small, if not even zero.
> >> >
> >> >Just a thought ...
> >> >Suggestions, flames :) ?
> >> >
> >> >best regards,
> >> >Roberto Nibali, ratz
> >> >
> >> >
> >> >--
> >> >mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
> >> >
> >>
> >>
> >>
> >>
>
>
|
