Solved [IPFW] Are these tips of a website useful or not?

[HL1234]

I'm now on the way to define my own rules in ipfw.rules for the firewall settings with IPFW.
First I have setting the rules exactly like they will build when using /etc/rc.firewall with parameter "workstation", what can be also done with settings in /etc/rc.conf. And I set some addition rules for my services.

I have look around with google how to do this at the very best and found this website
https://www.adminbyaccident.com/fre...ow-to-configure-the-ipfw-firewall-on-freebsd/
with a long description and that advice:

The rules should be first organized into three major sections, all the free unmolested interfaces, public interface outbound, and the public interface inbound.

# A) All the free unmolested interfaces
#==============================================================================

# B) Outbound Section (Interface facing Public Internet)
#==============================================================================

# C) Inbound Section (Interface facing Public Internet)
#==============================================================================

I like to change my rules in that way, but I'm unsure if this is OK.

Question: do you think this ordering is a good way to do so? Or would you advice against this and why?

Please read the website above, to get more information before answering. I.E. he "complain" that this tips from https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handbook/firewalls-ipfw.html in chapter '30.6.5.5 Stateful Ruleset', paragraph 5, are no more in the actual handbook. Is there a reason why the handbook has changed for this?

 

[smithi]

I'm now on the way to define my own rules in ipfw.rules for the firewall settings with IPFW.
First I have setting the rules exactly like they will build when using /etc/rc.firewall with parameter "workstation", what can be also done with settings in /etc/rc.conf. And I set some addition rules for my services.

That's a good place to start, where it fits your usage case.

I have look around with google how to do this at the very best and found this website
https://www.adminbyaccident.com/fre...ow-to-configure-the-ipfw-firewall-on-freebsd/
with a long description and that advice:

I don't consider that article either well-written or good advice in general, particularly as he considers the old handbook section from FreeBSD 7 as at all useful, and doesn't seem to follow consequences of allowing unfettered access to local services in 'workstation'.

Google is a poor source for this sort of thing. Search from www.freebsd.org may use google but is focused on freebsd sources, mailing lists, forums etc.

I like to change my rules in that way, but I'm unsure if this is OK.

I think you should research further before subscribing to any particular viewpoint.

The rulesets in rc.firewall were written by the authors of ipfw and senior network coders within the project; they are far more valuable in teaching correct usage than most third-party contributions - especially those based upon the extremely ignorant and biased contribution by Joe A1poweruser (ono) that became the first ipfw handbook section, by sheer weight of words in my view.

Question: do you think this ordering is a good way to do so? Or would you advice against this and why?

I haven't time just now to go into that in sufficient depth. It's one way. rc.firewall rulesets show other ways.

Please read the website above, to get more information before answering. I.E. he "complain" that this tips from https://docs.freebsd.org/doc/7.4-RELEASE/usr/share/doc/handbook/firewalls-ipfw.html in chapter '30.6.5.5 Stateful Ruleset', paragraph 5, are no more in the actual handbook. Is there a reason why the handbook has changed for this?

Yes, it was full of factual errors and misguided advice, most (but not all) of which has since been weeded out of the handbook.

My quick advice: refer to ipfw(8) as often as needed to learn at least all aspects of it that you need to use ;

refer to all /etc/rc.firewall examples for various scenarios, noting that they don't elevate stateful rules to the exclusion of stateless rules where these are more appropriate, particularly as noted in 'workstation';

add 'log' or 'log logamount N' to many rules, at least temporarily, and read the log (/var/log/security) to learn TCP/IP the illustrated way;

refer to the handbook section after establishing the basic concepts above. It retains 'stateful-worship' to too great a degree (IMO) and is still outright wrong about syslog logging limits (5 is absurd, 100 more useful), but is much better than the 7.4 example quoted and relied upon by the article you found.

Have to go .. more anon ..

 

[HL1234]

Thanks for your help.
I have started and try to change the ruleset in a copied file, but see now that some rules between the example and from the rc.firewall workstation created are more different. In the example there are "free unmolested", outbound allow and inbound deny settings in 3 blocks. With "rc.firewall workstation" all rules came anyway in a mixed order.

And second I'm asking me, why not set first inbound rules for deny before anything, in and out, is allowed (until the end the rest of all unnecessary is deny)?
(I know that a deny rule must not block anything that I want later to be allow, because first match count)

 

[PMc]

