From owner-freebsd-ports@freebsd.org Mon Dec 11 18:46:53 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3787FE9AA2B for ; Mon, 11 Dec 2017 18:46:53 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDC6C73462 for ; Mon, 11 Dec 2017 18:46:52 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eOT6N-0000Ok-Bt; Mon, 11 Dec 2017 19:46:55 +0100 Date: Mon, 11 Dec 2017 19:46:55 +0100 From: Kurt Jaeger To: Chris H Cc: freebsd-ports@freebsd.org Subject: Re: Procmail Vulnerabilities check Message-ID: <20171211184655.GC2827@home.opsec.eu> References: <20171211154257.GA2827@home.opsec.eu> <64e65ab97f9c2b086ed8c13620f06546@udns.ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64e65ab97f9c2b086ed8c13620f06546@udns.ultimatedns.net> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 18:46:53 -0000 Hi! > If you, as an administrator of a/your system(s), see no problem with > (port) scanners, and take no action to thwart such activity. You are > more than likely to encounter trouble(s) down the road. Right, portscanning is bad, if not done in a transparent way, so as sys-admin I have to reduce exposure. But it's a valid tool, nevertheless. > In short; I see them all as "black hats". Honestly. Can you *really* > determine good intentions from bad intentions on an incoming port scan? Yes. If it's done with full transparency, I don't mind scanning. With transparency, I mean: - reverse dns is set - scan from the same IP all the time - some point of contact for the scan (a website, email etc) - if requested, the scanner delivers individual results to the scanned - if requested, one can be excluded from the scan - all the results are only used for 'above-the-waterline' work, like research or statistics - scanner is willing to be audited - [maybe some other rules...] In fact, I've even organised such a project doing that for TLS: https://github.com/TLS-Check/tls-check I would not mind a registry at IANA for such transparent scan projects, so that all the other ones can be traced and stopped. -- pi@opsec.eu +49 171 3101372 3 years to go !