I have tried to enhance my FreeBSD desktop's security with some tweaks without knowing what they do ....Any other useful tweaks ?

[zirias@]

Not sure whether pf would already allow enough of it as part of the "connection state" implementation, but you normally want to also allow the ICMP type unreach. It's needed for reliable networking, e.g. to signal an unreachable UDP port, or to detect when path MTU is too small…

If you use IPv6, you'd need theses additional icmpv6 types to make SLAAC work correctly: neighbradv, neighbrsol, routeradv, routersol.

 

[john_rambo]

Not sure whether pf would already allow enough of it as part of the "connection state" implementation, but you normally want to also allow the ICMP type unreach. It's needed for reliable networking, e.g. to signal an unreachable UDP port, or to detect when path MTU is too small…

If you use IPv6, you'd need theses additional icmpv6 types to make SLAAC work correctly: neighbradv, neighbrsol, routeradv, routersol.

When you say ICMP type unreach do you mean allow outgoing ping ? If yes I have added this rule

 

[john_rambo]

Not sure whether pf would already allow enough of it as part of the "connection state" implementation, but you normally want to also allow the ICMP type unreach. It's needed for reliable networking, e.g. to signal an unreachable UDP port, or to detect when path MTU is too small…

If you use IPv6, you'd need theses additional icmpv6 types to make SLAAC work correctly: neighbradv, neighbrsol, routeradv, routersol.

When you say ICMP type unreach do you mean allow outgoing ping ? If yes I have added this rule

pass out inet proto icmp icmp-type { echoreq }

Honestly, I don't understand about any of the rest of the points you mentioned. I will have to search and learn.

 

[tux2bsd]

That's just awesome ! Success ! Thanks a lot for that.
This is my PF conf.

block all
pass out proto { tcp udp } to port { 53 80 443 995 }
pass out inet proto icmp icmp-type { echoreq }

Good to hear. There's more to learn, when you're ready you can revisit the topic (I'm not a PF expert).

 

[a6h]

Honestly, I don't understand about any of the rest of the points you mentioned. I will have to search and learn.

When a packet exceeds the MTU limit, the host sends back an ICMP message:

Type 3: unreach (Destination unreachable)
Code 4: needfrag (Fragmentation needed but DF bit set).
Hence, the unreach

icmp_types = "{ unreach }"

In short, don't block ICMPv4, unless you know what you are doing -- some limits are okay.

Some people hate ping and love NAT. They have websites to show you that your network is bad, because it's ping-able.
But ping is good! Hence,

icmp_types = "{ echoreq }"

Finally, to wrap it up:

icmp_types = "{ echoreq, unreach }"
pass inet proto icmp icmp-type $icmp_types

 

[john_rambo]

In short, don't block ICMPv4, unless you know what you are doing -- some limits are okay.

I am the only person in my house who uses a computer. I maintain only one desktop. So the question is since there is only one client behind my 4G router (my desktop running FreeBSD) does it really matter if incoming ping is enabled or not ?

BTW, when I check my router at grc.com all ports are blocked including ICMP. The website grc.com too thinks that allowing ping is not a good idea. If a user has enabled ping on his perimeter firewall grc.com reports the port scan test as "Failed".

 

[zirias@]

I check my router at grc.com

Unfortunately, you found the site of the greatest buffoon in network security. That's the same guy who recommends cascading two times NAT, cause more NAT, more secure

Just forget about it. There's no way to hide the presence of a machine on the network, as Gibson claims (btw, BECAUSE of ICMP and routers sending appropriate messages back when a machine really isn't there), so there's also nothing wrong with just rejecting what you don't want (which allows the other peer to fail quickly) instead of dropping it (which kind of breaks IP and requires the peer to wait for timeout).

As for ICMP, ping (echoreq) probably isn't very relevant for full functionality of your network. It's just a nice way for quick diagnostics. But unreach definitely is important for correct operation.

 

[john_rambo]

Unfortunately, you found the site of the greatest buffoon in network security. That's the same guy who recommends cascading two times NAT, cause more NAT, more secure

Just forget about it. There's no way to hide the presence of a machine on the network, as Gibson claims (btw, BECAUSE of ICMP and routers sending appropriate messages back when a machine really isn't there), so there's also nothing wrong with just rejecting what you don't want (which allows the other peer to fail quickly) instead of dropping it (which kind of breaks IP and requires the peer to wait for timeout).

As for ICMP, ping (echoreq) probably isn't very relevant for full functionality of your network. It's just a nice way for quick diagnostics. But unreach definitely is important for correct operation.

