From owner-freebsd-hackers Sat Nov 18 13:51:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 0E89937B4C5 for ; Sat, 18 Nov 2000 13:51:21 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 93BE33E5B; Sat, 18 Nov 2000 22:51:19 +0100 (CET) Date: Sat, 18 Nov 2000 22:51:19 +0100 From: Jesper Skriver To: Mike Silbersack Cc: Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001118225119.B73853@skriver.dk> References: <20001118183632.A99512@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Sat, Nov 18, 2000 at 03:18:36PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 18, 2000 at 03:18:36PM -0600, Mike Silbersack wrote: > > On Sat, 18 Nov 2000, Jesper Skriver wrote: > > > > or just stop filtering totally. > > > > Which is not a option in this case, and in the real world it's that > > uncommon. > > > > I'll see if I can get code together which will do this. > > > > If we leave this off by default, would people object to putting in > > this functionality ? > > > > /Jesper > > What's the point? If people complain about a badly setup MX behind a > firewall, are you going to respond and tell them to flip a sysctl? My motivation is primarily to get the code working, and perhaps in the future get it enabled by default. But until then tell people that a sysctl can get this behaviour. > This isn't a case of interoperability with a common TCP stack which needs > to be lived with. It's a case of something that is broken even with the > suggested "fix". I wouldn't call it broken, why should the routers bother to send a ICMP access prohibited (or any of the other unreachables) if nobody cares anyway. My approach is a bit more pragmatic, and as I can see it, the chance that a attacker can abuse this seems very slim. > The correct thing to do in this situation is to configure sendmail > properly so that the MX silliness isn't needed. Using a static mail routing from a public known MX to the real mailserver is certainly a better solution if the same people control both, but in this case it's not like that. Let me explain in a bit more detail. We have lots of ADSL users (potentially hundreds of thousands), lots of these have open relays(*) that relay via our mailservers, making our mailservers open for spammers to use. The best solution we have been able to find, was the filters that block access to tcp/25 except from the backup-mx host, this eliminated the open relays once and for all, with very little work. We have no knowledge of which domains the users have (and this also changes all the time), and the price structure doesn't leave room for the hazzle of maintaining (and supporting) such static mail routing table, it's also significantly easier for the users to understand why they should configure xyz.dk. IN MX 10 xyz.dk. xyz.dk. IN MX 20 backup-mx.post.tele.dk. than xyz.dk. IN MX 10 backup-mx.post.tele.dk. And then do what ever to get the static mail routing configured. *) Often a simple "gateway" like WinGate or similar with by default seems to give this "functionality" :-( /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message