Magic Banana lamented:
>The third column of "output-2-column-file.txt" cannot be computed from the
input alone, as far as I understand.
If it were mine to do as well as you can ... I'd reverse the octet order in
the third column, look them both
up with nMap or nslookup, and compare to the first column. That would work
for some of the IPv4's in column 2,
but would not solve the ones that move the left-most octet to the far right,
leaving the other three octets
in "standard" order. Another script might be written to do that in order to
produce a fourth column.
> If so, why is "ns530300.ip-198-27-67.net" mapped to 53.198.27.67? That
makes little sense to me (and,
> indeed, 53 is not part of the actual address).
Tricky server owner: He reversed the 53 to 35 and put it at far right just
like some of the 10's were handled;
Now we're up to a fifth column to try in our output comparisons.
My short-term strategy is to try Google, then Hurricane Electric's BGP files.
The next step in my plan is to
grab all the hostnames of the home servers of the malevolent country codes
that appear in the output files of
the searches emanating from the 35,000-row list (maybe a couple of thousand
CIDR blocks), see how many
duplicated hostnames appear, and then go after all the CIDR blocks in each of
the active ASN's. With the
tweaks that we've discussed recently, those nMap scans run remarkably
quickly. A dedicated pattern searcher
would not limit the analysis to the known malevolents. For example, my 100+
sextortion emails came from every
corner of the world. I have a couple written in portuguese. I grew tired of
collecting them and block any
message with the word for a popular form of virtual currency, which grew out
of the ancient practice of biting
precious-metal currency that was stopped when newer currency started to be
made with reeded edges.
It's too hard to predict what will appear in the results of a Google search
on an arbitrary but nonresolving
hostname ... maybe concentrate on some anti-spam services.
Hurricane Electric's BGP application is a little easier: Plug a three-octet
abbreviation of the IPv4 address
(as oct.oct.oct.0/24) into the Search: box, pick the smaller of the two CIDR
blocks that appear in response,
ask for the DNS records, put the unknown hostname into the browser's
search-this-page function, and see what,
if any, IPv4 address lights up. The BGP data is limited to one thousand
output lines, so many hostnames
disappear from view with the larger CIDR blocks, such as CIDR/21, especially
when there are sudirectories,
i.e. "A" records.
> Notice that ns530300.ip-198-27-67.net is not mapped. As I wrote above, I do
not think it should.
I peeked at the Google data, which made the "guessing" easier. "ns530300" ==>
53 ==> 35; 300 is impossible.
I tried Magic Banana's suggested scripts, and they work exactly as written.
Alas, I haven't managed any better
than getting more than just the left-most of my intended reverse=ordered
octets to print with this modification:
tr -sc 0-9\\n ' ' < hostname_list | awk '{ k = 0; for (i = 0; k < 4 && ++i
i; ) printf $k "."; print $i } else print "" }' | paste hostname_list -
