P.S.: Don't forget to subscribe to this thread. :cool:

Those extensions are not working for me C:\Documents and Settings\YOUR_NAME\.limewire
Alternate location: C:\Documents and Settings\YOUR_NAME\Application Data\Limewire kind of strange. I would really like to have that black list stated here to be safe too.

Did you find the location? You need to turn on option to show Hidden files & folders before you do the computer search. :) http://www.gnutellaforums.com/window...tml#post183932

?
 

well actually I am using an XP windows version and I do have the hidden folders thing switched on. Still wat is a contabanned dude?:D

I was unable to find the settings folder either as described above, but I have Vista so the layout is different there. I was able to find the following, which I think is what you want, at least it seems to work for me. Try putting the hostiles file in /<username>/AppData/Roaming/Limewire. Since I never set my user name, my account is Owner.

I haven't used XP, so I don't know whether this will work there.

Two possible locations for preferences folder in Windows XP:

1. C:\Documents and Settings\your username\Application Data\limewire

2. C:\Documents And Settings\your username\.limewire

Note the dot in front of limewire in the 2nd location. ;) The 2nd location is the old location that was used with older versions of LW. Might still be there if you started using LW some years ago.

P.S.: Don't forget to subscribe to this thread. :cool:

Thanks, Aaron, but I'm having some trouble downloading it. The first link gives me a time-out error (Problem loading page), and at the second link I am able to download a zip file, but it contains an empty folder (zero KB) with no hostiles.txt in it.

Has the file been moved? Thank you.

Both links worked fine for me & contents identical. Which browser are you using?

Try these links (you need to click the Request Download Ticket, then Download links & ignore adverts below): Hostiles.zip or Hostiles.sitx.

But you still need Aaron's response to your main question. :)

Just a note:

1. This Hostiles list has not been updated since June 2011.
2. This Hostiles format does not seem to be compatible with the LimeWire 5 versions. (Perhaps because LW 5 had its own optional built-in list.) I am guessing because LW 5 dropped this less memory efficient technique option of representing host addresses. LimeWire 4 appears not to use it either and refuses to even connect.

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:

