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

Reply via email to