I've been to the Soudan mine and the underground lab. Heck, I helped get them wired up. The network at the site is all fibre-optic and, except for the VAXen they still had running a few of years back, it is (or was) all very state-of-the art. The uplink, however, is a different story.
Perhaps this new project, which they've actually been working on for years, will give them the boost they need to get a fiber run from Ely. Maybe they've gotten it already. When I was working with the project, we had to run fiber to a hut on a hill, run coax to the other company's hut, microwave the signal to Tower, MN, and then run it over 11 pair of copper to Soudan.
It worked.
If you like the outdoors and like to travel, it's beautiful country up there. If you don't mind the skeeters and the black flies. The Soudan Mine is actually a state park, and during the summer months you can visit. They run tours down the mine on a regular basis. You ride a car down an incline into the mine, about a half mile down and they walk you around and show you how the mining was done. Greenstone and iron... the iron so pure you can weld to it.
If you catch the 10 am tour (double check me on that before you go) you also get a tour of the Physics lab. It puts the BatCave to shame--and yes, there are plenty of bats down there. The lab is carved out of the rock and iron of the mine and it looks like a set from a War Games or Dr. Strangelove type movie. Huge (very) steel plates hang from railings overhead, with fine fiber optic cable running through them, trying to catch a glimpse of a neutrino or two as they fly through. The neutrinos, of course, are being fired at Soudan from Fermilab in Illinois.
Worth the trip, just to see the mine, but the Physics lab is icing on the underground cake.
I tend to keep things simple. I wrote Implementing CIFS in very plain HTML. Yes, by hand. No, I didn't flail myself with birch bows or kneel on jacks just to prove my inner strength. It was honestly the simplest, easiest way to format everything. Mind you, I had a very supportive publisher.
...and I used to write college papers in Runoff, so I'm used to that kind of markup.
...and I would probably want to learn Docbook if I were to do it all over again.
What they had was greywater—wastewater that is undrinkable but perfectly useful for simple jobs like filling the toilet tank for flushing. Re-use of greywater is a well-known practice among conservationists and environmentalists and anyone concerned about fresh water usage. I'm in Saint Paul, and I know folks hosting protesters. I'm not making this up.
Think for a second... How practical would it be—even for a so-called "anarchist"—to store and tote buckets of urine up the hill to the convention site and fling it at anyone? A five-gallon bucket of water would weigh over 40lbs. If someone were aiming at causing that kind of trouble there are better, easier ways I'm sure.
The reports I have read from local sources indicate that the raid in Saint Paul was lead by the county sheriff, not by St. Paul police (though St. Paul officers were present). The Saint Paul police have saved my tail more than once and have my respect. I hope they don't get mired in this mess.
Legendary guitar great Richard Thompson has done covers of "Oops!". If you don't want to be caught listening to Brittany, you can download a free copy via Thompson's site.
Sorry for the confusion over the hashes. Let me explain...
Yes, there's such a thing as an NTLMv2 Hash. It is calculated using the NTLMv1 Hash, the username, and the login destination which may be a domain name or server name. That last input can (from the client's perspective) change with each login, so there's no real benefit (on the client side) of storing the NTLMv2 Hash.
It may be that Domain Controllers do store this value, but my guess is that they store only the NTLMv1 Hash and recalculate the NTLMv2 hash on the fly. The client is pretty much required to calculate the whole thing.
That's probably more detail that folks really want...:)
Chris -)----- PS. The book is a reference manual... of sorts. The print version is 1.5 inches thick, and it includes the SNIA CIFS Technical Reference.
PPS. Rabbit pellet mode... One of the Ethereal folks thinks he's got this nailed. Seems there's a layering violation in Microsoft's stack. If the lower TCP layers sense changes in latency they send a message up the stack and the CIFS layer tries to compensate.
Passwords longer than 14 bytes (OEM Charset) are truncated to form the LM Hash. The LM Hash may still be stored, it's just that you don't gain anything by having a password longer than 14 bytes.
If you disable LM Hashes altogether (as explained elsewhere in the comments) then you only have to worry about protecting the (stronger) NTLM Hash.
The NTLM hash is the MD4() of the full mixed case password in Unicode (UCS-2LE) password string.
The LM and NTLM hashes are what really need to be protected. They are (as I keep saying...sorry I'm on a rant) password equivalent. Once someone has the hash the password itself is of minimal additional value.
Note that it is fairly easy to discover the LM Hash given an LM challenge/response pair. That's why the LM challenge/response should not be allowed on the wire.
It's also possible to reverse the hash from the NTLM, LMv2, and NTLMv2 challenge/response protocols, but it gets progressively harder as the algorithms improve.
LM = Lan Manager, the Windows 95 way of handling network passwords.
LAN Manager was more than just the password system, and it dates back well before W95.
hash = a way of storing passwords without leaving the password on the disk. You encrypt the password into a hash code and store that instead. You can't unencrypt it to derive the password but you can check a password guess by encrypting the guess the same way. If the guess hash == the password hash, you get in.
Yes, a good explanation, except... Unix systems generally add a bit of "Salt" to the hash so that the hash itself is not password equivalent. I have to be honest and state that I'm not sure exactly how that works. I'll have to do some reading in Schneier tonight.:)
The best part is, you don't have to keep the hash code a secret, because it's not the hard part. You're not asked to provide the hash value; you're asked to provide something that hashes to the value. So you can store it on the disk and even send it out over the LAN where it can be sniffed.
Nope. This may be true if salt is used, but there is no salt used when creating the LM or NTLM hashes. That, combined with the mechanism used for network authentication, result in this oft-forgotten fact: Windows LM and NTLM Hashes are password equivalent. They must be protected because, basically, they are the passwords!
That's very convenient: you can cache the hash code on every computer without having to trouble the central server to do the work. You don't want to send the password over the network (where it could be sniffed); nor is sending the hash code to the server for verification (because that could be spoofed). You distribute the hash to each computer, then let it decide if the password guess is correct. The password never goes across the network.
Ouch...no. That works for public key cryptography but you're describing a symmetric key system. Password hashes must be protected, even those with salt. That's why the password hashes on Unix systems are stored in the shadow files instead of the passwd file.
I've already described challenge/response in other posts on this topic. I'm in major fud-fight mode here. Read the docs: http://ubiqx.org/cifs/SMB.html#SMB.8.
They improved on it a while ago (NTLMv2) but still transmit the LM hash by default in all authentication - basically rendering the security of NTLMv2 completely useless.
The hashes are never transmitted on the wire during authentication. The mechanism is challenge/response, and the hashes are used by both the client and the server to encrypt the same random string. The server compares the results in order to determine whether or not the client knows the hash.
There are two hashes used: LM and NTLM. The LM Hash is used with LM Challenge/Response, and the NTLM Hash (which is the MD4() of the raw Unicode password string) is used for NTLM, NTLMv2, and LMv2 Challenge/Response. Two hashes, four mechanisms.
...then, of course, there's Kerberos.
The things that people keep missing in this discussion are:
The hash is somewhat protected. You'd need to reverse the hash from the challenge/response or have direct access to the password files on the client or server in order to obtain the hash.
Once you have the hash, you don't need the original password. The password is only used to generate the hash. All of the authentication steps are done using the hash, not the password.
It is possible to reverse the hash given the challenge and response. The LM Hash is much easier to reverse than the NTLM Hash, but the only way that this database will help is as a LM Hash dictionary.
Basically, the hashes are generated with no salt...nothing to obfuscate them. The algorithm used to log in is challenge/response:
The server sends a random 8-byte string (the "challenge").
Both client and server encrypt the challenge using the LM and/or NTLM Hash, not the password.
The client sends its result (the "response") back to the server.
The server compares results. If they match, the server grants access.
So... The hash is not exposed on the wire.
It has to be reversed from the challenge and response. That's possible (and fairly easy with LM Auth), but it's got little to do with the password/LM Hash database.
The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.
There are two things people always forget about LM Hashes:
They are not exposed on the wire.
They are password equivalent.
The LM logon protocol is challenge/response. The server sends a random 8-byte string (the challenge) and both client and server encrypt it. The client sends back the result (the response) and the server checks to see if the responses match. If so, you're in.
Note that the hash is not sent over the wire.
That's important, because (large databases and rainbow tables aside) you don't need the original password. The hash is computed with no salt, so it is completely password-equivalent. Someone with access to the above documentation and the LM or NTLM hash has all they need in order to fake a login.
Chris -)-----
No, please don't do that!
on
Implementing CIFS
·
· Score: 2, Informative
One of the most common causes of network browsing problems is binding NetBIOS to multiple protocols. I have solved many, many such problems by going through all of the Windows workstations and servers and making sure that they are all configured to use the same single transport.
If you use NetBEUI, then use *only* NetBEUI.
If you use NWLINK, then use *only* NWLINK.
etc.
See the heading "Prolific Protocol Bindings" in Section 3.7.1 of the online version of the book.
Stress? Not from my systems. It's from the don't-getitude all around me. I'm constantly fighting with people who have more power and less understanding.
Scott Adams has documented this phenomemon in one of his Dilbert management books.
I have gotton no further response from Linksys, and the sources for the EFG80 have not been posted on their GPL source web site. I am fairly confident, however, that this is just a case of things moving slowly.
It would help if someone out there who has an EFG80 could verify that the sources are on the accompanying CD-ROM (and that they produce workable binaries).
Some vendors who use Samba will provide a test unit to the Team or access to a system at their end for use in the build farm, but that is certainly not a requirement. It just helps them, and us, keep everything working smoothly.
You need the NBT and CIFS stuff to implement the framework for carrying the MSRPC garbage. Otherwise, you're absolutely correct. Too much of the filesharing system relies on MSRPC now.
Thing is, most of what is done via MSRPC could be done without. MSRPC obfuscates things and makes the protocol more bulky, unwieldy, and annoying. I'm sure it benefits someone somehow. It seems to me that whenever the coders in Redmond want to do something they just add another RPC call to handle it...even if it can already be handled at the SMB/CIFS level.
The reason the SNIA stuff is interesting is that it is more complete and correct than the release Microsoft did last week, and it doesn't have the goofy licensing flaming hoop. That helps to show that Microsoft did not provide anything new or significant by releasing their CIFS docs.
Personally, I think that the reason that there is no value in Microsoft (or anyone else) releasing CIFS docs is that the protocol has spun out of control and is of no value any more. It needs to be retired and replaced with something that is open and freely implementable. Not a likely scenario...
According to this post on Samba Technical, the Storage Network Industry Association will soon release version 1.0 of their SMB/CIFS documentation. Version 0.9 has been available for some time.
The SNIA doc was based on the earlier Leach/Naik IETF draft, but was updated based on input from many sources, including IBM, HP, the jCIFS Team, Microsoft, NetApp, the Samba Team, and others. The new SNIA doc does not have the licensing restrictions of the Microsoft release.
It may not be clear to the moderators that CIFS and SMB are the same thing (well, the former being a "marketing upgrade"). Not unreasonable, as the lack of distinction is somewhat obscured.
--JLM
Re:Samba validates Microsoft
on
Samba Turns 10
·
· Score: 1
This is a valid point and well worth considering.
Regarding the "MS altered standards"... SMB itself has never been a standard. Microsoft's implementation of STD 19 (RFC 1001/1002) is very broken, however, and yes we do copy them on that. (I'm working on documenting their implementation errors.) Others, like their Kerberos PAC manglement and the evil they've done to/with DCE/RPC... again, this is a valid perspective and one that has not been lost on us.
On the plus side, by doing the work we do we expose some of these problems, and hopefully work toward raising awareness.
Thanks.
Chris Hertel -)-----
Samba Team
Re:New version => support for more hardware ?
on
OpenBSD 2.5 released
·
· Score: 1
If you're able to tweak things enough to get the SCSI working, perhaps you'd be able to add support for your card to the driver set.
In addition to voice and fax cards, I'm interested in switching functionality.
Hardware exists that makes it possible to build small and/or large-scale PBX switches using PCs. It should be possible to create a large, distributed (possibly even redundant) telephone switching system from these parts. Such a system could be used as the core of a telephone system for a large company or university campus.
So, is anyone working on this sort of application?
Slashdot Mirror
I've been to the Soudan mine and the underground lab. Heck, I helped get them wired up. The network at the site is all fibre-optic and, except for the VAXen they still had running a few of years back, it is (or was) all very state-of-the art. The uplink, however, is a different story.
Perhaps this new project, which they've actually been working on for years, will give them the boost they need to get a fiber run from Ely. Maybe they've gotten it already. When I was working with the project, we had to run fiber to a hut on a hill, run coax to the other company's hut, microwave the signal to Tower, MN, and then run it over 11 pair of copper to Soudan.
It worked.
If you like the outdoors and like to travel, it's beautiful country up there. If you don't mind the skeeters and the black flies. The Soudan Mine is actually a state park, and during the summer months you can visit. They run tours down the mine on a regular basis. You ride a car down an incline into the mine, about a half mile down and they walk you around and show you how the mining was done. Greenstone and iron... the iron so pure you can weld to it.
If you catch the 10 am tour (double check me on that before you go) you also get a tour of the Physics lab. It puts the BatCave to shame--and yes, there are plenty of bats down there. The lab is carved out of the rock and iron of the mine and it looks like a set from a War Games or Dr. Strangelove type movie. Huge (very) steel plates hang from railings overhead, with fine fiber optic cable running through them, trying to catch a glimpse of a neutrino or two as they fly through. The neutrinos, of course, are being fired at Soudan from Fermilab in Illinois.
Worth the trip, just to see the mine, but the Physics lab is icing on the underground cake.
http://www.dnr.state.mn.us/state_parks/soudan_underground_mine/index.html
I tend to keep things simple. I wrote Implementing CIFS in very plain HTML. Yes, by hand. No, I didn't flail myself with birch bows or kneel on jacks just to prove my inner strength. It was honestly the simplest, easiest way to format everything. Mind you, I had a very supportive publisher.
...and I used to write college papers in Runoff, so I'm used to that kind of markup.
...and I would probably want to learn Docbook if I were to do it all over again.
What they had was greywater—wastewater that is undrinkable but perfectly useful for simple jobs like filling the toilet tank for flushing. Re-use of greywater is a well-known practice among conservationists and environmentalists and anyone concerned about fresh water usage. I'm in Saint Paul, and I know folks hosting protesters. I'm not making this up.
Think for a second... How practical would it be—even for a so-called "anarchist"—to store and tote buckets of urine up the hill to the convention site and fling it at anyone? A five-gallon bucket of water would weigh over 40lbs. If someone were aiming at causing that kind of trouble there are better, easier ways I'm sure.
The reports I have read from local sources indicate that the raid in Saint Paul was lead by the county sheriff, not by St. Paul police (though St. Paul officers were present). The Saint Paul police have saved my tail more than once and have my respect. I hope they don't get mired in this mess.
Cray, which still exists and still builds and sells Supercomputers, also runs Linux.
http://www.cray.com/products/xt5/index.html
Credit where it is due.
http://www.eecs.umich.edu/~fessler/misc/funny/gore,net.txt
...which is why nowheresville, UT, is deploying their own.
'Course, communities solving their own problems might seem a bit "leftist" to some folks.
Legendary guitar great Richard Thompson has done covers of "Oops!". If you don't want to be caught listening to Brittany, you can download a free copy via Thompson's site.
Sorry for the confusion over the hashes. Let me explain...
Yes, there's such a thing as an NTLMv2 Hash. It is calculated using the NTLMv1 Hash, the username, and the login destination which may be a domain name or server name. That last input can (from the client's perspective) change with each login, so there's no real benefit (on the client side) of storing the NTLMv2 Hash.
It may be that Domain Controllers do store this value, but my guess is that they store only the NTLMv1 Hash and recalculate the NTLMv2 hash on the fly. The client is pretty much required to calculate the whole thing.
That's probably more detail that folks really want... :)
Chris -)-----
PS. The book is a reference manual... of sorts. The print version is 1.5 inches thick, and it includes the SNIA CIFS Technical Reference.
PPS. Rabbit pellet mode... One of the Ethereal folks thinks he's got this nailed. Seems there's a layering violation in Microsoft's stack. If the lower TCP layers sense changes in latency they send a message up the stack and the CIFS layer tries to compensate.
Excluding Kerberos authentication (which I should know more about, but don't) there are *two* hash types: LM and NTLM.
The LM Hash is used when performing LM challenge/response.
The NTLM Hash is used when performing NTLM, LMv2, and NTLMv2 challenge/response. Note that LMv2 is simply a degenerate case of NTLMv2.
I've written a book with a whole whoppin' big section on LM and NTLM auth: http://ubiqx.org/cifs/SMB.html#SMB.8.
Scroll down for information on specific auth protocols.
Chris -)-----
If you disable LM Hashes altogether (as explained elsewhere in the comments) then you only have to worry about protecting the (stronger) NTLM Hash.
The NTLM hash is the MD4() of the full mixed case password in Unicode (UCS-2LE) password string.
The LM and NTLM hashes are what really need to be protected. They are (as I keep saying...sorry I'm on a rant) password equivalent. Once someone has the hash the password itself is of minimal additional value.
Note that it is fairly easy to discover the LM Hash given an LM challenge/response pair. That's why the LM challenge/response should not be allowed on the wire.
It's also possible to reverse the hash from the NTLM, LMv2, and NTLMv2 challenge/response protocols, but it gets progressively harder as the algorithms improve.
It's all documented.
Chris -)-----
LAN Manager was more than just the password system, and it dates back well before W95.
hash = a way of storing passwords without leaving the password on the disk. You encrypt the password into a hash code and store that instead. You can't unencrypt it to derive the password but you can check a password guess by encrypting the guess the same way. If the guess hash == the password hash, you get in.
Yes, a good explanation, except... Unix systems generally add a bit of "Salt" to the hash so that the hash itself is not password equivalent. I have to be honest and state that I'm not sure exactly how that works. I'll have to do some reading in Schneier tonight. :)
The best part is, you don't have to keep the hash code a secret, because it's not the hard part. You're not asked to provide the hash value; you're asked to provide something that hashes to the value. So you can store it on the disk and even send it out over the LAN where it can be sniffed.
Nope. This may be true if salt is used, but there is no salt used when creating the LM or NTLM hashes. That, combined with the mechanism used for network authentication, result in this oft-forgotten fact: Windows LM and NTLM Hashes are password equivalent. They must be protected because, basically, they are the passwords!
That's very convenient: you can cache the hash code on every computer without having to trouble the central server to do the work. You don't want to send the password over the network (where it could be sniffed); nor is sending the hash code to the server for verification (because that could be spoofed). You distribute the hash to each computer, then let it decide if the password guess is correct. The password never goes across the network.
Ouch...no. That works for public key cryptography but you're describing a symmetric key system. Password hashes must be protected, even those with salt. That's why the password hashes on Unix systems are stored in the shadow files instead of the passwd file.
I've already described challenge/response in other posts on this topic. I'm in major fud-fight mode here. Read the docs: http://ubiqx.org/cifs/SMB.html#SMB.8.
Chris -)-----
The hashes are never transmitted on the wire during authentication. The mechanism is challenge/response, and the hashes are used by both the client and the server to encrypt the same random string. The server compares the results in order to determine whether or not the client knows the hash.
There are two hashes used: LM and NTLM. The LM Hash is used with LM Challenge/Response, and the NTLM Hash (which is the MD4() of the raw Unicode password string) is used for NTLM, NTLMv2, and LMv2 Challenge/Response. Two hashes, four mechanisms.
...then, of course, there's Kerberos.
The things that people keep missing in this discussion are:
- The hash is somewhat protected. You'd need to reverse the hash from the challenge/response or have direct access to the password files on the client or server in order to obtain the hash.
- Once you have the hash, you don't need the original password. The password is only used to generate the hash. All of the authentication steps are done using the hash, not the password.
It is possible to reverse the hash given the challenge and response. The LM Hash is much easier to reverse than the NTLM Hash, but the only way that this database will help is as a LM Hash dictionary.Chris -)-----
If you have the LM Hash, and the server accepts LM Authentication, you don't need the password. At all.
Likewise, if you have the NTLM Hash, and the server accepts NTLM, NTLMv2, or LMv2 authentication, then you don't need the password.
The hashes are password equivalent.
I've written it all up in my online book (slashdot review), but...
Basically, the hashes are generated with no salt...nothing to obfuscate them. The algorithm used to log in is challenge/response:
So... The hash is not exposed on the wire. It has to be reversed from the challenge and response. That's possible (and fairly easy with LM Auth), but it's got little to do with the password/LM Hash database.
The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.
Chris -)-----
- They are not exposed on the wire.
- They are password equivalent.
The LM logon protocol is challenge/response. The server sends a random 8-byte string (the challenge) and both client and server encrypt it. The client sends back the result (the response) and the server checks to see if the responses match. If so, you're in.Note that the hash is not sent over the wire.
That's important, because (large databases and rainbow tables aside) you don't need the original password. The hash is computed with no salt, so it is completely password-equivalent. Someone with access to the above documentation and the LM or NTLM hash has all they need in order to fake a login.
Chris -)-----
If you use NetBEUI, then use *only* NetBEUI.
If you use NWLINK, then use *only* NWLINK.
etc.
See the heading "Prolific Protocol Bindings" in Section 3.7.1 of the online version of the book.
Stress? Not from my systems. It's from the don't-getitude all around me. I'm constantly fighting with people who have more power and less understanding.
Scott Adams has documented this phenomemon in one of his Dilbert management books.
I have gotton no further response from Linksys, and the sources for the EFG80 have not been posted on their GPL source web site. I am fairly confident, however, that this is just a case of things moving slowly.
It would help if someone out there who has an EFG80 could verify that the sources are on the accompanying CD-ROM (and that they produce workable binaries).
Some vendors who use Samba will provide a test unit to the Team or access to a system at their end for use in the build farm, but that is certainly not a requirement. It just helps them, and us, keep everything working smoothly.
Chris -)-----
Thing is, most of what is done via MSRPC could be done without. MSRPC obfuscates things and makes the protocol more bulky, unwieldy, and annoying. I'm sure it benefits someone somehow. It seems to me that whenever the coders in Redmond want to do something they just add another RPC call to handle it...even if it can already be handled at the SMB/CIFS level.
The reason the SNIA stuff is interesting is that it is more complete and correct than the release Microsoft did last week, and it doesn't have the goofy licensing flaming hoop. That helps to show that Microsoft did not provide anything new or significant by releasing their CIFS docs.
See also: http://www.theregister.co.uk/content/53/24490.html .
Personally, I think that the reason that there is no value in Microsoft (or anyone else) releasing CIFS docs is that the protocol has spun out of control and is of no value any more. It needs to be retired and replaced with something that is open and freely implementable. Not a likely scenario...
-- JLM
According to this post on Samba Technical, the Storage Network Industry Association will soon release version 1.0 of their SMB/CIFS documentation. Version 0.9 has been available for some time.
The SNIA doc was based on the earlier Leach/Naik IETF draft, but was updated based on input from many sources, including IBM, HP, the jCIFS Team, Microsoft, NetApp, the Samba Team, and others. The new SNIA doc does not have the licensing restrictions of the Microsoft release.
-- JLM
It may not be clear to the moderators that CIFS and SMB are the same thing (well, the former being a "marketing upgrade"). Not unreasonable, as the lack of distinction is somewhat obscured.
--JLM
Regarding the "MS altered standards"... SMB itself has never been a standard. Microsoft's implementation of STD 19 (RFC 1001/1002) is very broken, however, and yes we do copy them on that. (I'm working on documenting their implementation errors.) Others, like their Kerberos PAC manglement and the evil they've done to/with DCE/RPC... again, this is a valid perspective and one that has not been lost on us.
On the plus side, by doing the work we do we expose some of these problems, and hopefully work toward raising awareness.
Thanks.
Chris Hertel -)-----
Samba Team
If you're able to tweak things enough to get the
SCSI working, perhaps you'd be able to add support
for your card to the driver set.
...and yes, don't forget NetBSD...
juan
Umm.... Keep the GPL in mind. Even a custom Linux *must* be available under the GNU Public License. (I.e., you could sue *them*.)
juan
In addition to voice and fax cards, I'm interested in switching functionality.
Hardware exists that makes it possible to build small and/or large-scale PBX switches using PCs. It should be possible to create a large, distributed (possibly even redundant) telephone switching system from these parts. Such a system could be used as the core of a telephone system for a large company or university campus.
So, is anyone working on this sort of application?
Juan