Okay I am I am enabling unreach now buy adding the rule vigole has mentioned. I am just curious. Despite the fact that unreach is not allowed at the moment everything is working as usual. What kinds of symptoms may appear later if unreach is not enabled ?

 

[zirias@]

What kinds of symptoms may appear later if unreach is not enabled ?

If pf doesn't allow it anyways because of connection state (might be, I don't know), you're running into timeouts trying to connect to some service that's down – instead of detecting that instantly.

Even worse (but rare), if somewhere on the path to a remote host, MTU is smaller than normal, and your protocol forbids packet fragmentation, those packets will just be lost and you'll never know unless, again, running into timeouts. Normal operation would be that the router that *would* need to fragment informs you about that fact using an icmp unreach packet, so your side can immediately retry sending smaller packets.

edit: again, I'm not sure this would be a problem with pf. Maybe pf's connection state would correctly attribute these ICMP packets to your connection and implicitly allow them. Someone on here knows for sure? Anyways, just allowing unreach doesn't hurt and makes sure IP works as designed.

 

[zirias@]

When a packet exceeds the MTU limit, the host sends back an ICMP message:

To be precise, it's most certainly a router sending this back (because the unfragmented packet can't make the next hop for being too large for the link MTU). But apart from that nitpick, thanks for adding details

 

[mickey]

edit: again, I'm not sure this would be a problem with pf. Maybe pf's connection state would correctly attribute these ICMP packets to your connection and implicitly allow them. Someone on here knows for sure? Anyways, just allowing unreach doesn't hurt and makes sure IP works as designed.

From pf.conf(5):

     Furthermore, correct handling of ICMP error messages is critical to many
     protocols, particularly TCP.  pf(4) matches ICMP error messages to the
     correct connection, checks them against connection parameters, and passes
     them if appropriate.  For example if an ICMP source quench message
     referring to a stateful TCP connection arrives, it will be matched to the
     state and get passed.

If that doesn't quite answer your question ...
So there should be no need to explicitly allow icmp type unreach messages.

 

[a6h]

Unfortunately, you found the site of the greatest buffoon in network security. That's the same guy who recommends cascading two times NAT, cause more NAT, more secure

Upvote and DOUBLE_THUMS_UP!
john_rambo just undo/un-learn whatever that GRC buffoon has ever said.

 

[zirias@]

If that doesn't quite answer your question ...
So there should be no need to explicitly allow icmp type unreach messages.

Unfortunately, it doesn't talk about UDP

 

[mickey]

Unfortunately, it doesn't talk about UDP

It talks about state matching, which I presume would include UDP, just not particularly

 

[john_rambo]

Upvote and DOUBLE_THUMS_UP!
john_rambo just undo/un-learn whatever that GRC buffoon has ever said.

I never visited grc.com to learn anything in particular. Whenever I have installed a new router or changed my ISP which again made me change my router I visited grc.com & used grc.com's sheilds up service to make sure all ports are closed. That's it.

 

[zirias@]

I never visited grc.com to learn anything in particular. Whenever I have installed a new router or changed my ISP which again made me change my router I visited grc.com & used grc.com's sheilds up service to make sure all ports are closed. That's it.

This service actually works quite fine, it just gives bad advice (all this nonsense about "stealth"). It's ok to verify the ports you want "closed" on your machine are indeed closed… (like, btw, many other online port scanning services)

Edit: I just had another look and noticed it completely ignored the fact that my host is "dual-stack" with IPv6. If you use IPv6, you definitely need other tools to verify your firewall rules

 

[mer]

as root sockstat -l will give you a list of the "Listening Sockets" on your system. a "-4" will give IPV4, -6 IPV6. Without either, gives all including unix domain sockets.
Example on one of my systems:
sockstat -4l USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 81036 3 tcp4 *:22 *:* root syslogd 72938 6 udp4 127.0.0.1:514 *:*

Shows on this machine I have sshd on port22 open (yes, on purpose, its on my internal LAN) and syslogd listening on port 514 BUT only on 127.0.0.1.
The whole LAN is behind a packet filter device that does "default deny in on WAN" so a connection from outside world should not be able initate conversation with anything behind it or the packet filter itself.

There are also a couple of sysctls that you can set to have the kernel explicitly drop the packet if there is nothing listening on the port (I think the tcp/udp blackhole sysctls). The normal behavior is to send back an ICMP if there is no listener for a given port.

I have no opinion on grc.com or the folks running and posting there. One has to be careful with any "tool": you have to make sure you understand what it's saying.
Example:
I remember a port scanner tool that would any ICMP response coming back from a system as an indication the port is open.
Concrete example:
using my system above, if it tried to connect to a.b.c.d port 837 it would normally get back an ICMP unreachable. The scanner would then say "System at a.b.c.d has port 837 open" which it does not.

