wanted: cyveillance IP address blocks

I just discovered these pricks malevolantly scanning my website.

I'm looking for a list of all known IP blocks this evilbot uses to scan with so I can make sure I have them all blocked.

And before any smartasses pipe up, there is nothing illegal on my site. I just don't want these guys crawling my whole website every day. They've become my #1 bandwidth user.

Brian

Reply to
Skywise
Loading thread data ...

The only netblock I've seen them out of is: 63.148.99.224/27 Qwest Communications [Cyveillance]

I've blocked them from all protocols and ports, not just my website.

Reply to
Ken

I have 38.118.42.32/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 63.148.99.224/27.

On what basis do you think 38.118.42.35 is Cyveillance? If it is them, I'm going to move it to "all protocols and ports" blocking.

Reply to
Ken

Ken wrote in news: snipped-for-privacy@4ax.com:

That's the one I've been seeing in google searches. However, they've been hitting me with 38.118.42.35.

So that's at least two netblocks and I suspect there may be others, hence my question.

Brian

Reply to
Skywise

Ken wrote in news: snipped-for-privacy@4ax.com:

Using samspade.org I got....

38.118.42.35 = [ ] network: ID: NET-26762A201D network: Network-Name: NET-26762A201D network: IP-Network: 38.118.42.32/29 network: Org-Name: CYVEILLANCE network: Street-Address: 1555 WILSON BLVD Suite 404 network: City: Arlington network: State: VA network: Postal-Code: 22209 network: Country-Code: US network: Tech-Contact: ZC108-ARIN network: Updated: 2004-11-11 10: 08: 47 network: Updated-By: dmcintosh

Brian

Reply to
Skywise

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.

Reply to
Ken

They popped up with another new one just today:

38.118.25.60 = [ ] network: ID: NET-267619381D network: Network-Name: NET-267619381D network: IP-Network: 38.118.25.56/29 network: Org-Name: CYVEILLANCE network: Street-Address: 1555 WILSON BLVD Suite 404 network: City: Arlington network: State: VA network: Postal-Code: 22209 network: Country-Code: US network: Tech-Contact: ZC108-ARIN network: Updated: 2004-12-28 17: 44: 46 network: Updated-By: dbruns
Reply to
Ken

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:

formatting link
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.

Reply to
Ken

Ken wrote in news: snipped-for-privacy@4ax.com:

Thanks for the new info.

As of right now I've only blocked the one specifc IP from my website. I want to see if they start using others to scan with.

BTW, I'm not a netadmin or anything. Just some joe who likes to read his web hosting stats.

Brian

Reply to
Skywise

That's just a rwhois output.

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:

------------------------

63.148.99.0/24 (actually 63.148.99.224/27) 65.118.41.0/24 (actually 65.118.41.192/27) 38.118.25.0/24 (actually 38.118.25.56/29) 38.118.42.0/24 (actually 38.118.42.32/29) 216.32.64.0/24 (Savvis - swiped to Layered Technologies)

------------------------

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 216.32.64.0, I get told:

[whois.arin.net] Savvis SAVVIS (NET-216-32-0-0-1) 216.32.0.0 - 216.35.255.255 Layered Technologies, Inc. NET-216-32-64-0 (NET-216-32-64-0-1) 216.32.64.0 - 216.32.95.255

which says that Savvis owns the block, and it's been swiped to Layered Technologies. When I query ARIN about those terms in parentheses, I find more data:

ReferralServer: rwhois://rwhois.exodus.net:4321/ NetRange: 216.32.0.0 - 216.35.255.255 CIDR: 216.32.0.0/14 NetName: SAVVIS NetHandle: NET-216-32-0-0-1 Parent: NET-216-0-0-0-0 NetType: Direct Allocation

and

ReferralServer: rwhois://rwhois.layeredtech.com:4321 NetRange: 216.32.64.0 - 216.32.95.255 CIDR: 216.32.64.0/19 NetName: NET-216-32-64-0 NetHandle: NET-216-32-64-0-1 Parent: NET-216-32-0-0-1 NetType: Reallocated

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.

Yeah, we have a few blocks in that category. ;-)

