# NFS vs. Firewall (iptables)

## Cr0t

I have a small (?) NFS problems

1. my Router FireWall rules

basic

```
modprobe ip_conntrack_ftp

modprobe ip_conntrack_irc

modprobe ip_nat_ftp

modprobe ip_nat_irc

echo 1 > /proc/sys/net/ipv4/ip_forward

echo 0 > /proc/sys/net/ipv4/tcp_ecn

iptables -F -v

iptables -t nat -F -v

iptables -t mangle -F -v

iptables -A INPUT -i lo -j ACCEPT -v

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE -v

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -v

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

iptables -A INPUT -p tcp --dport 21:22 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 80 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 161 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 9999 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 212 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 113 -j ACCEPT -v

iptables -A INPUT -p tcp --dport 25 -j ACCEPT -v

iptables -A FORWARD -p tcp --dport 25 -j ACCEPT -v

iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT -v

iptables -A INPUT -p udp -i eth1 -s 192.168.1.0/24 --dport 67 -j ACCEPT -v

iptables -A INPUT -p tcp -i eth1 -s 192.168.1.0/24 --dport 67 -j ACCEPT -v

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8080 -j DNAT --to-destination 192.168.1.2:80

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8181 -j DNAT --to-destination 192.168.1.3:80

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 2222 -j DNAT --to-destination 192.168.1.2:22

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 2323 -j DNAT --to-destination 192.168.1.3:22

iptables -A INPUT -p tcp --syn -j DROP -v

iptables -P INPUT DROP -v

iptables -A INPUT -p udp --dport 135 -j REJECT -v

iptables -A INPUT -p udp --dport 137:138 -j REJECT -v

iptables -A INPUT -p tcp --syn --dport 139 -j REJECT -v

iptables -A INPUT -p tcp --dport 445 -j REJECT -v

iptables -A INPUT -p udp --dport 445 -j REJECT -v

iptables -A FORWARD -p udp --dport 135 -j REJECT -v

iptables -A FORWARD -p udp --dport 137:138 -j REJECT -v

iptables -A FORWARD -p tcp --syn --dport 139 -j REJECT -v

iptables -A FORWARD -p tcp --dport 445 -j REJECT -v

iptables -A FORWARD -p udp --dport 445 -j REJECT -v

iptables -A OUTPUT -p udp --dport 135 -j REJECT -v

iptables -A OUTPUT -p udp --dport 137:138 -j REJECT -v

iptables -A OUTPUT -p tcp --syn --dport 139 -j REJECT -v

iptables -A OUTPUT -p tcp --dport 445 -j REJECT -v

iptables -A OUTPUT -p udp --dport 445 -j REJECT -v

iptables -A INPUT -i eth0 -j LOG

iptables -A INPUT -i eth1 -j LOG
```

NFS Rules

```
iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 111 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 111 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 635 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 2049 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 2049 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 884 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 884 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 887 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 887 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 32768 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 32771:32772 -j ACCEPT -v

iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 32771:32772 -j ACCEPT -v

```

2.

showmount -e IP takes 4 ever but after a minute or so i get the result

3.

mounting over the network sometimes takes up to 5 minutes?

Any idea what I am doing wrong?

----------

## ozukir@

Well, if NFS connections are made then I doubt your firewall is the culprit. Your firewall on the other hand could use some work.

There is no shortage of references and examples of working firewalls. The problem quickly becomes which information to follow. Firewalls are like opinions and assholes; it seems like everyone has one. This is not the quick and dirty answer you were looking for, but there are so many posts like these to the forum. My answer, don't recreate the wheel. Use one of the many working examples and tune it for your setup.

Here are my opinions about your setup (read at your leisure, they will not solve your current problem):

1. Always deny by default. You're wasting you time if you do it any other way. Then allow services in and out. Many people are happy with allowing everything out, but this is not very considerate of others on the public network (but sure makes your rules more simple).

```
iptables -P INPUT DROP -v

iptables -P OUTPUT DROP -v

iptables -P FORWARD DROP -v

iptables -t nat -P PREROUTING DROP -v

iptables -t nat -P OUTPUT DROP -v

iptables -t nat -P POSTROUTING DROP -v

iptables -t mangle -P PREROUTING DROP -v

iptables -t mangle -P OUTPUT DROP -v
```

2. Go ahead and free up that loopback, both ways.

```
iptables -A INPUT -i lo -j ACCEPT -v

iptables -A OUTPUT -o lo -j ACCEPT -v
```

3. Keep your rules organized so you can understand them. FORWARD policies together, INPUT policies together, .... You get the idea. It reduces hair pulling when debugging your rules.

4. Use stateful inspection to bypass unecessary rules. That means put it at the top of your rules.

```
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -v

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -v

iptables -A INPUT -m state --state INVALID -j DROP -v

iptables -A OUTPUT -m state --state INVALID -j DROP -v
```

5. Be specific about where things are going. Use "-i" and "-o" as much as necessary so your sure of what's going on.