I agree in many aspects to smithi.
The examples provided in earlier handbooks were bogus. The configurations provided by the installation are okay, but they are in a rather compact style - which is good for performance, but difficult to expand starting from them.

That is why I started to do things differently - less optimal performance-wise but much more easy to maintain: i separate directions and interfaces in distinct branches of the ruleset.
This assumes that net.inet.ip.fw.one_pass=0 is used, so that routed packets traverse the firewall twice.
Then we begin
00030 skipto 7650 out
From here on we will handle only incoming packets
00040 skipto 3140 not recv tap0
And from here on only incoming stuff arriving on tap0
At the end of the branch: drop or reject and log everything remaining:
03120 unreach filter-prohib log proto ip4 // END tap0
03130 unreach6 admin-prohib log proto ip6 // END tap0
03140 skipto 4350 not recv nlan_1u
Now we are handling the incoming stuff from nlan_1u interface
and so on...
When we are done with the incoming, we again drop all remaining
07630 unreach filter-prohib log proto ip4
07640 unreach6 admin-prohib log proto ip6
07650 skipto 10100 not xmit tap0
and now do the outgoing packets, again interface by interface

I don't think this even has much of a performance impact, because each packet traverses only the rules specific to the concerned branch. It is certainly more writing needed, because many rules need to appear in multiple branches. But then you know what rules you're placing exactly where and why.

Furthermore, such a structured approach allows to automate the whole rule creation. I no longer write rules, I have a script that does it for me (and cares for the line-numbering and the proper syntax). I'm now only using a web interface to define flows, e.g. "gimme ssh from this network to that network".

But again, this is only one possible approach, and one could do things differently...

 

[HL1234]

Thanks for all advices. I will discard the example from that website above and start again with the rules from /etc/rc.firewall workstation.

PMc thank you for your example, but I do not understand this. For me there are many new ipfw vocabulary like: skipto, unreach, recv | xmit ... And non explaination of tap0, nlan_1u. I think with only using the manual I can not learn this.

 

[PMc]

PMc thank you for your example, but I do not understand this. For me there are many new ipfw vocabulary like: skipto, unreach, recv | xmit ...

These are ipfw commands, they are explained in ipfw(8).

And non explaination of tap0, nlan_1u.

These are network interfaces as shown with ifconfig. You certainly know lo0 as the local network interface, and you will have at least one other for the physical wire.
These two in my config are virtual ones, they are used for connecting jails or guest systems.

I think with only using the manual I can not learn this.

It doesn't work without effort. The manual alone isn't too helpful, I agree to that. But you can start working that way, and then for things unclear you can ask here. Or you can bring beer.

 

[smithi]

Thanks for your help.
I have started and try to change the ruleset in a copied file, but see now that some rules between the example and from the rc.firewall workstation created are more different.

Just as well. The more I look at the example you are talking about, derived from that 7.4 handbook example, the more I'm reminded how lacking it was ...

And thanks PMc for help.

In the example there are "free unmolested", outbound allow and inbound deny settings in 3 blocks. With "rc.firewall workstation" all rules came anyway in a mixed order.

Try to avoid any too-rigid "should" or "should not" approaches to writing a good, useful firewall, given that examples like those in rc.firewall were written and extensively reviewed by ipfw authors and networking experts over years. These are the safest place to start, while developing your skills.

In any case, the workstation ruleset does generally follow that pattern: first unimpeded traffic on localhost and localnet, then all allowed outbound traffic, special cases (DHCP, stateless icmp), then allowed inbound traffic on services we offer, then specific denial without logging of common 'noise', and finally denial, with or without logging, of the rest.

While learning, log lots and browse logs to follow what's happening, then quieten the 'background radiation' of both local and outside nets.

And second I'm asking me, why not set first inbound rules for deny before anything, in and out, is allowed (until the end the rest of all unnecessary is deny)?
(I know that a deny rule must not block anything that I want later to be allow, because first match count)

If you try excluding all the bad packets, you'll wind up with hundreds of rarely used rules which you certainly don't want to traverse first, and ever be needing more.

A good ('inclusive') firewall concentrates on allowing desired traffic, out and in, dealing with any specific bad traffic that you want to be alerted to, but just dropping the rest; life's too short.

You haven't said what your host or net looks like, what your upstream router does about filtering etc, so I'm assuming the 'workstation' definition.

Feel free to post the ruleset you come up with, whenever.

cheers, Ian