Old guy

Reply to
Moe Trin

The complete block for Cyveillance is

63.148.99.224--63.148.99.255 Found this with GeekTools Whois 5.4.1 at
formatting link
I gives the best Whois lookup I have seen. Casey
Reply to
Casey

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.

Reply to
Ken

There supposedly is another block in the 63.100.163.0/24 area that is used as their office/official network. The block is part of the

63.64.0.0/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.

Old guy

Reply to
Moe Trin

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.

I will.

It wasn't any big deal. I put 38.118.25.48/29 in my private block tracking document instead of 38.118.25.56/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.

Reply to
Ken

Here's what I have for LACNIC in my blocklist document. The top three are still in postfix and should be moved to the router. I know there is more than this.

24.152.0.0/17 LACNIC 24.232.0.0/16 LACNIC 209.94.192.0/19 LACNIC 66.60.0.0/18 LACNIC 148.201.0.0/16 LACNIC 148.202.0.0/15 LACNIC 148.204.0.0/14 LACNIC 148.208.0.0/12 LACNIC 148.224.0.0/12 LACNIC 148.240.0.0/13 LACNIC 148.248.0.0/15 LACNIC 148.250.0.0/16 LACNIC 152.74.0.0/16 LACNIC 163.10.0.0/16 LACNIC 163.178.0.0/16 LACNIC 164.77.0.0/16 LACNIC 166.114.0.0/16 LACNIC 168.226.0.0/16 LACNIC 168.243.0.0/16 LACNIC 196.1.112.0/24 LACNIC 200.0.0.0/8 LACNIC 201.0.0.0/8 LACNIC 209.13.0.0/16 LACNIC

To the picky people, yes, I know that 200.0.0.0/8 plus 201.0.0.0/8 is

200.0.0.0/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.
Reply to
Ken

[compton ~]$ rwhois rwhois.layeredtech.com 216.32.64.34 %rwhois V-1.5:003eff:00 nictool.layeredtech.com (by Network Solutions, Inc. V-1.5.7.3) %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 216.32.64.32 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.

[compton ~]$ cut -d' ' -f2 < IP.ADDR/stats/LACNIC | cut -d'.' -f1 | sort -un | column 24 132 146 155 161 166 192 201 209 64 139 147 156 162 167 196 204 216 66 140 148 157 163 168 198 205 129 143 150 158 164 169 199 206 131 144 152 159 165 170 200 207 [compton ~]$ grep ' 24\\.' IP.ADDR/stats/LACNIC CL 24.152.0.0 255.255.128.0 allocated AR 24.232.0.0 255.255.0.0 allocated [compton ~]$

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.

Old guy

Reply to
Moe Trin

[slip list of 23 blocks] [compton ~]$ cut -d' ' -f2 < IP.ADDR/stats/LACNIC | cut -d'.' -f1 | sort -n | uniq -c |column 2 24 2 144 4 158 11 168 11 204 1 64 4 146 2 159 1 169 1 205 3 66 1 147 9 161 8 170 4 206 1 129 9 148 1 162 100 192 2 207 1 131 8 150 4 163 17 196 4 209 3 132 4 152 6 164 19 198 6 216 1 139 1 155 3 165 3 199 2 140 1 156 3 166 1148 200 4 143 4 157 4 167 49 201 [compton ~]$

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 24.0.0.0 has allocations in .ar, .bs, .cl, and .nl (and used-to-was in .au).

Old guy

Reply to
Moe Trin

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.

Reply to
Ken

That's reasonable. In the block 61.128.0.0 to 61.191.255.255, 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 60.254.128.0 255.255.192.0 allocated US 150.197.0.0 255.255.0.0 allocated US 163.60.0.0 255.255.0.0 allocated US 192.103.43.0 255.255.255.0 allocated US 202.72.96.0 255.255.240.0 allocated US 202.76.240.0 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.

Old guy

Reply to
Moe Trin

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 ...

  1. I'm the only user, so there are no users whose legitimate email I might block.
  2. It's not commercial, so there is no chance of me inadvertantly blocking a current customer or potential customer.
Reply to
Ken

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.