-> Attachment 5939 <- (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.):
Attachment 6387

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):
Attachment 6189


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. :o (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.
Attachment 6409

How to add an ip block list to Kaspersky Firewall.
Attachment 5983
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? :D 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.

There's lots of Taiwan hosts that spam or ping, but their numbers seem wide and varied. I do not know if there are centres set up there to spam or if these are proxies. Taiwan hosts are also guilty of DDoS attacks.

Quebec addresses also seem prolific for spam.

Japan has a healthy gnutella community, but it also has a large share of hosts set to either spam, research people's shares robotically, or try to fill up all your upload slots for days on end. Usually choosing your largest files or largest collections of files to download. It seems 99% of Japan's overall ip addresses below the 200.?.?.? range are static.

At least from my locale, Japan seems to represent 35-50+% of all spam. 80+% of robotic browses, and 80+% of attempted upload slot containment attempts. But I am sure people from USA and Europe get different results.

I'll leave the post at this point without commenting about USA, Europe (France and Germany in particular) and the proxy ip addresses used from world-wide for spam purposes.

BTW the previous post was more than a week after I had tried an experiment with banning over 80% of Japan. Yes spam definitely dropped considerably. Who knows, maybe this triggered an onslaught against me. Or perhaps MediaDefender and related companies have stepped up the tempo and ferocity of their war.

wow!

For any LimeWire users who wished to block out Japan and Taiwan hosts, see http://www.gnutellaforums.com/limewi...tml#post369081
Some other clients such as Phex and GTK-Gnutella could also use this list with the notation it uses. However, I do not think BearShare 5 was set up to use that kind of ip address notation format. I do not understand the older notation BearShare used, but I could investigate to try to learn how it works.

BearShare use the Hostiles.txt to handle ip adresses which it should not connect to and block them out from the search results, thats the only way for BearShare to use a block list like that...

New Fullsize Hostiles List for BearShare
 

I have updated the Fullsize Hostiles block list file after figuring out how to do it. :D

This list not only adds new listings of spam networks and known spam addresses, but also adds Japan and Taiwan to the list. In effect, because some of the ranges removed many thousands of previous individual listings, the overall size of the block list is now 10% smaller than the previous block list last updated over a year ago. This should make it a little faster to load when opening BearShare and use a fraction less RAM memory.

The size of this list is about 54,000 less listings and about 2 MB smaller than the previous hostiles list file. However, no previous hosts have been removed from the list, they are still within the ban ranges for better or worse. I did not think I was the appropriate person to choose what to remove.

If you wish to download Japanese related material, then choose the BearShare - Hostiles Blocklist 2012-NoJapBlocks.zip version.

The reasons for the addition of Taiwan and Japan are (1) their large numbers with spamming and other kinds of anti-file-sharing activities, such as deliberate upload slot containment and robotic browsing, and heavily pinging users. (2) to assist people's searches to return more culturally similar results. This is also assisted when you are not connected directly to several such hosts.

The list may be updated on the fly without notice. And is likely to be updated at least monthly or bi-monthly. (Edit: hostiles is updated approximately every 2 months.)

The links? Oh the links:

Download the Fullsize Hostiles List 2013 via MediaFire . or via SaberCat

or

Download the Fullsize Hostiles List 2013 via 4Shared (need to be a 4Shared member to use their downloads) and the no Jap Block version via 4Shared.

If you would prefer an installer for the Fullsize Blocklist, then see either the Hotfile or filecloud links.

Edit February 2013: a single installer is now inclusive of both options and for either standard BearShare or the BearShare 5.1 Beta Test version. (Also removed uninstall data from all installers. I previously had no idea this had been included by default without anything in the code to say it had been.) Edit March: fixed a small silly error I made with the installer. Apologies if it affected anyone who downloaded the February installer as one choice would not install an appropriate file. :o

The hostiles files have been put together in same folder as other BearShare material to download from (with exception of the 4Shared links.) This makes it easier to update the files without changing the forum's download links.

Windows 8 users will either need to use the installer or else, change the permissions of the BearShare program folder and reboot computer so you have permission to replace items in the db folder.



BTW as a note, if you read the first page of this thread, someone was put on the hostiles list for simply having 2 files in their shares which coincidentally matched the same size as a common spam file of that time. This suggests there are probably other listings of similar nature. I noticed that person's address was not removed from the hostiles list and in fact the entire sub-range and next one to it are banned. I presume there was a valid reason for this such as multiple findings in each of those small sub-ranges. The average true spammer has a lot more than two spam files in their shares, if you have ever browsed one you will know what I mean. Mind you, those posts on the first page were from over 5 years ago. But I doubt a hash check of the files was done at the time to verify they were spam files.

(The asian blocklist is not intended to be any kind of insult to the asian community. This block incorporation is due to sensible file-sharing. And due to forum members noting their frustrations to only or mostly connecting to asian hosts. As a personal note, personally, I studied 3 asian languages at university, and unofficially other asian languages and many dialects including Japanese dialects. I have a high appreciation of Japanese culture. I have spent months at a time traveling asia. Not to mention our work and friendships alongside. And several years sharing accommodation locally. ie: the blocklist is due to 'underhand' RIAA, and similar sponsored group pressure. Don't we love Sony's music and video/film company interests ... cough coff!!! They destroyed our local music industry, that's enough for me! They walked in bought up all the local music companies, sacked so many successful local bands, then americanised the local music industry all so commercially .. yew! pewk! Australia's music has no independent styles now, .. it simply copies what the usa music companies want them to. pfft .. I'm more than happy to protect my ears from that crap lol .. sorry, as usual starting to ... but anyway, americanisation of music means variant styles and independency and originality of musical ideas vaporise. And people once asked, whatever happened to the great designers of new ideas and products and concepts that came from our country throughout our entire history that we were secretly famous for, why not now?)

I was just looking at my firewall ip pings. Realised one specific ip I had put there has over 5,000 pings. I cannot remember why I put it there lol. I'm guessing it was a finding I forgot to report here (luckily it's a static address as are all in that range.) This ip is not in the Hostiles list, but will be in the next updated version. This amount of pings is about the fifth most I'm getting but the others are ip ranges. Most is the infamous 70.38. range with 31,000. Taiwan and Japan next with over 7,000 in specific ranges each.

For LimeWire 5 users, I will put out an experimental shortened version of the Hostiles list if anybody is interested. I will also supply a converted version of the full hostiles list if you are brave enough to try it lol. Maybe in another week or so. I do not know how effective the shortened version will be as it will lack most individual addresses and concentrate on the larger ranges and the most important of the small ranges that 'I am aware of'.

Edit: 17 hours later and the specific ip mentioned earlier has pinged me 26,000 times, now the 2nd largest pinger. 70.73. with 152,000. But then I have not been doing network searches which keeps some of the other ranges more quiet.

hi can i downdown on

See bottom of the first post on page 1. :)