That's why I set the sysctls to just drop the inbound packets if there are no listening sockets open.

 

[john_rambo]

Edit: I just had another look and noticed it completely ignored the fact that my host is "dual-stack" with IPv6. If you use IPv6, you definitely need other tools to verify your firewall rules

I just checked my router's admin page. On the WAN page lists both an IPV4 & an IPV6 address. So which online site is capable of verifying my router's firewall rules ?

 

[john_rambo]

mer
This is what I see on my system

~> sockstat -4l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
root     cupsd      1973  6  tcp4   127.0.0.1:631         *:*
avahi    avahi-daem 1961  14 udp4   *:5353                *:*
avahi    avahi-daem 1961  16 udp4   *:13614               *:*
ntpd     ntpd       1931  21 udp4   *:123                 *:*
ntpd     ntpd       1931  24 udp4   127.0.0.1:123         *:*
ntpd     ntpd       1931  25 udp4   192.168.225.21:123    *:*
root     syslogd    1839  7  udp4   *:514                 *:*
root     wpa_suppli 1381  3  udp4   *:*

~> sockstat -6l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
root     cupsd      1973  5  tcp6   ::1:631               *:*
avahi    avahi-daem 1961  15 udp6   *:5353                *:*
avahi    avahi-daem 1961  17 udp6   *:13094               *:*
ntpd     ntpd       1931  20 udp6   *:123                 *:*
ntpd     ntpd       1931  22 udp6   ::1:123               *:*
ntpd     ntpd       1931  23 udp6   fe80::1%lo0:123       *:*
root     syslogd    1839  6  udp6   *:514                 *:*

 

[mer]

That's pretty much "normal".
cupsd is printer support, if you don't need it, disable it. Other wise, it's listening on loopback so not really a big deal.
avahi: "multicast DNS" stuff. I turn it off, regular DNS works fine for me.
ntpd: even if you only use it for a client the base ntpd will open a couple of listening sockets. If you are not going to serve time from this machine, take a look at the openntpd port/package. Works fine and if in client mode, no listening sockets. But if your machine has firewall rules that start out with 'default deny' it's ok, because that prevents outside machines from initiating a connection to your ntpd.
syslogd: that's the default, if you add:
syslogd_flags=" -b 127.0.0.1"
to your /etc/rc.conf and service syslogd restart it will listen only on loopback so the local machine can log.
Again, if your firewall rules are default deny, outside machines can't initiate a connection to it.

 

[zirias@]

I just checked my router's admin page. On the WAN page lists both an IPV4 & an IPV6 address. So which online site is capable of verifying my router's firewall rules ?

Google will find many portscanning services for IPv6

But first verify that your host actually has a public IPv6 address (one without an interface scope at the end like e.g. %re0). I assume it doesn't, cause you'd have to configure FreeBSD to accept router advertisements etc. In that case, your host won't be reachable by IPv6 anyways.

 

[john_rambo]

Google will find many portscanning services for IPv6

But first verify that your host actually has a public IPv6 address (one without an interface scope at the end like e.g. %re0). I assume it doesn't, cause you'd have to configure FreeBSD to accept router advertisements etc. In that case, your host won't be reachable by IPv6 anyways.

I used the ifconfig command but see only a IPV4 address for wlan0. Under Linux I used to get both a IPV4 and IPV6 local address . So my router has both an IPV4 & IPV6 public IP address while FreeBSD has only a IPV4 local IP address. Are there any disadvantages of not having a IPV6 local IP address that I should be aware of?

 

[zirias@]

Are there any disadvantages ?

You can't reach IPv6-only services. But these are still very rare. The only example I know right now are the official FreeBSD package builders, if you want to browse build logs there (E.g. this link to a package build for fbsd13/amd64 won't work without IPv6)

So well, maybe you might want to enable IPv6, but then, you should make sure it's properly secured as well!

 

[john_rambo]

You can't reach IPv6-only services. But these are still very rare. The only example I know right now are the official FreeBSD package builders, if you want to browse build logs there

Okay, then my plan is to continue using FreeBSD with only the IPV4 address. If in future if I face any issues like a web page not loading in Firefox due to lack of IPV6 address I will attempt to enable IPV6 locally.

 

[john_rambo]

So well, maybe you might want to enable IPv6, but then, you should make sure it's properly secured as well!

When I look at how the rules of PF are created, they neither mention IPV4 nor IPV6. So doesn't that mean when you are creating a block rule both IPV4 & IPV6 are getting blocked & similarly when there is a pass/allow rule it applies to to both IPV4 & IPV6 ?