Other Confusing documentation

Having read, and re-read Chapter 31. Firewalls, I'm hugely disappointed in the lack of clear direction offered by the author. As a reference, it's not horrible, but for someone looking to turn on the firewall so their workstation or server is relatively safe, it's not good. I'm not a new user and I'm not an expert. I use FreeBSD behind a secure router in my home network, as a server for my git repo (dell workstation) and as a laptop (lenovo t430). I've toyed with turning on the firewall, off and on, over the years and every time, I have found it a frustrating experience.
If I had hopes for the handbook, they were quickly dashed. The handbook tells us right off that there are three firewalls included with FreeBSD and then gives absolutely no direction as to which one to use for what purpose. Then it tells how to configure a basic PF ruleset for a machine with no services that needs access to one network. OK, after a bit of struggle, the example makes some sense, but what about allowing ssh? That seems pretty important... Lots and lots of discussion about gateways, proxies, ICMP, MTU, tables and so on, though. Maybe the section on IPFW would be better? No, a tiny bit about rc.conf and then jump into rulesets, in-kernel NAT, port and address redirection and so on.

What I eventually found on the venerable internet was this:
sudo -s

sysrc firewall_enable="YES"
sysrc firewall_type="workstation"
sysrc firewall_myservices="22 / tcp 80 / tcp 443 / tcp"
sysrc firewall_allowservices="any"
sysrc firewall_quiet="YES"
sysrc firewall_logdeny="YES"

service ipfw start
WTF? This is pretty friggin' simple and it seems to work and it doesn't have any arcane rules. Parts of it are covered in the handbook and others not so much. Is my laptop secure? I tested with a few scans and such and it seems to work, but I dunno. The firewall stuff in the handbook (which is my number one source for all things FreeBSD) seems to be written for security network nerds and not casual, but serious users like me.

Does anyone know of any better documentation that is geared towards the casual user?
 
The sysrc way is poor documented.
So you write your own script /etc/ipfw.rules
In rc.conf you only need:
Code:
firewall_enable="YES"
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
You don't need nothing more.

In the script /etc/ipfw.rules you can for instance start by removing all rules and then add the ones you need,
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
/sbin/ipfw -q -f flush    # Flush out the list before we begin.
# No restrictions on Loopback Interface
$cmd 00100 allow ip        from any to any via lo0
... add all the rules you need.

Do you need incoming or outgoing ssh connections ?
 
ipfw.rules for incoming ssh normally
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
pif="tun0"  # Interface
$cmd 04000 allow tcp from any to me 22 in via $pif setup keep-state

ipfw.rules for anything outgoing:
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
pif="tun0"  # Interface
$cmd 04010 allow tcp  from any to any out via $pif setup keep-state
$cmd 04020 allow udp  from any to any out via $pif keep-state
$cmd 04030 allow icmp from any to any out via $pif keep-state

It's not that complicated.
 
The handbook tells us right off that there are three firewalls included with FreeBSD and then gives absolutely no direction as to which one to use for what purpose.
Of course not, they all serve exactly the same purpose. You just choose the one you're most comfortable with configuring.
what about allowing ssh? That seems pretty important...
That's something many want blocked. But then, the handbook shows you how "block" and "pass" rules work and how to specify services/ports. So, you really need this exact rule you want literally in the handbook? ?
This is pretty friggin' simple and it seems to work and it doesn't have any arcane rules.
"arcane" ?

If you don't want to write rules, you don't want to configure a firewall. BTW, technically, a firewall is a device between your network and the outside network, so these "firewalls"*) are just packet filtes (that are meant to be used for building a firewall). Anyways, filtering network packets needs a set of filter rules. It's a complex thing, and how these rules are shaped will be different for every network that should be "protected". There's no sane way the handbook could give you exact solutions.

But hey, maybe you don't have to?
I use FreeBSD behind a secure router in my home network
Sounds like you already have a firewall. Why add extra filtering behind it? Would only make sense for a portable device when used in a "foreign" (untrusted) network, and then, a simple "block all incoming" ruleset is normally what you want.

--
*) The handbook isn't exact here with wording, probably because it would just confuse more people. Once companies started selling packet filtering software for windows 9x and labelled it "desktop firewall" (cause it "sounds better"), exact definitions were down the drain anyways…
 
