Solved IPFW on workstation - Coming from linux to FreeBSD

Hi

In Linux I use the graphical GUFW, so it is a bit of a change to make a firewall in FreeBSD. Does this look right?

I want to allow all outgoing traffic, but deny all incoming traffic, and deny ssh access to my desktop from outside.

At the same time, I want to have access to my websites with ftps, to be able to upload and download files from my websites

Code:
sysrc firewall_quiet="YES"
sysrc firewall_type="workstation"
sysrc firewall_allowservices="any"
sysrc firewall_logdeny="YES"
 
Last edited:
An example , I have rc.conf,
Code:
# Firewall
firewall_enable="YES"
firewall_type="open"       # !!!!!!!!!!!!!!!!!!!!!!!
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
firewall_logdeny="YES"

And ipfw.rules
Code:
cmd="/sbin/ipfw -q add"   # Set rules command prefix
pif="tun0"
localpif="re0"
/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
$cmd 00200 deny  ip        from any to 127.0.0.0/8
$cmd 00300 deny  ip        from 127.0.0.0/8 to any
$cmd 00400 deny  ip        from any to ::1
$cmd 00500 deny  ip        from ::1 to any
$cmd 00600 allow ipv6-icmp from :: to  ff02::/16
$cmd 00700 allow ipv6-icmp from fe80::/10 to fe80::/10
$cmd 00800 allow ipv6-icmp from fe80::/10 to ff02::/16
$cmd 00900 allow ipv6-icmp from any to any icmp6types 1
$cmd 01000 allow ipv6-icmp from any to any icmp6types 2,135,136


# The next rule allows the packet through if it matches an existing entry in the dynamic rules table
$cmd 02000 check-state

### INCOMING
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 03001 deny all from                 0.0.0.0/8   to any in via $pif #Loopback
$cmd 03002 deny all from               10.0.0.0/8   to any in via $pif #Private
$cmd 03003 deny all from           100.64.0.0/10 to any in via $pif #Private
$cmd 03004 deny all from             127.0.0.0/8   to any in via $pif #Loopback
$cmd 03005 deny all from         169.254.0.0/16 to any in via $pif #DHCPautoconfig
$cmd 03006 deny all from           172.16.0.0/12 to any in via $pif #Private
$cmd 03007 deny all from             192.0.0.0/24 to any in via $pif #Private
$cmd 03008 deny all from             192.0.2.0/24 to any in via $pif #Docs
$cmd 03009 deny all from         192.88.99.0/24 to any in via $pif #Reserved IPV6IPV4relay
$cmd 03010 deny all from         192.168.0.0/16 to any in via $pif #Private
$cmd 03011 deny all from           192.18.0.0/15 to any in via $pif #Private
$cmd 03012 deny all from       198.51.100.0/24 to any in via $pif #Docs
$cmd 03013 deny all from         203.0.113.0/24 to any in via $pif #Docs
$cmd 03015 deny all from             224.0.0.0/4   to any in via $pif #Multicast
$cmd 03016 deny all from         233.252.0.0/24 to any in via $pif #Docs
$cmd 03017 deny all from             240.0.0.0/4   to any in via $pif #Reserved Class E
$cmd 03018 deny all from 255.255.255.255/32 to any in via $pif #Reserved Broadcast

# Deny fragments
$cmd 03100 deny all from any        to any frag in via $pif
# Deny ACK packets that did not match the dynamic rule table
$cmd 03200 deny tcp from any to any established in via $pif

# Allow incoming access from localnet
$cmd 04050 allow tcp from 192.168.1.0/24 to any in via $localpif setup keep-state
$cmd 04060 allow udp from 192.168.1.0/24 to any in via $localpif keep-state

