Re: Block a single connection with npf

[Rocky Hotas <rockyhotas%firemail.cc@localhost>]

On dic 12 12:48, Greg Troxel wrote:

> First, you are talking about "gateway" so I am guessing you have the
> usual computer with two interfaces, one to your ISP with a single IPv4
> address and one that is your home LAN, where is is .1, does dhcp, and is
> running npf.  If not please explain.

You perfectly guessed and depicted the scenario. (I omitted this because
I took this typical configuration as granted, but maybe it was necessary
to briefly mention it).

> Normally, people set up nat from LAN to WAN

Yes, exactly, and that's my case, too.

> and a firewall for incoming
> WAN packets that blocks most things except for what they want, and
> usually a stateful pass out rule so that matching packets from outgoing
> things are allowed.

I jumped straight to the second step, not having (so far) specific needs
to block something from the outside (there are no services exposed to my
public IP address):

pass stateful out all

> I am not an npf expert yet -- still on the steep part of the learning
> curve

Me neither. I'm even behind you, probably, on the very beginning of that
steep part :).

> -- but I think stateful rules only on syn packets and then apply
> to others.

Sorry, I can't understand what you meant here.

> This is a normal desire, to stop "phoning home" and "exfiltration" by
> your adversary-controlled proprietary-software-infested IOT things :-)

Yes exactly! :)

> Steppping, back, the real goal is to stop the packet from going to the
> ISP and onwards to the destination.    So you can block the packet
> inbound to if_mylan or outbound on if_mywan.  But outbound on wan, you
> have to be careful about if NAT is applied when the rule is evaluated so
> you can match.   Or you can just block target_address entirely.

I think that blocking the packet inbound to $if_mylan is the best
solution. This action should be as narrow as possible, blocking only
this connection (blocking entirely <target_address> seems to be overkill).

> I would add
> 
>   block in family inet4 proto tcp from <not_nice_host> to <target_address> port 443
> 
> instead.  Basically you want to drop all packets on that port from
> <not_nice_host> to <target_address> and you don't care if the connection
> is open or not.
> Generally I find I want to use stateful rules only to allow a reverse flow,
> and this isn't one of those times.

Ok, so basically (comparing it with my solution) you would not use
`stateful'. This makes sense.

> Another strategy, that works with ipfilter, is to have (pseudocode for example)
> 
>   block out log on wan from 10.0.0.IOT1 to any
>   block out log on wan from 10.0.0.IOT1 to <unwanted-known-place>
>   pass out on wan from 10.0.0.IOT1 to [exactly what I want to allow]
> 
> With ipf, the rule is evaluated before nat.

I think that it would be before NAT even with npf.

> However, for block-all pass-some, you need to do it outbound, because
> you might want these devices to be able to do DNS or NTP to your router
> box, even if you don't want them to communicate externally in general.

This would be a very careful strategy. However, in this specific case I
don't want to block anything, so I prefer the "block-some" approach. 

Another issue I'm struggling with is to block not a single IP, but a
custom bunch of IPs, so not a ip/subnet couple, but a range:

block in family inet4 proto tcp from <not_nice_host> to <first_IP_of_range>-<last_IP_of_range>

This gives a syntax error in npf. Also, I would like to use the
namespace, for example:

block in family inet4 proto tcp from <not_nice_host> to *.netbsd.org

But this gives error as well. I still don't know if this is just a
syntax error, or if npf does not support these two features at all.

If you dealt with this, let me know.
Thanks for your thorough message.

Rocky