> JD Bronson wrote: >> ipmon[133]: 05:18:02.104155 bge1 @0:2 b 192.168.1.254 -> 224.0.0.1 PR >> igmp len 24 (36) IN low-ttl > > If you're not using multicast IP for anything important: > > block in quick from any to 224.0.0.1 > > And/or: > > block in quick all with lowttl
I have a tendency to put the following at the top of my ipf.conf : # -------------------------------------------------------- # see http://www.obfuscation.org/ipf/ipf-howto.txt # -------------------------------------------------------- # # -------------------------------------------------------- # Block unroutable networks block in quick on hme1 from 192.168.0.0/16 to any block in quick on hme1 from 127.0.0.0/8 to any block in quick on hme1 from 0.0.0.0/8 to any block in quick on hme1 from 169.254.0.0/16 to any block in quick on hme1 from 192.0.2.0/24 to any block in quick on hme1 from 204.152.64.0/23 to any block in quick on hme1 from 224.0.0.0/3 to any # # The 127.0.0.0 is a largely wasted class-A network used # for loopback. Much software communicates with itself on # 127.0.0.1 so blocking it from an external source is a good # idea. The fifth, 0.0.0.0/8, should never be seen on the # internet. Most IP stacks treat "0.0.0.0/32" as the default # gateway, and the rest of the 0.*.*.* network gets handled # strangely by various systems as a byproduct of how routing # decisions are made. You should treat 0.0.0.0/8 just like # 127.0.0.0/8. 169.254.0.0/16 has been assigned by the IANA # for use in auto-configuration when systems have not yet been # able to obtain an IP address via DHCP or the like. Most # notably, Microsoft Windows will use addresses in this range # if they are set to DHCP and cannot find a DHCP server. # 192.0.2.0/24 has also been reserved for use as an example IP # netblock for documentation authors. We specifically do not # use this range as it would cause confusion when we tell you # to block it, and thus all our examples come from # 20.20.20.0/24. 204.152.64.0/23 is an odd netblock reserved # by Sun Microsystems for private cluster interconnects, and # blocking this is up to your own judgement. Lastly, # 224.0.0.0/3 wipes out the "Class D and E" networks which is # used mostly for multicast traffic, although further defini- # tion of "Class E" space can be found in RFC 1166. # # -------------------------------------------------------- what do you think ? Dennis
