kiwirecorder.py is mechanism for taking the data stream from the Kiwi SDR and recording/processing it locally, in the same way Firefox is software for taking HTML (website) data and rendering it locally.
If you saw Firefox being used to access your website that is not one person, it is a method, the same with kiwirecorder.py, there are many users, including but not limited to your polite listener.
Your situation sounds completely different with the exception of kiwirecorder.py being used. Kiwirecorder.py is a python script where you can automate to record data from the kiwisdr's. Anyone and everyone can use it and if they leave the default name in there, they all show up as "kiwirecorder.py." The fact that you were contacted by the individual is enough for me to believe that this isn't the same individual or individuals involved.
Nobody contacted me or anyone else that I know of since this issue began back in early March. Initially, they were using numerous VPNs to connect to all 4 of my channels at the same time for an extended period of time. Then they evolved to about 1:30 each time every 30 minutes to an hour or so. Had they contacted me, the situation would have been different, but now every time I see any resemblance of kiwirecorder.py, they get bounced and blocked.
Don't get me wrong, it's a neat script that has it's place and I don't mind my receiver being used for research purposes, but there's just a right way and a wrong way to go about it. Your user did it right by at least letting you know what he was doing. These other folks just don't care, as Powernumpty stated above.
My kiwi has been pretty quiet but I had a couple more kiwirecorder hits this past week. One was an OP in China recording EAM messages in one hour segments every hour on the hour so effectively tying up a channel for a whole day before I caught it. I at least know what they were doing.
The other hit was another 1:33 connection from London. I checked and my device doesn't show a blacklist update available so it should be up to date but this IP range isn't in there from what I can tell. There is a 192.248.144.XXX in there but not 192.248.159.XXX.
Jun 16 04:08:11 kiwisdr kiwid: 1d:10:26:59.643 01.. 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 04:09:43 kiwisdr kiwid: 1d:10:28:31.527 .1.. 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 04:55:21 kiwisdr kiwid: 1d:11:14:09.358 012. 2 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 04:56:53 kiwisdr kiwid: 1d:11:15:41.163 .1.. 2 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 05:40:09 kiwisdr kiwid: 1d:11:58:57.775 01.. 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 05:41:41 kiwisdr kiwid: 1d:12:00:29.589 .1.. 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 06:27:22 kiwisdr kiwid: 1d:12:46:10.629 01.. 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 06:28:54 kiwisdr kiwid: 1d:12:47:42.414 .1.. 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 07:10:45 kiwisdr kiwid: 1d:13:29:33.507 01.. 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 07:12:18 kiwisdr kiwid: 1d:13:31:06.419 .1.. 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:33)
Jun 16 07:56:44 kiwisdr kiwid: 1d:14:15:33.034 01.. 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 07:58:17 kiwisdr kiwid: 1d:14:17:05.921 .1.. 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:33)
Jun 16 08:44:14 kiwisdr kiwid: 1d:15:03:02.222 0... 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 08:45:45 kiwisdr kiwid: 1d:15:04:33.960 .... 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 09:31:40 kiwisdr kiwid: 1d:15:50:28.074 0... 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 09:33:12 kiwisdr kiwid: 1d:15:52:00.808 .... 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:33)
Jun 16 10:20:33 kiwisdr kiwid: 1d:16:39:21.301 0... 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 10:22:04 kiwisdr kiwid: 1d:16:40:53.033 .... 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:33)
Jun 16 11:10:16 kiwisdr kiwid: 1d:17:29:04.113 01.. 1 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 11:11:47 kiwisdr kiwid: 1d:17:30:35.608 0... 1 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
Jun 16 11:55:41 kiwisdr kiwid: 1d:18:14:29.302 0... 0 58.59 kHz WF z8 "kiwirecorder.py" 192.248.159.204 (ARRIVED)
Jun 16 11:57:12 kiwisdr kiwid: 1d:18:16:01.021 .... 0 28125.00 kHz WF z3 "kiwirecorder.py" 192.248.159.204 London, United Kingdom (LEAVING after 0:01:32)
KU4BY - I've had the Chinese bots many times, sitting on USAF frequencies as well. I have 7 KiwiSDRs here, and sometimes the bot(s) will be on all of them. They change IP addresses frequently, so it's a game of whack a mole.
Besides tying up channels, the major problem is that they also seem to be causing Kiwi operation problems, glitchy audio on other channels. Not sure this is purposely malevolent, but the end result is the same. So I kick/ban them when I see them.
@ChrisSmolinski Yeah when we first started noticing this, they weren't showing up in the Admin page because of how they were accessing the receivers so there was no way of kicking or banning them from the GUI. You had to do it at the OS level and I'm not very proficient with linux but I am getting better. My major issue was that they tied up all 4 channels so where I thought I couldn't access it, it turned out that nobody could access it.
Generally speaking, I'm a fan of automation and research, but if you plan on using my receiver to do it, I would appreciate some sort of heads up explaining what you're doing and maybe some insight into what was gained from it. I'd even provide a designated channel if required. The way it is now, it's more like a DOS attack so I blacklist them every time I see them.
I haven't noticed any other issues but that doesn't mean that there weren't any.
I'm going to try updating the blacklist today (192.248.158.0/23 and 115.171.128.0/18 will be new). This will be the first live test of the recent auto update mechanism, other than my testing.
Let's see if I can crash every Kiwi worldwide that hasn't opted-out of the updates. As usual when I send out updates I'll be watching map.kiwisdr.com for all the markers to start turning purple 🙄
Update: seems to be going okay. 3 public Kiwis observed to have auto-updated properly. The next release will include a hash of the current blacklist used in the info reported by a /status inquiry.
I added these, but note 140.82.0.0/18 (0.0:63.255) has been in the blacklist for almost a year. So I don't know how you'd be seeing 140.82.24.131 if you have things configured properly. Make sure you are running a recent software version and have automatically download IP blacklist? set to yes on the admin page, network tab.
I recently noticed these strange connections from the same ip which is once indicated as Chinese and another time as French.
the user connects and remains fixed on the same frequency sometimes the two connections coexist with the same IP and with different geographical indication: (see the attached log).
I checked the IP and the same is traceable to:
IP Address Location Information for 217.69.9.162
City: Aubervilliers
State: Ile-de-France
Country: France
Postal Code: 93537
Time Zone: +01:00
ISP: The Constant Company LLC
Domain: vultr.com
Network Speed: T1
It seems that these strange connections are restarting, in addition to blocking the IP (at least on my KIWI) do I need to do anything else?
LOG:
Thu Feb 2 17:43:06 07:45:40.544 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|217.69.9.162 url=</> qs=<f=5455/0,6000usb&mute>
Thu Feb 2 17:43:06 07:45:40.548 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|217.69.9.162 url=</> qs=<f=5455/0,6000usb&mute>
Thu Feb 2 17:43:06 07:45:40.550 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|217.69.9.162 url=</> qs=<f=5455/0,6000usb&mute>
@fabrys That's very odd. Looks very much like a bug. Although we should have noticed something as basic as that long ago (showing a duplicate [existing] ip address).
On the Admin page, Network tab, what is Prevent multiple connections from the same IP address? set to?
as far as the multiple connection is concerned, I had actually enabled it some time ago... probably, for reasons that are not clear to me, I checked today and it was disabled, now I have restored it.
As an update I report the same user who changed address
Login IP:
Thu Feb 2 19:38:44 09:41:18.741 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|8.215.71.240 url=</> qs=<f=7788/0,6000usb&mute>
Thu Feb 2 19:38:44 09:41:18.744 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|8.215.71.240 url=</> qs=<f=7788/0,6000usb&mute>
Thu Feb 2 19:38:44 09:41:18.747 0... L WEB: IP BLACKLISTED: 0|1 127.0.0.1|8.215.71.240 url=</> qs=<f=7788/0,6000usb&mute>
Sun Mar 12 19:04:43 00:01:46.757 0... 0 L 8992.00 kHz usb z0 "103.68.194.78" Piscataway, New Jersey, USA (ARRIVED)
Sun Mar 12 19:04:53 00:01:56.896 0... 0 API: decided connection is non-Kiwi app (0) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Sun Mar 12 19:04:53 00:01:56.896 0... 0 API: ext_api_users=1 >? ext_api_ch=0 T(DENY)
Sun Mar 12 19:04:53 00:01:56.896 0... 0 L API: non-Kiwi app was denied connection: 1/0 103.68.194.78 "103.68.194.78"
Sun Mar 12 19:04:53 00:01:56.935 0... 0 L 8992.00 kHz usb z0 "103.68.194.78" Piscataway, New Jersey, USA (LEAVING after 0:00:10)
Has been going on for some time now. At least a week.
Ok. It keeps going on and on and on. It changes IPs. Connects for about 10seconds and gets rejected. Then starts over. I guess it is not harming much and I can just turn the port forwarding off to isolate that KiwiSDR from internet access if I really need to. I'd love to send a return poke in the snoot though. It uses the same geo location every time. Can that be used for a filter somehow? It is trying to monitor 8.992Mhz, which has been masked in response.
Thank you John, it's not a biggee, just thought I might have missed something.
I got a couple hits from "directTD0A_v7.02" today. It was connecting every few minutes and parking on a single frequency. Anyone know if this is a legit use or have they just changed the way they do things? I kicked them a few times and the connections ceased since then.
Jun 30 09:08:55 beaglebone kiwid: 09:57:04.801 01.. 1 40.75 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 (ARRIVED)
Jun 30 09:09:29 beaglebone kiwid: 09:57:38.429 0... 1 40.75 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 Qinnan, China (LEAVING after 0:00:35)
Jun 30 09:17:04 beaglebone kiwid: 10:05:13.055 01.. 1 40.75 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 (ARRIVED)
Jun 30 09:18:04 beaglebone kiwid: 10:06:12.862 0... 1 40.75 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 (LEAVING after 0:01:01)
Jun 30 09:29:39 beaglebone kiwid: 10:17:48.243 01.. 1 24.00 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 (ARRIVED)
Jun 30 09:30:25 beaglebone kiwid: 10:18:34.406 0... 1 24.00 kHz iq z0 "directTDoA_v7.02" 117.61.97.208 China (LEAVING after 0:00:51)
Jun 30 16:25:00 beaglebone kiwid: 03:01:55.255 01.. 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:26:11 beaglebone kiwid: 03:03:06.407 0... 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 Guangzhou, China (LEAVING after 0:01:16)
Jun 30 16:28:01 beaglebone kiwid: 03:04:55.924 01.. 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:29:56 beaglebone kiwid: 03:06:51.030 0... 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 Guangzhou, China (LEAVING after 0:02:03)
Jun 30 16:30:15 beaglebone kiwid: 03:07:09.899 01.. 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:31:19 beaglebone kiwid: 03:08:14.192 0... 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (LEAVING after 0:01:11)
Jun 30 16:33:54 beaglebone kiwid: 03:10:48.918 01.. 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:35:02 beaglebone kiwid: 03:11:57.004 .... 1 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 Guangzhou, China (LEAVING after 0:01:12)
Jun 30 16:35:56 beaglebone kiwid: 03:12:51.071 0... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:36:07 beaglebone kiwid: 03:13:02.245 .... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (LEAVING after 0:00:14)
Jun 30 16:36:31 beaglebone kiwid: 03:13:25.941 0... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:36:36 beaglebone kiwid: 03:13:31.533 .... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (LEAVING after 0:00:08)
Jun 30 16:38:06 beaglebone kiwid: 03:15:01.068 0... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:38:11 beaglebone kiwid: 03:15:06.489 .... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 Guangzhou, China (LEAVING after 0:00:15)
Jun 30 16:38:44 beaglebone kiwid: 03:15:39.529 0... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 (ARRIVED)
Jun 30 16:39:13 beaglebone kiwid: 03:16:08.457 .... 0 24.00 kHz iq z0 "directTDoA_v7.02" 203.168.4.2 Guangzhou, China (LEAVING after 0:00:31)
And the frequencies are for real stations (US Navy MSK sub comm). Do you have decent reception of them? 24 kHz is NAA Cutler. 40.75 kHz is NAU Puerto Nico.
Thanks, so now it sounds like China is trying to use my kiwi to spy on US Navy sub comms?
During the day I have no reception from PR except around the CB band but I can hear a beacon from there at night on lw so maybe so. Perhaps I'll unblock them and see what they're up to. my sdr is @ kiwisdr.ku4by.com:8073 if you want to check it out.
VLF signals make great TDoA targets because of their stability, SNR, well known tx locations etc. All the MSK stuff is so heavily encrypted (as you'd expect) that there is no spying motivation.
You've got nice reception on LF/VLF. Here it is at 15:30 local. NAA/24 and NAU/40.75 are obvious. But also a weak NLK/24.8 Washington state and a trace of NPM/21.4 Hawaii.
Cool, I never listen down that low. I am fairly close to the Atlantic and my noise floor is typically pretty low so I guess it makes sense. Thanks for checking it out.
Make sure your IP address blacklist is up-to-date by going to the admin network tab and checking for a message that a new blacklist is available. You may have auto downloading of the blacklist enabled. But that won't occur if you have active connections during the nightly update window.
There has been recent activity from a new set of Alibaba (China) IP addresses that can lock up all of your channels in some cases.
not sure since when, but the blacklist is now preventing my node from being able to update its ddns enty into duckdns.org. Duckdns is a somewhat popular free service that does dynamic dns and they use amazon:
appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com. 45 IN A 3.97.82.174
appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com. 45 IN A 3.99.1.61
appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com. 45 IN A 35.182.71.129
At some point those ranges were banned:
root@kiwisdr:~# iptables -L -n | egrep ' 3\.| 35\.'
DROP all -- 35.0.0.0/8 0.0.0.0/0
DROP all -- 3.0.0.0/9 0.0.0.0/0
I understand why we don't want amazon hosts to connect to Kiwis, but the reverse is less obvious: how many public services (such as Duckdns) are we preventing from being reached? Shouldn't established connections be instead allowed?
But are you running the DuckDNS client on the Kiwi? Could you run the client on some other machine on your local network?
Another thing we could do (I think) is make the iptable rules port-number specific to the Kiwi. That should let through the traffic to the DDNS client. For example it looks like the noip.com DDNS client the Kiwi includes uses TCP port 8245.
Comments
Can someone else respond to this please? (re: what kiwirecorder.py really is) I'm drowning in problems right now..
@o00scorpion00o
kiwirecorder.py is mechanism for taking the data stream from the Kiwi SDR and recording/processing it locally, in the same way Firefox is software for taking HTML (website) data and rendering it locally.
If you saw Firefox being used to access your website that is not one person, it is a method, the same with kiwirecorder.py, there are many users, including but not limited to your polite listener.
Some other users just don't care.
@o00scorpion00o
Your situation sounds completely different with the exception of kiwirecorder.py being used. Kiwirecorder.py is a python script where you can automate to record data from the kiwisdr's. Anyone and everyone can use it and if they leave the default name in there, they all show up as "kiwirecorder.py." The fact that you were contacted by the individual is enough for me to believe that this isn't the same individual or individuals involved.
Nobody contacted me or anyone else that I know of since this issue began back in early March. Initially, they were using numerous VPNs to connect to all 4 of my channels at the same time for an extended period of time. Then they evolved to about 1:30 each time every 30 minutes to an hour or so. Had they contacted me, the situation would have been different, but now every time I see any resemblance of kiwirecorder.py, they get bounced and blocked.
Don't get me wrong, it's a neat script that has it's place and I don't mind my receiver being used for research purposes, but there's just a right way and a wrong way to go about it. Your user did it right by at least letting you know what he was doing. These other folks just don't care, as Powernumpty stated above.
My kiwi has been pretty quiet but I had a couple more kiwirecorder hits this past week. One was an OP in China recording EAM messages in one hour segments every hour on the hour so effectively tying up a channel for a whole day before I caught it. I at least know what they were doing.
The other hit was another 1:33 connection from London. I checked and my device doesn't show a blacklist update available so it should be up to date but this IP range isn't in there from what I can tell. There is a 192.248.144.XXX in there but not 192.248.159.XXX.
KU4BY - I've had the Chinese bots many times, sitting on USAF frequencies as well. I have 7 KiwiSDRs here, and sometimes the bot(s) will be on all of them. They change IP addresses frequently, so it's a game of whack a mole.
Besides tying up channels, the major problem is that they also seem to be causing Kiwi operation problems, glitchy audio on other channels. Not sure this is purposely malevolent, but the end result is the same. So I kick/ban them when I see them.
@ChrisSmolinski Yeah when we first started noticing this, they weren't showing up in the Admin page because of how they were accessing the receivers so there was no way of kicking or banning them from the GUI. You had to do it at the OS level and I'm not very proficient with linux but I am getting better. My major issue was that they tied up all 4 channels so where I thought I couldn't access it, it turned out that nobody could access it.
Generally speaking, I'm a fan of automation and research, but if you plan on using my receiver to do it, I would appreciate some sort of heads up explaining what you're doing and maybe some insight into what was gained from it. I'd even provide a designated channel if required. The way it is now, it's more like a DOS attack so I blacklist them every time I see them.
I haven't noticed any other issues but that doesn't mean that there weren't any.
I'm going to try updating the blacklist today (192.248.158.0/23 and 115.171.128.0/18 will be new). This will be the first live test of the recent auto update mechanism, other than my testing.
Let's see if I can crash every Kiwi worldwide that hasn't opted-out of the updates. As usual when I send out updates I'll be watching map.kiwisdr.com for all the markers to start turning purple 🙄
Update: seems to be going okay. 3 public Kiwis observed to have auto-updated properly. The next release will include a hash of the current blacklist used in the info reported by a /status inquiry.
I have finally been hit with a suspect series of connections.
Jul 3 10:22:45 beaglebone kiwid: 9d:14:52:27.584 01.. 0 58.59 kHz WF z8 "Tom.Miller" 65.49.218.21 (ARRIVED)
Jul 3 10:24:17 beaglebone kiwid: 9d:14:53:59.207 .1.. 0 28125.00 kHz WF z3 "Tom.Miller" 65.49.218.21 Los Angeles, California, USA (LEAVING after 0:01:32)
Jul 3 14:41:59 beaglebone kiwid: 9d:19:11:41.511 0... 0 58.59 kHz WF z8 "Pony.Stuart" 65.49.218.21 (ARRIVED)
Jul 3 14:43:30 beaglebone kiwid: 9d:19:13:13.035 .... 0 28125.00 kHz WF z3 "Pony.Stuart" 65.49.218.21 Los Angeles, California, USA (LEAVING after 0:01:32)
Jul 3 17:27:18 beaglebone kiwid: 9d:21:57:00.776 0... 0 58.59 kHz WF z8 "July_Miller" 65.49.218.21 (ARRIVED)
Jul 3 17:28:50 beaglebone kiwid: 9d:21:58:32.283 .... 0 28125.00 kHz WF z3 "July_Miller" 65.49.218.21 Los Angeles, California, USA (LEAVING after 0:01:32)
The same IP but different names.
They then change IP and go again. All VPNs
65.49.218.21 IT7 networks
207.148.70.7 The Constant Company choopa.com
140.82.24.131 Vultr Holdings LLC
Jim
I added these, but note 140.82.0.0/18 (0.0:63.255) has been in the blacklist for almost a year. So I don't know how you'd be seeing 140.82.24.131 if you have things configured properly. Make sure you are running a recent software version and have
automatically download IP blacklist?set toyeson the admin page, network tab.Interesting about the fake names..
I looked at my logs again.
The 140.82.24.131 occurred while the iptable was being rebuilt after I added one of the other addresses.
Unfortunate timing and not a problem with the blacklist...
23:01:50.075 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 27.154.20.0/24 -j DROP" rv=0
23:01:50.287 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 27.154.22.0/24 -j DROP" rv=0
23:01:50.500 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 34.0.0.0/8 -j DROP" rv=0
23:01:50.573 0... 0 58.59 kHz WF z8 "Lily" 140.82.24.131 (ARRIVED)
23:01:50.711 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 35.0.0.0/8 -j DROP" rv=0
23:01:51.171 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 38.106.20.0/24 -j DROP" rv=0
23:01:51.382 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 38.143.0.0/16 -j DROP" rv=0
Jim
Good morning.....
I recently noticed these strange connections from the same ip which is once indicated as Chinese and another time as French.
the user connects and remains fixed on the same frequency sometimes the two connections coexist with the same IP and with different geographical indication: (see the attached log).
I checked the IP and the same is traceable to:
IP Address Location Information for 217.69.9.162
City: Aubervilliers
State: Ile-de-France
Country: France
Postal Code: 93537
Time Zone: +01:00
ISP: The Constant Company LLC
Domain: vultr.com
Network Speed: T1
It seems that these strange connections are restarting, in addition to blocking the IP (at least on my KIWI) do I need to do anything else?
LOG:
@fabrys That's very odd. Looks very much like a bug. Although we should have noticed something as basic as that long ago (showing a duplicate [existing] ip address).
On the Admin page, Network tab, what is
Prevent multiple connections from the same IP address?set to?as far as the multiple connection is concerned, I had actually enabled it some time ago... probably, for reasons that are not clear to me, I checked today and it was disabled, now I have restored it.
As an update I report the same user who changed address
Login IP:
An interesting resource
I'm wondering who the jackass from Piscataway, New Jersey, US is that keeps hamming my KiwiSDR on 8992.
Has been going on for some time now. At least a week.
That ip is actually in Hong Kong. Blacklist updated.
Ok. It keeps going on and on and on. It changes IPs. Connects for about 10seconds and gets rejected. Then starts over. I guess it is not harming much and I can just turn the port forwarding off to isolate that KiwiSDR from internet access if I really need to. I'd love to send a return poke in the snoot though. It uses the same geo location every time. Can that be used for a filter somehow? It is trying to monitor 8.992Mhz, which has been masked in response.
Thank you John, it's not a biggee, just thought I might have missed something.
I got a couple hits from "directTD0A_v7.02" today. It was connecting every few minutes and parking on a single frequency. Anyone know if this is a legit use or have they just changed the way they do things? I kicked them a few times and the connections ceased since then.
Could be legit. directTDoA is an independent TDoA front-end program developed and actively maintained by @linkz (https://github.com/llinkz/directTDoA)
And the frequencies are for real stations (US Navy MSK sub comm). Do you have decent reception of them? 24 kHz is NAA Cutler. 40.75 kHz is NAU Puerto Nico.
Thanks, so now it sounds like China is trying to use my kiwi to spy on US Navy sub comms?
During the day I have no reception from PR except around the CB band but I can hear a beacon from there at night on lw so maybe so. Perhaps I'll unblock them and see what they're up to. my sdr is @ kiwisdr.ku4by.com:8073 if you want to check it out.
VLF signals make great TDoA targets because of their stability, SNR, well known tx locations etc. All the MSK stuff is so heavily encrypted (as you'd expect) that there is no spying motivation.
You've got nice reception on LF/VLF. Here it is at 15:30 local. NAA/24 and NAU/40.75 are obvious. But also a weak NLK/24.8 Washington state and a trace of NPM/21.4 Hawaii.
Cool, I never listen down that low. I am fairly close to the Atlantic and my noise floor is typically pretty low so I guess it makes sense. Thanks for checking it out.
Make sure your IP address blacklist is up-to-date by going to the admin network tab and checking for a message that a new blacklist is available. You may have auto downloading of the blacklist enabled. But that won't occur if you have active connections during the nightly update window.
There has been recent activity from a new set of Alibaba (China) IP addresses that can lock up all of your channels in some cases.
cutting out the IP 47.251.0.0/17 helps with this botnet
The latest blacklist contains 47.250.0.0/15 (250.0.0:251.255.255), which is a superset of 47.251.0.0/17. So no need to add that additionally.
Hello,
not sure since when, but the blacklist is now preventing my node from being able to update its ddns enty into duckdns.org. Duckdns is a somewhat popular free service that does dynamic dns and they use amazon:
At some point those ranges were banned:
I understand why we don't want amazon hosts to connect to Kiwis, but the reverse is less obvious: how many public services (such as Duckdns) are we preventing from being reached? Shouldn't established connections be instead allowed?
Thanks
But are you running the DuckDNS client on the Kiwi? Could you run the client on some other machine on your local network?
Another thing we could do (I think) is make the iptable rules port-number specific to the Kiwi. That should let through the traffic to the DDNS client. For example it looks like the noip.com DDNS client the Kiwi includes uses TCP port 8245.