SMB vs NFS

> Just to clarify my "speculations", this is what you wrote:
>
> -----8<-----
> More like running programs remotely that write to config/log files in
> one place.
> ----->8-----

Allow me to clarify once more :-)
I won't be sharing any system logs, which would most certainly be a security
risk. I believe the other poster implied this. Any programs I run may from
time to time generate error logs, which I don't need (but am not concerned
about sharing).

> > This whole approach will be no less secure than an SSH session.
>
> I disagree, but I'm not going to argue why I think SMB is less secure
> than SSH. Your system, your call. I'd still advice against it tho.

I agree that SMB on its own is less secure than SSH, but I'm interested to
know what possible security breaches can occur on a standalone SMB
installation with password-protected shares (apart from the obvious
un-encrypted data in transit). Not that I want this sort of setup, I'm just
curious.

> A VPN would definitely be my suggestion as well. You can set up such a
> connection point-to-point, assuming that the remote network allows the
> ports for it. Given that you were planning to use SMB ports, I'd be
> extremely surprised if you'd have a problem getting through on ports
> 500 et al for IPSec.

I've only ever used a VPN using Win2k as a client and server. Could you run
over the general layout of a VPN and what sort of file access you get with
it? Which tools do I need to set up a VPN under Linux?


cheers,

C3

So anyway, it was like, 11:40 CET Feb 03 2004, you know? Oh, and, yeah,
C3 was all like, "Dude,

> I've only ever used a VPN using Win2k as a client and server. Could
> you run over the general layout of a VPN and what sort of file
> access you get with it? Which tools do I need to set up a VPN under
> Linux?

You can do it in a number of ways, but there are as I see it two major
approaches. You either have a "client-server" type setup, or you have
some form of transparent (to the user) peer-to-peer solution.

In the former case, you have some sort of client software that
authenticates on a user basis and encrypts traffic from one single
client to what is probably a larger network behind a firewall. Take
for instance SecuRemote (SecureClient) from Checkpoint or the Cisco
VPN client. This requires that each workstation that needs access to
the protected network has to be set up for encryption.

This is probably the method you'd be familiar with from your
experience with setting up w2k.

The latter case means, more or less, two firewalls exchanging
encrypted traffic, each governing their "own" subnet. In this case,
the workstations on either network are unaware of encryption even
taking place.

Depending on your cirumstances, either approach may be in order. In
either case, you can have as much or as little access as you want,
even if TCP is probably more universally supported than UDP.

You'll need to install something like frees/wan for linux, or activate
the isakmp daemon for bsd. As for w2k, you probably know more than I.

Keywords for google would be vpn, ipsec and perhaps isakmp.

hth.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
12:46:38 up 9 days, 20:22, 3 users, load average: 2.05, 2.09, 2.09
$ cat /dev/bollocks Registered Linux user #261729
engage frictionless e-tailers

"C3" <gned@telsmonopolytradotcom.ignore.this> wrote in message news:<401f6332$0$4256$afc38c87@news.optusnet.com.a u>...
> > security tricks that are not known to work simply don't
>
> I'd like to use this as an invitation to anyone who wants to discuss the
> merits and downfalls of this strategy. Speculation won't cut it.
>
> > The port knocking depends largely on security-thru-obscurity. Anyone
> > who does get in will quickly clean up the logs to hide they were ever
> > there.
>
> This is true of any break-in. It has nothing to do with the port knocking
> mechanism.

Obscurity simply hides. If an access route is found, the obscurity
(and likely the security) is gone. _Secure_ authentication and
authorization do _not_ depend on hiding any thing: the mechanisms are
public knowledge, the encryption and key exchange mechanisms that
underlie the A&A implementations are unbreakable (though the same
cannot always be said of the implementations). Obscurity can slow
down the determined, it cannot stop them. It is a useful tool but is
not in itself sufficient (and may "obscure" your own vulnerablilties
to you). Port knocking depends on obscurity -- anyone who duplicates
the sequence is in by design!

> > The fact that you will be connecting from only a few subnets
> > is also of dubious help -- it only reduces the range of valid IP's
> > accepted.
>
> Are you seriously arguing that blocking all but a few subnets is not going
> to improve security, noticeably?

Like obscurity, it slows things down, it does not prevent them. IP
source addresses can and usually are forged by any hacker beyond
script kiddie "nubbie" status. This is the basis of a "sequence
guessing" attack, among others.

>
> > Besides, without an acknowledgement mechanism, there is no
> > way know to be certain that the connection attempts will arrive in the
> > order that you sent them
>
> I consider this to be a positive point. You could think of it as unreliable,
> but I prefer to see it as more reliable because by not acknowledging the
> connection attempt, it does not reveal any information about the presence or
> absence of a network service. Besides, it is one more layer of security that
> is easily logged.

But it depends on each knock arriving in the proper sequence -- there
is no network structural mechanism that ensures this. Without
acknowledgements, failed knocks leave you clueless. "Failed" attempts
in the logs may or may not be signs of breakin attempts -- which won't
matter much if you don't monitor your logs daily. Got scripts?

>
> > this whole approach depends on the
> > arbitrary chacteristics of the net, not on any protocols or mandated
> > net features you can rely on.
>
> If you are referring to timeouts associated with the firewall ruleset, I can
> see what you're getting at. This isn't a big issue for me since the places I
> plan to connect from do not have a significant latency to my server.

