I understand anti spoof being a special case... but I think traffic blocking is working with the self keyword in my tests and what I am trying to prevent are internal tunnels. Sounds paranoid.... but I found more than a few of my passwords as compromised.
Is there something that I'm missing? Are there firewall rules you'd use that I won't have? ----------------------------- Vaughn A. Hart [email protected] 646-284-4291 https://www.linkedin.com/in/vahart https://github.com/vaughnhart https://open.spotify.com/user/aojaa35704q6no3iqt4h6k8im?si=b8f2195781f64632 2Sam 14:14a We must all die; we are like water spilled on the ground, which cannot be gathered up again.“ Jesus said to her, “I am the resurrection and the life. Whoever believes in me, though he die, yet shall he live,” (John 11:25 ESV) On Tue, Mar 25, 2025 at 8:08 AM Stuart Henderson <[email protected]> wrote: > On 2025/03/24 12:31, Vaughn A. Hart wrote: > > Stuart, > > > > Thank you for the response. I see the antispoof for self rules expand > when I run pfctl - s all. > > I'm not 100% sure but I think antispoof may be a special case. > > > But I don’t see the block rules for the self keyword do the same; which > is why I emailed you. > > What I am attempting to do I capture all the interfaces whether they are > present at plugged in > > (say a new docking connection or thunderbolt display) and block those > addresses. I was creating > > a table for int (en0-4) and utun but I felt it wouldn’t enable filtering > on newly plugged in > > device that’s given a new interface number. So I tried to use self. > > > > block in log on self from any to 255.255.255.255 > > > block in log on self from <bad_actors> to any > > . > > > block in log on self from <level2> to any > > > block in log on self from <level3> to any > > > block in log on self from <webclient> to any > > I don't understand why these block rules need to be per-interface. > Can't you just "block in log from <bad_actors> to any", etc? > >
