On Tue, 12 Dec 2017 09:23:55 +0100 "Kurt Jaeger" <li...@opsec.eu> said
Hi! > > With transparency, I mean: > > - reverse dns is set > > - scan from the same IP all the time > They don't. For the sake of argument, I'll name showdan; they use (off > the top of my head) some 9 to 12 addresses. Addresses the move, also. :( If their IPs are published somewhere in a parseable format, I'm fine if it's multiple IPs or if they move etc. > > https://github.com/TLS-Check/tls-check > I respectfully agree to disagree with you on this. Mostly on one point; > I should be informed *prior* to the port scan/audit, not *after*. What type of announcement on what list/forum/irc-channel would you accept/monitor/etc ? 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 ? That would differentiate a research scan from an attack scan, wouldn't it ? 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.
OK My knee-jerk reaction is; there is no such thing as a "good" broad based scan -- ever. But big data is all the rage these days. So that kind of data is worth big bucks, and everybody wants a piece of the action. The scan I found most offensive, was conducted by IANA (as memory serves). It was just around the time chicken little was screaming the IP4 address exhaustion sky was falling. What I found most offensive about it, was that it was performed by one of the root servers. I have all the data somewhere, including some log excerpts. But I'm not going to have time to try and find it this morning. The purpose, again, as memory serves; was to see how much of the IPv4 address was actually being used, and what for. 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. OK that may not have been the best example; as one could argue that the onboard computers in newer cars are already capable of doing much of that, already. But I think you can see my point -- privacy should always be respected, and any (potential) violation should avoided. It should be an "opt in". One should have the opportunity waive their rights to privacy. By virtue of being connected to the internet, does not, nor should not assume you no longer have the final say on your termination point on the vast network called the internet. Sorry. I know the preface is a bit long. But I wanted to be clear, and this was as concise as I could get. I wanted to cover all the bases before articulating my responses to your questions. Using (any) of the root servers to perform such tasks is especially egregious, given that we *depend* (see; require) them to keep the internet functional. So it's harder to justify blocking all traffic from their location. I guess I've probably already answered your questions. But to address them specifically; ICAN/IANA should probably have a registry for any/all so-called; above board scanning projects/initiatives/skript-kiddies. IOW, if such a thing should/could be considered "acceptable". One should be *required* to register at IANA. They must be required to fully explain their purpose, their intent, how they 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. The last item is the one I find most troublesome. The chance that data will not be shared is next to nill. That that data won't be used for reasons *you* as a target, don't approve of, is next to nill. But if it is to ever be "permissible". Those should be the minimal terms. A fee must be required. This will help ensure that IANA can maintain, and enforce these requirements, lessen the likelihood that anyone do any of this on a whim. Lastly; for the "target". IANA must one) make the registry, and it's content public. two) IANA should create an RSS, and a list-feed, that the potential targets can subscribe to. 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. OH, you asked about (DNS) TXT entries. That would help, I suppose. In fact, as memory serves, that's what they (IANA) did in the one I mentioned above. But I think that's far too little, and ends up too late. Registration, and guidelines are the only thing that can even come close to making any of this seem even slightly tolerable, and even then... :-) Sorry. This turned out much longer than intended. I'm afraid I did all this as it came to me. Rather than better formatting it all. Hope you, and others will forgive me. My intents were pure. :-) All the best to you, Kurt! --Chris
-- p...@opsec.eu +49 171 3101372 3 years to go !
_______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
