Help - Search - Members - Calendar
Full Version: Disabling Firewall On 1 Of 2 Nics
Linuxhelp > Support > Technical Support
cmcp
I've more-or-less got a client setup properly for NFS, but now I think that the NFS server's firewall is too strict and results in a time out error. The server has two NIC cards -- eth0, which is for the internet and outside connections, and eth1, which is for the private network that the NFS clients are on.

As it is, the firewall on the server applies to both eth0 and eth1. I am interested in flushing all the rules (disabling the firewall) on eth1, the private NIC, which will hopefully allow it to serve NFS mounts. Does anybody know what file(s) I need to modify or what command(s) I need to issue to flush the IPTables rules for eth1? Thanks in advance for your help!
Joey
Are you running the IPTables script from the Guides Page?

If so try adding this to it:

$IPT -A INPUT -i eth1 -j ACCEPT
cmcp
I haven't tried using the IPTables script yet because the firewall on the server is set up basically how I want it (except for the eth1 firewall that I am trying to remove) and I don't want to risk changing it somehow by running the script and not knowing what some of its rules do exactly.

Is there a file (or more than one file) that I can just add "$IPT -A INPUT -i eth1 -j ACCEPT" to in order to make the change? I might try using the script later if nobody knows what files need to have that rule added, but I would prefer to just manually modify the file(s) to make sure that I don't mistakenly change something important to the firewall. Thanks again for your help.
Joey
I've never used the default firewall setup with redhat so I'm not sure where they store their rules. Check to see if you have /etc/init.d/iptables and if so you might be able to add it in there.

Actually, as root run this:

iptables -L

It should print out your current rule set.

If that works just run

iptables -A INPUT -i eth1 -j ACCEPT
hughesjr
The default location of the file to edit (for RedHat) is:

/etc/sysconfig/iptables

If you are using the RedHat 9 Distro and are configuring the firewall via the Menu - System Settings - Security Level program (redhat-config-securitylevel), then just select the eth1 as a trusted device....

Or the text for a line in the the /etc/sysconfig/iptables file that should work (for RedHat 8 or 9) is:

-A INPUT -i eth1 -j ACCEPT
cmcp
Thanks, both, for your help.

I am using RedHat 7.3, and I looked in /etc/sysconfig and there was no file for iptables. (There was one for ipchains.) So I looked in the /etc/init.d directory and found the iptables file that Joey mentioned. It was a script that said "Startup script to implement /etc/sysconfig/iptables pre-defined rules."

So I'm a bit confused -- I found a startup script that implements rules in a file that doesn't appear to exist. Should I just create a /etc/sysconfig/iptables file and add -A INPUT -i eth1 -j ACCEPT to it, or could that cause problems? Can you suggest any other ways to edit my firewall file(s)?

Thanks so much!
cmcp
One more quick idea:

I don't know how compatible ipchains rules and iptables rules are, but could I just take the rules in /etc/sysconfig/ipchains and create a file /etc/sysconfig/iptables with the same rules plus the additional one to trust eth1?

The ipchains file exists because the firewall is configured during RedHat installation (for 7.3 at least) by lokkit, which implements its rules exclusively by ipchains. Now I've disabled ipchains and I am only using iptables. For reference, here are the rules in my /etc/sysconfig/ipchains:

:input ACCEPT
:forward ACCEPT
:output ACCEPT
-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
-A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT
-A input -s departmentsubnet.1 53 -d 0/0 -p udp -j ACCEPT
-A input -s departmentsubnet.2 53 -d 0/0 -p udp -j ACCEPT
-A input -s someothersubnet.61.59 53 -d 0/0 -p udp -j ACCEPT
-A input -s 0/0 -d 0/0 -p tcp -y -j REJECT
-A input -s 0/0 -d 0/0 -p udp -j REJECT

That's the whole file. Can this just be put right into iptables or does it need to be modified somehow? Thanks again!
hughesjr
RedHat 7.3 used ipchains as the default and iptables was the next kernel firewall. Iptables is supposted to be better than Ipchains because iptables provides a stateful firewall....that is, it keeps track of each connection. You can look at connections by examining /proc/net/ip_connect...so iptables is a better and more secure way of doing firewalls....but Ipchains is also good:

you have the line:

-A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT

which is the same as the line we told you to add...it should allow all traffic to and from eth1 ... but is the NFS service listening on eth1 or eth0...a netstat -an | grep LIST will show all listening ports ...and from what IP's ... the NFS Ports are 2049, 111, and whatever your system uses for mountd, lockd, and statd ... they float. If these are not listening on eth1's IP (or 0.0.0.0) then NFS must be configured to listen so connections can be made from eth1.

Here is a good reference for NFS on IPCHAINS:
http://www.derkeiler.com/Mailing-Lists/sec...02-02/0597.html
cmcp
Yeah, 7.3's default is ipchains. You noticed that a rule in my ipchains file shows eth1 is a trusted device. I just made that change using lokkit today in light of your advice to designate eth1 a trusted interface. Thing is, I have turned off ipchains because I know that iptables is better and Joey has been trying to help me set up this stuff with iptables for a while.

Regarding the listening ports, 111 is listening on 0.0.0.0 but I didn't see 2049 listening.

Now, the real question is, does it matter much if I use ipchains or iptables for this stuff? Even though iptables is better, as you saw, there is a rule for ipchains that should enable all connections on eth1 and so it would probably be easier to just reenable ipchains. On the other hand, if anyone thinks that iptables is just far above ipchains for whatever reasons, can you explain so I can decide what the best way to go is?

Anyway, thanks hughesjr for all your help. I'll mess around with ipchains a little to see if I can get the NFS stuff working with it.
cmcp
Well, this little game gets more exciting by the moment.

I tried turning ipchains back on and iptables off. Then I checked the rules for ipchains; eth1 should still be good to accept connections. So I try adding a rule for tcp on port 2049 for NFS based on the website for configuring NFS with ipchains that hughesjr recommended. The message returned is "ipchains: Protocol not available." Mmm, interesting. So I try ipchains -L to see rules that are set: "ipchains: Incompatible with this kernel." Wow. And I thought that ipchains would work with 7.3 seeing as its the default firewall for it.

Well, the incompatability may be because of the fact that I configured the system at install time as a server. (In the RH 7.3 installation, there are choices to configure as a workstation, server, laptop, and maybe 1 or 2 others.) Now, I'm not sure if the kernels are different depending on what configuration is chosen, but that could be one problem. Thing is, the computer does function as a server, so I don't know if it would work properly if it were configured any other way.

The main question now is, if ipchains is incompatible and iptables is turned off, how is the firewall on the server still running? Is ipchains somehow incompatible but nevertheless working? Man, what an odd issue.

I'm truly sorry for all the questions that I've brought up, but this is quite an ordeal. Unless someone knows of a way to fix ipchains' compatability, it looks like I'm going to have to try to go with iptables now. Thanks for the help so far.
hughesjr
What version kernel are you using ... if the kernel was installed via and RPM , type this command to see the version:

rpm -qa | grep kernel

Or did you compile your own kernel?

I would say that you don't currently have any firewall if IPCHAINS isn't working. ohmy.gif

The reason IPCHAINS isn't working is probably because IPTABLES is in memory right now ... do a /etc/init.d/iptables stop.

To test IPCHAINS, make sure the file /etc/sysconfig/ipchains exists... then use the command /etc/init.d/iptables stop, then /etc/init.d/ipchains stop, then /etc/init.d/ipchains start ... then do a ipchains -L. If it works, you can use IPCHAINS ... but you have to check and make sure IPCHAINS is running on startup ... and that IPTABLES is not running on startup. (you can have one or the other but not both).

If IPCHAINS doesn't work ... try IPTABLES. create a file called iptables in /etc/sysconfig ... in it (for now) put this:

:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
COMMIT

This should accept all connections and start if IPTABLES works...after creating the file, do /etc/init.d/ipchains stop, then /etc/init.d/iptables stop, then /etc/init.d/iptables start....then iptables -L...if that works, you can then add the other rules you have after modifiying them slightly for iptables.

Since the ruleset that you have is small, I would change over and start using IPTABLES ... On newer Linux distros and kernels, IPTABLES is the default and IPCHAINS will go away.