There's an updated version released recently. The previous version had not been updated in 15 months.
The TechNutopia Fullsize Hostiles List for BearShare and LimeWire, page 1

Alternatively, I'll repeat two of the download links:

Download the Fullsize Hostiles List 2013 via MediaFire

via SaberCat

You have choice between an installer or just the hostiles file and instructions on where to place it. These files are in same folder as the Connection Fix installers at each of those sites.

Whilst an ultrapeer and all guards down, I actually connected to both of these. All sorts of clients using same/similar ip's just different ports:

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:40695
WinMX Music
199.127.253.17:36696
GTK-Gnutella

199.127.253.89:38982
WinMX Music
199.127.253.89:36865
morph500
199.127.253.89:46032
WinMX Music

On another note, I have finally finished a shortened version of the Hostiles for LW 5. Two versions, I am referring to one as Light Security, and the other as Medium Security. They both have the main hosts listed. The Light one also lightens up on Japan a little, closer to the original full Hostiles blocks of Japan. Both seem to run fine with LPE in testing so far without any lag or other issues detected during long sessions. I will first package the LW and FW installers with installers for such lists, then post links to 'add them yourself' versions here.

On a sadder note. I tried the BearShare Full Hostiles out with 3 versions of LW 4 and neither LW was able to connect and only whilst the hostiles file was within the folder. Not even the simplest of hints of trying to connect. Makes me wonder if it were really a myth the full-hostiles was compatible with LW 4. Unless the problem is related to my set-up, which is a possibility. Regardless, the newer LW blocklist versions will hopefully suffice for LW 4 users. For LW 4, I thus have 3 versions: light, medium and strong security.

I've provided alternative Full-Hostiles versions. 1. Hostiles with full Japanese Block: BearShare - Hostiles Blocklist 2012 . . 2. Hostiles with just standard Japanese fien spam client Block: BearShare - Hostiles Blocklist 2012-NoJapBlocks

Sorry if it sounds confusing. No longer separate installer for the Beta and regular BearShare (finally figured out how lol), just separate installer for either of the (1) or (2) options above. Or alternatively the Hostiles.txt file as a zip if you prefer to place the file yourself: 1. Hostiles_2012 or 2. Hostiles_2012_NoJapBlocks (which means just standard Japanese fien client blocks.) Sorry for the silly name but needed something to distinguish them.

The Full-Japanese Block is not a true 100% Japanese block, it blocks about 85-90% of their ip ranges. The non-Japanese blocklist is a much larger file as you might imagine because it includes many of their individual and small range blocks.

Fresh hosts added. I will not be updating these files as often as I have been over past couple of months which was every 1-2 weeks. I've been working on LimeWire blocklists and now there's simply too many lists to maintain.

The reason for the Japanese block: Several people contacted me in regards to (a) reducing the options for connecting mostly only to Japanese hosts, (b) Finding material through hosts that are more regionally or more culturally-similar to share with. (c) reducing Japanese spam.

The reason for the non-Japanese block: I feel there should be a choice for users.
Over the years I have personally downloaded a lot of Japanese music and video and shared material back. It's only been the past 18 + months that the Japanese anti-file-sharing companies have become somewhat over-bearing and very high in numbers.
There is a large 'genuine' file-sharing community in Japan. It is not their fault both the Japanese government and business is sponsoring anti-file-sharing companies to cause problems on the Gnutella network. The Japanese file-sharing community should not be left out in the cold for that reason alone.

Edit: as of two days ago: Edit February 2013: a single installer is now inclusive of both options and for either standard BearShare or the BearShare 5.1 Beta Test version.

Edit 13 March 2013: added a small Japanese range that was in the LW equivalent list but missing in BSHostiles list. Will now work the files on XP instead of Win 7 after finding processing errors, which did not affect using the file however. The blank lines only showed on XP. On 2000 simply a marker. And Win 7 did not show any issue.
If there is an error in the hostiles, BearShare will do either of the following as soon as it opens: 1. Delete almost all (over 99%) of the contents of the file. 2. Remove all contents after a point somewhere near the error. 3. Will ignore the host listings which have errors.

