Feature Request: Add "not" to Destination Port Range"

rjoffe

I think the subject says it all :)

i.e. block all but port 1234 or if using a port alias, block all but ports listed in ALIAS

(if this is the wrong forum, please let me know the correct place)

Ron

KOM

I'm not sure I understand. Everything is blocked by default. You must manually allow things through the firewall with rules. So if you want to block all but 1234, then just add a rule that allows 1234 and put it at the top of your rules list.

rjoffe

KOM,

Thanks for the reply. What I'm trying to achieve is something like this:

Let's look at ssh. I wan to end up with something like this:

Rules:

1. Filter all ports except 22 (ssh).
2. Filter all traffic from known list (for example pfBlocker) and log.
3. Allow port 22 in from known white list.

The key here is the logging part of step 2. If I skip step 1 and just have steps 2&3, I'll end up with junk in my filter logs which I have no interest in (for example ntp scans). Step 1 eliminates the "noise".

I can achieve this with current config, by blocking 1-21 and 23-65535 as a step 1. However this gets more complicated when I also want to allow a few other ports through. That's the request for the "not" on the destination port range.

Does this make sense, or is there a better way to achieve the same functionality

Thanks,

Ron

KOM

The firewall rules include a hidden rules called Default Deny rule which has logging enabled. Any unhandled traffic will be blocked and logged by this rule. If you want to eliminate log noise from this rule, I would create a manual block rule, set it to not log and place it at the bottom of your rules. That way it should be processed before the default rule and not log the blocked traffic.

rjoffe

KOM,

Again, thanks for the reply. Let me see if I can make the request a bit cleaner.

If I have rule set A:

1. Allow port 22 (ssh) from known hosts (no logging)
2. Deny Default (logging)

I would end up with a list of anyone not in my known hosts list with any type of connection logged.

If I then go to rule set B:

1. Deny port 1-21 (no logging)
2. Deny port 23-65535 (no logging)
3. Allow ssh from known hosts (no logging)
4. Deny Default (logging)

I would end up with a list of only those not in my known hosts list which try to connect on port 22 (ssh)

My enhancement request is for rule set C:

1. Deny NOT port 22 (no logging)
2. Allow ssh from known hosts (no logging)
3. Deny Default (logging)

This also would end up with a list of only those not in my known hosts list which try to connect on port 22 (ssh), but is cleaner.

Rule set C is a very simple example. real world is very much more complicated.

Thanks,

Ron

KOM

OK, now I see what you want and why. Sorry it took so many explanations. I've been having issues with my density lately.

rjoffe

KOM,

If you are having density issues, then you are having minor ones.

Thanks for the feedback.

Ron

Trel

@rjoffe:

My enhancement request is for rule set C:

1. Deny NOT port 22 (no logging)
2. Allow ssh from known hosts (no logging)
3. Deny Default (logging)

I think you can achieve this now like so

1. Deny port 22 from NOT known hosts (logging)
2. Allow port 22 (no logging)
3. Deny all (no logging)
4. Default Deny All (logging) <–- should never happen due to #3

Derelict

You know this seems like it should be easy. I'm going to look at it.

dennypage

I have another situation in which I would find this useful. I am looking at restricting outbound connections from a local segment to a specific set of ports (outbound connections are currently unrestricted). However before I put a restriction in place, I'd like to use a logging rule for some period of time to ensure that I won't be breaking anything.

Trel

@dennypage:

I have another situation in which I would find this useful. I am looking at restricting outbound connections from a local segment to a specific set of ports (outbound connections are currently unrestricted). However before I put a restriction in place, I'd like to use a logging rule for some period of time to ensure that I won't be breaking anything.

Have you tried this option yet?

https://forum.pfsense.org/index.php?topic=82055.msg449806#msg449806

dennypage

This is my use case:

1. Allow portlist from * (no logging)
2. Allow * from * (logging)

But sense inversion the port list would be more convenient. It wouldn't require futzing with the default rules, and is easy to convert between logging and rejecting/blocking.

Trel

@dennypage:

This is my use case:

1. Allow portlist from * (no logging)
2. Allow * from * (logging)

But sense inversion the port list would be more convenient. It wouldn't require futzing with the default rules, and is easy to convert between logging and rejecting/blocking.

What would the inversion case be? Because the rule 1 and 2 work now as you wrote them if you use an alias for the ports.

dennypage

1. Allow !portlist from * (logging)

Which after testing would change to

1. Reject !portlist from * (logging)

I agree that this use case can be achieved currently by using multiple rules based on inclustion, however it's more convenient to use a single rule based on exclusion.

@Trel:

What would the inversion case be? Because the rule 1 and 2 work now as you wrote them if you use an alias for the ports.