Here is the RedHat guide to IPTABLES in RH7.3:
http://www.redhat.com/docs/manuals/linux/R...h-iptables.html
---------------------------------------
As a side note ... I don't think you have NFS server running. If the NFS server was running properly ... then I think you would have a LISTEN on 0.0.0.0 port 2049....you can test this by turning off both IPCHAINS and IPTABLES and trying to do the NFS connect from a client. Here is the RH7.3 NFS guide:
http://www.redhat.com/docs/manuals/linux/R...ide/ch-nfs.html

Basically, you put the directories you want to share and the IP's you want to share them with in the file /etc/exports and run the command /etc/init.d/nfs start on startup ... see the above guide for the details of the /etc/exports file and options...but when /etc/init.d/nfs start is run (and starts correctly), you will have a listening process on port 2049.
cmcp
You could be right about NFS not running, though I'm not sure. I setup the NFS server with help a while ago when I knew even less about Linux than I do now, so I trusted that my help knew what was going on.

First, yes the kernel was installed via RPM (the RedHat installer used them I'm sure) and its version is 2.4.18-3. It also says the kernel picker is 1.3-1, whatever that is.

Perhaps the timeout error could result from the server not thinking the client that I'm trying to mount on is allowed access. In /etc/hosts.allow, I've got the following:
#portmap:192.168.181.0/255.255.255.0
#lockd:192.168.181.0/255.255.255.0
#rquotad:192.168.181.0/255.255.255.0
#mountd:192.168.181.0/255.255.255.0
#statd:192.168.181.0/255.255.255.0

Well, they're all commented out it looks like -- should they be? Also, in /etc/hosts.deny:
#portmap:ALL
#lockd:ALL
#mountd:ALL
#rquotad:ALL
#statd:ALL

Again, all commented. What do the 'ALL's mean, and should they be there? And, here's the /etc/exports:
#
/home/mpich-1.2.4/share 192.168.181.40/255.255.255.0(rw)
#192.168.181.8/255.255.255.0(rw,no_root_squash)

Should the uncommented line allow 192.168.181.40 read-write privileges when it mounts /home/mpich-1.2.4/share, which is what I want, or is that wrong and it actually means something else? Based on what I've read, that seems right. Thanks again.
hughesjr
ALL means something different, depnding on which file it's in and where it is in each line. In both hosts.allow and hosts.deny, the basic format is xxx:yyy .... xxx is the daemon (or service) that is allowed or denied to start (like portmap) and yyy is the name(s) or IP(s) that are allowed to start or stop the daemon.

in hosts.allow the line:

ALL:192.168.181.0/255.255.255.0

would mean that the network 192.168.181.0/255.255.255.0 could start (or connect to) ALL tcp_wrapper daemons ...but the line:

portmap:ALL

means that all IPs can connect to portmap...
---------------------------------------------------------------
in hosts.deny the xxx and yyy ave the same meaning ...

so same line:

ALL:192.168.181.0/255.255.255.0

Means that the network 192.168.181.0/255.255.255.0 is denied the ability to start all daemons (controlled by tcp_wrappers)...
-----------------------------------------------------------------------
hosts.allow and hosts.deny are used {if you have tcp_wrappers installed .... do rpm -qa tcpwrappers to see if you have it} to control access when a daemon (aka a service) is started by either inetd or if a service has specific built in tcp_wrapper support {portmap, statd, and mountd have built-in tcp_wrapper support}.

Since all the values in your hosts.allow and hosts.deny are remarked out with #, they are not active now.

I'm not sure that lockd or rquotad use tcp_wrappers, but I don't normally have them in my hosts.* files. On 2.4 and higher kernels, lockd is not normally used and NFS is a kernel option .... rquotad is only used if you have a quota set in NFS.

Let's take 2 examples (assuming your curent hosts.allow / deny were turned on ... ie the #'s were removed).

1st example, the client 24.24.24.24 tries to connect to a running portmap ... 2nd example, the client 192.168.181.6 tries to connect.

The process is that hosts.allow is consulted before a monitored progam starts to see if a client is specifically allowed to start it, then hosts.deny is checked to see if the client is denied to start it. If you have no entries preventing someone from starting a process, then they can start it...even if they are not in hosts.allow.