Wait, you read the handbook?
Well, every book I've ever read has a target demographic. Sci-fi, history, even tech books.
Toss in the facts that someone may not be getting paid to write it, they may only be updating a part of it, and yes it be difficult at times, even for veteran users.
As Zirias points out, very very hard to talk about packet filters without talking about rules.
I understand the frustration, but asking the question here, giving a little time for people to read and respond is often worth the wait.
As for the handbook, perhaps a patch for the documentation or a suggestion on how to make it more useful for newbies would move it along.
Honestly, a lot of your question could have been answered with a simple "take a look the file /etc/rc.firewall and man sysrc". And yes I recognize an answer like that can be annoying when you are looking for exact steps.
 
Well, adding more examples etc is almost always a way to improve documentation, but again: "exact steps" isn't something you can expect when it comes to firewalling. Only the administrator of a network can know and/or decide which rules it would need…
 
Then it tells how to configure a basic PF ruleset for a machine with no services that needs access to one network. OK, after a bit of struggle, the example makes some sense, but what about allowing ssh?
31.3.2. PF Rulesets , the instructions for that (ssh + others) are literally right there.
 
Wait, you read the handbook?
Well, every book I've ever read has a target demographic. Sci-fi, history, even tech books.
Toss in the facts that someone may not be getting paid to write it, they may only be updating a part of it, and yes it be difficult at times, even for veteran users.
As Zirias points out, very very hard to talk about packet filters without talking about rules.
I understand the frustration, but asking the question here, giving a little time for people to read and respond is often worth the wait.
As for the handbook, perhaps a patch for the documentation or a suggestion on how to make it more useful for newbies would move it along.
Honestly, a lot of your question could have been answered with a simple "take a look the file /etc/rc.firewall and man sysrc". And yes I recognize an answer like that can be annoying when you are looking for exact steps.
I read the handbook for everything. No, it's not written for one demographic, or I wouldn't be making these observations. I've used it to learn more about every aspect of the OS and often, it's the best resource available. This section and others that lean toward networking or hardware palates tend to be more difficult. Unfortunately, while video card details can be ignored, if you don't have that particular card, firewall seems to have a wider audience :). As for looking at rc.firewall and man sysrc (or man firewall, etc). I didn't ask a howto question at all. I remarked that the handbook doesn't talk to casual users.
 
Seriously, and no offense intended: Configuring a real-life firewall box just isn't for "casual users". That doesn't mean there's no room for improvement in the handbook, of course. But having some "do it like this" advice just isn't possible for firewalling.
 
Of course not, they all serve exactly the same purpose. You just choose the one you're most comfortable with configuring.
Wow, if three, why not 50? Surely there's a difference worth noting that even a newb could appreciate? If not, then say it directly - FreeBSD offers three different firewalls and choosing between them is simply a matter of preference.

That's something many want blocked. But then, the handbook shows you how "block" and "pass" rules work and how to specify services/ports. So, you really need this exact rule you want literally in the handbook? ?
Nope. Didn't ask about rules. I asked about writing for the casual user. Explaining, in logical steps how to set up a firewall for the simple case - not the minimalist case, just a case similar to what I described, before launching into internals.

"arcane" ?
I'm laughing on the inside. Please, if you think that "pass out proto tcp to any port $tcp_services keep state" is self explanatory or obvious, good for you.
If you don't want to write rules, you don't want to configure a firewall. BTW, technically, a firewall is a device between your network and the outside network, so these "firewalls"*) are just packet filtes (that are meant to be used for building a firewall). Anyways, filtering network packets needs a set of filter rules. It's a complex thing, and how these rules are shaped will be different for every network that should be "protected". There's no sane way the handbook could give you exact solutions.

But hey, maybe you don't have to?
You misunderstood the question. I don't want to build a firewall appliance to protect one network from another. While that might be fun to do as an experiment. I'd like to start small and just get my laptop set up. Yes, I have a router/firewall that is doing it's duty on the periphery, but I still like to dip my toes in the water every now and then and learn something new and useful. Even my small use-case has merit. Unfortunately, the handbook doesn't help much, in this case.

Hopefully, somebody will think a bit more about this and add a "So you want to protect your laptop from intrusion, let's start with a basic introduction to firewalling, otherwise, here's the thorny details for you networking nerds" type section. I'd do it, but I don't yet fully grasp the fundamentals.
 
Seriously, and no offense intended: Configuring a real-life firewall box just isn't for "casual users". That doesn't mean there's no room for improvement in the handbook, of course. But having some "do it like this" advice just isn't possible for firewalling.
Hi Zirias, no offense taken. if what you say is the case, then poke holes in the simple example I gave. Is it insecure? I do understand that a simple configuration isn't teaching anyone about firewalls, generally, but they are helpful, and it just seems like the handbook is a tad bit difficult.
 
