The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

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.

N1NKM
«1

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.


    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
    


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

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

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

  • 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

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

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

  • 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

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

  • I'm getting again access attempts (only "SET GET_USERS") to my Kiwi from Russia every 30 seconds, from a new subnet.

    195.128.246.0/23

  • Okay, added to blacklist. Thanks.

    Yogicat
  • Added to blacklist: 137.220.40.124 and 207.148.92.163 observed making rapid connections, then using old API (SET MARKER variant). Both from constant/vultr/choopa VPS IP ranges.

  • Another Constant/VULTR (136.244.116.0/23)

    L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    L API: non-Kiwi app fingerprint was denied connection
    

    I wonder if it might cause trouble to block all their IP ranges in a dedicated ipset list. That way we could clean up the block list. They are so kind and list all their networks here: https://geofeed.constant.com/

  • edited May 10

    I am seeing the same thing on my public Kiwi2. I added them to my blocklist. 11 attempts within 3 minutes.

    Fri May 10 17:33:32 10:02:54.040 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:33:33 10:02:55.124 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:33:33 10:02:55.128 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:33:49 10:03:10.857 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:33:49 10:03:10.864 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:33:49 10:03:11.679 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:33:49 10:03:11.682 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:34:05 10:03:27.403 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:34:05 10:03:27.408 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:34:06 10:03:28.500 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:34:06 10:03:28.505 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:34:22 10:03:44.419 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:34:22 10:03:44.424 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:34:23 10:03:45.324 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:34:23 10:03:45.326 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:34:38 10:03:59.955 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:34:38 10:03:59.960 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:34:39 10:04:00.844 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:34:39 10:04:00.847 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:34:54 10:04:16.545 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:34:54 10:04:16.553 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:34:55 10:04:17.446 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:34:55 10:04:17.449 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:35:11 10:04:33.158 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:35:11 10:04:33.164 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:35:12 10:04:34.083 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:35:12 10:04:34.086 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:35:27 10:04:49.776 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:35:27 10:04:49.783 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:35:28 10:04:50.669 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:35:28 10:04:50.672 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:35:44 10:05:06.358 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:35:44 10:05:06.363 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:35:46 10:05:08.349 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:35:46 10:05:08.354 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:36:02 10:05:24.089 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:36:02 10:05:24.097 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    Fri May 10 17:36:03 10:05:24.984 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
    Fri May 10 17:36:03 10:05:24.986 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
    Fri May 10 17:36:18 10:05:40.732 0.234567 0        L PWD new connection --------------------------------------------------------
    Fri May 10 17:36:18 10:05:40.737 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
    
  • They are so kind and list all their networks here: https://geofeed.constant.com/

    Interesting. I'm surprised such a list is public. The problem with adding an exhaustive list like that is the extra burden it places on the Beagle. I imagine the traffic filtering code has been tuned to be as efficient as possible. But every search traversal is going to cost something. And the poor Beagle needs all the help it can get.

  • That 136.244.117.202 IP range is now in the blacklist as other people have seen it.

  • For the sake of completeness, vultr is active from a new ip range

    192.248.162.0/23

    I think some old vultr ranges could be removed, they seem to change the network every few weeks.

    There's something that I don't understand. The range is already in the block list, I don't quite understand how it gets past iptables:

    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>
    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>
    


  • If your Kiwi is proxied then the filtering cannot be done at the iptables level since all traffic appears with a source IP of the kiwisdr.com proxy server. The filtering must be done by the Kiwi server based on the true IP source passed along in the X-Forwarded-For and X-Real_IP HTML headers added by the proxy server.

  • edited May 16

    I see, but it shouldn't be proxied, as far as I'm aware of. (21445) I was using the "domain name" configuration.

    The proxy url was not leading to my kiwi, when I tried it. ("The page you visit not found.")

    I've changed "automatic configuration" to "no" now.

    Not sure if it's a bug related with that; I can't get my two kiwi 2's signed up to my.kiwisdr.com both at the same time.

Sign In or Register to comment.