Look at 1 example ... 24.24.24.24 tries to start portmap ... and hosts.allow is checked {it is looking for either ALL:something or portmap:something} ... and 24.24.24.24 is not allowed to start the program specifically (the portmap entry only allows the client IPs 192.168.181.1 - 254 [that is what the network 192.168.181.0/255.255.255.0 means] to start it. Now portmap checks hosts.deny to see if there is an entry for denying ... it is looking for either ALL:something or portmap:something agian} and portmap finds the portmap:ALL entry ... so 24.24.24.24 is denied access to portmap ... and a log entry is made (in /var/log/syslog and maybe /var/log/security).

Example 2 .... 192.168.181.6 tries to connect to portmap ... portmap checks hosts.allow, 192.168.181.6 is allowed to use portmap .... so it allows the connection. hosts.deny is not checked at all.

If there was an entry in hosts.allow like this:

ALL:ALL

then hosts.deny would never be checked....
-----------------------------------
There are some very good tools on redhat 8.0 / 9.0 for setting up NFS, IPTABLES, APACHE, etc. Is there anything that your server is running that would preclude your upgrading it to redhat 8 (or even better 9)?
hughesjr
I recommend that you start off by totally redoing the NFS setup......

By default lockd, mountd and rquotad get a random port number from portmapper when they start ... making it almost impossible to use a firewall to control their security.....

I would recommend that you look at this page:

http://www.lowth.com/LinWiz/nfs_help.html

It details how to setup NFS with static ports (so you can use a firewall).
--------------------------------------------------------------------------------------------
There are a couple issues on the above page ...First issue is for NFS Lock Manager (lockd). Is lockd compiled as kernel module ... or directly in the kernel?

If you have not recompiled your kernel, then it is probably a module. Here is how to check:

lsmod | grep lockd

if it shows lockd, it's a module ... if this returns blank do this:

modprobe lockd

if this returns to the command line without error, lockd is probably now loaded ... redo the lsmod command:

lsmod | grep lockd

you should now have a lockd running....if so, add the line (or if there is already an options line for lockd, edit it) for /etc/modules.conf from the above page:

options lockd nlm_udpport=4001 nlm_tcpport=4001
---------------------------------------------------------
Next issue, do you have quota installed ... (my version is 3.06 and it works OK...)

do the command:
rpm -qa | grep quota

If it returns blank, install quota from the redhat discs ... or from the up2date command, or however to keep your redhat updated.

---------------------------------------------------------
now modify your /etc/exports file to this:
/home/mpich-1.2.4/share 192.168.181.40(rw)

