I have 22.214.171.124/29 blocked from my website, but I didn't see anything to make me think it is the Cyveillance people. It's not SWIPed to them. There are no other netblocks reassigned (or allocated) to the CYVEIL organization id besides 126.96.36.199/27.
On what basis do you think 188.8.131.52 is Cyveillance? If it is them, I'm going to move it to "all protocols and ports" blocking.
I don't normally use samspade, but using it I see that the netblock was reassigned but not SWIPped, so the ARIN server does not have the information, which is why it didn't show up in my own investigation.
That netblock is definitely getting moved to "all protocols and ports". Thanks.
I run my website and email on a server in my apartment (on a business-class connection with a static IP address so it's all legit). I built the server, installed the operating system (Linux), etc. Ditto for the Linux-based firewall/router system. So I have *ultimate power*.
I'm getting increasingly nasty about blocking unidentified robots. When I block website access, I don't use deny processing in Apache that would generate a 403 error or anything like that, I block 'em at the router, so they don't show up in my Apache logs at all.
I also block overactive robots, like msnbot. The only search engines that I much care about are Google and Yahoo!.
If you go to my router blocking page:
can see who I have blocked at the router from all protocols and ports (if I find any more Cyveillance blocks, that's where they'll be), who I have blocked at the router from email, and who I have blocked at the router from my websites.
I also do a lot of email blocking in postfix on the server, which allows senders to reach my role accounts and private email addresses but be blocked from my public email addresses. Blocking them at the router obviously blocks them from being able to send email to any of my email addresses at all.
For what it's worth, a searching at google pulls up a page that gives several address blocks, though it incorrectly uses a /24 (256 addresses) mask which makes it more difficult to see the true assignments. Five blocks are listed:
I'm not say>I don't normally use samspade, but using it I see that the netblock
Sam Spade is one of a number of "user friendly" tools to access core information from the Internet. When you query the RIR servers (AFRINIC, APNIC, ARIN, LACNIC, or RIPE), you are accessing the 'whois' database. But some entities like Savvis, or Layered Technologies run their own referral servers, so that when I query ARIN about 184.108.40.206, I get told:
Now, your windoze browsers may have an rwhois capability (though I would be a bit surprised if they did) and if so, running a query with an IP address of interest would give you the information in a form similar to the samspade output you posted.
The real problem is that the information on these referral whois (rwhois) servers is not absolutely standardized, and is not reported to a central database (such as the RIRs) in one easy-to-search location. This means that you can look up an IP address and find out who is involved, but you can't search for all addresses owned by $FOO. For that, you need to search diligently at archives like google.
The first four are clearly Cyveillance (the netblocks you have listed on the right). The second block is a new one for me, and is now preemptively blocked.
Samspade crapped out so I was running whois by hand on one of my Linux system. That last block is not Cyveillance at that base address. I tried stepping through /24 by /29s, but rwhois.layeredtech.com was giving me error messages on most (but not all) of my queries. I didn't find a Cyveillance netblock on any of the queries that I actually got information back on. I'm not going to worry about it at this point.
I did discover on the third block, which is the one I reported, that when I put in on my router blocks webpage and in the router itself, I managed to screw it up. Comparing my stuff to the list above showed me my error, which is now corrected.
There supposedly is another block in the 220.127.116.11/24 area that is used as their office/official network. The block is part of the
18.104.22.168/10 assigned to uu.net, but a few spot checks in that range doesn't turn up anything.
Sorry, I forgot you have Linux boxes available. Yeah, samspade, geektools and others often become unusable because of excess use. I avoid using them as much as practical for that reason. Use of whois is mainly limited by knowing which whois server to ask - or occasionally by language problems. There are also a few blocks who list a rwhois service, but either block all queries, or the server doesn't even exist. At least one provider seems to do this to block investigations of their pet spammers.
What error? A /24 in /29 steps is 32 queries, and they may block you for excessive use, which is why I normally use a separate dialin connection with lots of dynamic addresses for that kind of search.
At this point, I'd just be watching the logs for addresses in that range. Post if you see anything, PLEASE!
"Always re-read what you typed before hitting , especially as root."
I've also got a couple of cross check programs that look at mask sizes and address ranges. This is needed because one of my primary data sources is the RIR zone files, and these give mask sizes not in binary or slash values (meaning 255.255.248.0 or /21) but in the number of addresses that are in a given assignment (2048 in this case). There are about 64000 records of assignments, and about 61400 use one of 22 binary masks (from
255.0.0.0 down to 255.255.255.248), but another 2300 assignments use one of 179 different decimal block sizes from 36 to 9175040.
I don't remember the error exactly, something about "object does not exist", but I don't think it was excessive queries because when I retried one of the queries that had worked, I got the proper results again, not the error.
It wasn't any big deal. I put 22.214.171.124/29 in my private block tracking document instead of 126.96.36.199/29 and carried it over from there into the webpage and the iptables script.
That's one of the reasons I don't use the RIR files a whole lot. I use them only for router blocks, not for postfix blocks. I use the APNIC one the most, trying to avoid blocking AU and NZ at the router (except when deliberately blocking a specific ISP). I use the RIPE one occasionally for certain countries to see if I want to expand an ISP router block to a country router block. I block all of LACNIC at the router so I don't need the RIR file, just the allocation to LACNIC from the ARIN whois. I block ARIN space at the router just for specific ISPs so I don't need the RIR file for that.
To the picky people, yes, I know that 188.8.131.52/8 plus 184.108.40.206/8 is
220.127.116.11/7 and that's the way I have it in my router rules. I have it split in my document to match the way it is on my webpage and I have it split on my webpage to help people trying to check if there is a block so that they can find a match on at least the first octet.
[compton ~]$ rwhois rwhois.layeredtech.com 18.104.22.168 %rwhois V-1.5:003eff:00 nictool.layeredtech.com (by Network Solutions, Inc. V-22.214.171.124) %error 230 No Objects Found [compton ~]$
That error means that the address isn't currently listed in the rwhois database - supposedly, that means the address isn't assigned to a customer. For what it's worth, I only found the first four /29s occupied. Scattered tries above 126.96.36.199 yield the same "No Objects Found".
Sounds familiar. Once a month, I run a sanity check on my databases looking for dumb things like a comma in place of a decimal in addresses - hate to say how often I see that pop up. Must be bad keyboards ;-)
Oz has a lot of blocks - 4571 from APNIC, 3 from ARIN. .nz only has 731, all from APNIC.
That's a good use for it. I grab the zone files monthly, and one of my tools does a 'diff' to see what may have changed.
Some people think LACNIC only has 200/7 - they are wrong. LACNIC is supposed to be allocating IPs to Mexico and the Caribbean South to the Antarctic, but ARIN still has a number of to 7 countries (AR, BB, DO, GD, JM, LC and MX) that will probably be transferred. There are still companies like IMPSAT (based in Miami, but all of the customers are in South America) whose registrations are also being transferred.
Yeah, I think you need to grab the latest zone file. The files I'm using are not quite two weeks old.
The only reason I suggest the larger block sizes is that it minimizes the number of rules - which reduces the cost in CPU cycles. Actually, ARIN and AFRINIC are also assigning out of 200/8 (200.16.8/21 is in South Africa to my surprise - and there are 15 blocks "assigned" or "allocated" to the US though most are probably for customers in Central/South America). There are some people who use 'shotgun' rules (blunderbuss would be a more appropriate description) to block "all of APNIC and LACNIC" using just eight rules (58/7, 60/7, 124/7, 126/8, 200/6, 210/7, 218/7, 220/6 - overlooking the many other blocks in 128/2 and 192/3 in the "Various Registries" category), or that 188.8.131.52 has allocations in .ar, .bs, .cl, and .nl (and used-to-was in .au).
I do compress the router rules. Not just 200/7; anytime I have adjacent rules, even if they are totally unrelated, that can be merged together, I do so (assuming I notice it).
I've yet to actually see any AfriNIC allocations even though they've been an official RIR for three weeks. I expect to treat them like LACNIC.
I do that with LACNIC. Not with APNIC only because of AU and NZ. Where there are few enough AU and NZ blocks in a /8, I create exceptions, then block the /8. (Using an iptables user chain with RETURN for the exceptions ahead of the REJECT for the /8.)
I know there are some U.S. companies with IP address allocations from APNIC. I do *not* make any holes for those blocks and won't unless specifically requested.
This is my router and server for my personal websites and personal email, so I can be as much of a hard-ass as I want! If I were ever to put up a commercial website that could involve email as part of the business, I'd definitely have to make some changes.
That's reasonable. In the block 184.108.40.206 to 220.127.116.11, there are
58 different assignments. But if you are all huffy about CN, the 58 become one (61.128/10). There are a number of others like that, but the RIRs don't often make it that easy - assigning addresses in quite a random order.
[compton ~]$ wc -l IP.ADDR/stats/AFRINIC 446 [compton ~]$ cut -d' ' -f1 < IP.ADDR/stats/AFRINIC | sort -u | column AO CI EG GH LY MR NA SN TZ ZW BF CM ER GM MA MU NE SZ UG BJ DJ ET KE MG MW NG TG ZA BW DZ GA LS ML MZ SD TN ZM [compton ~]$ cut -d' ' -f2 < IP.ADDR/stats/AFRINIC | cut -d'.' -f1 | sort -n | uniq -c | column 19 62 3 137 8 160 3 193 1 205 1 64 1 139 9 163 3 194 1 206 2 66 2 143 3 164 3 195 2 209 2 69 6 146 7 165 229 196 13 212 12 80 1 147 1 166 1 198 18 213 9 81 7 152 11 168 1 200 1 216 5 82 10 155 2 169 1 202 13 217 2 84 1 156 28 192 4 204 [compton ~]$
I haven't seen that many _new_ assignments. With few exceptions, these were just transfers from RIPE and ARIN, just as LACNIC was created by transfers out of ARIN. They are still learning - for at least two weeks, they had
10.0.0.100 - 10.0.0.255 allocated to Angola. I'm not sure what the official start date was - their zone files go back to March 3, plus two possible test zone files in February.
Excellent strategy. My home setup has a few 'ALLOW' rules, and everything else hits the default 'REJECT'. I'm not the firewall guy at work, but I believe they're running something similar for the interior firewall - I've no idea what the border firewall rules are, as I don't have access to it.
[compton ~]$ grep US IP.ADDR/stats/APNIC US 18.104.22.168 255.255.192.0 allocated US 22.214.171.124 255.255.0.0 allocated US 126.96.36.199 255.255.0.0 allocated US 188.8.131.52 255.255.255.0 allocated US 184.108.40.206 255.255.240.0 allocated US 220.127.116.11 255.255.248.0 assigned [compton ~]$ grep -E '(AS|GU|MN)' IP.ADDR/stats/APNIC | cut -d' ' -f1 | sort | uniq -c | column 1 AS 8 GU 9 MN [compton ~]$
I vaguely recall looking at those - at least one is a screwup (150.197/16 is actually a Korean government research outfit), and one I'm not sure of (163.60/16 looks like a US branch of a Japanese company). The others don't look to be that useful.
"My network - my rules" See the relatively common statement to people posting in news.admin.net-abuse.blocklisting crying about being listed on the various block lists. I happen to agree with this philosophy.
Not knowing what rules you have in place, I can't say. But this concept is discussed frequently, both here in comp.security.firewalls and elsewhere with only a small amount of flames.
I don't post much in NANABl, but I do read there. I do more posting in NANAE. I'm very much a proponent of my network/server, my rules. In this case, though, there are a couple of additional points ...
I'm the only user, so there are no users whose legitimate email I might block.
It's not commercial, so there is no chance of me inadvertantly blocking a current customer or potential customer.