6. Optimize your rules by design. Remember that rule inspection occurs beginning at the top of your chain. Traffic that you generate and receive most should be covered in rules at the beginning of your chains.

7. DROP traffic from the outside, REJECT traffic from the inside. Your LAN can handle the traffic, but no need to slow down your Internet connection with RST traffic or make DoS of a possibility.

8. If you have specific problems and need help, always include information in the beginning of your request about your setup. Which interface is connected where, what services you are offering (if it isn't obvious).

Sorry about writing so much without giving you any kind of answer. I guess I'm pedantic like that.

----------

## neilhwatson

I've read in the Oreilly firewall book (http://www.oreilly.com/catalog/fire2/) that it is not possible to filter the NFS service through a firewall and still keep the firewall secure.

----------

## Cr0t

 *ozukir@ wrote:*   

> Well, if NFS connections are made then I doubt your firewall is the culprit. Your firewall on the other hand could use some work.
> 
> There is no shortage of references and examples of working firewalls. The problem quickly becomes which information to follow. Firewalls are like opinions and assholes; it seems like everyone has one. This is not the quick and dirty answer you were looking for, but there are so many posts like these to the forum. My answer, don't recreate the wheel. Use one of the many working examples and tune it for your setup.
> 
> Here are my opinions about your setup (read at your leisure, they will not solve your current problem):
> ...

 

Are you a little bit paranoia?   :Rolling Eyes: 

----------

## sebest

you can't really filter if you are using nfs because of RPC, 

i guess you are using the portmapper right? (port 111)

The portmapper is used to attribute dynamic ports.

You would need something like the ftp helper in iptables, something that understand the rpc protocol and dynamically open the necessary ports upon a rpc request..

----------

## sebest

maybe you can bypass this problem... it may be possible to specify the port that you want to use and then bypass the portmapper.

i found something about it, but didn't have time to read it completely but i think it can help you solving your problem:

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

----------

## neilhwatson

Your paranoid is what we call thorough.  If you don't have a thorough firewall then there is no point in running one.

----------

## ozukir@

 *neilhwatson wrote:*   

> Your paranoid is what we call thorough. If you don't have a thorough firewall then there is no point in running one.

 

Too true.

I was running some net services from my home box early last year. I briefly had a Win2K box up running IIS in a default setup, patched mind you. It was hacked in three days. I took care of it the moment I realized, but after that I guess I became something of a target.

First they hacked my SOHO firewall gateway, it wouldn't filter packets until I upgraded the firmware. Then they hacked a FreeBSD firewall gateway a friend and I set up, took them almost a month. Then I put up an OpenBSD fw/gw which did the job (I figured out my friend wasn't the expert he thought he was). I was port forwarding to an internal box (RedHat web server only listening for Apache and OpenSSH), and the day that I learned about a vulnerability in OpenSSH I checked it's logs; there were no logs for the last two days. For more than 6 months, my boxes were probbed, picked, and hacked on by who knows how many people. One day, within a 1 hour period I logged 63 unique IPs that were scanning my hosts. They even sent me email from my own address. My friend had his laptop running Win2K on my network around the same time (for 1 day). After he left and put his laptop on the university network, he created a new email account. Within 6 hours they sent him an email from my account to his new address. Amazing. I forget the details, but I definately remember feeling at their mercy (and they had little mercy).

I told a friend about all this. He asked me if this was some kind of role-playing game like D&D. No I replied, this is really happening. He's an admin at one of the largest IT service companies I can imagine.

----------

## sebest

If your firewall is properly setup, even if your IIS was vulnerable, the attacker could install a backdoor but he wouldn't be able to access it.

That's where a statefull firewall with a dmz is usefull.

If your gate was hacked, it means that you were not paranoid enought.

The gate/firewall should be the most secured host of your network, 

it should only be doing firewall task no other service,

maybe only ssh from the GREEN part of your network, accesible with a RSA/DSA authentication from only a limited list of IP.

Every firewall with a web interface, a squid proxy etc etc, is far less secure.

So if you"ve been hacked it means that you are not paranoïd enought for the network environment you live in.

----------

## ozukir@

Yeah that's the amazing part. My first firewall on FreeBSD ran no services and only allowed access to SSH from the LAN. I wasn't running my servers on a DMZ, so I'm sure it fell first. I still don't know how they hacked that FreeBSD box (pretty up-to-date, no unnecessary services, etc.), but they could have only done it from my LAN. But like I said, my friend helping me was not the expert he claimed to be. I faired much better with the OpenBSD box.

 *sebest wrote:*   

> That's where a statefull firewall with a dmz is usefull.

 

Stateful firewalls are not the magic bullet that everyone thinks. Their purpose is to by-pass rules for established and related connections. You still need to maintain logical, well thought out rules for all your connections. 

 *sebest wrote:*   

> So if you"ve been hacked it means that you are not paranoïd enought for the network environment you live in.

 

And this is kinda obvious.

My real point was that not every hacker out there is some lame script kiddie, some of those guys and gals really know their stuff.

----------

