Magic Banana grumbled:
"Still no expected output..."
Maybe our postings passed each other by like ships in the night ... I really
did add several example files
attached to their relevant postings or referenced to a preceding posting.
Maybe a list of what appears to
be missing would help. I was careful to test all the scripts with their
source files.
"If the so-called "painfully obvious IPv4 addresses" are those that my last
sed's substitution extract, ..."
Not so. Too much is being read into my hyperbolic remark. Those pesky IPv4
addresses are listed, thoroughly
intermixed, with the looked-up PTR data. They're difficult to unmix, because
sorting doesn't discriminate
between numerical parts of PTR's and real IP addresses. IPv6 addresses are
easy, because they can be found
with grep by searching on the colon ':' separator.
Repeating: those IPv4and IPv6 addresses that weren't looked up by the
website's apache server had no DNS
service, and so are in classes by themselves. The addresses that Magic
Banana's excellent scripts extract
can often be tested by applying reverse DNS, but I'm finding that some IPv6
addresses that came to my
attention by means of nMap scans can be rather refractory, sometimes because
their server has been powered
down or because new PTR records have been applied to them. I even found one
set of addresses that came back
online between a Sunday nMap scan and a Tuesday re-scan.
Magic Banana's fourth script in his June 23 (17:00) works convincingly:
sed
's/[^0-9]*\([0-9]\{1,3\}\)[^0-9]\{1,5\}\([0-9]\{1,3\}\)[^0-9]\{1,5\}\([0-9]\{1,3\}\)[^0-9]\{1,5\}\([0-9]\{1,3\}\).*/\1.\2.\3.\4/'
IPv4-SourceList.txt | paste IPv4-SourceList.txt - > FourthScriptOutput.txt
Bear in mind that various obfuscation schemes may have been applied to these
PTR's, as Magic Banana addressed
some time ago with more sophisticated scripts, so the IP addresses have to be
checked by reverse DNS against
their PTR records as recorded in the Recent Visitor data. I'll check these
with:
awk '{print $2}' 'FourthScriptOutput.txt' > Temp0623E.txt ; dig -x -f
Temp0623E.txt | grep -A 1 "ANSWER SECTION:" '-' | awk '{print $5} '-' |more
The output of this ad hoc script is simply, 92.242.140.21, which is the
catch-all for unresolvable addresses.
That's the same as the apache server reported for those IPv4 addresses in May
2020. Their CIDR/24 scans may be
more revealing. That said, my check does not discover any IPv4 addresses that
inadvertently came from any of
the PTR's. Incidentally, the IPv6-List.txt file gives the identical result,
which is as expected, as there are
no PTR's with colon ':' separators.
In the meantime, collecting multi-addressed PTR's lurking in CIDR blocks has
been proving very fruitful,
especially when applied to the CIDR/32 portions (i.e., the left-most two
hextets of the not-looked-up
IPv6 addresses in the Recent Visitor data, as well as the right-most octets
of the not-looked-up IPv4
addresses in the same Recent Visitor data). There remain a great many simple
PTR records with no
embedded IP data at all or with inscrutible obfuscations that can only be
resolved by the nMap searching
scripts which are filling up my storage media.
Thank you for your continuing constructive analyses.
George Langford