### OUTGOING
# Allow access to outside
$cmd 04030 allow tcp  from any to any out via $pif setup keep-state
$cmd 04040 allow udp  from any to any out via $pif keep-state
$cmd 04040 allow icmp from any to any out via $pif keep-state
# Allow access to localnet
$cmd 04050 allow tcp  from any to 192.168.1.0/24 out via $localpif setup keep-state
$cmd 04060 allow udp  from any to 192.168.1.0/24 out via $localpif keep-state
$cmd 04060 allow icmp from any to 192.168.1.0/24 out via $localpif keep-state

$cmd 05000 reject log all from any to any
$cmd 06000 deny   log all from any to any
/sbin/ipfw list
 
I think your allowservices is incorrect.
My is specifically allowing ssh from 2 internal hosts.
your allowservices=any I think would be allowing any host to hit any port on your system.

if you look at /etc/rc.firewall, "workstation" by default is "block all in, allow all out keep state"
that means your workstation can initiate connections to anything outside of it, but nothing can initiate
connections to your workstation. The keep state part allows responses to traffic you initiate to come back in.
Alain De Vos is basically starting with fully open and then specifically allowing or blocking traffic.

my config: To get what you want simply remove the myservices and allowservices lines.
firewall_enable="yes" firewall_type="workstation" firewall_myservices="ssh/tcp" firewall_allowservices="192.168.251.11 192.168.252.11"
 
In Linux I use the graphical GUFW, so it is a bit of a change to make a firewall in FreeBSD. Does this look right?

I want to allow all outgoing traffic, but deny all incoming traffic, and deny ssh access to my desktop from outside.

At the same time, I want to have access to my websites with ftps, to be able to upload and download files from my websites

Just to clarify: you want ftps access from system/s on the inside net, not the outside?

Code:
sysrc firewall_quiet="YES"
sysrc firewall_type="workstation"
sysrc firewall_allowservices="any"
sysrc firewall_logdeny="YES"

Better to quote the resulting section in /etc/rc.conf, e.g. you also need firewall_enable=YES. sysrc is handy for quick fixes, but I keep rc.conf neat, and backed up against oops! ...

I think your allowservices is incorrect.
My is specifically allowing ssh from 2 internal hosts.
your allowservices=any I think would be allowing any host to hit any port on your system.

Yes, that's right. Snubbi If you carefully read the workstation code and comments in /etc/rc.firewall you'll see that mentioned explicitly.

phk@, one of FreeBSD's top developers, added the workstation section so it's good learning. Also, if you make ipfw(8) your primary reference, you'll more quickly get the hang of it, the handbook chapter secondary.

if you look at /etc/rc.firewall, "workstation" by default is "block all in, allow all out keep state"
that means your workstation can initiate connections to anything outside of it, but nothing can initiate connections to your workstation. The keep state part allows responses to traffic you initiate to come back in.
Alain De Vos is basically starting with fully open and then specifically allowing or blocking traffic.

my config: To get what you want simply remove the myservices and allowservices lines.
firewall_enable="yes" firewall_type="workstation" firewall_myservices="ssh/tcp" firewall_allowservices="192.168.251.11 192.168.252.11"

All good stuff mer.

Mine is essentially the same with different inside net addresses. Actually I think Snubbi does want
Code:
firewall_myservices="22/tcp"
allowservices="$somehosts"
(assuming using port 22 for sftp) ...

Some find the need to add ports to firewall_nologports if your router (or other hosts) spam you - in my case on port 1900 - so /var/log/security remains genuinely useful.

ipfw -ted show is your friend.

Good luck!
 
  • Like
Reactions: mer
Hi

In Linux I use the graphical GUFW, so it is a bit of a change to make a firewall in FreeBSD. Does this look right?

I want to allow all outgoing traffic, but deny all incoming traffic, and deny ssh access to my desktop from outside.

At the same time, I want to have access to my websites with ftps, to be able to upload and download files from my websites