If anybody is interested ...

I think I might have discovered a new network set-up to spam and DDoS based in France. All the host addresses are within two small adjoining sub-ranges of each other. I have not seen any of these host addresses on any other blocklist. Something to keep in mind is some hosts do not attack the client program directly, but once they know your address they will periodically DDoS you. The affect of this a is drop in search results, possible loss of upload and download connections or loss in speed or consistency in either activity, and possible loss of connections with hosts, and at worst loss of internet connection. Those are their purposes. That is why I do strongly recommend blocking the worst of them via your firewall at least. And also to take the weight off your program taking all the hits when they are directed at it but not actually attempting to download or anything (ie: DDoS'ing your program client.) If anybody wants a list of the worst DDoS hosts then just ask.

Anyway update to the blocklist will be coming soon.

For LimeWire users, I have figured a way for both LW 4 and LW 5 versions to read a blocklist file in similar fashion to BearShare and FrostWire. Except these blocklists for LW use CIDR format which I was told start of year is more memory friendly than the older format BearShare uses. Also, the size of the Heavy/Strong Blocklist is 25% smaller than the original BearShare Blocklist and 10% smaller than the FrostWire blocklist. But is no less powerful. I will post a release on this in a few days time. Still doing last updates to the blocklist which is a very slow process when I have several lists to update. :eek: The LW blocklist version has been tested with 4.14 to 5.6.2. I have not yet tested earlier versions. Results have been seconded by a second person.
If you want me to test earlier versions of LW then bump the 'like' this post/thread and give your reason for testing earlier LW versions and it will be done. :D

DDos Attacks and Other Dodgy Stuff
 

Hi LOTR

You, like I, probably suspect that these attacks are sponsored by the RIAA and with tacit approval of of the US Government, even though what is being done to your computer is illegal in most western countries.

Plus, while you as an Australian citizen are likely to enjoy the protection of your government, and the sanctity of your laws, in the UK I would have no such protection if I continued to use P2P software.

Therefore, while you can continue to use P2P software, because you have broken no Australian law, while I, if accused by the US of doing something against one of their laws, the UK government would virtually say "come and get him, he is all yours".

Now, you could call me paranoid because there is nothing tangible I can point to in order to support my position. However, there is enough experiential observations to show that unless a poor unfortunate UK citizen has public support the maxim seems to be "What the US wants the US gets".

While you could go to the authorities and complain that your computer is under attack, if I was in your position I would be laughed out of the police station, i.e. if you are hacked or electronically attacked in the UK you can only report it to the police.

The way I see things going is that sooner or later the last bastion of individual freedom (Australia) will be sold out to the US, just like the UK has, and there will be concerted pressure to discourage the use of P2P apps, just as it now is in the UK.

So, because of the various things happening to discouraged P2P usage, e.g your ISP, various UK government backed campaigns, possible US sanctioned attacks, etc. I no longer use P2P software and the reason why I would not advise anyone else to use it either.



UK (Paranoid) Bob

Finally finished a LimeWire version: Security packages for LimeWire (help block out the spam and evil hosts). Intended for use with both LimeWire 4 and 5 versions. It works fine without memory issues for LW 5. I could have called the actual security file anything, including just security file. :D

In the March 13 update over half of the new listings are the port 27016 spam clients. So that will take 128 away from the chance to spam you. Others added were spam hosts, DDoS and BOT browsers (ie: 2 kinds; (a) browse you as soon as and every time you log onto the network, (b) browse you robotically every 10-15 minutes. One of these browsed me 5 times over 20 minutes. I was only sharing 500 files which is a fraction of my usual shares.)

Don't forget there is also an installer which caters for both BearShare 5.1 beta and other BearShares and choice of which hostiles to install.

If anybody wishes to volunteer their services for taking on the updating of the Hostiles, I would love to hear from you.
I do not know if there is another equivalent hosted elsewhere that is being updated. AW's old one had not been updated since June 2011 or earlier.

As it is, since the LW users do not seem that interested in their updates, I will probably be slowing down my updates for that package or stopping altogether since their 4 lists take considerable time to update. Not many download the updates. But their situation is different. They can ban hosts manually. Whereas BearShare has no other protection choice other than the Hostiles being loaded as it opens. So I do feel as though there is a demand for the BS Hostiles.

Received UDP OOB Hits Announcement for GUID: PSXHDKDY(edit) to proxy to Leaf in 7*.1**.*.*** ("BearShare Lite 5.2.0.1" WinXP 2904 msgs) from 188.142.66.5:27016, but the query is stopped. - I wonder what that means? Too much spam being transmitted by Mr. 188.142.66.5:27016 ? :D

I have not heard from the Phex dev for a very long time So I am making my own call here.

If you see any Phex version Phex 3.2.0.102 then boot it off your connection list. I have seen far too many of these over very recent past. Absolutely no reason for anybody to be using such an old Phex version below 3.4, so to see so many of them with identical version reminds me of these: Spam sample 1, . . Spam sample 2, . . Spam sample 3, . . Spam sample 4

Example of these Phex BOTs are listed in post #78 below, scroll down to 195.50.2.185. Another range they use is 192.155.80.0 - 192.155.95.255. When I blocked this in Phex, the block count increases by about 31 per minute.

Browse-BOT obvservation
 

Past two days (after I deciding to use the less stringent on Japanese hosts hostiles), found a handful of Japanese Browse-BOTs that browsed me as soon as I connected to the network (all within 5-10 seconds.) These ones browse repeatedly over a period of time. Here's an example of one today over a 70 minute period:
ID: 59.147.135.13:50652-Tokyo So-net Entertainment Corporation. <- (List, name & shame!)
You'll notice where I was attempted to be browsed up to 7 and 8 times over a minute. Even after banning the host. I am obviously not the only host this BOT is attempting to constantly browse. Also this is not the only browse-BOT. So if you can imagine several hundred of these browse-BOTs, it starts to become a semi-DDoS.

LW 4 usually shows each occasion a person is browsed. LW 5 / LPE do not. If the Browse listing is still up in the upload window, it will not repeat itself even if you have been browsed several times over a period of time. Only if you clear it from the Upload window will it re-list itself.

The example above was of a new BOT I found today. I checked my firewall log via console & realised the others I found yesterday had also been attempting to browse at a similar rate. Again, up to 8 times a particular minute. Over a period of time the others with slightly greater occurrences than the new BOT today.

Japan BOTs are notorious for deliberately causing heavy traffic. But from my experience, Taiwan BOT's seem to be designed purely for DDoS purposes. ie: not attempting to connect, browse, or download. Simply pinging the program (the firewall console verifies this, example: Allow LimeWire connecting from 1.*.*.*:51768 to port *****)

My answer for helping to prevent the actual program from being pinged into lagginess & eventual crashing is to block various known ip pingers in the firewall. Particularly the Taiwan DDoS BOTs. MS Windows 7 & higher, and some 3rd party firewalls have the ability to block ip's. MacOSX can only achieve it via using 3rd party apps. Personally I use WaterRoof which adds abilities to the OSX built-in firewall, but this app is slow & tedious to add ip's one by one, especially if there's a large list already there. This app should have ability to add a block of ip's at once like Windows firewall does. (1-2 mins between each addition when a large list already exists. Not a well thought out design.)

So you wonder, why is it these Japanese BOTs are browsing everyone & why once is not enough? And why certain BOTs from other parts of the world browse everyone as soon as they can after you first connect to the network?

Edit: Attachment 6515 connected to my Phex on 11 May 2014. I added this Washington address to the hostiles 16 March 2013, stated reason was DDoS @ LW & BearShare. I noted it again 19 April for same reason.

Some BOT samples
 

Just thought I'd give a few simple examples of BOTs on the network from a couple days ago:

Even for these examples, I'm not pretending this is all of them within those ranges, just the ones detected over a period of about 30 mins (which is how fast the console log pages were refreshing at the time.) But it does give an idea about how they spread themselves. Either using same address with different ports or even the same address & port. Or buying up lots of addresses for their mass purposes. I believe several of these listed above had multiple ports in use but for simplicity I removed the multiples of same ip address.
This example is simply a recent capture of them via the firewall console (with a few exceptions such as the 2007 version Phex ones from March - blood suckers.)

This snapshot is from 29 June 2016. It shows a mass of LW 4.14 Download-BOTs in the upload window of Phex. LW 4.14 was my favorite LW 4 version (and then 4.16). But there is some doubt these really are LW 4.14 or modified 4.14 versions. It's been known for about a decade that some BOTs can change program ID on the fly.

Some of the BOTs have same ip address but different port and some are downloading the exact same file. Amazon ip range; generally a professional proxy service to hide and protect the original business's source.
54.187.25.79
54.187.186.48
54.187.240.221
54.187.246.227
54.191.73.20
54.200.31.26
54.200.95.239
54.201.11.100

All Amazon.com ip ranges. Hostname .us-west-2.compute.amazonaws.com

Interestingly just 7 days earlier via a GWC I came across 54.201.11.100:4396 Gnucleus 2.0.9.0 (GnucDNA 1.1.1.4) which is most likely what all of these so-called LW 4.14's are actually using.
Same probably applies to the LW 4.12 Download-BOTs discussed elsewhere.

Download BOTs
 

I'm one of those rare people that keeps an eye on their uploads (& network as a whole.) Last night whilst using WireShare I was surprised to see my upload window full before noticing the pseudo-name SmilingPig beside many of them and with different identifying addresses.

One alarm bell was that the host was identifying itself as LimeZilla/1.8 (if it really was LimeZilla), but this version is ancient. LimeZilla is up to using version 4 nowadays. Two of the uploads SmilingPig was downloading/queued to download were the same two files; thus 4 upload/queue slots for two files. Surprised it was not sapping the entire upload bandwidth made available to WireShare however.

ISP: NFOrce Entertainment B.V. Netherlands; Netname: Amsterdam_Residential_Television_and_Internet_Netw ork. Services: Network sharing device or proxy server.

IP addresses blocked:
212.92.108.24
212.92.108.34
212.92.108.44
212.92.108.84
212.92.108.224
212.92.111.192
212.92.112.81
212.92.112.101
212.92.112.181
212.92.114.178
212.92.115.67
212.92.117.65
212.92.117.155
212.92.119.143
212.92.121.97
212.92.123.116
212.92.124.91
212.92.124.211
212.92.124.221

Upload window: (WireShare's display of total upload bandwidth had not yet caught up at the moment of this snapshot)
Attachment 6912
After blocking several, more showed up:
Attachment 6913

Then another attack a day later with 16 fresh addresses within the same sub-ranges. It also browsed me.
212.92.104.85
212.92.105.147
212.92.108.54
212.92.109.34
212.92.115.77
212.92.115.107
212.92.116.246
212.92.117.75
212.92.118.94
212.92.120.208
212.92.120.218
212.92.121.167
212.92.122.136
212.92.122.206
212.92.123.65
212.92.123.75

If you look carefully among the two lists you will notice the same sub-ranges using the same last number. ;) Example: all those in the 212.92.115.* range use 7 as the last number, all those in the .108.* range using 4 as the last number, etc. Although the .123.* range shows a variance.

Edit 2018-04-29: Discovered this from a GWebCache:
212.92.122.146:50903 (u:23:18:29) 2018-01-04.
212.92.123.162:50903 (u:23:18:05) 2018-01-04.
Host using WireShare or identifies itself as WireShare. Not sure this WireShare host could be trusted.

On a positive note, one type of SpamBOT appears to have been either removed or greatly downsized in its use on the Gnutella network. This is probably due to the network population having shrunk considerably in size over this decade. But possibly also in small part due to my efforts back in 2014 (also thanks to Bigjx) to have WireShare armed with blocking such SpamBOTs at 3 levels, one of which includes using the hostiles security file thus rendering such SpamBOTs powerless on the greater population of the network. Normally whilst using Phex in ultrapeer mode there would be a SpamBOT attempting to connect once every 1 to 3 minutes. But over past two weeks have not seen any. Nor have I seen any appear on GWC’s. At least one type of GWC now blocks such SpamBOTs reducing their ability to find hosts to connect with. My last finding of these type of SpamBOTs was via using Gnucleus and only via finding them on the host file in July and prior to that via a GWC in May. Edit: Still getting block hits for a few previously active spambots, but not many.

Edit November: Well, the SpamBOTs are still around after all. Perhaps in smaller numbers.

There are still other types of active BOTs on the network. Browse and download BOTs for example. Some identify as standard programs, an example such as a BOT that identifies itself as LW 4.16 (fake as it lacks a minor version) that connects in leaf mode and found in various ip ranges. The Japanese Browse-BOT is a Cabos version that also only connects as a leaf. Neither of these give file-share data which suggests they are either firewalled or not wired to pass such information to the network.

Terrorist BOT
There’s also the Trend Micro black hat bot which is more of a generic BOT in that it not only attacks and menaces the Gnutella network but anything on the internet, including websites. It is a terrorist BOT. Trend Micro executives (and perhaps also the company's shareholders) should be jailed for operating this damaging BOT that attempts to steal information from any location of the computer. These BOTs can also have a contributing DDoS effect, rendering a website inaccessible.

As an example of BOT's still around the network, using Phex I've highlighted some in the following GiF images. The GiF shows the finding in the hosts connection window, then after blocking the blocked hits count after an hour or two, then a few hours later and again a day later. Notice the ShareAza with the same address as the Phex's. Also two Phex's connected via the same port. After I removed all these hosts, more Phex's of same address but different ports than shown here connected briefly until I blocked the address. Also shown is a BOT identifying itself as LW4.16.

Phex Connections window: Attachment 6914 . . Phex Security window: Attachment 6915

An example of BOTs still around the network in 2017. Running BearShare without the hostiles file resulted in a notable number of BOTs connecting. Although I did sew some of these (the 4.12 Pro's) together over about an hour due to them only connecting briefly. Also some of these were downloading from me. Every host shown is a BOT.

Attachment 6933

All those hosts are not what they appear to be, they give fake ID's.
Here's a couple of examples from several years ago: seen via Phex and seen via BearShare

The present version of BearShare Hostiles (Jan 2016) is somewhat out of date but will still do a good job of blocking out most BOTs. But unfortunately will also block out a heck of a lot of innocent hosts. Even my own dynamic address has changed to a different blocked range six or so occasions this year (no exaggeration.) I hope I'll be able to release an update over coming weeks or so.

New Hostiles installer options for BearShare users
 

Instead of spending a life-time to attempt to update the Hostiles from Jan 8, 2016, a smaller version (used by LimeWire and WireShare) has been converted from CIDR to the Netmask format used by BearShare.

Reasons:
1. The bulk of the original BearShare hostiles is out-of-date, with most of it having been added during the first decade of this century.

2. The internet landscape has changed dramatically over the past 10 years in most countries. New ISPs (internet service providers) have appeared, some larger ISPs have taken over multiple smaller ones. These ISPs have re-allocated many ip address ranges to other purposes such as from business or government to residential. A good example is a very large range that previously belonged to the UK government (pensions dept.) has been divided with UK gov using a half & the remainder split up and shared between residential use in UK, at least 3 European countries and Saudi Arabia. ie: ipv4 ranges have also been changed since last decade with some ranges now used by different countries. Other examples: 146.198.0.0/16, 146.200.0.0/16, 165.120.0.0/16 previously owned in USA now belong to two ISP’s in the UK. ISP's also lease or purchase ip ranges from other ISP's as they need.
How many people in the world still have the same ip address to the one they used ten years ago!

3. Last decade probably over 80% of the world's internet addressing system (ip addresses) were Static (never changed.) Whereas these days probably well over 75% of the world's ip addresses are now dynamic (change from anywhere between daily to every couple of years depending on ISP policy applied. In my experience, there's highly dynamic and sticky dynamic; the latter might be based on either 3 or 6 week, 3 or 6 month, one or more years turnaround time; there's also a variable/random dynamic policy used by an ISP in Australia, Austria, Norway & Singapore & probably several others ~ these ip addresses might change from after a day (or a few times a day) up to over 6 months & the ipv4 address lifespan duration changes each time.) I'm not aware of any country that does not now use dynamic addressing for a percentage of residential purposes and that includes every continent and country large or small.

4. Question marks exist over many of the additions to the hostiles file in the first place. Last decade it was the default for most gnutella programs to immediately share downloaded files. Some people (myself included) might not check all files they downloaded for weeks or even months. I greatly suspect many additions to the hostiles file were not BOTs but accidental sharers of bad files. Do hosts accidentally sharing bad files 10+ years ago still deserve to be blocked? I doubt the hosts were really periodically re-checked and removal of hosts made on any consistent note (if at all.) It would have been far too difficult to re-check over half a million blocks representing many, many millions of individual hosts. Some of the logic (post #1 of this thread topic on page 1) about updating virus/malware scanners, etc. was barely applicable for those using MacOSX, not to mention an odd logic in any case.

5. Some organisations involved in spamming, attempted interruption or investigating the network last decade have since stopped, either replaced with new ones or never replaced.

Edit 2018-04-29: I've personally found my own unique dynamic ip address within a range block on the hostiles more than a dozen occasions over the past 15 months and more than this over past 3 years despite removing the blocked range or part of it each time.

I've also noticed with the old hostiles at least a couple of BearShare hosts would not have been able to connect to other BearShare hosts if using the original hostiles file. There's probably been at least a handful of such false-positive ('cry wolf') hostile blocks directly affecting BearShare hosts. Nothing wrong with the ip ranges these BearShare hosts are/were using in recent times. If there's doubt, the blocks remain.

The newer hostiles is smaller but no less effective. The biggest plus is now you will be able to connect to more innocent hosts (faster connecting time) and find more files. The newer hostiles is sized around 29-30,000 hosts compared to the original hostiles of 2011 of over half a million or the 2016 version of 430,000. Regular BearShare users will find the program quite noticeably starts up much faster than previously as the hostiles is loaded (previously it could take 10 to 20 seconds depending on computer.) Whilst the full-Japanese hostiles version has been retained, it is definitely not recommended. Using this will definitely slow your connections to the gnutella network, and besides, you might also be losing out on finding files. They share both local & international content. ;)

There is also a Super-Light hostiles option. This file only contains hostiles found over the past 5 or so years & have still been active hostiles over the past year (around 1,800.) I made some effort to avoid adding hostile hosts that change their addresses frequently. The Super-Light hostiles is 6% the size of the new but larger hostiles and around 0.3% the size of the BearShare hostiles of previous years.

Although the BearShare hostiles update download links have been repeated a few times in this topic thread, I'll repeat them once more below:
via SaberCat
via MediaFire (ad-blocker advised)
via 4Shared (need to be a member of this site to download & be extremely careful of pop-up windows such as fake Flash plug-in updates not belonging to Adobe website, fake virus messages, priority download or false download buttons. The genuine button is usually next to the Share button. Then choose Free download. sighs! I'm reluctant to use 4Shared these days but the download links have been the same since early this decade.)

I periodically like to remind people about BOTs on the Gnutella network. I set-up Phex on a different OS to usual and recorded a few findings after 24 hours. Some of the same old BOTs still around and of course the port 27016 Spam-BOTs that show up with different addresses periodically. GTK-Gnutella has its own way of blocking BOTs. During the 2014-15 period I helped with the addition of ways to block three BOT types for WireShare. But for all other BOT variations and for all other LIME code based programs and including BearShare, the best way to block these hostile hosts is via using a hostiles security block list.

Below is a few listings of BOTs seen at moments over a day. The first picture, a connection listing is from two snapshots taken one hour apart. The Phex security block window shows some of the BOT block rules I set-up and how many times they had been blocked within a 24 hour (or less) period. I've also shown a pic of a connection listing of PyGnutella from Jan 2012 using the same port as the other PyGnutella's still use now. The reason for the range blocks is because each range belongs to a particular company and in many cases the BOTs are dispersed across the range.

(1) Attachment 6941 . (2) Attachment 6942 . (3) Attachment 6943

I want to apologise to those few persons who downloaded the BearShare Hostiles update over the past 48 hours. I forgot to test the files before deploying to the public. There was an error in two of the files that causes BearShare to delete the contents and replace it with a minimal outdated (2005) list with a file size of around 4 KB. This usually occurs within 5 to 10 seconds of the BearShare window showing up on screen during startup. :o

The installers have been updated to fix the problem (207.177.64.0/255.255.192.0 had a double //)
You can either re-download the hostiles updater or re-install and fix the error yourself (within the db folder of the BearShare program folder.) ;)
The super-light hostiles was unaffected.
The file sizes should be over 800 KB each or over 60 KB for the super-light hostiles. Definitely not 4 KB which is a clear sign of an error in the file.
There were also an extra two BOT addresses added in this fresh update compared to two days ago.