From nobody Wed Jun 12 21:47:54 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vzzg61KBgz5NWpy for ; Wed, 12 Jun 2024 21:48:02 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vzzg50xjkz4NC7; Wed, 12 Jun 2024 21:48:01 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gndrsh.dnsmgr.net; spf=pass (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net designates 65.75.216.6 as permitted sender) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45CLls89042314; Wed, 12 Jun 2024 14:47:54 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45CLlsgN042313; Wed, 12 Jun 2024 14:47:54 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Wed, 12 Jun 2024 14:47:54 -0700 (PDT) CC: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.896]; DMARC_POLICY_ALLOW(-0.50)[gndrsh.dnsmgr.net,none]; R_SPF_ALLOW(-0.20)[+ip4:65.75.216.0/23]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Vzzg50xjkz4NC7 > I propose that we start dropping inbound ICMP REDIRECTs by default, by > setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > changing the associated rc.conf machinery). I've opened a Phabricator > review at https://reviews.freebsd.org/D45102. I propse that we NOT do this. If you need this to protect your end node your probably doing something really unsafe network wise. The place that ICMP REDIRECTS should be dropped, and is most places, is at access routers and firewalls. Any one that needs this change to protect there network has larger issues than an ICMP REDIECT causing some issues. ICMP redirectr are very usefull for not having to run routing protocols on all your end nodes and allowing your edge/access routers tell your internal hosts via redirects how to get to places more efficiently. > > ICMP REDIRECTs served a useful purpose in earlier networks, but on They still serve this very usefull purpose. > balance are more likely to represent a security issue today than to > provide a routing benefit. With the change in review it is of course > still possible to enable them if desired for a given installation. > This change would appear in FreeBSD 15.0 and would not be MFC'd. > > One question raised in the review is about switching the default to > YES but keeping the special handling for "auto" (dropping ICMP > REDIRECT if a routing daemon is in use, honouring them if not). I > don't think this is particularly valuable given that auto was > introduced to override the default NO when necessary; there's no need > for it with the default being YES. That functionality could be > maintained if there is a compelling use case, though. The policy that is there now is exactly how things should be configured for a host in a network protected by a proper router w/firewall. The existing "auto" does exactly the right thing. > > If you have any questions or feedback please follow up here or in the review. > > -- Rod Grimes rgrimes@freebsd.org