Code:
sysrc firewall_quiet="YES"
sysrc firewall_type="workstation"
sysrc firewall_allowservices="any"
sysrc firewall_logdeny="YES"
Nope, workstation is for providing (some) services. When You have a pure desktop that only connects to elsewhere, but never gets connected from elsewhere, then "client" would be the type.
If you have some smarthome gadgets or stuff like that which needs to connect to your desktop, you can additionally allow these with something like firewall_client_net="192.168.0.0/24". Otherwise only connections initiated from your desktop are allowed (these are always allowed).

Type workstation is only when your machine shall be reachable from the internet, e.g.. is accessible per ssh from somewhere/anywhere.

Edit: I don't know what ftps is and how that works. I find it in services
Code:
$ grep ftps /etc/services
ftps-data       989/tcp    # ftp protocol, data, over TLS/SSL
ftps-data       989/udp
ftps            990/tcp    # ftp protocol, control, over TLS/SSL
ftps            990/udp

so if this works like the original ftp, then it will need some port opened and probably a workstation configuration. (I try to avoid these things and copy thru firewalls with plain https or ssh)
 
Nope, workstation is for providing (some) services. When You have a pure desktop that only connects to elsewhere, but never gets connected from elsewhere, then "client" would be the type.

Well, not necessarily. In this case ftps access is required, though it's not clear where the website server is, local or remote.

Workstation doesn't have to offer any services at all, in which case it's just a client but using stateful rules, with the ability to easily add services as required, either for outside and/or inside clients.
If you have some smarthome gadgets or stuff like that which needs to connect to your desktop, you can additionally allow these with something like firewall_client_net="192.168.0.0/24". Otherwise only connections initiated from your desktop are allowed (these are always allowed).

Though 'client' itself allows port 25 mail access in from anywhere, yet allows NO icmp at all, whereas workstation allows 'mandatory' icmp, plus ping, but (eg) mail would need adding - but it doesn't require modifying to add services.

No icmp is a real fault in both client and 'simple' rulesets, one that I fixed in modified 'simple' rulesets ever since our first little router/server with dialup clients back in '98.

Type workstation is only when your machine shall be reachable from the internet, e.g.. is accessible per ssh from somewhere/anywhere.

I don't understand why you say that; I've heard noone else do so. Both mer and I are merrily using it on systems that offer services - in this case only SSH - to other clients on the local LAN. It doesn't offer NAT.

Edit: I don't know what ftps is and how that works. I find it in services
Code:
$ grep ftps /etc/services
ftps-data       989/tcp    # ftp protocol, data, over TLS/SSL
ftps-data       989/udp
ftps            990/tcp    # ftp protocol, control, over TLS/SSL
ftps            990/udp

so if this works like the original ftp, then it will need some port opened and probably a workstation configuration. (I try to avoid these things and copy thru firewalls with plain https or ssh)

/etc/services is way out of date about some things. Google "ftps vs sftp". services has sftp as Simple File Transfer Protocol on tcp+udp port 115, but for the recent decade? it's Secure FTP on the SSH port, default 22. I prefer SCP to my remote server, on an obscure port, because it can preserve perms and modtimes.

AndFTP is a great Android FTP, SFTP, FTPS and SCP clent, btw.
 
Well, not necessarily. In this case ftps access is required, though it's not clear where the website server is, local or remote.

Workstation doesn't have to offer any services at all, in which case it's just a client but using stateful rules, with the ability to easily add services as required, either for outside and/or inside clients.


Though 'client' itself allows port 25 mail access in from anywhere, yet allows NO icmp at all, whereas workstation allows 'mandatory' icmp, plus ping, but (eg) mail would need adding - but it doesn't require modifying to add services.
Ups, indeed. Interesting, thank You. I had the understanding that "client" is the most safe approach without further configuration. Apparently that is not true.

I don't understand why you say that; I've heard noone else do so. Both mer and I are merrily using it on systems that offer services - in this case only SSH - to other clients on the local LAN. It doesn't offer NAT.
That was my understanding - I need "workstation" for setting up a cloud machine so I can reach it with ssh (and I do not know my source IP, it is dynamic), until it is fully integrated and fetches it's firewall configs from the intranet.
Otherwise, for my desktop I used "client" and never bothered about it further. But it is true, it cannot ping.
 