See above. I'm talking about TCP/IP protocol requirements and network
transmission characteristics, ie., the stuff _between_ the endpoints,
stuff that you have no control over.

>
> > Re: SMB
> > Let us count the ways this service can/is abused to gain root/admin
> > access. It keeps several ports open that provide "direct" access to
> > security info unless _very_ carefully set up and monitored.
>
> Please back this up with evidence. I'm not going to try to argue that a
> Samba installation accessible from anywhere on the internet is a good idea,
> but I would be interested to know what security issues it may pose, even if
> you exposed ports 137-139 to the whole internet. Assume all shares are
> passworded.

If you can find a remaindered copy of "Hacking Exposed - Win 2000",
buy it before someone else does. Even at the full $35 it is worth it.
There are other books available -- I just happen to be familiar with
this one. It will make you shudder! Try these for a start:
http://www.hackingexposed.com/links/links.htm
http://www.sans.org/rr/catindex.php?cat_id=66
http://neworder.box.sk/codebox.links.php?&key=hack-nt
not to mention sites that specialize and share hack attacks.
>
> > Last, but certainly not least. Of all the files to be accessed over
> > the Internet, config files and logs are certainly, absolutely, without
> > a question, no doubt about it the _very_ worst thing you can do. The
> > only thing worse is to make password and shadow files with world
> > read/write access.
>
> I never, ever planned to share log files. You have taken that from the
> parent poster who was speculating. ...

Think you are correct here.

>... The only config files I will be sharing
> are personal config files with nothing sensitive in them.

Not sure what you mean by "personal" config files, but unless you know
_everything_ they effect and what clues they offer up, you don't
really know what you're exposing -- you may be more "obscured" than
the hacker that knows how to use them. The files themselves may be
harmless, but are you sure that they are properly isolated by
share/file access guards to protect neighboring sensitive files.

>
> > If after all this you're still wanting/needing access as you describe,
> > you really should look into setting up a VPN. Your DIY approach will
> > never be confirmable as safe and once it fails provides an almost
> > instant access route to admin/root (else how would _you_ get access to
> > those log and config files?).
>
> This whole approach will be no less secure than an SSH session.

SSH is fine (and much simpler to set up) if it provides the
"convenience" in use that you seek. VPNs provide a different kind of
accessibility and perhaps the kind of convenience you seek as well as
security. But it can be _very_ tough to set up as each OS/vendor
provides the service in (usually) incompatible ways. Personally, I
would need a _very_ good reason to go down this road (though personal
education generally ranks high on my list of motives).

>
> > At least with VPN you'll be working in
> > several layers of security/encryption.
>
> I will look into setting up a VPN, as well. Thanks for your input.

You might want to look into using VNC together with SSH as a means to
set up a simple VPN that provides access similar to PCanywhere and
Timbuktu. It basically kicks back a desktop, ie., a remote, graphical
desktop. It's like sitting in front of your computer -- keyboard,
mouse, and screen -- from a remote loaction. Not sure about
SMB/Samba, but the tools are available for both Win and Linux. Double
check current security concerns in NGs and Google. VNC is available
here:
http://www.realvnc.com/
Try googling: VNC VPN Linux

>
>
> cheers,
>
> C3

W2K _can_ be made pretty secure, but you have to work at it. It
offers too much backward compatability. Some of the "good stuff"
requires you to edit the registry. One of the first steps to
hardening a W2K box is to eliminate the legacy SMB vulnerabilities as
much as possible -- it is simply too closely tied to the NetBIOS
naming services and (in)security mechanisms. Even this can be
substantially tightened, but again, you have to work at it. As it
comes from the factory, W2K is still vulnerable to a "null session"
exploit that effectively dumps the security database of the whole
system! Exposing SMB on the net, if diligently hardened, _may_
provide a level of risk you're willing to accept -- but not on my
box,ever.

hth,
prg
email above disabled

"C3" <gned@telsmonopolytradotcom.ignore.this> wrote in message
news:401dfec9$0$4249$afc38c87@news.optusnet.com.au ...
> Interesting... The setup I have at the moment involves one Win2k machine
and
> my Linux server which is directly connected to the internet. My win2k
> machine shares some directories via SMB, and my Linux machine also shares
> some directories via SMB.
>
> I'd like to be able to mount drives from either my Linux or Windows
machine
> over the internet. Is it possible to remotely mount Samba shares through
> SSH? Similarly, is this possible from a Windows client (also via SSH)?
>
>
> cheers,
>
> C3
>
>

VPN... compatible with Windows, WinCe and Linux
http://www.poptop.org

Handy for running mounts over the net, as well as Netmeeting and
other nasty things, that you don't want to cripple your firewall
to permit.

Oh yeah, its free :-)

Have fun,
Mangled & Munged

I'll have a look at it.

cheers,

C3

"Johan Lindquist" <spam@smilfinken.net> wrote in message
news:6se4f1-o6j.ln1@news.smilfinken.net...
> Take
> for instance SecuRemote (SecureClient) from Checkpoint or the Cisco
> VPN client. This requires that each workstation that needs access to
> the protected network has to be set up for encryption.