FreeBSD offers three different firewalls and choosing between them is simply a matter of preference.
Actually, that's a very accurate description of the situation ?‍♂️
Please, if you think that "pass out proto tcp to any port $tcp_services keep state" is self explanatory or obvious, good for you.
I don't, but the handbook already explains a bit more than that and refers to some external docs for those who want to know more ;)
You misunderstood the question. I don't want to build a firewall appliance to protect one network from another. While that might be fun to do as an experiment. I'd like to start small and just get my laptop set up. Yes, I have a router/firewall that is doing it's duty on the periphery, but I still like to dip my toes in the water every now and then and learn something new and useful. Even my small use-case has merit. Unfortunately, the handbook doesn't help much, in this case.
Then I have to repeat myself a bit (but maybe it wasn't clear enough): The only sane usecase I could see for packet filtering on the host itself is for mobile devices (e.g. a laptop) operated in an untrusted network. Yes, this makes sense, and what you normally want for that usecase is just blocking anything from the outside. I think the handbook gives examples for this simple scenario?
 
[BGCOLOR=rgb(245, 245, 245)]Yes, this makes sense, and what you normally want for that usecase is just blocking anything from the outside. I think the handbook gives examples for this simple scenario?[/BGCOLOR]
Sort of. My thought is this could be written more clearly and compactly. It’s there, just spread out.
 
As I always say, the Handbook is a place to get started. The FreeBSD project usually would point to places where you can get more documentation. Same with firewalls - you can get started using the Handbook, but for anything more advanced, you're encouraged to read the manpages, documentation hosted on project's web site, and pick up more advice on the Internet, including these forums. I don't think it's a great idea to bash the Handbook for incomplete info - it's only meant to be a starter. ?
 
As I always say, the Handbook is a place to get started. The FreeBSD project usually would point to places where you can get more documentation. Same with firewalls - you can get started using the Handbook, but for anything more advanced, you're encouraged to read the manpages, documentation hosted on project's web site, and pick up more advice on the Internet, including these forums. I don't think it's a great idea to bash the Handbook for incomplete info - it's only meant to be a starter. ?
Fully agreed, trying to document everything there is moot. But maybe there's a point to better document this simple usecase for a "host-based packet filter" that just rejects everything from the outside ... which is probably the most common usecase if you're not building a real firewall.
 
Firewall is not hard to learn, but it's hard to write a comprehensive documentation for it. You're not dealing with an isolated problem, with possible answer "A" or NOT "A". You're dealing with a scenario. Eric's machine is entirely different from Bill's machine, i.e. completely different scenarios. Above that, the order of the rules, state, VPN, port forwarding, etc. all demands to know something about networking. Keeping that in mind; committing few examples to the documentation may help few, but it doesn't work for everyone else. There's always going to be complaints.

It's very much like calculus. Calculus is not complex, but you have to know trigonometry and algebra, to be able solve a problem.
 
As I always say, the Handbook is a place to get started. The FreeBSD project usually would point to places where you can get more documentation. Same with firewalls - you can get started using the Handbook, but for anything more advanced, you're encouraged to read the manpages, documentation hosted on project's web site, and pick up more advice on the Internet, including these forums. I don't think it's a great idea to bash the Handbook for incomplete info - it's only meant to be a starter. ?
Not bashing. As I’ve said, I use it all the time and appreciate it more often than not. However, this article could use some help.
 
Firewall is not hard to learn, but it's hard to write a comprehensive documentation for it. You're not dealing with an isolated problem, with possible answer "A" or NOT "A". You're dealing with a scenario. Eric's machine is entirely different from Bill's machine, i.e. completely different scenarios. Above that, the order of the rules, state, VPN, port forwarding, etc. all demands to know something about networking. Keeping that in mind; committing few examples to the documentation may help few, but it doesn't work for everyone else. There's always going to be complaints.

It's very much like calculus. Calculus is not complex, but you have to know trigonometry and algebra, to be able solve a problem.
I'd say a firewall is more like a Pratt Parser than calculus. Just try doing a triple integral on a trig hyperbolic function in Reverse Polish Notation. ;)
 
Hmm... based on reactions, so far, either I’ve misstated my issue, or I stand alone on it. Either way, I’ll go dig in a bit more and if I can learn enough to better formulate a tweak, I’ll beta test it with y’all and see what you think.
 
Back
Top