Weird Content Filter behaviour

Hello guys, im trying to make the NEFilterDataProvider work but i just cant seem to do so. Basically what i want to do is recieve all flows (in/out) in the handleNewFlow function.

What i intend to do there is drop all inbound flows but before doing that i want to log them. Also i want to allow all outgoing flows and also log them.

Code Block
let anyHostAndPortRule = NENetworkRule(
       remoteNetwork: nil,
       remotePrefix: 0,
       localNetwork: nil,
       localPrefix: 0,
       protocol: .any,
       direction: .any
    )
     
 filterRules = [NEFilterRule(networkRule: anyHostAndPortRule, action: .filterData)]
     
    let filterSettings = NEFilterSettings(rules: rules, defaultAction: .allow)


I understand that this rule alone should be able to acomplish what i want but for some reason im not receiving outbound traffic. Is there an explanation to this?
I think its weird because when i change the
Code Block
defaultAction: .drop

to drop, i loose access to the internet so that means the outbound flows are not matching with the rule i showed you earlier. Why is that?

Thanks in advance

Replies

Addition:

This is my handleNewFlow function
Code Block
   override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict {
    if flow.direction == NETrafficDirection.inbound {
      os_log("Inbound flow %{public}s ", log:logger, flow.debugDescription)
      return .drop()
    } else {
      os_log("Outbound flow", log:logger)
      return .allow()
    }
  }

As you can see im dropping the flow after logging it but the flow doesn't seem to get dropped because i can get a connection from another mac.
From the other mac im executing
Code Block
telnet 192.168.0.19 22

and i can get a connection so i really dont know whats happening here :)
I would attempt to log the flow first before you do anything. That way you can always review it when debugging your code. For a combined approach you could try something like:

Code Block swift
override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict {
os_log(.debug, log: self.log, "Received a new flow: %{public}@ with direction: %{public}@", flow.description, getDirection(direction: flow.direction))
...
}
private func getDirection(direction: NETrafficDirection) -> String {
switch direction {
case .any:
return "(Any)"
case .inbound:
return "(Inbound)"
case .outbound:
return "(Outbound)"
default:
return "(No Recorded Direction)"
}
}



Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks Matt i'll try that.

If i use the rule i showed in my first post, shouldn't the defaultAction be irrelevant since i am filtering all flows in every direction. Also i did some tests and i found that when i use a rule that filters only inbound flows i get less flows on handleNewFlow compared to when i filter any flows. Is it possible that some flows are outbound but are mistakenly labeled as inbound?

For example if i set the direction to any i see this flow but if i set it to inbound i don't
Code Block     
 identifier = D89B5B5D-793C-4940-C0A8-001315000000
    sourceAppIdentifier = .com.apple.netbiosd
    sourceAppVersion = 
    sourceAppUniqueIdentifier = 20:{length = 20, bytes = 0x26296d2b1d70408dc2401edcce00ba38a6857ac2}
    procPID = 2910
    eprocPID = 2910
    direction = inbound
    inBytes = 0
    outBytes = 0
    signature = 32:{length = 32, bytes = 0x7e970233 faf7ac94 9d91e0a9 553ddf36 ... c7aebadc 1d6e711a }
    socketID = 151300a8c0
    localEndpoint = 192.168.0.255:137
    remoteEndpoint = 192.168.0.19:137
    protocol = 17
    family = 2
    type = 2
    procUUID = 309D480E-6792-3B63-9C4A-C295F11FF097
    eprocUUID = 309D480E-6792-3B63-9C4A-C295F11FF097


If i use the rule i showed in my first post, shouldn't the defaultAction be irrelevant since i am filtering all flows in every direction.

You should be handed the flow to take action on it if the flow matches your rule. For all other flows that do not match your rule the defaultAction will take place. If there are some flows that escape this rule, then the default action will take place.

Is it possible that some flows are outbound but are mistakenly labeled as inbound?

I have never run into this situation.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com