As I've stated before, there are redundancies in my scripts, but they force
me to
check the order of the columns in the original files. Once the script
functions as
I expect it should, I relax and press on. Time flies when one's making
progress.
The whole exercise in this posting is exactly to create a whole mess of
files,
each one listing the (sometimes millions) of IP addresses claiming the same
PTR
record. These text files will be linked to the Recent Visitor data
spreadsheets
(which Magic Banana has helpfully taught me to code in HTML), thereby keeping
the
basic presentation within reason. The entire set of illustrative address
listings
would make one webpage hopelessly immense, defeating the purpose of calling
attention
to the abuse of IPv4 and IPv6 address space.
The address listings ought to remain in text form so that exploring the
contents of
those many like-named servers is done only by experienced and wary observers.
The number-of-instances column in PTRList.txt is retained only as a check on
the
accuracy of any script that creates individual text files for all the
multi-address
PTR records. Concatenated into one file makes such a list a very slow-loading
page.
The final join between the listing of the PTR's in the overall PTRList.txt
file will
dictate which PTR's make the final cut. The counts can be restored later.
The initial step is to extract all the multi-address PTR's after
concatenating the
outputs of the nmap scripts that queried the 50,000 CIDR/16 blocks extracted
from
the Current Visitor data. Those scripts are already written & tested. Next,
join the
PTRList.txt file (no need for that superfluous Column $3) with the Recent
Visitor
data to discover which (of the multi-address PTR's resolved by the nmap
scans) are found
in the gratuitously looked up hostnames cataloged by the Webalizer analyses
of the
reporting domains. Those many Internet addresses can be readily checked with
dig -x
or nslookup; most of the ones that haven't been defensively changed already
on the
servers should resolve to their hostnames as listed in the Recent Visitor
data. The last
step is to publish these correlations to facilitate the defense of domains
undergoing
attack by hosts that cannot be resolved, except by tedious perusing of search
engine
data, and therefore are unblockable. Uploading the text files listing the
known
addresses of the reported multi-address PTR records will be a slow process,
but the
separate listings linked in the presentation webpage will be more accessible
on a
one-file-at-a-time basis than an all-encompassing master list that might
quickly
become obsolete.
George Langford