Linux to Linux

[Rick Stevens]

Mark Knecht wrote:
> On Mon, 07 Mar 2005 09:37:06 -0800, Rick Stevens
> <rstevens at vitalstream.com> wrote:
> 
>>brad.mugleston at 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 at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
- grasshopotomaus: A creature that can leap to tremendous heights... -
-                                                ...once.            -
----------------------------------------------------------------------