jKILLSPAM.schipper@math.uu.nl wrote:
> Igor Sobrado <igor@nospam.invalid> wrote:
>>
>> Indeed. But the final ruleset can be complex. A way to check these
>> rules (apart of translating all the rules to ipf and using ipftest)
>> would be great. Even if the initial set of rules is simple (all
>> connections blocked by default, dynamic/private ports with the
>> behaviour shown here), the pf configuration file can grow and become
>> complex. It would be nice being able to check the proposed configuration
>> files, apart of translating the rules to ipf or using nmap.
>
> pfctl -nf /some/file does a basic syntax check, which does not of course
> prove your rules correct but will at least catch some mistakes.

Thanks a lot for this excellent advice. Indeed, it is the way
I discovered some days ago that groups (in the *ipf* sense) are not
available in pf... at that time I supposed that a mostly portable
ruleset (e.g., not using lists) and some minor changes to take
advantage of pf improvements (e.g., scrubbing) was all we need.
But all rulesets I wrote in the past use groups.

Now I am looking at the excellent FAQ, looking for information about
how "anchors" work. I like ipf groups *not* because it is a way to
optimize rules (I certainly prefer automatic optimization!); for me,
the main advantage of groups is that it helps organizing rulesets
in a logical structure. I think that "anchors" are more powerful
to achieve this goal. It seems that anchors have all the advantages
of ipf groups but let the computer to optimize rulesets. Another
excellent design decision.

> Otherwise, running an OpenBSD instance in a emulator (qemu, vmware, or
> - hopefully soon - Xen) might be good for helping. However, to the best
> of my knowledge, there is no tool corresponding to ipftest currently
> available on OpenBSD.

Well, as you say I can set up the firewall on some machine. Now tools
like netstat and nmap can do an excellent work analyzing our ruleset.

I will do it, thanks!

>> That is the reason I am considering using "UsePrivilegedPort", it is
>> not only documented on ssh(1) but it is also the first question on
>> the OpenSSH FAQ. The real issue is not passing traffic to port 22,
>> but sending traffic out of the machine (I want to block both incoming
>> and outgoing packets by default).
>
> It appears we are not understanding each other.
>
> pf(4) allows you to allow connections to port 22 on either all hosts or
> a list/table of hosts; this is about *outgoing* connections, of course -
> incoming connections can be treated similarly, but we are not talking
> about them here.
>
> When using the 'keep state' mechanism, the return traffic of the
> connection is also taken care of - there is no need to explicitly allow
> traffic back to some high-numbered port.
>
> This is done with 'pass out on $some_if to <ssh_servers> port ssh keep
> state', as noted above. I do not understand what else you want to
> achieve.

I know that a "keep state" would open a (previously closed) port to
the machine on the other end of the communication channel. In other
words, if port "x" on machine "A" establishes a communication to
port "y" on machine "B", all traffic with source on B:y is automatically
accepted by A:x -- no need to explicitly allow connections from B.

My problem is that I do not want to set a rule like "block in all",
but a rule like "block all" (both incoming/outgoing traffic blocked
by default), except for high-numbered ports (where clients should be
able to establish connections with remote servers, but only with these
servers). I do not want to expose a client if it is not required at all
(perhaps am I a bit paranoid?).

My goal is that a server (or a client using a port < 49152, except an ssh
client, of course) will not be able to establish a connection with a remote
machine without being authorized.

Certainly "keep state" will do the work if all traffic with source on
the local workstation is allowed to reach the world.

Perhaps it is a too complex design to win too few, and it is better
stay at a classic "all traffic arriving to our machine blocked by
default, all traffic with source on our machine allowed". What do
you think?

Cheers,
Igor.