Yes, after I posted I went and saw that you public Kiwi is not proxied and uses DDNS. So it's quite possible there is a problem. I agree that iptables should be doing the filtering in that case.
Not sure why my.kiwisdr.com is not registering both of your Kiwis. Here, my many test Kiwis all register simultaneously without problems. So it should work. Registration is maintained by public IP and serial number. So as long as the serial numbers are unique multiple Kiwis should work.
If you email your serial numbers to support@kiwisdr.com I can check the registration requests to the kiwisdr.com web server and perhaps see what's going wrong.
Okay, after reviewing the code it has reminded me of something. There is a feature that if a connection that has exceeded the 24hr connection time limit continues to try connecting (like a bot might) it will dynamically get added to the in-memory (not iptables/ipset) blacklist.
For this to work the in-memory blacklist must run all the time. Not just for proxied Kiwis. For non-proxied Kiwis there will be few entries in it because iptables is catching most of the blacklisted addresses.
Is it possible that the 195.128.246.85 address you show was not actually in iptables/ipset at the time those log messages occurred? Because the log messages might simply be a result of the 24hr auto-ban before you manually added the range to the blacklist.
Remember there is a new shell alias ips to check if a range is in the ipset table. Since individual ranges are no longer in the iptable itself.
v1.682 fixes the problem reported by @HB9TMC where ipset/iptables wasn't filtering properly (but the Kiwi server was as a backup).
But I also noticed something important. On the admin network tab, the "local blacklist" section where you can enter your own ip addresses and ip ranges: Be careful to not enter invalid or duplicate entries. Especially duplicates. Because processing of the local list will terminate at the point it finds a duplicate. It's a pain for me to detect this condition and report it back to the admin interface. I have much more important things I need to be working on. So this warning will have to suffice.
There are two problems here. 217.150.74.0/16 is deceptive because the /16 means the bottom 16-bits are considered the wildcard host address part and should really have been specified as 0.0 as in 217.150.0.0/16. That means the following 217.150.75.255/16 is also wrong and also considered as 217.150.0.0/16. Hence two identical entries in a row causing an error which prevents the 5.6.7.8/32 entry from being added to the blacklist!
So be careful when constructing your lists. Use a site like https://www.ipaddressguide.com/cidr to check your IP range for proper CIDR representation.
Wed Jun 5 05:02:42 1d:07:47:02.896 0123 1 L PWD new connection --------------------------------------------------------
Wed Jun 5 05:02:42 1d:07:47:02.903 0123 1 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 109.107.180.245
Wed Jun 5 05:02:52 1d:07:47:12.296 0123 1 API: decided connection is non-Kiwi app (served=0)
Wed Jun 5 05:02:52 1d:07:47:12.296 0123 1 API: ext_api_users=1 >? ext_api_ch=4 F(OKAY)
Wed Jun 5 05:02:52 1d:07:47:12.296 0123 1 L API: TRIG=F SND(T3) f_kHz=0.000 freq_trig=0 hasDelimiter=0 z=0
Wed Jun 5 05:02:59 1d:07:47:19.309 0123 1 L GEOLOC: 109.107.180.245 sent no geoloc info, we got "Russia" from geo host #0
Wed Jun 5 05:02:59 1d:07:47:19.314 0123 task geoloc_task:P2:T013((1000.000 msec) TaskSleep) exited by returning
Wed Jun 5 05:03:07 1d:07:47:27.295 0123 1 L "(no identity)" 109.107.180.245 Russia incomplete connection kicked
Sat Oct 26 10:25:54 12:32:19.364 01.. 1 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 124.205.145.240
Sat Oct 26 10:25:54 12:32:19.367 01.. 1 foff: foff_set_in_URL=0 foff_in_URL=0.00 freq.offset_kHz=0.00
Sat Oct 26 10:25:57 12:32:22.190 0... 1 L --- connection closed -----------------------------------------------------
Sat Oct 26 10:26:03 12:32:27.881 01.. 1 L --- new connection --------------------------------------------------------
Sat Oct 26 10:26:03 12:32:27.884 01.. 1 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 124.205.145.240
Sat Oct 26 10:26:03 12:32:27.887 01.. 1 foff: foff_set_in_URL=0 foff_in_URL=0.00 freq.offset_kHz=0.00
Sat Oct 26 10:26:06 12:32:30.706 0... 1 L --- connection closed -----------------------------------------------------
Sat Oct 26 10:26:40 12:33:04.744 01.. 1 L --- new connection --------------------------------------------------------
Sat Oct 26 10:26:40 12:33:04.749 01.. 1 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 103.135.104.143
Sat Oct 26 10:26:40 12:33:04.749 01.. 1 foff: foff_set_in_URL=0 foff_in_URL=0.00 freq.offset_kHz=0.00
Mon Nov 18 19:40:13 5d:00:26:32.827 01.3 0 L --- new connection --------------------------------------------------------
Mon Nov 18 19:40:13 5d:00:26:32.832 01.3 0 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 198.11.168.156
Mon Nov 18 19:40:13 5d:00:26:32.832 01.3 0 foff: foff_set_in_URL=0 foff_in_URL=0.00 freq.offset_kHz=0.00
Mon Nov 18 19:40:15 5d:00:26:35.160 .1.3 0 L --- connection closed -----------------------------------------------------
Mon Nov 18 19:40:38 5d:00:26:57.552 01.3 0 L --- new connection --------------------------------------------------------
Mon Nov 18 19:40:38 5d:00:26:57.557 01.3 0 L PWD kiwi SND ALLOWED: no user password set, so allow connection from 198.11.168.156
Mon Nov 18 19:40:38 5d:00:26:57.557 01.3 0 foff: foff_set_in_URL=0 foff_in_URL=0.00 freq.offset_kHz=0.00
Mon Nov 18 19:40:40 5d:00:26:59.875 .1.3 0 L --- connection closed -----------------------------------------------------
Something new, it set itself to a freq. that my SDR does not support
after a kick it returns and still no reaction.
for now I block the entire IP pool 92.72.0.0/13
there is another botnet with variable IP locations, listening to 11900kHz and searching for +/- 200kHz in IQ mode. it shows up cyclically for a few minutes and disappears
It's a member of the UDXF list logging ALE networks, which requires long periods of continuous monitoring to capture stations that may only sound once an hour.
I have given him passwords for my KiWi's so that he doesn't time out.
I couldn't resolve the domain however I think that might be my firewall (or pi-hole) - ill check the logs. I tried resolving logdb.utdx.de outside my network, and got the answer I needed :-)
Comments
Yes, after I posted I went and saw that you public Kiwi is not proxied and uses DDNS. So it's quite possible there is a problem. I agree that iptables should be doing the filtering in that case.
Not sure why my.kiwisdr.com is not registering both of your Kiwis. Here, my many test Kiwis all register simultaneously without problems. So it should work. Registration is maintained by public IP and serial number. So as long as the serial numbers are unique multiple Kiwis should work.
If you email your serial numbers to support@kiwisdr.com I can check the registration requests to the kiwisdr.com web server and perhaps see what's going wrong.
Okay, after reviewing the code it has reminded me of something. There is a feature that if a connection that has exceeded the 24hr connection time limit continues to try connecting (like a bot might) it will dynamically get added to the in-memory (not iptables/ipset) blacklist.
For this to work the in-memory blacklist must run all the time. Not just for proxied Kiwis. For non-proxied Kiwis there will be few entries in it because iptables is catching most of the blacklisted addresses.
Is it possible that the 195.128.246.85 address you show was not actually in iptables/ipset at the time those log messages occurred? Because the log messages might simply be a result of the 24hr auto-ban before you manually added the range to the blacklist.
Remember there is a new shell alias
ipsto check if a range is in the ipset table. Since individual ranges are no longer in the iptable itself.The IP was in a range that was included in the ipset list at that time for a very long time already. I tripple checked it :)
It happened several times from two different IPs.
I've updated the public kiwis today and will report if it happens again. Will also send you an e-mail regarding the serial number thing.
Thanks.
v1.682 fixes the problem reported by @HB9TMC where ipset/iptables wasn't filtering properly (but the Kiwi server was as a backup).
But I also noticed something important. On the admin network tab, the "local blacklist" section where you can enter your own ip addresses and ip ranges: Be careful to not enter invalid or duplicate entries. Especially duplicates. Because processing of the local list will terminate at the point it finds a duplicate. It's a pain for me to detect this condition and report it back to the admin interface. I have much more important things I need to be working on. So this warning will have to suffice.
Consider this local blacklist entry:
1.2.3.4/32 217.150.74.0/16 217.150.75.255/16 5.6.7.8/32
There are two problems here.
217.150.74.0/16is deceptive because the /16 means the bottom 16-bits are considered the wildcard host address part and should really have been specified as 0.0 as in217.150.0.0/16. That means the following217.150.75.255/16is also wrong and also considered as217.150.0.0/16. Hence two identical entries in a row causing an error which prevents the5.6.7.8/32entry from being added to the blacklist!So be careful when constructing your lists. Use a site like https://www.ipaddressguide.com/cidr to check your IP range for proper CIDR representation.
another
and so every several seconds
I had them too.
I had to turn off non Kiwi apps because they are trying to connect one after another. They won't stop!
hello, today another garbage activation
77.111.244.0/24 91.225.160.0/22 103.135.104.0/24 124.205.128.0/17
a new pain here
@WA2ZKD Yeah, I noticed those on someone's Kiwi this morning. Now added to the global blacklist. Thanks
it's been going on for over an hour
Object,
asn:"AS45102",
name:"Alibaba (US) Technology Co., Ltd.",
domain:"alibabagroup.com",
route:"198.11.128.0/18",
type:"hosting",
Thanks. Global blacklist updated..
Something new, it set itself to a freq. that my SDR does not support
after a kick it returns and still no reaction.
for now I block the entire IP pool 92.72.0.0/13
there is another botnet with variable IP locations, listening to 11900kHz and searching for +/- 200kHz in IQ mode. it shows up cyclically for a few minutes and disappears
I will be removing posts that talk about code security issues, weaknesses and strategy.
I've recently seen a number of these from Germany.
"logdb.utdx.de"
199.175.220.92Wanderup, Germany7:16:31[1d:20:03:58 total]
199.175.223.53Wanderup, Germany8:24:49
199.175.221.24Wanderup, Germany11:39:13
199.175.223.255Wanderup, Germany7:07:41
103.204.206.193Wanderup, Germany9:35:44
199.175.223.127Wanderup, Germany0:00:00
Just sits on ALE_2G scanning
Those are valid, and he has identified himself.
It's a member of the UDXF list logging ALE networks, which requires long periods of continuous monitoring to capture stations that may only sound once an hour.
I have given him passwords for my KiWi's so that he doesn't time out.
Regards,
Martin
Incidentally if you are at all interested in reception of Short Wave stations outside of the Amateur and Broadcast bands I can recommend
The files sections on both sites are valuable sources of information, with frequency and callsign lists.
Regards,
Martin
Cool, thanks.
I couldn't resolve the domain however I think that might be my firewall (or pi-hole) - ill check the logs. I tried resolving logdb.utdx.de outside my network, and got the answer I needed :-)
Wanderup ... That's not far away from where I was born. 😊
Ah - yes, I am a member of that forum. I do struggle a bit with the groups.io format. However thats a me thing and need to spend more time on it.