ufw forward rules after the filter is applied?

[darkod]

Hi all.

I am setting up a machine to be router/firewall and bit by bit I am getting there.

However, I noticed one thing today. Even if I delete the allow rule in ufw for port 80, it still opens the website on the webserver behind the router/firewall.

Does this mean the port foward (NAT) rules in ufw are executed before the firewall filter and regardless if I am blocking port 80 for example? Is there a way to execute the port forward after the filter is applied? And where should the rule be in that case?

Most port forward tutorials mention /etc/ufw/before.rules so I have my port forwards there, but does being in before.rules actually means it is applied before the filter? I did a test putting it in after.rules but things didn't change. Or maybe I got the syntax wrong if it needs to be changed to be used in after.rules.

Any ideas? I need this pretty ASAP. Thanks.

[Doug S]

Hi Darkod,

I'm not sure, but yes I think your forward rules are effectively by-passing your input chain firewall filters. It is important to know that there are multiple paths through IPTABLES depending on if forwarding or not. There is a good diagram of packet flow that I always have right here at my desk to help me (I'll find and edit in a link later).

If you post your iptables, we can know for sure what is going on (although I sometimes have difficulties reading ufw generated tables):

sudo iptables -x -n -L -v

sudo iptables -t nat -x -n -L -v

or

sudo iptables-save -c

[darkod]

Thanks. Here you go.

I have also attached the before.rules and after.rules. In before.rules the forward entries are commented out at the moment for my tests.
In after.rules I have added the *nat section after the *filter section as seen on one website but even that latest try didn't change things. The website still opens and there is no entry for port 80 in ufw to allow it.

[darkod]

Better iptables screenshot.

[Doug S]

Thanks for the better screen shot added. I was just about to write and say the prevous one was chopped.

You still have bypass rule in your 3rd of 3 screen shots. It says "after rules" but it will be "first" in the prerouting.

(sorry for the brief reply, but I am out of time for just now)

[darkod]

Does that mean I need to work with POSTROUTING?

All examples of port forwarding I found said PREROUTING although now that i think about it they might not care if you forward the packet before the firewall filter. I do.

I know I can add a source limitation in PREROUTING with -s but i was hoping the firewall rules to be one more layer of protection. Like this, they seem completely bypassed.

[Doug S]

You might be able to do what you want with rules in the forward chain, I'm not sure.
Wouldn't you do any other filtering or whatever at the destination machine?
I don't know enough about what you are trying to do to be able to comment further. (and I have seen some of your other threads).

By the way, the diagram I referred to earlier can be found here: http://bodhizazen.net/Tutorials/iptables/

[darkod]

Well, since you obviously know more than me on this topic, if you feel you can help I can give you the short version.

Internet space (fixed public IP) --- server A --- server B

Server B is a webserver (Win 2008 IIS7) that will be connected to the private interface of server A, only private IP. The external interface of server A will have a fixed public IP and gateway, etc....

Server A is the router/firewall server machine I am talking about.

So, for the webserver the router/firewall needs to be the gateway to the internet. For this I did the necessary changes in /etc/default/ufw and /etc/ufw/sysctl.conf and the *nat section in /etc/ufw/before.rules as per google tutorials.

The routing works fine, I can ping outside from server B both with IP and domain names.

I am after protecting the webserver from smallish attacks (I am aware it will hardly hold any major attacks but we don't expect them ). My understanding was that ufw will protect also the traffic passing through, not only the server A machine itself.

Of course, 80 and 443 will need to be open for all, and forwarded to the webserver private IP (lets call it 10.0.0.2). That is easy, you do it with:
-A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.0.2

Works fine. Of course I opened port 80 in ufw. Only today it occurred to me to test with 80 closed and sure enough, the test website is still available. Which means the forward rule above is executed before any firewall filtering rules.

Which is not what I expected.

Any alternative I tried today to make it block 80 unless it is allowed in the firewall, failed. It either doesn't open if you completely remove the rule to forward 80, which is understandable, or it opens as soon as you configure a rule for the port forward regardless if that rule is in before.rules or after.rules and that port 80 is blocked in ufw.

Of course, the port 80 is not the main issue since it needs to be available to all anyway.

The problem is how to give max protection to the ports used for windows Remote Desktop, and FTP (I will not use the default ones).

The only option I have available as I see it, is something like this in before.rules:
-A PREROUTING -i eth0 -p tcp -s <office public IP> --dport 3389 -j DNAT --to 10.0.0.2

NOTE: Forgot to mention, the servers will be hosted with a hosting provider in another town, hence the office needs to have RD and FTP access. The office has fixed public IPs on its ADSL lines so that can help use the -s option to limit the source IP.

Now, is the above enough?????

I was going to complement it with something like:
ufw allow in on eth0 from <office public IP> port 3389 proto tcp

as additional defense thinking the firewall will block any attempt on port 3389 not coming from the office. Together with the forward rule doing the same, better.

But if the forward happens before the firewall filter, the ufw allow or deny has no meaning. Right?

Sorry about the long post, I tried to explain everything. Any ideas???

PS. In the last few hours I tried to read more about the FORWARD option (chain) but never found anything relating that to port forwarding. Can you suggest some example syntax?

[JKyleOKC]

I'm not surprised that you've been confused -- it's a very murky area.

The oversimplified version, though, is pretty clear. When a packet comes into the machine through the WAN interface, it goes to the INPUT chain if addressed to the local machine, and to the FORWARD chain if not -- but never through both of them.

The prerouting and postrouting rules have nothing to do with firewall filtering. They are part of the nat module, and handle routing and redirection.

For the firewall, you need to duplicate your INPUT chain's rules in the FORWARD chain of the filter module. That will achieve what you want, and it really won't matter where in the routing sequence of events the filtering happens. I believe it will come as early as possible, since there's no point to doing all the (invisible) NAT bookkeeping on packets that are just going to be thrown away, but I've not tried to verify this by digging through kernel source code.

It's a bit tedious to duplicate all the rules, but it can be done easily by copy-and-paste, then replace INPUT with FORWARD in the second copies...

It may be a bit more difficult with ufw, but you can view the actual rules by doing "sudo iptables-save >$HOME/myrules.txt" and examine them. This may give some hints on what you need to do with the ufw rules...

Hope this helps!

[darkod]

I'm not surprised that you've been confused -- it's a very murky area.

The oversimplified version, though, is pretty clear. When a packet comes into the machine through the WAN interface, it goes to the INPUT chain if addressed to the local machine, and to the FORWARD chain if not -- but never through both of them.

The prerouting and postrouting rules have nothing to do with firewall filtering. They are part of the nat module, and handle routing and redirection.

For the firewall, you need to duplicate your INPUT chain's rules in the FORWARD chain of the filter module. That will achieve what you want, and it really won't matter where in the routing sequence of events the filtering happens. I believe it will come as early as possible, since there's no point to doing all the (invisible) NAT bookkeeping on packets that are just going to be thrown away, but I've not tried to verify this by digging through kernel source code.

It's a bit tedious to duplicate all the rules, but it can be done easily by copy-and-paste, then replace INPUT with FORWARD in the second copies...

Hope this helps!

It does, but does it change things that I have been "handling" the rules with ufw and not iptables directly? If I start with iptables I will get even more lost, and I have no much time to finish this off right now. If I discovered this last week...

ufw sounded like good and simple front of iptables. Can I still do this with ufw only?