Second build sold out. Message will appear here when store is ready for third build ordering.

Call for IP address blacklist contributions

The next software release implements Rob's suggestion of a "download" button on the admin page network tab that populates the IP address blacklist text area from a file fetched from kiwisdr.com

Those of you that have curated extensive blacklists, that you'd like to see merged into that file, please post them here and I'll include them for the initial version. The file can be viewed manually at kiwisdr.com/ip_blacklist/ip_blacklist.cjson

«13

Comments

  • Just simple bash script for create ipset from this file on personal frp-server (for example):

    #!/bin/bash

    ipset -N kiwiblacknets nethash

    wget -q http://kiwisdr.com/ip_blacklist/ip_blacklist.cjson -O - | grep -o '".*"' | sed 's/"//g' | while read NET

    do

    ipset -A kiwiblacknets $NET

    done

    After run, - check it (ipset -L kiwiblacknets) and add drop rule to input iptables:

    iptables -I INPUT -m set --match-set kiwiblacknets src -j DROP

  • I'll revisit/refresh my lists as I was a bit to quick to block wide swathes of IP's rather than drill down and try and limit it them to the subnet associated with the company.

    Now if I could block any IP that comes back as under the control of Vultr.com I would.

    Someone seems to use a very wide range of addresses from them to get round blacklists. I've built /16 addresses around some of the connecting addresses, but as they can be Germany, US, Japan etc some legitimate connections would be unfairly blocked. Doesn't matter for me but would for a decent SDR site.

    Yesterday's IP's active on my blocklists (not the Vultr.com ones)

    45.145.67.74 - 376 times

    140.255.87.192 - 1104

    8.210.96.121 - 4

    139.198.178.150 - 106

  • Here is the blacklist I am using at KFS and KPH:


    1.160.0.0/16

    39.105.0.0/16

    46.165.245.1/24

    46.165.245.1/24

    47.240.0.0/14

    47.240.23.0/24

    47.74.181.109/32

    47.74.181.109/32

    47.88.219.24/24

    69.251.12.188/24

    94.190.209.0/24

    110.87.0.0/16

    110.87.122.99/32

    139.99.219.160/32

    139.99.219.160/32

    149.129.0.0/16

    149.129.81.68/32

    161.117.57.140/24

    185.220.101.1/24

    185.220.101.1/24

    185.237.99.234/32

    210.152.84.111/32

  • Some dupes in there and singles (/32) covered under wider ranges.

    I think a shorter version is

    1.160.0.0/16

    39.105.0.0/16

    46.165.245.1/24

    47.240.0.0/14

    47.74.181.109/32

    47.88.219.24/24

    69.251.12.188/24

    94.190.209.0/24

    110.87.0.0/16

    139.99.219.160/32

    149.129.0.0/16

    161.117.57.140/24

    185.220.101.1/24

    185.237.99.234/32

    210.152.84.111/32

  • The javascript that downloads the blacklist does consistency checks that can then be fed back into correcting and minimizing the list. This was essential to make merging of lists from multiple contributors less error prone than if done by hand.

    For example a blacklist containing 47.240.23.0/24, followed later on by 47.240.0.0/14, has the /24 removed. And 69.251.12.188/24 is AND'ed with its netmask to obtain 69.251.12.0/24. Also simple things like dups are removed.

  • Thanks John,

    I look forward to being freed of blacklist maintenance. My Kiwis are still running v1.461 from Aug 16th. Will there be a new build or a new version which includes your auto-blacklist feature?


    Rob

  • Yes, I'm trying to get v1.462 ready for release. Almost 5000 lines of changes/additions. So lots of checking and testing required. And we know my track record on that isn't so good 🙄

  • Goodness, when are you going to label a release V2.0 ;=)

  • jksjks
    edited August 2021

    An excellent question. I was saving v2.x for after there is a proper mobile interface implemented, user preferences and a few other major improvements that have been in the queue for years now..

  • edited September 2021

    I looked at Vultr Scans from 5th September to 11th (part day). Bear in mind my Kiwi is not publicly listed (or if it is that is an old listing) Many of these IP's were in the syslog "3 times" or "6 times" for one count here

    45.77.188.205    188 times

    149.28.98.168    12

    45.77.191.18     88

    209.250.251.56   884

    149.28.26.247    136

    45.63.68.182     86

    18.139.114.60    3982

    45.76.121.158    404

    18.167.85.70     7102

    149.28.148.234   69

    149.28.255.44    1283

    96.30.197.224    564

    198.13.61.137    909

    149.28.50.55     1

    45.77.185.7      1550

    216.128.140.72   1651

    45.32.229.90     964

    45.32.182.8      20

    45.32.152.178    24

    149.248.53.170   799

    45.63.115.181    516

    66.42.95.115     707

    108.61.87.5      31

    45.63.71.59      30

    45.76.241.86     40

    That is (mostly) just the scan mechanism, the actual connecting machines will be different (and fewer) but I have little interest in following that up.

    Some of these like 18.167.85.70 are probably not Vultr, that might be one of the actual servers that connect, can't remember the exact sequence, but once I spot the fingerprint of Vultr scan - hand off for access it gets (grumpy - manually) associated with this list. It is possible an odd IP got listed that is OK but as the SDR is not listed that would have to be "Old listing" + Similar range to scan bots.

    Also I'm not saying these are bad actors but they do have the feel of bots looking to tie up channels and scrap data and unless that is what your SDR is online for I'd reject the connection.

    This also does not cover my other "bad actors" list built up from actual connections that tied up the channels to timeout or acted like Mil HF sniffing bots.

    Stu


    --Edit--

    (2021-09-13) Today's Vultr addition 139.180.164.84

    Does seem like they have enough funds to use a lot of global VM's or IP's.

  • Bot from IP 39.105.90.102 is very active now, I recommend for all put his network to BlackList, how did @Powernumpty to do or full CIDR for this IP: 39.96.0.0/12

  • That 39.105.0.0/16 listing was from Rob, I was just trimming it down, I will change my local firewall to /12 tnx.

    For some reason I don't generally get hit by that IP or range. I might be targeting sites that have been public recently.

    Yesterday's Vultr addition 70.34.195.103

    I also see possible Bots on for 36 seconds, default frequency every time

    Sep 7 18:21:06 Dest Kiwi, Source "172.245.187.128" (LEAVING after 0:00:37)

    Sep 8 22:59:20 Dest Kiwi, Source "172.245.187.128" (LEAVING after 0:00:36)

    Sep 12 12:35:24 Dest Kiwi, Source "172.245.187.128" (LEAVING after 0:00:36)

    Sep 13 11:30:05 Dest Kiwi, Source "172.245.187.128" (LEAVING after 0:00:36)

    Sep 14 11:04:31 Dest Kiwi, Source "172.245.187.128" (LEAVING after 0:00:37)

  • jksjks
    edited September 2021

    Thanks Yuri. Click the "download" button on the admin network page to get a new blacklist that expands that ip range to from 39.105/16 to 39.96/12

  • edited September 2021

    Thanks for the blacklist feature John!

    How will we know when you have updated your master copy?

  • Added another ip belonging to vultr.com to my local list: "155.138.139.75"

     

  • Today's Vultr 173.199.70.39

    Followed up by 103.144.148.124

  • edited October 2021

    And also these added today (originating from vultr / constant) :

    173.199.70.0/23 70.34.192.0/19 207.246.104.0/23 137.220.52.0/22 216.128.128.0/18
    


  • edited October 2021

    Vultr very active with scanning my Kiwi the last couple of days and I added these as well:

    149.28.162.0/23 45.77.112.0/21 45.77.84.0/22 149.28.195.108 45.76.248.0/21 45.76.112.0/20 45.77.96.0/20

    This is like hydra, chop off one head and another one grows back right away...Shortly after adding one range to the ip block list the "vultures" are back via another server sometimes from a different part of the world.

  • edited October 2021

    That (perhaps) is just the scanner, I think we should record the IP that connects once the Vultr's have noticed an accessible radio. Simple scanners on new short term VM's are probably cheap but moving the main info gathering servers IP's might be more problematic.

    iptraf-ng is quite interesting to watch after Vultr finds us, I'm only using or two channels, not sure how badly it would affect multiple users so don't recommend for popular radios. I did just have my Kiwi go slow (I don't think it was running).

  • Good morning,

    I have a question about the blacklist.

    On my Kiwi, a few weeks ago I had an IP address 120.36.245.22 connected h / 24 on a single am frequency where there are no transmissions, after performing the Kick I noticed that 7 seconds maximum it reconnected, to which I decided to blacklist the address.

    The next day I find myself connected on the same frequency and in the same ways the IP 120.36.244.18, both belonging to the same domain [.broad.xm.fj.dynamic.163data.com.cn].

    The question is simple, what should I write in the admin blacklist box to block all 120.36.xxx.xxx addresses?

    I read something about the CIDR but I still have some doubts, it might be right 120.36.0.0/16 to block all 65.536 addresses of the 163data.com.cn domain.


    Thanks for the help

    Fabrys

  • edited December 2021

    Hi Fabrys,

    It is normally enough to add a mask after the IP, this covers a range of addresses. For example

    120.36.244.0/22

    Covers 120.36.244.1 - 120.36.247.254

    That would include the two you have seen and a good few more, I'd be more precise if they were local.

    Regards

    Stu


    -Edit-

    The proper way to do it is probably to find the range of addresses covered by the domain you want to block, then use that range, or ranges. That works if the details are readily available and you are concerned about blocking indiscriminately. I started out like that but after seeing IP's change every few days at most I realised some geographically specific ranges seem safe to just block without affecting genuine users.

  • jksjks
    edited December 2021

    I just added 34.0.0.0/8 and 35.0.0.0/8 to the list fetched by the "Download" button on the admin page, network tab. So just click that and don't worry about what to enter in the "IP address blacklist" field.

    UNLESS you've made a bunch of custom changes to the field you don't want overwritten by the download (in which case you should already know how to add the new entries manually).

  • Hi Stu ....

    thanks for the tip, I'll do some tests hoping to get rid of these annoying accesses.


    Greetings

    Fabrys

  • Being that this is a new scourge to me of recent times and that I'm particularly computer illiterate: is it possible to add a button in admin/status section (beside the 'kick' option) to 'add IP address to blacklist' or a combo of 'kick and add to blacklist'?

    Also, is there a master list that I can add to for consideration for the download list?

  • ...today so far I've blocked the pesky ones from the location "Piscataway, New Jersey":

    107.150.102.71/24

    107.150.103.171/24

    152.32.233.153/24

    128.14.230.15/24

    128.1.49.86/24 

  • Also, is there a master list that I can add to for consideration for the download list?

    The first post in this thread has a link to the current blacklist retrieved by clicking the "Download" button on the admin page, network tab.

  • Just now I have updated the download blacklist with all the suggestions from this thread and some other sources. So if you are using the downloaded list you might want to click the "Download" button again.

  • Kramcd, yes, those are the same addresses I have been seeing. The "Piscataway NJ" location comes from the application; the addresses themselves are all over the place.

    Has this sort of thing been going on for a long time? What are they trying to do?

  • I'm still not seeing any attacks on the new port number despite being listed in kiwisdr.com/public for several days. The attacks still persist on the old port number, however. Instead of using iptables to simply drop incoming packets, I'm sending them to the TCP discard service. Because the attacker's application level timeout is much longer than his TCP retry timer, this cuts down significantly on the actual number of unwanted packets/sec.

    I'm able to do this because my router is a general purpose Linux system. I don't know how you'd do it on a turnkey router.

  • Maybe there could be an option to allow an an automatic update of the IP blacklist when the Kiwi updates or reboots ?

    This would help protect admins who don't maintain their own entries.

This discussion has been closed.