Procmail Vulnerabilities check

[Chris H]

On Tue, 12 Dec 2017 09:23:55 +0100 "Kurt Jaeger" <lists at 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

> 
> -- 
> pi at opsec.eu            +49 171 3101372                         3 years to go
> !