Question Regarding Default Deny Rules
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k that rule you have there with 0/0 has never been evaluated.
You sure that 192.168.x.x is in your alias - it pretty pointless to obfuscate rfc1918.. Like trying to hide you live on the planet earth.. Nobody can do anything with your rfc1918 space..
My machine is 192.168.9.100, my nas is 192.168.9.10 my ntp server is at 192.168.3.32 - what would you do with those IPs? You going to hack me now? ;)
I would have to do some testing, but my default deny has been off for year and years.. I setup a rule to log what I want to see.. For example on my wan I only log syn packets, and some common udp ports.. I don't care to see all the other noise out there.
But my from the hip thing to look at since that rule has never been evaluated is that your IP is not in the alias that is being blocked and logged by the default deny.. Look in tables under diagnostics
What I would do is just turn off default logging.. Your any any rule above is going to allow everything.. So anything blocked is going to be out of state anyway.. There is zero reason to see that noise.
Fair enough. Its just habit to redact stuff, so I don't even really think about it when I do it.
I understand your point about disabling the log and adding entries to target specific stuff to log. I am just in the beginning stage of using pfsense on this network so I want to just monitor it a bit before I disable or mask the logging. I realize it will probably be fruitless but again its the comfort of habit if nothing else. I would also say that learning some of these things is also to help me in the event I have to troubleshoot packets being blocked in the future. Learning about the default deny rule will serve me well for sure.
I did double check and the IP from that log entry is 100% in the Alias.
-
@djtech2k then you might have to do what @stephenw10 mentioned about the states.. Its possible that block rule is only looking for syn to block and not log, and the fa are falling thru all the way to the default deny still. Which would explain the 0/0 showing it has never triggered ever.
Or set it to any vs tcp might do the same thing has he mentions in next post.
-
I changed the FW block rule and checked the All TCP Flags block. I will monitor the logs and see what happens.
-
@djtech2k prob just set to any for the protocol as well vs calling out tcp. it would be a cleaner looking rule.
-
I just saw more logs from roku with the TCP:RA flags so I guess I will try any protocol. This seems so strange to show up as it is setup.
-
@djtech2k assuming your rokus are wireless right.. Wireless can introduce retrans of packets.. so pfsense might have seen the RA and closed the state, but then it saw another one of them after the state was already closed - so yeah it would block it because loss of state.
you might want to run a sniff for one of your roku IPs and then wait til you see one of thos fa or ra blocks and look into the packet capture of exactly what pfsense saw.. Quite possible they are retrans after the state has already been closed - ie noise, which is why turning of default logging is great option for reducing log spam/noise.
You can put a default rule at the end of your interfaces that have complex allow rules to see if your missing something that should be allowed, etc.
Example - my work laptop connects to my guest network, it is almost always connected to work vpn.. But when its not it can send out noise trying to get to rfc1918 stuff at work that it can not get to because well its not connected to the work network via vpn.. So I created some rules not to log any noise it might send out.
-
I have about half of my Roku's wireless and the other half are connected via ethernet. I am going to continue to check the logs every so often to see what pops up and maybe I will grab another packet capture.
I realize this traffic is probably benign and turning off the default logging is the easiest way to avoid it. Like I said, I am more using this as an opportunity to investigate something that I may want/need to do for another purpose down the road.
-
@djtech2k sure makes sense - keep in mind that if your ever running into something weird that not sure what is going on - turn default logging back on is always just a click away ;)
-
Hmm, I would have expected that block to match before the default block though. It's definitely on the correct interface?
-
@stephenw10 said in Question Regarding Default Deny Rules:
Hmm, I would have expected that block to match before the default block though. It's definitely on the correct interface?
Yes, everything is on the LAN interface. All other physical interfaces are disabled there are only 2 vif's, which are for the vpn server and vpn client.
-
Hmm, must be something not matching. The source traffic is definitely in the alias?
What exactly do the rules look like now?
-
@stephenw10 said in Question Regarding Default Deny Rules:
Hmm, must be something not matching. The source traffic is definitely in the alias?
What exactly do the rules look like now?
I have checked the alias members a few times when looking at a specific packet and its always been in a member.
Here are the current rules:
-
And it's still logging TCP flagged packets from devices inside that alias hitting the default deny rule?
If you reload the ruleset in Status > Filter Reload does it show any errors?
-
I am not seeing it this second but I will check back on it every once in a while to see if it shows up. I have my logging set to the last 750 lines so it rotates/overwrites pretty quickly.
-
So far I am not seeing it from Roku. I am seeing it from a couple of other devices, like a camera. Its getting the TCP:RA or TCP:PA flags and trying to hit a port 443 destination. This device(s) are not in the Alias because its not a Roku but if the same theory applies, I could add it to the alias.
-
Given what I have gathered from this thread, I do wish I could figure out the right flags or whatever needed to catch these packets so I could create a rule for all of them. I hate having a block rule for wide open protocols, etc.
So as of now, I have the block rule as you see from the screenshot. Its isolated to my Alias, but if there are other devices with similar traffic, would it be harmful to just make the rule apply to everything? I mean it would be at the bottom so theoretically it would only apply if the Allow Any/Any rule did not apply for some reason.
To be honest, it is a bit confusing how the default deny rule is not shown and then there are things like these 443 packets that don't get caught with a TCP filter. I am ok to create a rule to block/remove the logging but don't want to put in something that may end up blocking traffic that could impact something.
-
@djtech2k said in Question Regarding Default Deny Rules:
. I am ok to create a rule to block/remove the logging but don't want to put in something that may end up blocking traffic that could impact something.
putting any sort of rule that blocks below a any any rule isn't going to block anything that could get out anyway. If there is no state it isn't getting out anyway so the block is there to just not log noise/spam
-
Corrected: Now seeing it from Xbox, not “not” seeing it from Xbox.
Just for additional info, I am now seeing a ton of traffic like this for an Xbox. I guess it’s just been turned on or at least that I saw it. Lots of port 443 traffic with the TCPFA or TCP:PA flags getting blocked by the default rule.
-
@djtech2k said in Question Regarding Default Deny Rules:
Given what I have gathered from this thread, I do wish I could figure out the right flags or whatever needed to catch these packets so I could create a rule for all of them. I hate having a block rule for wide open protocols, etc.
Yes, you are only seeing blocked TCP traffic so you should be able to block-not-log only that. I would have expected the rule with 'any flags' you have previously to do that.
-
Yes, I was surprised that the filter with TCP any flags did not catch this stuff. Either way, I am not seeing ROKU logging this morning so I adjusted the rule to include LAN subnets with destination port 443. Since the Any/Any rule is above it, I am assuming any traffic that hits this block rule will be blocked anyway so this rule will at least suppress the logging. When I end up disabling the default deny logging, I can disable this rule, but for now this rule will help me get a better idea of what is being blocked and it anything needs tuned.
