Hackers be hacking..

jksjks
edited April 10 in General Chat

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

  • fabrysfabrys

    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.


    Thu Apr 11 07:57:03 00:49:18.038 01..        child_task WARNING: child returned without WIFEXITED status=0x0000008b WIFEXITED=0 WEXITSTATUS=0
Thu Apr 11 07:57:03 00:49:18.039 01..  1   L GEOLOC: 80.87.192.7 sent no geoloc info, we got "Khimki, Russia" from geo host #1
Thu Apr 11 07:57:03 00:49:18.042 01..        task geoloc_task:P2:T007((1000.000 msec) TaskSleep) exited by returning


  • jksjks

    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.

  • WA2ZKDWA2ZKD

    people are using other's callsigns to ID themselves on login.

  • jksjks
    edited April 11

    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.

  • WA2ZKDWA2ZKD

    somone used my WA2ZKD call.... so that might mislead an admin thinking "oh it's Jim"..... nothing is safe

  • jksjks
    edited April 11

    Okay, yeah, that's more serious then.

  • jksjks
    edited April 11

    @fabrys That IP address has been showing up elsewhere. Part of a Russian datacenter subnet. Onto the blacklist it goes..

  • fabrysfabrys
    https://forum.kiwisdr.com/index.php?p=/discussion/comment/18360#Comment_18360

    Ok!

  • HB9TMCHB9TMC
    edited April 11

    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

  • g0ftdg0ftd

    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

  • jksjks
    edited April 13

    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).

  • g0ftdg0ftd

    >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

  • jksjks

    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..

  • AB9ILAB9IL

    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.

  • dl7awldl7awl
    edited April 17

    @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:

    PasswordAuthentication no
PubkeyAuthentication yes

    (However, I would leave or set PasswordAuthentication to yes 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

  • jksjks

    There are some further security restrictions you can place on access to the admin interface: http://kiwisdr.com/quickstart/index.html#id-opt-dot

Sign In or Register to comment.