Maybe M-soft has viral attitudesNot that I realized it. Now I see what 20.20.20.0/4 is.
Thanks for the boink.
I don't think that came from the Book of pf...
Maybe M-soft has viral attitudesNot that I realized it. Now I see what 20.20.20.0/4 is.
Thanks for the boink.
I don't think that came from the Book of pf...
No. You are mixing up terms and lists.So an IETF bogons list would be more like this?
cmd="/sbin/ipfw -q add" # Set rules command prefix
pif="tun0"
### INCOMING
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 03001 deny all from 0.0.0.0/8 to any in via $pif #Loopback
$cmd 03002 deny all from 10.0.0.0/8 to any in via $pif #Private
$cmd 03003 deny all from 100.64.0.0/10 to any in via $pif #Private
$cmd 03004 deny all from 127.0.0.0/8 to any in via $pif #Loopback
$cmd 03005 deny all from 169.254.0.0/16 to any in via $pif #DHCPautoconfig
$cmd 03006 deny all from 172.16.0.0/12 to any in via $pif #Private
$cmd 03007 deny all from 192.0.0.0/24 to any in via $pif #Private
$cmd 03008 deny all from 192.0.2.0/24 to any in via $pif #Docs
$cmd 03009 deny all from 192.88.99.0/24 to any in via $pif #Reserved IPV6IPV4relay
$cmd 03010 deny all from 192.168.0.0/16 to any in via $pif #Private
$cmd 03011 deny all from 192.18.0.0/15 to any in via $pif #Private
$cmd 03012 deny all from 198.51.100.0/24 to any in via $pif #Docs
$cmd 03013 deny all from 203.0.113.0/24 to any in via $pif #Docs
$cmd 03015 deny all from 224.0.0.0/4 to any in via $pif #Multicast
$cmd 03016 deny all from 233.252.0.0/24 to any in via $pif #Docs
$cmd 03017 deny all from 240.0.0.0/4 to any in via $pif #Reserved Class E
$cmd 03018 deny all from 255.255.255.255/32 to any in via $pif #Reserved Broadcast
{ long list of rules }My current block list, it could be wrong, but everything seems to work:
I should hope so <&^}=Even listening to online radio on firefox works.
Poul-Henning Kamp wrote the default rules for the packet filters a long time ago. They were basic, but sound.
Filtering "fragmentation-needed" (ICMP type 3/4) traffic is a BAD idea. So you can't just ignore ICMP.
I detect some finger trouble there. "Destination Unreachable" is type 3. ICMP types 1-2 are unassigned.No point denying type 1 (destination unreachable) either.
169.254.0.0/16 are IPv4 link-local addresses. https://en.wikipedia.org/wiki/Link-local_addressIs there a great DHCP server in the cloud? What historically uses that?
Basically serverless DHCP. Each node picks an address in that range and does an ARP broadcast for it. If no one answers, it's available for use and the node grabs it.169.254.0.0/16 are IPv4 link-local addresses. https://en.wikipedia.org/wiki/Link-local_address
Yep. But because of this (local) usage that range isn't being routed on the internet. So it's a good idea to block incoming connections from 169.254.0.0/16 on your WAN interface.Basically serverless DHCP. Each node picks an address in that range and does an ARP broadcast for it. If no one answers, it's available for use and the node grabs it.
Quite so. Confusion with ipv6, where type 1 is destination unreachable, phk@ had it right there.I detect some finger trouble there. "Destination Unreachable" is type 3. ICMP types 1-2 are unassigned.
This had me scurrying off to patch my firewall.Yep. But because of this (local) usage that range isn't being routed on the internet. So it's a good idea to block incoming connections from 169.254.0.0/16 on your WAN interface.