Other Confusing documentation

decuser I think the expectation to get "recipes" just doesn't apply too well to firewalling. For a real firewall, you WILL write a ruleset, and it will be your own.

On my firewall box, supporting several zones (internal clients, internal servers, guests, management and dmz), it currently looks like this:
Code:
# wc -l /etc/pf.conf
     163 /etc/pf.conf
(yes, it includes blank lines and comments…)

JFTR, the functionally same thing as a script configuring iptables on Linux was several times larger. I like PF :cool:
 
Maybe this is just a copy/paste error but you have spaces surrounding the slashes, those shouldn't be there.
Code:
sysrc firewall_myservices="22 / tcp 80 / tcp 443 / tcp"
This should be correct:
Code:
sysrc firewall_myservices="22/tcp 80/tcp 443/tcp"
 
decuser I think the expectation to get "recipes" just doesn't apply too well to firewalling. For a real firewall, you WILL write a ruleset, and it will be your own.
Got it. I am not interested in recipes. I think it would help to start with a simple scenario, as was suggested above, with beginner level discussion, before going deep. I’ll work on it and see if it makes sense after I put more effort into it. The discussion has helped a lot to refine my understanding of what I really think the problem is as well as why it is the way it is.
 
One pitfall is that there's still a certain logic to the precedence rules in firewalls. A misplaced rule may end up working differently than expected.
 
Maybe this is just a copy/paste error but you have spaces surrounding the slashes, those shouldn't be there.
Code:
sysrc firewall_myservices="22 / tcp 80 / tcp 443 / tcp"
This should be correct:
Code:
sysrc firewall_myservices="22/tcp 80/tcp 443/tcp"
Interesting. I had the same issue with copying the example I borrowed it from. Some artifact of the copy/paste buffer between my Mac terminal, the ssh session, and bash. I’ll be more careful in the future.
 
Got it. I am not interested in recipes. I think it would help to start with a simple scenario, as was suggested above, with beginner level discussion, before going deep. I’ll work on it and see if it makes sense after I put more effort into it. The discussion has helped a lot to refine my understanding of what I really think the problem is as well as why it is the way it is.
Maybe you can replace your router's firewall some day. It might be just me, but I don't really trust "consumer plastic".
One pitfall is that there's still a certain logic to the precedence rules in firewalls. A misplaced rule may end up working differently than expected.
Indeed, and this logic is pretty much the opposite between IPFW and PF, so, pay attention to that ?
 
I'm in the process of learning how to configure PF on a couple of FreeBSD servers. Here's what I've done so far, in order:

1. I read chapter 31. I kinda agree with decuser because I had no idea which of the 3 firewalls/packet filters to choose. But I did some Googling and people generally said PF was easier to configure (I have no idea if that's true of course) so I went with PF. I'd say chapter 31 is a bit... sparse. I had lots of unanswered questions.

2. I tried the example and BOOM I blocked myself from connecting to the server at my office. I had to get dressed and drive to my office at 2am, sit down at the terminal, and turn off PF. After returning home and sleeping a bit, I decided to Google some PF guides or tutorials. I found the one sidetone linked above, and...
- http://artemisa.unicauca.edu.co/~mtrujillo/OpenBSD/pf/filter.html
- http://home.nuug.no/~peter/pf/en/intro.html (many pages of info)
- https://www.digitalocean.com/community/tutorials/how-to-configure-packet-filter-pf-on-freebsd-12-1 (recent)

3. I made a FreeBSD virtual machine on my home computer. Then I opened a second terminal window, connected to the VM over SSH and kept playing with pf.conf. After the 4th or 5th time of locking myself out of the SSH connection, I was REALLY HAPPY I could just click in the VM window to turn off PF instead of driving to my office in the middle of the night.

4. Once I had a reasonably working set of rules for my VM, I made a new ruleset for the server at our office. The office server has a few web sites so it needs to be public facing. No one except me needs SSH access outside of the office, and only a couple workstations in the office need FTP access (for reasons lol). Here's what I did:
(for anyone new to PF reading this, these are NOT ACTUAL RULES, I'm just summarizing)
- created a whitelist with the office workstations on the local network
- pass my home IP on my custom SSH port
- pass the whitelist for all ports (this lets FTP work on the local network without any weird FTP rules)
- block martians
- block IPs on the blocklist
- block return in log all (<--- that one's an actual rule)
- pass on tcp ports 80, 443, etc
- pass on udp ports 53, 123, etc

I'm still figuring this out and I have LOTS of questions that don't seem to be answered in any of the tutorials. Yes, everyone's firewall rules are going to be different. But I think there's a LOT of room for improvement to the docs. For example...
- should I always use "return" or should I use "drop" sometimes?
- why are the lists of martians slightly different in almost every guide/tutorial?
- why doesn't traceroute work on the server when PF is running?
- should I still use antispoof if I'm blocking all the martians? (someone gave a good reason in another thread)
- should I use the built-in blacklistd or should I use fail2ban?
- do I need to use fail2ban if no one outside of the local network is accessing SSH or FTP?
- and many more... but I'm still studying and learning.

Anyway, I hope this helps someone.
 
- should I always use "return" or should I use "drop" sometimes?
It depends. Drop is if there's a strategic need for it to be silent, and to let the other side assume the packet got lost. For example, if something can test the system, and you don't want the firewall to return information by giving an error message. It's like a submarine receiving a ping, and staying silent. Return gives back an error. This can be found in pf(5).

There was something else that came to mind, about waiting for a response to packets, that allowed responses within a given time from the same port from a computer that a message was sent to. It was a stateful connection, which if the reply took too long, and the rules otherwise blocked it, it would be dropped. It could just be that any type of outgoing data went to another computer on a port, and any kind of response could come back from it, given a small window. That isn't reliable, however, for receiving data back.
- why doesn't traceroute work on the server when PF is running?
You can do a macro of variables or equivalencies of imcp and imcp6 types, which can go into the rulesets. trace for traceroute is in imcp(4).
Code:
# Macros section
icmptypeallow="{ unreach echoreq trace }"
The macro variable can be anything you choose, apart from icmptypeallow. Then, this would have to be allowed in a ruleset, which the macro is a convenient way to reference it.
- should I use the built-in blacklistd or should I use fail2ban?
Whichever works for you, has the features you need, is easier for you to use, or is to your style.
 
I'm still figuring this out and I have LOTS of questions that don't seem to be answered in any of the tutorials. Yes, everyone's firewall rules are going to be different. But I think there's a LOT of room for improvement to the docs. For example...
- should I always use "return" or should I use "drop" sometimes?
Depends on the firewall you choose.

- why are the lists of martians slightly different in almost every guide/tutorial?
Tutorials are meant as a guide. Following a tutorial to the letter may not fit your scenario exactly (Different paths, different options, etc.). You gotta be able to extract useful info and be able to connect it to your own setup. There's still a logical pattern that all those tutorials have in common, and yeah, it's on you to figure out how to mate that pattern to your system. Integrity of your system takes priority, BTW.
- why doesn't traceroute work on the server when PF is running?
Most likely, that's because ICMP (or port 33434, traceroute's default (see traceroute(8) for more info)) is blocked as a net effect of all the rules you set up.

Debugging a firewall is a MAJOR pain. So, in keeping with the Keep It Simple, Stupid principle, I can suggest an overall approach to make things a bit easier: Start by securing individual applications first. You wanna limit access to XDMCP to a list of specific users? Look at xorg.conf first. You wanna have an Apache subdomain be internal-only (but also have a public-facing site) ? look at httpd.conf before messing with the firewall.

A good analogy (with limitations, of course!) would be airport security. The firewall is TSA - they will check your luggage for guns and other prohibited items, but they will not stop you from going to the wrong gate and missing your flight. Applications are the airlines - If you have a ticket to fly on Delta, you won't be allowed to board a United flight, even if it goes to the same destination. TSA won't enforce that - it's up to the airline, not TSA. Same with firewalls - don't ask a firewall to enforce application-specific rules.

Oh, and pay attention to post #31, it contains really good and concise info:
 
Back
Top