Hackers be hacking..
An alert Kiwi owner/admin has sent me some suspicious log messages. They are obvious hacking attempts. If you see anything similar or unusual in your logs I'd appreciate it if you could forward the relevant log messages to support@kiwisdr.com
I'm particularly interested in log messages containing ### SECURITY: NO AUTH YET:
And also **** unknown stream type
And any attempted admin login messages from IP addresses you're not expecting.
So far the Kiwi security mechanisms appear to be working and there has not been any evidence of any breaches. Please be sure you have a good, strong admin password in place.
The IP address in question has been added to the IP blacklist which your Kiwi should receive during the overnight update window. You can also update it manually on the admin page, network tab.
Thank you.
Comments
I don't know if I'm on topic but I find this string repeating on my log. although my kiwi is set to not have any free access channels but only with a password.
While on the new kiwi2 which is not registered online there are no strings that I don't recognise.
I'd have to look at this more carefully. It could be a timing bug where the connection attempt is denied due to lack of a provided password. But not before the code sees that no API-provided geo location information had been sent and attempts to obtain it locally.
There are several timing cases like this at connect time I had to deal with.
people are using other's callsigns to ID themselves on login.
Not sure I understand. Sure, people spoof stuff in the name/callsign field all the time. Not much to be done about that. But the log stuff is a little more serious.
somone used my WA2ZKD call.... so that might mislead an admin thinking "oh it's Jim"..... nothing is safe
Okay, yeah, that's more serious then.
@fabrys That IP address has been showing up elsewhere. Part of a Russian datacenter subnet. Onto the blacklist it goes..
Ok!
I think 8.219.247.109 (alibaba cloud) is doing the same as the russian datacenter guys. I've seen that for quite some time but didn't bother, as they did it not as extensive as the russian guys, only maybe once or twice a day.
It looks like they are collecting information about who is listening to which frequency
Hi folks,
Is the recent requirement to enter a callsign / nickname related to this ?
Not sure that this really helps if it is.
Anyone can enter a ham callsign, and how does a Kiwi sysop contact
a user for a check, since many of us already take our own precautions to avoid
our email adressess being spread about to avoid spammers ;-)
At this point can I also raise some awareness of a small group of operators that
use the QRSS mode. They often use a segment immediatly below the WSPR freqs
and can be mistaken for someone trying to monitor WSPR, which would be
deemed a wasting or duplicating the inbuit wspr decoder etc.
The reality is that occasionally they use the Kiwi RX to feed the audio stream to
what is known as a "grabber" to visually show QRSS signals for an *hour or two
a week for tests.*
So please don't assume that they are bandwidth wasters and block them ;-)
73 de Andy G0FTD
No, we've had a bot/hacking problem for years now.
Generally only IP ranges belonging to virtual private server (VPS) providers, where the bots originate, are blocked. Individual IPs are only blocked from obvious hackers (abusing/testing the Kiwi API, etc).
>No, we've had a bot/hacking problem for years now.
Agreed.
You should see my firewall logs ;-)
>Generally only IP ranges belonging to virtual private server (VPS) providers, >where the bots originate, are blocked. Individual IPs are only blocked from >obvious hackers (abusing/testing the Kiwi API, etc).
That's good to know. At least most Kiwi providers know the score.
But of course some might be a bit more cruder / less wise and might take a
blunter instrument to solve the problem, thus locking out legit users.
I've only seen it happen one, but once is enough.
I guess if we publicize some awareness then we can reduce any issues.
(REDUCE, since we know that no solution is perfect).
73 de Andy
We've had a couple of cases where after blocking an IP range of a VPS provider a legit Kiwi user (who happens to be using a VPS from that provider) finds they can no longer access kiwisdr.com etc. That's why we have the whitelist mechanism that can make an exception for a single IP address within a blocked range.
Similarly, there is an option to block only port 8073 connections (or whatever external port the Kiwi uses) in a blocked range instead of everything in the range. This was necessary because some Kiwis used DDNS from providers who were blocked.
The fun never ends..
JKS,
Is there an option to limit admin access to key-based ssh only, thereby eliminating username / password access? These attacks on KiwiSDRs may be part of the large scale campaign going on since mid-March against _everything_.
There's an Ars Technica article, "Attackers are Pummeling Networks..." which speculates that the goal is reconnaissance and service disruption. It is so bad that the login attempts are having effects similar to denial-of-service attacks, except these guys seem to want the passwords. Deep down, I'm sure the attackers are the sort who just want to watch the world burn.
@AB9IL:
You asked John, but I try to answer, as it's pure Linux and nothing kiwi-specific. Do the following settings in
/etc/ssh/sshd_config
:(However, I would leave or set
PasswordAuthentication
toyes
until the key-based login is tested and proved to work.) After each change to/etc/ssh/sshd_config
,sshd
must be restarted to let the changes take effect.Edit: Sorry, I should have mentioned also the other necessary steps to establish a key-based login to kiwi (or any other linux system with ssh access). Here are step-by-step-instructions. (I didn't explicitly test them, but they seem okay.)
@General
Whatever measures are taken, I always found it advisable to additionally put ssh on an unusual non-guessable port. I do that since decades with my servers. It doesn't really enhance security, but as a small extra hurdle, it reduces the rush and keeps the logs (
/var/log/auth.log
in this case) from lots of "noise". This setting is done in the same configuration file.Regards,
Manfred
There are some further security restrictions you can place on access to the admin interface: http://kiwisdr.com/quickstart/index.html#id-opt-dot
John:
I caught a couple of those messages you refer to:
Apr 29 11:48:54 KiwiSDR21391 kiwid: 04:26:20.361 0123 0 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Apr 29 14:23:31 KiwiSDR21391 kiwid: 07:00:57.498 0123 1 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Apr 30 07:04:34 KiwiSDR21391 kiwid: 04:32:24.695 0123 3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Apr 30 07:05:25 KiwiSDR21391 kiwid: 04:33:15.575 0123 3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Apr 30 07:06:16 KiwiSDR21391 kiwid: 04:34:06.408 0123 3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Apr 30 07:07:06 KiwiSDR21391 kiwid: 04:34:57.258 01.3 3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231
Carl
@engineercarl
That should be prevented with the latest blacklist update. Click "download" on the network tab if you have not allowed automatic updates. But I think your entries (Apr 30) were from before that update.
I do allow automatic updates, but I didn't know how often they updated. This was just the result of a grep from 'messages' this morning. I had added him to my (very long) list of local blacklists so either way, that IP won't be getting in again.
Carl/K6CRS
Thanks Carl for reporting this. Always interesting to know there are people actively probing the API as opposed to bots just running around.