Ridicoulus amount of private traffic hitting WAN
-
@furom if the rule that is logging is your built in block rfc1918 rule... yeah you would have to turn that off, or turn off its logging. Little point in logging rfc1918 hits.. How many do you see other than this noise.. But you should be able to put a rule in floating, those rules are evaluated before the interface rules. But not sure about those - they might come before floating? But you could try putting a rule in floating, for that traffic, set it to quick and not to log.
I don't log that rule, and even if I did hard for me to test since
in the 6 days since I updated to 23.01, and had to reboot I have see a whole 3KB of noise.. I think I can live without those logs ;)
But if floating rule set to not log, make sure you click quick on it doesn't work.. You could disable it and then create your own rules, one that blocks the 224.0.01 noise and then one right below that does log and setup an alias for rfc1918 networks, other multicast, etc. that does log.
But I think a rule in floating should work..
-
@johnpoz Thanks, that's a possibility... Everyone is urging to enable these for WAN, but as you say, hits of this kind is not very frequent. I will give the floating a go, almost had forgotten about those. Guess I'd use it more when it comes to stuff all nets should have... :)
-
@furom Unfortunately did the floating not catch it. I set it;
I turned on logging just in case, but never hits. I'm left with disabling the built-in one then. Would have been nice to have an override on the move-restriction now... :) -
@furom Is the full description of the what "Block private networks and loopback addresses" option contains somewhere? I'd rather not remove recommended stuff
From it's description it seem to cover
- RCF1918
- RFC 4193
- Loopback 127/8 (whatever that translates to)
-
@furom yeah not sure you would have to look at the rules directly to see order, on why the ones shown on interface are before floating.
Generally floating is before interface, but not sure on those built in rules - while they are shown on the interface, in the actual rule order they might before the rules you put on floating. I would have to dig into that to be sure.
127/8 is the loopback space, ie 127.0.0.0/8
4193 is the ULA ipv6 space or fc00::/7
edit: ok looked at the rule set with cat /tmp/rules.debug and yeah the rfc1918 and bogon are before even the floating rules
# block bogon networks (IPv4) # https://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt block in quick on $WAN from <bogons> to any ridentifier 11001 label "block bogon IPv4 networks from WAN" # block bogon networks (IPv6) # https://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt block in quick on $WAN from <bogonsv6> to any ridentifier 11002 label "block bogon IPv6 networks from WAN" antispoof for $WAN ridentifier 1000001470 # block anything from private networks on interfaces with the option set block in quick on $WAN from 10.0.0.0/8 to any ridentifier 12001 label "Block private networks from WAN block 10/8" block in quick on $WAN from 127.0.0.0/8 to any ridentifier 12002 label "Block private networks from WAN block 127/8" block in quick on $WAN from 172.16.0.0/12 to any ridentifier 12003 label "Block private networks from WAN block 172.16/12" block in quick on $WAN from 192.168.0.0/16 to any ridentifier 12004 label "Block private networks from WAN block 192.168/16" block in quick on $WAN from fc00::/7 to any ridentifier 12005 label "Block ULA networks from WAN block fc00::/7"So with that, easy enough for you to recreate the block rfc1918 rule on your own, see it includes the fc00::/7 space.. And the 127.0.0.0/8 space
Since the block rfc1918 built in rule includes ipv6 space, if your wanting that in there you would make your own rule for both ipv4 and v6.. Or you could create 2 rules, and create a specific rule for the fc00::7 space
edit: Just a discussion topic. Not sure why you are worried about logging rfc or bogon to be honest.. It amounts to noise, its blocked so what does it matter? I don't have any of the default rules logging. I have my own log rules for stuff that interests me..
I don't care about out of state tcp nonsense, so my block rule for wan is SYN only block. I really could care less about UDP noise.. But there are some common ports that are used with UDP that I am interested in - so I log the interesting ports.
Now if for some reason I was seeing my rfc and bogon traffic go up, like 3GB or even 3MB vs the 3KB seeing now, and the 0 for bogon.. I prob would enable logging on them to see what is going on.
I don't really care to see multicast nonsense whatever else some noise might be on my lan side interfaces either. if something was going on and having issues or something not working - click and default rules are logging, etc. I have my own rules on my interfaces for traffic that would be of interest to me that is blocked, so I can see what device on my network is generating the traffic.
But what I do doesn't mean its what everyone would want - so if you want to log that traffic, not just this noise maker.. Then seems you will want to generate your own rules for the block rfc1918 and create a rule not to log that noise then.
Let me know if can help you get it working how you want.
-
@johnpoz Well, perhaps an update to the documentation is called for too...? While digging into RFC's I found what I belive to be a potential error in the doc here...
This network is in RFC 5735 mentioned differently, namely having CIDR of 15, not 25. But I may be way off here if intentions were something else.
-
@johnpoz said in Ridicoulus amount of private traffic hitting WAN:
Since the block rfc1918 built in rule includes ipv6 space, if your wanting that in there you would make your own rule for both ipv4 and v6.. Or you could create 2 rules, and create a specific rule for the fc00::7 space
Yes, true. For now I will create the IPv4 one, but perhaps time to include IPv6 too. It is beginning to be messy to keep stuff apart as some insist on include it, some not so much. I have tried to resist, but time to learn I suppose
-
@furom where are you seeing that.. Your link is not working.
The built rules do not block those networks.. To be honest, the odds of seeing such traffic is pretty freaking slim.. It would have to come from the wan L2 network, or your isp network none of those networks route over the public internet.
And blocking the cgnat could cause a lot of people issues - many an ISP use that to provide their customers an IP..
To be honest you could really debate the usefulness of blocking rfc or bogon to be honest - they do not route on the internet. The only concern might be if you had a port forward open.. But if you have a port forward open, and its not locked down to the source net.. Your open to all anyway.. So what does it matter if some source IP from your local ISP could talk to something you have open to the whole internet - even if not a viable public internet IP, etc.
To be honest, the only reason I have those rules even enabled on my wan, is if I post screenshots of my wan and those rules are not there - people ask why ;) heheh Easier just to leave the default wan rules in place.. But to be honest not blocking them isn't much a security issue.. And if you don't have any port forwards open, they are zero risk. And if you have your port forwards locked down to specific source IPs, again the risk falls to zero ;)
All of my wan rules include specific source nets that can talk to them - none of which would include any bogon or rfc1918 or 5735 space.
-
@johnpoz said in Ridicoulus amount of private traffic hitting WAN:
you could really debate the usefulness of blocking rfc or bogon
The way you put it, yes, sounds reasonable. I just have them on as it is the pfSense recommended way. As is right now at least, I have no need for any open ports, but still want to build in a way I could open some and not having to reinvent the whole wheel...
-
@furom haha lets go through a scenario that you do open a port.
Is this something you would open to the whole internet? If so what is the difference if someone on your same ISP or some device your isp was trying to talk to this open port from say rfc1918.. Your open to the whole internet anyway.
Better practice if opening anything up to the internet would be to lock the access to the IPs to those that might use it.. For example in mine.. That alias includes US ip space, which does not include rfc1918.. It also includes some specific IPs for monitoring services (which some are international IP space), and I do have a user of my plex currently living in Morocco, so those IPs are allowed. Again none of this space includes rfc1918, nor bogon, nor 5375, etc. So the blocking of those before become pointless from a security point of view.. Since the port forward doesn't allow them anyway.
Since something from bogon or rfc1918 would not be allowed anyway, nor would say an IP from DE, or Russia, etc. or China, etc. etc. The block rfc1918 and bogon rules really become pointless.
IMHO those rules are really left over from a bygone era - I was around during that, and sure the internet was a different place then..
We have already run into some issues here on the boards with the bogon, as new space opened up and the bogon list wasn't updated that new valid IP space was blocked as bogon.. Is there really that much space even left in there hehe.. Any who, back in the day you could not easy create an allow list with specific countries or services, etc.
You do you - and if you feel more comfortable blocking rfc1918 and bogon and 5735 - here to help you do that for sure. But their value from a security point of view -- I'm not seeing it to be honest.
-
@johnpoz lol! Yes, if I can help it I will keep things private and locked down appropriately. I will plan that carefully if that were to happen, right now it's just a thought but have no need :)
