LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: ideas about kernel masq table syncing ...

To: Ratz <ratz@xxxxxx>
Subject: Re: ideas about kernel masq table syncing ...
Cc: Wayne <wayne@xxxxxxxxxxxxxxx>, "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Kyle Sparger <ksparger@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 8 Aug 2000 08:58:52 -0400 (EDT)
> IMHO it's safe enough to make a new dedicated net (192.168.100.0/30 [has
> anyone  more than 4 nodes?]) for syncing.

IMHO, I agree.  But I also agree with Wayne that in some cases (eg, colo
farms) this isn't feasible, and especially if you want to go the ip
tunnelling method over public lines to separate physical locations.  Of
course, you could always use IPSec or some other encrypted tunnel, but,
why do that if/when you can simply authenticate the messages themselves?

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

Actually, I was thinking from an end-user point of view.  Spoof a ton of
udp/icmp packets, and send them through as if they were regular traffic.
Not a whole lot ipchains can do about it -- if you know a way, other than
stopping it at the source, I'd like to know -- this sort of garbage is the
bane of network engineers/ISPs 'round the world ;)

> rethink again, you've to pass the whole template, 
> and you could only save some bits calculating the
> hash value for the template.

Thus the usage of the word "minimum" -- I was assuming that _all_ you were
passing was that data.  :)  I didn't honestly think for a moment that it
actually would be all you sent :)

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 Tue, 8 Aug 2000, Ratz wrote:

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




<Prev in Thread] Current Thread [Next in Thread>