[Samba] Fwd: The network path was not found.
gregs at sloop.net
Thu Apr 11 09:13:33 MDT 2013
>> And IMO, trying to do this, while streaming the CIFS data and login
>> via the unprotected and vast-vagaries of the open internet - well that
>> just seems pretty crazy to me.
H> Is CIFS data unencrypted or unprotected, or have some other vulnerability I
H> should be aware of?
I believe the authentication transactions are secure - though I'd
still rather not having these streaming over a totally insecure
network - even if they are, it allows a larger attack surface for
attackers to go after. [The whole AD...]
But if you open/save files, I don't believe that there's any encryption
on those at all. Anyone in the packet path could reconstruct all/any
files - and perhaps even inject data into the packet-streams.
So, I think the Auth system is secure, actual file use under CIFS
[Someone correct me if I'm wrong here...]
H> I'm setting up a central auth system for a hackerspace. A lot of vagaries
H> of the internet come inside the private lan anyway. Non-secured networks
H> is just something I am going to have to handle.
I do understand this - but limiting attack surface is, IMO, really
important. No reason to get your whole server owned because you've let
at attacker get to a service you didn't really need to offer. IMO,
make each server as secure as you can, but also use the firewall [et
al] as a 2nd or 3rd layer to limit what an attacker can get at in each
>> You'll have no idea what might be happening to the traffic, not to
>> mention the security and integrity of the connections.
H> I was asuuming, perhaps incorrectly, that the data could be encrypted
H> without the need of a tunnel. I still assume that the ldap and kerberos
H> data is safe. If not I need to abondon this approach altogether.
As said above, I think LDAP and K are secure. CIFS data isn't.
>> As was mentioned before...
>> Is there some reason you're not running this over a tunnel of some
>> sort? Even if you completely strip the encryption away [which seems
>> like a nearly equally terrible idea] you'll at least know, that if the
>> tunnel works at all, someone isn't messing with something inside the
>> tunnel -
>> it [the tunnel] is either up or down. And then you don't have to worry
>> about Comcast filtering CIFS ports, or messing with the traffic with
>> sandvine etc.
H> I am avoiding running a tunnel, but not refusing too. I felt the SRV
H> record approach was worth investigating.
H> The reason for avoiding using a tunnel is to reduce the overhead of adding
H> machines to the domain. Also, I havn't set up a vpn for this site yet.
>> So, really - building a tunnel - even a simple one would be cheap and
>> easy. Why make this so hard on yourself and burden everyone else with
>> troubleshooting a problem that might have a million different issues
>> that would be completely out of your control and would require hours
>> and hours of troubleshooting to find, much less resolve.
H> I was trying to save the time of first establishing a vpn conneciton, and
H> then using services. I was trying to go straight to the using services
H> Reducing troubleshooting is the goal I had with adjusting SRV records. I
H> have also heard of L2TP getting wonky if 2 users use it from behind the
H> same NAT. I am still concerned that adding a VPN increases complexity
H> instead of reduces it. You are probably right that I have no better
H> alternative at this point.
Yes, I think there's a problem with multiple L2TP users behind the
same NAT. But why not build site-to-site tunnels, and do that instead
of each user as an individual island. I do think OVPN handles this
>> [A couple of Routerboard's would do the trick, and if you don't need
>> huge levels of VPN throughput, a pair of RB750's are probably < $150 -
>> just one example...]
>> A VPN or other tunnel is really the only answer.
H> Agreed, I'm thinking of giving
H> shot before falling back to openvpn.
>> I'm sure that's not the answer you want - but IMO, it's the only
>> reasonable answer.
H> Don't get me wrong, I really do appreciate your help.
More information about the samba