Hi, my modest opinions: > Instead of implementing more and more details of RFC, we should > discuss what the goal is.
I'd like to have multicast routing working properly. Multicast routing with good network architecture allows people to save tons of resources on hosts, as well as saving a lot of network bandwidth. > What are the IGMP illegal packets that an attacker might use? We > should drop them. This IGMP logic is deep down in pf that a user > cannot override. Good point, and I'm happy that OpenBSD people always have security in mind. That is the main reason - not the only one - why OpenBSD is always my first choice for my projects. A couple of ideas here: 1 - discard IP and IGMP packets with illegal lengths: Ref: https://support.huawei.com/enterprise/en/doc/EDOC1100112357/11182319/defense-against-malformed-packet-attacks 2 - discard IGMP packets if multicast=NO (rcctl get multicast) Maybe the kernel already does this, but I'm not sure about it. Thanks again, regards Il giorno sab 4 mar 2023 alle ore 00:38 Alexander Bluhm < alexander.bl...@gmx.net> ha scritto: > On Sat, Mar 04, 2023 at 12:09:41AM +0100, Alexandr Nedvedicky wrote: > > 6847 /* IGMP packets have router alert options, allow them */ > > 6848 if (pd->proto == IPPROTO_IGMP) { > > 6849 /* > > 6850 * According to RFC 1112 ttl must be set to 1 in > all IGMP > > 6851 * packets sent do 224.0.0.1 > > 6852 */ > > 6853 if ((h->ip_ttl != 1) && > > 6854 (h->ip_dst.s_addr == INADDR_ALLHOSTS_GROUP)) { > > 6855 DPFPRINTF(LOG_NOTICE, "Invalid IGMP"); > > 6856 REASON_SET(reason, PFRES_IPOPTIONS); > > 6857 return (PF_DROP); > > 6858 } > > 6859 CLR(pd->badopts, PF_OPT_ROUTER_ALERT); > > > > This change should make pf(4) reasonably paranoid while keeping IGMP > working. > > OK bluhm@ >
