On Wed, 20 Feb 2002, Victor Usjanov wrote:

> I agree with you, but we use NIS domain and NFS for mounting of user home
> areas .. So that i why i am running NFS- to get my home area when i log on
> other computers over here.

Do you have the resources to put the users who are mounting NFS home
partitions on a firewalled LAN rather than having them mount their
partitions across the Net? Something simple like this:

   ------------                         ---------
  (            )      ----------       (         )
 (   internet   )----| Firewall |-----(    LAN    )
  (            )      ----------       (         )
   ------------                         ---------

Where the LAN contains the NFS server and the client workstations that
will be mounting their home partitions from the server? 

Even if you did have distributed users (across the net), you could set up
a VPN using either Freeswan on a Linux firewall, built-in ipsec on
OpenBSD, or (pay for a 3DES key) for ipsec on a Cisco PIX. Then NFS
traffic (and any traffic) between the clients and the NFS server will be
significantly better protected. (obviously goes for samba, etc.)

> Did that, but anyway i had to have "-A input -s our_nettwork -d
> my_ip_here -i eth0 -j ACCEPT " to get it working. Without it it was just
> standing and searching for computer, and gave me an error. I put that in,
> and restart ipchains (ipchains restart), and it goes right it..This part i
> am not sure that i undertand - course the line above makes me wide open, but
> things does not work without it. Just to remind - i have just one eth i this
> PC.

For the input and output chains, the rules apply to every interface on the
system (lo, eth0, eth1, ppp0, eth0:0, eth0:1, etc.), unless the rule
specifically identifies a particular interface. 

If you only have one interface (eth0), specifying it in the rules
shouldn't be necessary. If you run "ipchains -L -n -v", it should indicate
a "*" under "ifname" for the interfaces to which the rules are applied.

For example, if you had a rule:
-A input -p tcp --dport ftp -j REJECT

ipchains would fill in all of the unspecified elements with default
wildcard values (-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 ftp -p tcp
-j REJECT) and the would apply to all interfaces.


> I have tried to modify the line that you suggested above to "-A input -s
> 0/0 -d 0/0 -i eth0 -p tcp ! -y -j ACCEPT", but it did not help either.

That would only help with applications *initiated from* the machine
loading the ipchains. So it will only help clear-up extraneous problems,
like initiating outbound tcp applications (ssh, telnet, basic nmap scans,
etc.).

You might consider 

1.) adding logging to the NFS and samba chains (-l -j ACCEPT) and running
"tail -f /var/log/messages" while attempting a connection from one of your
clients 

or

2.) employing tcpdump to monitor the interface while attempting to
initiate an nfs mount from one of your clients. 

This will help determine whether the connections are even able to "run the
gauntlet". If you are receiving the packets, then you can start narrowing
down where the problem is.

wishing you success! :)

justin 




Reply via email to