Date: Tue, 12 Dec 2017 08:11:22 -0800 From: "Chris H" <portmaster@BSDforge.com> To: "Kurt Jaeger" <lists@opsec.eu> Cc: <freebsd-ports@freebsd.org> Subject: Re: Procmail Vulnerabilities check Message-ID: <0920fb2159f099e7c3e28ec31c0da955@udns.ultimatedns.net> In-Reply-To: <20171212082355.GE2827@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Dec 2017 09:23:55 +0100 "Kurt Jaeger" <lists@opsec=2Eeu> said > Hi! >=20 > > > With transparency, I mean: > > > - reverse dns is set > > > - scan from the same IP all the time > > They don't=2E For the sake of argument, I'll name showdan; they use (off > > the top of my head) some 9 to 12 addresses=2E Addresses the move, also=2E := ( >=20 > If their IPs are published somewhere in a parseable format, > I'm fine if it's multiple IPs or if they move etc=2E >=20 > > > https://github=2Ecom/TLS-Check/tls-check > > I respectfully agree to disagree with you on this=2E Mostly on one point; > > I should be informed *prior* to the port scan/audit, not *after*=2E >=20 > What type of announcement on what list/forum/irc-channel would you > accept/monitor/etc ? >=20 > Would it be sufficient, if the PTR record has some TXT that points > to the official site with the details of the scan ? So that > during incoming scans you can automatically look up the source > of the scan ? >=20 > That would differentiate a research scan from an attack scan, wouldn't it= ? >=20 > Given that most attackers scan unannounced, and systems have to handle > that case, I do not see the problem in scans being done unannounced, btw=2E OK My knee-jerk reaction is; there is no such thing as a "good" broad based scan -- ever=2E But big data is all the rage these days=2E So that kind of data is worth big bucks, and everybody wants a piece of the action=2E The scan I found most offensive, was conducted by IANA (as memory serves)=2E It was just around the time chicken little was screaming the IP4 address exhaustion sky was falling=2E What I found most offensive about it, was that = it was performed by one of the root servers=2E I have all the data somewhere, including some log excerpts=2E But I'm not going to have time to try and find it this morning=2E The purpose, again, as memory serves; was to see how much of the IPv4 address was actually being used, and what for=2E Frankly, I say bullshit! Again, I could liken it to real life situations; I bought an automobile from a car dealership, only to find later, that they've put some monitoring device in it, that tracks everything done with, and in it=2E OK that may not have been the best example; as one could argue that the onboar= d computers in newer cars are already capable of doing much of that, already=2E But I think you can see my point -- privacy should always be respected, and any (potential) violation should avoided=2E It should be an "opt in"=2E One sho= uld have the opportunity waive their rights to privacy=2E By virtue of being conn= ected to the internet, does not, nor should not assume you no longer have the fin= al say on your termination point on the vast network called the internet=2E Sorr= y=2E I know the preface is a bit long=2E But I wanted to be clear, and this was as concise as I could get=2E I wanted to cover all the bases before articulating my responses to your questions=2E Using (any) of the root servers to perform such tasks is especially egregious, given that we *depend* (see; require) t= hem to keep the internet functional=2E So it's harder to justify blocking all tra= ffic from their location=2E I guess I've probably already answered your questions=2E But to address them specifically; ICAN/IANA should probably have a registry for any/all so-called; above boar= d scanning projects/initiatives/skript-kiddies=2E IOW, if such a thing should/c= ould be considered "acceptable"=2E One should be *required* to register at IANA=2E They must be required to fully explain their purpose, their intent, how the= y intend to perform it, they should also be required to produce a schedule, including the times, and dates, and what the data will be used for=2E The las= t item is the one I find most troublesome=2E The chance that data will not be s= hared is next to nill=2E That that data won't be used for reasons *you* as a target= , don't approve of, is next to nill=2E But if it is to ever be "permissible"=2E T= hose should be the minimal terms=2E A fee must be required=2E This will help ensure = that IANA can maintain, and enforce these requirements, lessen the likelihood th= at anyone do any of this on a whim=2E Lastly; for the "target"=2E IANA must one) make the registry, and it's content public=2E two) IANA should create an RSS, and a list-feed, that the potential targets can subscribe to=2E Oh, and there should be some (further) restrictions imposed on the registrants regarding (at least) the load(s) they may impose upon their targets/victims=2E OH, you asked about (DNS) TXT entries=2E That would help, I suppose=2E In fact, as memo= ry serves, that's what they (IANA) did in the one I mentioned above=2E But I thi= nk that's far too little, and ends up too late=2E Registration, and guidelines are the only thing that can even come close to making any of this seem even slightly tolerable, and even then=2E=2E=2E :-) Sorry=2E This turned out much longer than intended=2E I'm afraid I did all this as it came to me=2E Rather than better formatting it all=2E Hope you, and other= s will forgive me=2E My intents were pure=2E :-) All the best to you, Kurt! --Chris >=20 > --=20 > pi@opsec=2Eeu +49 171 3101372 3 years to= go > !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0920fb2159f099e7c3e28ec31c0da955>