(when referencing a full class c network, the subnet mask in /etc/exports would be /255.255.255.0 ... like this 192.168.181.0/255.255.255.0 ... for a single IP it would be 192.168.181.40/255.255.255.255 ... but 255.255.255.255 is the default and doesn't need to be stated. The actual subnet mask assigned on the PC 192.168.181.40 is 255.255.255.0 because it's ON the 192.168.181.0 subnet ... but when refering to it as a single IP address, it is 192.168.181.40/255.255.255.255.
---------------------------------------------------------
After everything is configured, do the command /etc/init.d/nfs stop ...

now turn off IPTABLES and/or IPCHAINS .... /etc/init.d/ipchains stop and /etc/init.d/iptables stop

now start nfs using /etc/init.d/nfs start.

----------------------------------------------------------
The PC 192.168.181.40 should now be able to mount the directory /home/mpich-1.2.4/share using nfs...
----------------------------------------------------------
When this is working, then lets do IPTABLES and hosts.allow / hosts.deny ....
cmcp
Thanks a lot, hughesjr. I've started going through the process of assigning ports to the NFS services.

About rquotad -- I do have it, but the version is 3.03-1. I download 3.08 from sourceforge, but I'm not sure what I have to do to install it. There doesn't really appear to be a readme file or instructions for it, so I found some on the internet that I can probably use. They say to remove the old version, but do I need to do that manually or will the new version just overwrite the old one?

Thanks so much again for all your help. It's truly appreciated.
cmcp
Actually, forget it, I just followed the instructions and I guess it worked fine because all the services are running on the correct static ports now. I turned off ipchains/iptables and the mount worked fine. So now its a matter of configuring the firewall to keep those ports open. There is an IPTables configuration utility on www.lowth.com that I could possibly use, but there are parts about it that I probably can't answer easily how I want a service or feature configured. Do you know simply of some lines that I can add to /etc/sysconfig/iptables that allow traffic on specific ports? I would especially prefer it if, in those rules, traffic to certain ports can be allowed only on the private (eth1) network card so that the ports remain closed to connections from the internet.
hughesjr
Try this as /etc/sysconfig/iptables ... it should allow ssh in from all, allow dns and NFS in only from eth1 and reject incoming connections from everywhere else ... while allowing the server to make outgoing connections and prevent SYN-FLOOD type attacks ... The pinging is now not allowed from anywhere, just remove the appropriate # for all pings allowed, or eth1 pings allowed if you want either.... this assumes that you don't want to forward info between network cards ... your other ipchains didn't have a forward chain either.....


*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:REJECT-PKT - [0:0]
:SYN-FLOOD - [0:0]

######################################################################
# Allow all loopback interface traffic

-A INPUT -i lo -j ACCEPT

##############################################
# Use this to accept all traffic from eth1 ...
# or use the rules below for NFS and DNS only
# from users on eth1
#
# -A INPUT -i eth1 -j ACCEPT
##############################################

# Block Syn Flood attacks

-A INPUT -p tcp -m tcp --syn -j SYN-FLOOD

# Ensure that TCP connections start with syn packets

-A INPUT -p tcp -m tcp ! --syn -m state --state NEW -j DROP

# Allow session continuation traffic

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

##################################
# Allow ICMP ping requests, remark to become unpingable
# -A INPUT -p icmp -m icmp --icmp-type ping -j ACCEPT
#
# This one allow only pinging from eth1 ... not from all
# -A INPUT -p icmp -m icmp --icmp-type ping -i eth1 -j ACCEPT
#
#Use only ping all or ping eth1, or neither
#################################

# Allow selected TCP/IP and/or UDP services

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 111 -i eth1 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2049 -i eth1 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4000:4003 -i eth1 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -i eth1 -j ACCEPT
-A INPUT -p udp -m udp --dport 111 -i eth1 -j ACCEPT
-A INPUT -p udp -m udp --dport 2049 -i eth1 -j ACCEPT
-A INPUT -p udp -m udp --dport 4000:4003 -i eth1 -j ACCEPT

# Block all other TCP/IP and UDP traffic

-A INPUT -j REJECT-PKT

######################################################################
# Syn flood filtering chain

-A SYN-FLOOD -m limit --limit 1/s --limit-burst 4 -j RETURN
-A SYN-FLOOD -j DROP

######################################################################
# Chain used to reject all TCP/IP, UDP and ICMP/PING packets

-A REJECT-PKT -p tcp -m tcp -j REJECT --reject-with tcp-reset
-A REJECT-PKT -p udp -m udp -j REJECT --reject-with icmp-port-unreachable
-A REJECT-PKT -p icmp -m icmp --icmp-type ping -j REJECT --reject-with icmp-host-unreachable

COMMIT
cmcp
Thanks so much man -- it worked! Awesome. I appreciate your help more than you know.

Anyway, I was wondering if anything need to be done with hosts.allow/deny, or if I can just leave things as they are now since they seem to work just as I want them to? Perhaps for security it would be best to set them up. Thanks so much again!
hughesjr
It shouldn't hurt anything to also setup the hosts.allow and hosts.deny .... right now the NFS will accept all connections made from eth1 .... which could allow people who you don't want to make a connection.....

I did some checking and rquotad doesn't seem to support tcp_wrappers ... so I won't put it in the files. Since you are using the module version of lockd it also doesn't use tcp_wrappers.....

Here is a hosts.allow that allows the whole class C 192.168.181.0 to make the NFS connections:

portmap:192.168.181.0/255.255.255.0
mountd:192.168.181.0/255.255.255.0
statd:192.168.181.0/255.255.255.0

This would be the hosts.deny:

portmap:ALL
mountd:ALL
statd:ALL

--------------------------------------------------

If you wanted to limit it further ... for example you wanted only 192.168.181.40 and 192.168.181.44 to be able to connect, you could do this with hosts.allow:

portmap:192.168.181.40 192.168.181.44
mountd:192.168.181.40 192.168.181.44
statd:192.168.181.40 192.168.181.44
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2017 Invision Power Services, Inc.