Feel free to put these host addresses on your ban lists. These are hosts set up to
DDoS various gnutella clients.
72.22.25.1 - 72.22.25.127
217.239.2.2
216.174.143.145
70.83.206.27
76.114.35.182
80.67.3.14
84.196.11.75
84.196.82.177
70.30.239.145
The first listing is obviously a network of
DDoS hosts. Hosts anywhere from
72.22.25.1 to
72.22.25.127 will DDoS your client 1-5 times per second each for hours and days on end. They will mostly do their deeds to those sharing lots of files. It might even be wise to ban the above hosts in your router's firewall settings if your router has that option. If you find your internet browsing is getting slow, you are probably being
DDoS'd by these hosts. Your firewall log should tell you if this is happening. Another effect of this DDoS is lack of search results by your gnutella client. The 216.174.143.145 or 216.174.143.0/24 range added up to 10099 pings which equated to about 600/hour or 10 pings/minute.
I discovered some clients like LimeWire 5 have an individual ID. So even force-changing ip address made no difference. And deleting the client ID in the settings file seems to make no difference, it may have been set internally upon installation. Though this might not be the reason for the quick rediscovery by the DDoS hosts.
For those using LimeWire 5/LPE who wanted to ban such hosts via LW itself, the first would be best banned by using this format: 72.22.25.0/25
which covers half of that sub-range. This is a memory efficient binary process of representing ip host addresses which the later LW 4 versions understood, but I am not sure BearShare understood. But this will not prevent such hosts from at least reaching your client program, so it's best to ban them either at firewall or router level so they are unable to intrude and affect traffic levels and as such your personal web-browsing. ie: stop them even getting passed your router or firewall, your router probably being the best option to prevent their actions and effects.
(Edit: adding more)
70.38.38.101 - 70.38.38.217 . . (5 hosts seen in this range heaps of pings, maybe spam)
70.38.54.15 - 70.38.54.244 . . (15 DDoS hosts seen within this range)
75.40.34.169 . . (major DDoS host)
174.131.182.240 . . (major DDoS host)
188.165.220.59 * . . (major DDoS host) - Uses LimeWire 5.1.2 ... not one host, a network of many using different ports. No doubt the
MediaDefender company.
188.165.230.147 * . . (major DDoS host)
199.127.249.19 - 199.127.249.247 . . (15 within this range) This and one below are heavy DDOS pingers from NY USA. Coincidentally same address ranges are already in the Full Hostiles list. Firewall is best so the ping hits will not affect LW's performance.
199.127.253.8 - 199.127.253.124 . . (11 within this range)
208.93.7.14 - 208.93.7.254 . . (7 hosts seen in this range, spam)
* I discovered via Phex these are not the only host addresses MediaDefender use within these sub-ranges ! Phex's block count for both 188.165.220.0/24 and 188.165.230.0/24 are continually increasing. The specific addresses listed above were already blocked via firewall, thus could not reach Phex. If you are using Phex, you can actually watch as those in the 188.165.220.0/24 and 188.165.230.0/24 are blocked out and starts to add up into dozens and eventually hundreds. That is if you have them blocked at the Phex level and not in the firewall or router already.
Just as a test, I white-listed
188.165.220.59 for a while and sure enough, their colors showed. Example of MediaDefender's clients below:
->
<-
(click to see image, click twice to open in its own window)
(all LW 5.1.2, all same ip address, simply different ports for each client. Remind you of
this?)
Edited again to add some more:
And some more listings
in order of ping frequency grouped into sub-ranges where applicable:
86.11.111.162
173.32.197.229
65.83.131.202
67.205.112.173
98.116.165.20
211.18.159.174
125.30.13.56
115.124.174.213
208.99.193.58
98.195.206.182
70.38.37.22 * (70.38.37.? is a sub-range also widely used, similar to previous 70.38.?.? listings above. Personal choice, but if you block 70.38.38.0/24 and 70.38.54.0/24 in your router-firewall the heavy hits do not affect the internet speed of other computers using the same router. Compared to if you only banned the range in your software firewall on one computer.)
64.6.132.197 and
64.6.132.200
1.171.212.33
98.228.15.122
50.23.112.2 - 50.23.112.25 . . (4 hosts)
69.171.166.13 - 69.171.166.206 . . (4 hosts)
69.171.171.39 - 69.171.172.190 . . (4 hosts)
69.171.163.54 - 69.171.163.152 . . (6 hosts)
66.212.143.105 - 66.212.143.116 . . (5 hosts)
66.212.143.105, 66.212.143.106, 66.212.143.107, 66.212.143.110, 66.212.143.116 - (Multiple hosts per host address, see Dec. 21, 2012 snapshot below)
66.249.5.139
80.6.254.38
58.96.85.205
74.171.214.5
122.135.45.6
207.6.231.91
50.58.238.131 - (this one is always consistently high with pings)
173.193.77.4 - 173.193.77.62 . . (3 hosts)
76.73.128.75
50.18.227.125
50.196.56.94 - Specifically a BeaShare DDoS host.
190.71.233.91 - Specifically a BeaShare DDoS host.
66.56.213.56 - Specifically a BeaShare DDoS host, but is a dynamic address.
66.142.89.210 - Specifically a BeaShare DDoS host, but is a dynamic address.
69.141.48.179 - Specifically a BeaShare DDoS host, but is a dynamic address.
68.98.199.166 - Specifically a BeaShare DDoS host, but is a dynamic address.
68.82.158.29 - Specifically a BeaShare DDoS host, but is a dynamic address.
24.9.10.51 - Specifically a BeaShare DDoS host, but is a dynamic address.
69.171.160.30 and
69.171.160.68 . . (2 hosts)
about equal, so arranged numerically:
24.242.233.252
38.101.222.251
65.199.18.0/24 - Various hosts. Known upload slot containers. Also on original hostiles list.
83.211.103.159
88.123.195.66
94.193.183.239
99.251.185.253
123.110.82.95
154.45.216.163
154.45.216.177
154.45.216.185
159.253.131.147
159.253.131.162
159.253.131.213
159.253.131.230
175.98.48.201
180.218.80.193
182.233.240.232
184.173.3.44 -
184.173.3.50 . . (2 hosts)
187.78.164.190
206.45.6.228
218.15.114.134
218.160.153.248
218.187.115.208
218.187.119.80
219.70.10.90
220.140.232.58
220.142.3.66 -
220.142.3.189 . . (2 hosts)
May 28, 20013: Using Phex, same upload-slot containers I'd had problems with 12 months earlier. As a test I opened 39 upload slots (Upload.MaxParallelUploads=39) with
only one slot per host. Guess what, 39 hosts of all different client program types and more than one of each downloading from me. Almost all had same ip address and port number. They download the largest audio files (in my case, FLAC), largest collection of file-topics, etc. Image is a snapshot of 29 of them put side by side for viewing purposes (this was not all of them.):
And the Phex connection file showed these addresses. (All belong to BMI (Broadcast Music, Inc. ))
66.212.143.104:7001
66.212.143.105:7001
66.212.143.106:7001
66.212.143.107:7001
66.212.143.110:7001
66.212.143.116:7001
Dec. 21, 2012: Here's a funny episode. Whilst using BearShare I accidentally replaced my BearShare hostiles with the original and ... these hosts, each time I removed them they were replaced with more of same ip address or similar, example 3 snaps joined here (all same port, all same shares):
Mid-September 2012 (all connected to me at once - my ip block was off for testing):
199.127.249.95:38790 - LimeSharePro/1.5.0
199.127.249.95:38229 - morph500
199.127.249.241:20433 - WinMX Music
199.127.253.17:36696 - Gtk-Gnutella
199.127.253.17:40695 - WinMX Music
199.127.253.89:36865 - morph500
199.127.253.89:38982 - WinMX Music
199.127.253.89:46032 - WinMX Music
China and Hong Kong seemed to have joined with Taiwan to become a major DDoS threat.
A quick example from my console log:
15/11/12 12:27:01 PM Firewall[133] Allow LimeWire connecting from 222.93.119.95:2435 (China)
15/11/12 12:31:43 PM Firewall[133] Allow LimeWire connecting from 203.198.79.125:7791 (Hong Kong)
Example of one of each from multitudes, and different addresses. But they did not connect, did not upload/download. Just pinging LW for the sake of it. If you wish China and Hong Kong blocks for your firewall I will attach below when I have finished the list. In some ways it would be a smaller list if they were combined with Taiwan and possibly Japan because their ip ranges are often adjoining. Many/most of the asian ip ranges are side by side each other.
I was watching BS's console and saw this: "Discarding questionable cache entry http://216.18.206.17:2108/gwc/cgi-bin/fc"
I suspect that was a gwc site I tested from an entry from a LW clone cache listing. Though I may have obtained it from another source. It falls within the Hostiles ranges.
Firewall blocks: Blocking hostile hosts in the firewall reduces lag and loss of performance of your file-sharing program! You will also get better search results and download and upload performance.
Port blocks: * Recommended to block ports 27016 and 7001 in your firewall. These ports are used by companies of spammers only. My firewall block count adds up considerably over time with the 27016 listing. Block these ports for
both TCP and UDP. I get about 10 times more blocks with UDP for this port (example over 6,000 blocks of compared to 600 odd of TCP of spam hosts over a period of a day.) Windows 7 and 8 firewall can be set to block specific incoming ports easily using the incoming rules for blocking. MacOSX firewall needs some tricks to block ports or specific hosts. I've come to the conclusion hosts with port 27016 use ip address proxy switchers. Whereas port 7001 hosts seem to be static ip addresses.
However, I do have several records of the port 27016 hosts keeping same address (23 April - 19 July 2013 for example, not bad considering it is officially a dynamic USA address, obviously sticky dynamic.) And another good example was 8 May, 29 June & 7 July seen with same Belgian address. And another good example early May to July static USA address. So I'm reviewing my decision to leave dynamic addresses and at some point (a couple months ago), all port 27016 ip addresses off the hostiles. It seems they do either re-use some addresses since they are still available for proxying or simply maintain their use. Other reason of course is different spam groups based in different countries use different approaches with their ip addressing. AFAIK, LW 5 or the later LW 5 versions and LPE have an in-built block for either port 27016 or the LW4.21.1(rc) hosts. Strange FrostWire did not follow suit because FW4 (& all the LW4 clones) has a severe problem with such spam hosts. Phex has a user option for port blocking. I added certain port blocks via the connection-fix for Phex which also has other off-topic benefits. BearShare totally relies on the Hostiles. Which is why I recommend firewall blocking to assist. Edit September 2013: I noticed from a 2009 BetterShare connection file a common spam port seemed to be 41000. Not sure that port is still being used. It does not show up on any of my gnutella program connection lists or spam log file. I think port 41000 can be ignored for now.
Sample image showing how to block port 27016 in Windows 7 Firewall for TCP. Same should be done for UDP also.
Windows 7 Port block sample image and
Sample 2. Specific details how to do it are
here. * Sorry, last year I gave incorrect instructions, this one is correct.
(Nobody told me.)
How to set up a port block rule when you are port forwarding your router? This applies for Windows 7 or later. Set up a rule based on port. For example, block port 27016. Then double click the rule after saving so the rule is open for editing. Choose Programs and Services tab. Then check option for 'This Program'. Browse to find the program, example BearShare. Save and click OK. Alternatively set up a custom rule with same settings as suggested: Select port and then program and block. The rule has now become a specific port block rule only applying to that specific program. Otherwise port forwarding the program may by-pass any specific port block rule. A separate rule should be done for each of both TCP and UDP. Wise to also block port 7001 in same fashion.
How to add an ip block list to Kaspersky Firewall. 
Firewall -> Settings -> Network Packets -> select 'Addresses from Group' and click Add -> click Add to add an ip address and continue doing this. After adding all the addresses, name the rule something like 'ip address block list' & click OK. Make sure that rule is still selected in the Network Packets section and select 'Block' at top and 'Any Network Activity' in the middle section. Though you can select the Block option after selecting addresses from group option near beginning of the process.
A Gnutella ip Group Block in Windows 7 and 8 Firewall
Windows 7 and 8's firewall have the option for doing a group block. I created one for TCP and UDP. In fact, you only need to do one then duplicate it and change the rule's protocol from TCP to UDP then rename it or a single group rule and set the protocol to All. Sounds easy?
Set up a new inbound rule, and set it to Custom. Choose either all programs or LimeWire/FrostWire/BearShare, etc. path, then all ports. Then start adding the host addresses you wish to add. Then when finished, name the rule. I have created a sample image but note, the sample GiF is a little large in size and has quite a few frames. The advantage of a group block is you could disable it if or when necessary, or simply set it to only apply for LimeWire/FrostWire/BearShare, etc. in the program/path option.
Windows 7 firewall ip Group block (sample image). And
Second sample (this sample only needs a single rule by using the 'Any' protocol and applied specifically to the program to be used for.) Blocking hostile hosts in the firewall reduces lag and loss of performance of your file-sharing program.
Outgoing rules?
Why set up outgoing rules to block certain ip ranges instead of only incoming rule blocks? Because if you are sharing files, your program sends your shared files details that correspond to a particular search. Do hostile clients search? Since some hostile clients are known to browse hosts, then chances are they also do searches.
Hosts with port - 7001 are known as upload-slot containers, they will download everything you have, they get paid to do this to prevent you sharing to anybody else. Having equivalent outgoing rules may help to slightly reduce some incoming traffic from bad hosts. Example:
deny ip from me to 50.58.238.131
. (resulting packets over 50 minutes = 1338 and after 270 mins = 7734; Starting up as a UP, after 50 mins = 2144) - (consistent climber of stats every minute or two 24 hrs/day)
deny ip from 50.58.238.131 to me
. (resulting packets over 50 minutes = 0 and after 270 mins = 3; Starting up as a UP, after 50 mins = 104)
(the outgoing rule listed first!)
The attachment below is the binary system used by LimeWire for ip address blocking and 'some' firewalls for banning ip addresses. ie: 256 possible addresses for each block/sub-range x.x.x.x thus, 2 to the power 32 = 2^32 = 256x256x256x256=4,294,967,296
In the Kaspersky Firewall example above, you will see I chose 72.22.25.0/25 which represents a range from 72.22.25.0 to 72.22.25.127 which is half a sub-range. Or 72.22.25.128/25 would be 72.22.25.128 to 72.22.25.255. 72.22.25.0/24 would have been a full sub-range from 72.22.25.0 to 72.22.25.255. Whereas /32 represents a single ip address, /31 = 2 sequential addresses, /30 = 4 sequential addresses, /29 represents 8 sequential ip addresses, etc., doubling with each step. I like to see the sub-ranges as A.B.C.D representing x.x.x.x for ease of reference.
Thus my text example attachment below-bottom. Nobody is pretending this is easy to learn, at first seems rather difficult. That's why I set up a reference list for myself so there would be less chance of errors.
. . . This also helps give some picture of how it works.