@F5LFE This is really interesting to me because it seems to be an admin connection attack. I'll bet each of those is trying with a different password.
Here's something you can do to verify that. With the admin console type cdk; touch opt.debug. And then click the restart button on the admin control tab. This will print more messages in the log when someone connects including the attempted password. See if it changes each time.
I had to blacklist 3 different IP addresses before the attack stops.
Each time I added an IP to the blacklist, I noticed the following message from the log : "Admin connection closed" or something looking like from my memory.
I think this confirms that is a brut force attack on the admin login.
I did what you suggested but since there is no attack at the moment, I do not see anything else than my own connexion.
BTW could you tell me how to come back to the initial logging parameters ?
Thank you for your help and I will keep the community informed.
From the admin console type: cdk; rm opt.debug and then restart. That will stop those additional logging messages.
@smg Running fail2ban would kill the Linux realtime response causing the audio to break up as the Kiwi server process becomes starved for CPU cycles. You can't run a heavy process like a Python interpreter at the same time. We are already extremely lucky that running kernel iptables filtering and user mode frp proxying doesn't cause trouble.
I'm seeing a lot of connections with Headless-Chrome (so it's something scripted) from the Waseda University of Japan 133.9.0.0/16. They just sit on the default frequency for hours. Not sure what this is about. Anybody else seeing those?
Do you have a more specific IP address? There is no way Waseda has a /16 allocation (64k hosts) and I'm not going to blacklist 133.9.0.0/16 since the whois for that large range is not allocated to Waseda.
Waseda University is a big research school in Tokyo. They even have a department for telecoms, the Graduate School of Global Information and Telecommunication Studies. When they hit my KiwiSDR it was always running FT8 on 40m (not the default frequency). I'd make a guess it was part of a PhD research project. They are welcome to my Kiwi any time they want.
@bwilson That's valuable intel -- thank you. I've taken them out of the global blacklist. If anyone wants to add them back just put 133.9.0.0/16 into your local blacklist.
Comments
Are you direct connected to the internet and not via a proxy?
Yes I'm connected directly.
That certainly does make your device a target. Are you using a firewall or router?
Hi,
this morning my log looks like someone is trying a brut force on my kiwi.
Could somebody confirm if this is an attack ?
I am not an expert in this matter.
That's similar to what I saw on my KiwiSDR, although from yet another IP-Address.
@F5LFE This is really interesting to me because it seems to be an admin connection attack. I'll bet each of those is trying with a different password.
Here's something you can do to verify that. With the admin console type
cdk; touch opt.debug. And then click the restart button on the admin control tab. This will print more messages in the log when someone connects including the attempted password. See if it changes each time.Look for log entries of the form:
PWD admin admin RESULT: allow=0 pwd_s=<actual admin pwd> pwd_m=<attempted pwd> cant_determine=0 is_local=0 is_local_e=0 [IP address]I had to blacklist 3 different IP addresses before the attack stops.
Each time I added an IP to the blacklist, I noticed the following message from the log : "Admin connection closed" or something looking like from my memory.
I think this confirms that is a brut force attack on the admin login.
I did what you suggested but since there is no attack at the moment, I do not see anything else than my own connexion.
BTW could you tell me how to come back to the initial logging parameters ?
Thank you for your help and I will keep the community informed.
73 F5LFE
@jks Would it be worth installing fail2ban - or just another can of worms for you to deal with when people lock themselves out of their kiwis?
From the admin console type:
cdk; rm opt.debugand then restart. That will stop those additional logging messages.@smg Running fail2ban would kill the Linux realtime response causing the audio to break up as the Kiwi server process becomes starved for CPU cycles. You can't run a heavy process like a Python interpreter at the same time. We are already extremely lucky that running kernel iptables filtering and user mode frp proxying doesn't cause trouble.
Ah - makes sense.
I'm seeing a lot of connections with Headless-Chrome (so it's something scripted) from the Waseda University of Japan 133.9.0.0/16. They just sit on the default frequency for hours. Not sure what this is about. Anybody else seeing those?
Hi, in my user list, apart from the normal connections, I also see this:
127.0.0.1 West Virginia, USA 0:00:00
"i like cheeseburgers" 127.0.0.1 West Virginia, USA 0:01:16
"I'm seeing a lot of connections with Headless-Chrome (so it's something scripted) from the Waseda University of Japan 133.9.0.0/16."
I have them also
Regards
Do you have a more specific IP address? There is no way Waseda has a /16 allocation (64k hosts) and I'm not going to blacklist 133.9.0.0/16 since the whois for that large range is not allocated to Waseda.
The IP address reaching my 3 Kiwis is 133.9.169.36 and is geoloc @ Tokorozawa, Japan.
Regards
Well, it seems they do have an assigned /16. You have to go to the .jp nic to find it.
No wonder we're out of IPv4 addresses. There's no way a university needs 64k public IPs in this day and age..
Okay, blacklist pushed with 7 new IP ranges.
Waseda University is a big research school in Tokyo. They even have a department for telecoms, the Graduate School of Global Information and Telecommunication Studies. When they hit my KiwiSDR it was always running FT8 on 40m (not the default frequency). I'd make a guess it was part of a PhD research project. They are welcome to my Kiwi any time they want.
@bwilson That's valuable intel -- thank you. I've taken them out of the global blacklist. If anyone wants to add them back just put
133.9.0.0/16into your local blacklist.