[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Linux to Linux



Mark Knecht wrote:
On Mon, 07 Mar 2005 09:37:06 -0800, Rick Stevens
<rstevens vitalstream com> wrote:

brad mugleston comcast net wrote:

What am I doing wrong?  I seem to have no problem networking from
Windows to Windows or Windows to Linux or Linux to Windows but
for some reason I can get my Linux to Linux network talking to
each other.

I need some instructions - simple if possible.  It seems that
people have gone to great lengths to simply describe or simplify
the Windows connection (using SAMBA) but when I start looking at
Linux to Linux connections it's all in tech talk which is over my
head.

I will do it command line (as long as its permanent) or using
WebMin or something else if needed.  I need to know how to
configure things or what ever I need to do.

I want to share drives and printers.

I'm running RH9.0 on one machine and RH FC2 on the other (this
one is also a notebook with a wireless network adapter).  Like I
said I can share drives and printers with my windows machines but
these two don't want to play nice and share.

As far as sharing files, Linux "speaks" two languages, Samba and NFS (network file system). You already seem to know about Samba, since you're sharing files between Linux and Windows (which is the hardest bit).

A samba server shares its files by specifying those files in a "[label]"
stanza in /etc/samba/smb.conf and runs the nmbd and smbd daemons.  I
assume you know how to set that up.  Conversely, a samba client simply
mounts shares by use of the "mount -t smbfs" command (or by specifying
"smbfs" in the /etc/fstab).

Similar stuff is done in NFS.  An NFS server puts the directories it
wishes to share in the /etc/exports file (see "man exports").  The
server then runs several daemons: portmapper, rpc.lockd, rpc.statd and
rpc.nfsd to share those directories out.  Conversely, an NFS client runs
portmapper and mounts the directories via "mount -t nfs" (or specifying
"nfs" in the /etc/fstab entry).

If you could be a bit more specific in what you want to do, I can help
more.


One thing I found was that for my network  I had to turn the iptables
firewall off on then Linux machine that was sharing an NFS mount or
the other machines on the network couldn't mount it. I thiink this was
due to the way NFS sets up ports? I didn't know where to make changes
in the way NFS gets started to make it run on a fixed port so this
worked but I wasn't overly happy with the solution.

NFS uses portmapper to map ports and these can vary widely. Predicting which is going to be used is difficult as portmapper can dynamically change things. You can bypass portmapper to some extent by launching the majority of NFS-related services with specified ports.

The only two ports you can be sure of is that portmapper listens on port
111, rpc.nfsd normally uses port 2049 (note: both TCP and UDP--NFS is
primarily a UDP service).  rpc.mountd, rpc.statd, and rpc.lockd normally
use ports assigned by portmapper, but you can specify which ports to use
by means of the "-p portnumber" option on most of those commands.  Then
simply ensure that you leave those ports open on your firewall.

That's still a security issue.  You really only want to allow the NFS
stuff between SPECIFIC machines anyway.  I'd prefer you do something
like permitting any traffic between your known NFS clients and servers,
and block all else.  This is a highly restrictive firewall, but here
are some suggested rules:

	iptables -P INPUT DROP
	iptables -A INPUT -p tcp -s NFS-buddy/netmask -d 0/0 -j ACCEPT
	iptables -A INPUT -p udp -s NFS-buddy/netmask -d 0/0 -j ACCEPT

and so on.  Also note that portmapper is tcp-wrappers-aware, so you
could use tcpwrappers to restrict access to the portmapper from the
outside world.  The portmapper issue is similar to the FTP issue as far
as port assignments are concerned, but you really can't use the
"ESTABLISHED" or "RELATED" part of the conntrack module of iptables
since most NFS traffic is UDP.  You can use TCP (and if you have high
traffic levels, I'd suggest using it) by specifying "tcp" in the mount
command options.

How do we do it?  All of our NFS traffic is done over a backside network
that is not routable (10/8 or 192.168/16).  All nodes that need access
to the NFS data must have a NIC on that network.  We allow NFS traffic
ONLY over that network.  Nodes that have NICs on that network AND one on
the public internet are firewalled out the wazoo on the public side and
are kept as current as possible WRT security updates. The NFS data is
exported only to specific clients as well.

BTW, the only hack we ever saw is because our NFS servers also export
the data via CIFS (Windows networking) and one of our IIS servers was
hacked (gee, someone broke into a Windows box that had all of the latest
security patches...what a surprise!)  We've never had a NFS compromise
with Linux boxes.

If you're concerned, this is the solution I think best.  Two networks,
one backside for private stuff like NFS, backups, and management; and
one for the "public" face which is heavily firewalled.  NFS was designed
for LANs primarily and back when the internet was a kinder and gentler
place.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens vitalstream com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
- grasshopotomaus: A creature that can leap to tremendous heights... -
-                                                ...once.            -
----------------------------------------------------------------------


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]