Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: ToySoldier who wrote (28453)	10/5/1999 8:17:00 PM
From: Scott C. Lemon	Read Replies (2) \| Respond to of 42771

Hello ToySoldier, This is getting to be fun ... I love hacking and experimenting with networked systems ... ;-) > YES - if @HOME or one of their competitors implements an NDS > authentication client and it is a condition of receiving service, > then control can be attained. This includes the NAT gateways. WHY > you ask.... Yes ... I'm sorry, but your explanation below would not stop me ... ;-) > Lets use an NDS-enabled firewall like BorderManager and I tell > BorderManager to filter Internet access based on NDS user ID. But you obviously know that this is really not how the filtering occurs! The NDS authentication is simply based on the association between the NDS user and their IP address. So what you are really doing is filtering based on IP address. When the user authenticates, this association between user and IP address is made, and then filtering can be done. The NDS user name is never sent again ... This is, unless you are using the "proxy/browser" authentication, in which case BorderManager starts to use the security headers in HTTP to pass the session information. > So I say, Scott Lemon is not allowed to login to the @HOME NDS tree > more than once. Ok ... full NetWare client allows this ... the BorderManager authentications don't follow the accounting rules. You can't limit the browser authentications this way (no matter how desparately I asked for this feature!) > Now Scott Lemon sets up a NAT gateway behind his Cable Modem and > plugs 10 home PCs on the ethernet behind the NAT gateway. Scott > goes to his 1st PC and of course has to log into the @HOME NDS > tree. Yes ... and the authentication then causes the association between the NDS user and the NAT IP address. > Thats it, no other login's are allowed for you - the user. So you > go through the NAT and head on out toward the @HOME firewall > (bordermanager). BM says, "ohh your authenticated now as Scott > Lemon, your allowed through)"> Yep ... so I cruise the net to my hearts content ... ;-) > Now Scott lets his buddy on his second computer behind the NAT. The > second computer asks Scott's buddy to authenticate into the @HOME > NDS. And this is where it gets fun. And this is why I have a whole bunch of friends who like to hang out with me ... we get through this kind of stuff easily! ;-) > Scott's friend is not allowed to use Scott's ID since single > login restriction is enable. Scott's friend decides to ignore the > login. Makes a request to go to the Internet site - BorderManager > says "Hmmm - your not authenticated as anyone I know I can allow > through - BYE BYE". Buzzzzzzzzzz ... wrong! Since my buddies would be using my NAT, all of their traffic would appear to emanate from the same IP address. And since the restriction is actually based on this IP address association it would get through just fine ... ;-) (Actually, I have another way that I could easily get around this with shareware also ... ;-) > That is how NAT becomes useless as a cheating method within @HOME. Oops ... but it didn't! For the xact reasons that I was trying to indicate before. The central problem in trying to stop NAT is that all devices appear to be one. If you filter any, then you filter all ... > A logical layer of security makes physical security hacks basically > impossible for the most part - including the NAT concept. Nope .. ain't workin' here ... ;-) > BorderManager that is configured to restrict internet access by NDS > user-ID couldnt care less what your IP address is (legal or > leveraged). Sorry, but that just isn't the way it works. The only way for this to work is to associate the NDS username with an IP address, and then to filter based on that. > I do agree with you that the pain to develop a Directory Enabled > solution is high, but the rewards and opportunities are greater. I would agree that there are many advantages to running a network where the management is based around a directory ... but only if all of the services and applications are integrated. > Yes there may be a few peices missing, but most do exist. I would think that a few of the pieces exist, but more are coming! ;-) Scott C. Lemon