Directly from rc.firewall. Both are "default deny in" so connections that originate from outside the device are denied. Unless I'm misreading rc.firewall, "client" is basically "allow in from my network", "workstation" is "allow out to any keep state" which means responses are allowed back in, but still default deny. That's why I specifically allowed ssh from specific hosts; meaning I can ssh to my "workstation".

# client - will try to protect just this machine
# workstation - will try to protect just this machine using stateful
# firewalling. See below for rc.conf variables used
from the client section:
# Allow any traffic to or from my own net.
${fwcmd} add pass all from me to ${net}
${fwcmd} add pass all from ${net} to me
 
su
My password for root

Code:
sysrc firewall_enable="YES"
sysrc firewall_quiet="YES"
sysrc firewall_type="workstation"
sysrc firewall_logdeny="YES"
cat /etc/rc.conf | grep firewall
Code:
firewall_enable="YES"
firewall_quiet="YES"
firewall_type="workstation"
firewall_logdeny="YES"
service ipfw start
Code:
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
Firewall rules loaded.
service ipfw status
Code:
ipfw is enabled


According to this explanation that I found, a Stateful Firewall is better, Therefore must "Workstation" be better in my opinion. But I'm just starting out with FreeBSD, so I don't want to get smart about something I don't know much about.

https://www.fortinet.com/resources/cyberglossary/stateful-firewall

A stateful firewall collects data regarding every connection made through it. All of these data points form profiles of “safe” connections. When a subsequent connection is attempted, it is checked against the list of attributes collected by the stateful firewall. If it has the qualities of a safe connection, it is allowed to occur. If not, the data packets are discarded. Data packets contain information about the data within them. A stateful firewall performs packet inspection, which checks the contents of packets to see if they pose threats.

Stateful firewalls can also integrate additional services, such as encryption or tunnels. These boost performance because they block malicious actors from reading the contents of communications, thereby making the connection safer through access control.
 
  • Like
Reactions: mer
What do you think of my setup? Is it a correct way to create a firewall on a Desktop. Is it adequately protected?
 
cat /etc/rc.conf | grep firewall

Also check
grep firewall /etc/defaults/rc.conf
for default settings, that your rc.conf entries override.

(I only just noticed the default for firewall_nologports, which I had unwittingly replaced with others rather than appending!)

According to this explanation that I found, a Stateful Firewall is better, Therefore must "Workstation" be better in my opinion. But I'm just starting out with FreeBSD, so I don't want to get smart about something I don't know much about.

https://www.fortinet.com/resources/cyberglossary/stateful-firewall

A stateful firewall collects data regarding every connection made through it. All of these data points form profiles of “safe” connections. When a subsequent connection is attempted, it is checked against the list of attributes collected by the stateful firewall. If it has the qualities of a safe connection, it is allowed to occur. If not, the data packets are discarded. Data packets contain information about the data within them.

That much is true of ipfw in the general sense, however:

A stateful firewall performs packet inspection, which checks the contents of packets to see if they pose threats.

ipfw records a 5-tuple of each stateful connection, being src and dest IP addresses and ports plus the interface used. Only those are checked, and no inner packet inspection occurs.

If you only plow all the way through ipfw(8) once, you'll at least know what's there and where to find it next time <&^}=

Stateful firewalls can also integrate additional services, such as encryption or tunnels. These boost performance because they block malicious actors from reading the contents of communications, thereby making the connection safer through access control.

That's just fortinet sales pitch.

Also, notice the allowservices / myservices section of workstation uses non-stateful rules by default; it's fine to mix these with stateful rules where appropriate, e.g. both 'client' and 'simple' use both, so it's good to know both methods.

cheers
 
  • Like
Reactions: mer
Back
Top