From nobody Thu Jun 13 17:02:09 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 4W0TGx562qz5P0PM for ; Thu, 13 Jun 2024 17:02:17 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0TGx1qmxz4YJd; Thu, 13 Jun 2024 17:02:17 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DH29bE047482; Thu, 13 Jun 2024 10:02:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718298136; x=1718298736; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fKsHBKntoWqHG6NAfgOrN9Uek22zuvb7Mw2oySXWaxb0OJee5M7PC6UIdJdu0sLuv GP8YTJMgvh/SJoR7IjsSw8eYIzQEwEEJO9m9zxBeFIzAs8YFoXGiBeNAJ8Iep+dXgE OJ3GDQYlFL+PX+unfH1wA5saHUJaWxRhbb9610achJp88rjejVCs1SkYchLWAO1B9d u4eeEYyYt60muz4dd9iyMUS5lJCbF4dsGa7jwXlNg7hBhwzbmI3XwIn4EAu+uNKxFX 5D9eN6XLMenbxmHbISdoBjHLw04rrHT5tlQSPJTSFCL3Iz09X080y5t6+9bgYPadup EnIW85/kZF+uw== 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 Date: Thu, 13 Jun 2024 10:02:09 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <458c91d8529cf1cb2218f8ba62e706ae@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0TGx1qmxz4YJd On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> 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. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris