Second build sold out. Message will appear here when store is ready for third build ordering.

W/F and SND Bad Params

I'm seeing stuff like this in my logs:

Mon Jul 29 08:11:48 05:12:35.039 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:11:43] ip=47.88.219.24 ####################################
Mon Jul 29 08:12:06 05:12:53.170 0... 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:12:02] ip=47.88.219.24 ####################################
Mon Jul 29 08:12:48 05:13:35.208 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:12:43] ip=47.88.219.24 ####################################
Mon Jul 29 08:13:06 05:13:53.337 0... 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:13:02] ip=47.88.219.24 ####################################
Mon Jul 29 08:13:48 05:14:35.247 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:13:43] ip=47.88.219.24 ####################################
Mon Jul 29 08:14:06 05:14:53.334 0... 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:14:02] ip=47.88.219.24 ####################################
Mon Jul 29 08:14:48 05:15:35.278 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:14:43] ip=47.88.219.24 ####################################
Mon Jul 29 08:15:06 05:15:53.363 0... 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:15:02] ip=47.88.219.24 ####################################
Mon Jul 29 08:15:48 05:16:35.310 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:15:43] ip=47.88.219.24 ####################################
Mon Jul 29 08:16:06 05:16:53.382 0... 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:16:02] ip=47.88.219.24 ####################################
Mon Jul 29 08:16:48 05:17:35.189 0... 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 16:16:43] ip=47.88.219.24 ####################################

IP back to something in Singapore.

What's this about?
«1

Comments

  • edited July 2019
    I had the same, pretty sure I've mentioned it before on here (only seen from IP addresses in China) and was told it was not an issue.
    I might start geo blocking on my router as would prefer not to see all that unknown traffic.

    W/F BAD PARAMS: sl=18 50|48|49 [2019/7/29 19:22:26] ip=47.88.219.24 ######
    --removed-383-lines

    12hrs of this junk

    Stu
  • I'm having it pretty badly here too.

    SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 12:15:26] ip=47.88.219.24 ####################################
    Tue Jul 30 04:15:32 8d:12:53:17.283 01234567 1 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 12:15:26] ip=47.88.219.24 ####################################

    Same IP that you're seeing and another one. It's getting in the way of user access.
  • I'll look at this when I get home in a few weeks. Connections are being made specifically to the sound and waterfall web sockets. Then a timestamp (the stuff inside the brackets, e.g. "2019/7/30 12:15:26") is being sent as a command. This of course is unexpected and gives rise to the message which is part of some debugging code leftover from long ago.

    I don't see how this could be part of the random network scanning which happens all the time on the Internet. Someone is specifically looking at Kiwis. Like they've taken the kiwiclient code and modified it to do this driven from the list of public Kiwis. It would be interesting to see if any legitimate commands are being sent from those ip addresses. But that will have to wait..
  • That sounds right.
    The unlisted Kiwi saw no traffic, the currently-public one sees attempts every hour despite the IP being dropped at the router.
    Personally I'd just drop it at the router unless you want to help the user who may be well intentioned, but could also be unintentionally D.O.S.ing online receivers.

    I might allow it again later (after work) and do some network sniffing.
  • edited July 2019
    Whatever they are doing, it happens once a minute. This log shows the only legitimate connection I've seen from this IP:

    Jul 30 09:05:45 kiwisdr kiwid: 06:06:25.345 01.. 1 15598.00 kHz usb z8 "47.88.219.24" Singapore (ARRIVED)
    Jul 30 09:05:58 kiwisdr kiwid: 06:06:37.838 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:05:50] ip=47.88.219.24 ####################################
    Jul 30 09:05:58 kiwisdr kiwid: 06:06:37.918 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:05:50] ip=47.88.219.24 ####################################
    Jul 30 09:06:57 kiwisdr kiwid: 06:07:37.725 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:06:50] ip=47.88.219.24 ####################################
    Jul 30 09:06:58 kiwisdr kiwid: 06:07:37.796 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:06:50] ip=47.88.219.24 ####################################
    Jul 30 09:07:58 kiwisdr kiwid: 06:08:37.785 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:07:50] ip=47.88.219.24 ####################################
    Jul 30 09:07:58 kiwisdr kiwid: 06:08:37.866 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:07:50] ip=47.88.219.24 ####################################
    Jul 30 09:08:58 kiwisdr kiwid: 06:09:37.757 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:08:50] ip=47.88.219.24 ####################################
    Jul 30 09:08:58 kiwisdr kiwid: 06:09:37.873 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:08:50] ip=47.88.219.24 ####################################
    Jul 30 09:09:58 kiwisdr kiwid: 06:10:37.749 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:09:50] ip=47.88.219.24 ####################################
    Jul 30 09:09:58 kiwisdr kiwid: 06:10:37.837 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:09:50] ip=47.88.219.24 ####################################
    Jul 30 09:10:57 kiwisdr kiwid: 06:11:37.720 01.. 0 SND BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:10:50] ip=47.88.219.24 ####################################
    Jul 30 09:10:58 kiwisdr kiwid: 06:11:37.825 01.. 0 W/F BAD PARAMS: sl=18 50|48|49 [2019/7/30 17:10:50] ip=47.88.219.24 ####################################
    Jul 30 09:11:06 kiwisdr kiwid: 06:11:46.177 0... 1 5598.00 kHz usb z9 "47.88.219.24" Singapore (LEAVING after 0:05:34)
  • I added an entry to iptables on my router to drop anything from that IP address (well the entire subnet just to be sure)

    iptables -I FORWARD -s 47.88.219.24/24 -j DROP
  • My router doesn't seem to be so flexible. Is there any reason not to do this on the kiwi itself? My kiwi seems happy with it and iptables -L shows it as in place. Since doing that, I've had no more issues on a sample of three.
  • I guess it is probably just about loading but if your BeagleBone is not maxed out there shouldn't be an issue (IMHO).
    My "Drop at the router" sees them test access every 78 minutes so not exactly heavy traffic.
    Stu
  • I'm not sure it's just traffic loading. My log was getting filled and I too thought that the availability of receivers was suffering. When the offending address found a response it seems to have pounded on it fairly hard.
    In any even, other than having to make sure the iptables entry doesn't get washed out by FW changes it seems a useful solution.
  • Once they get a response they do hit it every minute or so, just seems like too much bother to leave that open for no obvious benefit, if they said "we are doing this RF survey for some good cause and will clean up the script" then I figure a lot of people wouldn't mind, but as it is, rubbish stuffing the logs and a poorly executed hidden connection does not invite participation.
    My guess is that China is mass producing Kiwi clones for RF monitoring behind their firewall and someone has been tasked with writing the info-scraping software. >:)
  • edited July 2019
    I'm 99 44/100 % convinced this bot script was the cause of the problem I was experiencing with several receivers not being available for use (since that problem went away when I started to block them).

    I am not sure if this is related, but the radio related website https://www.hfunderground.com/board/ which I run was getting overrun with bots a few days ago. You get three chances to guess from where, and the first two don't count. Hundreds at a time, at one point I saw over 500. They have stopped, for now anyway, but I am seriously looking into figuring out how to geoblock China if it happens again. It's an ugly solution which I don't want to have to implement, but it's potentially an even uglier problem.

    This is why we can't have nice things.
    VK3KHZ
  • Chris,
    I wish I could find a good argument against what you suggest...
  • iptables -I FORWARD -s 47.88.219.24/255.255.255.0 -j DROP
    should block it out. I'll watch and see if it does. A whois search lists Alibaba as the owner and has information on complaining about abuse.
    Ron
    KA7U
  • edited August 2019
    In a kiwi itself rather than my router, after trying it with FORWARD, I ran:
    iptables -I INPUT -s 47.88.219.24/24 -j DROP
    iptables -I INPUT -s 184.22.160.13/24 -j DROP
    since I'm trying to stop packets from two different offenders at the kiwi rather than from being forwarded by the router. This I followed with:

    iptables-save

    so that it will (I hope) get restored upon reboot. Examining the results I get:

    root@kiwisdr:~# iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    DROP all -- 184-22-160-0.24.nat.tls1a-cgn02.myaisfibre.com/24 anywhere
    DROP all -- 47.88.219.0/24 anywhere

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination
    DROP all -- 184-22-160-0.24.nat.tls1a-cgn02.myaisfibre.com/24 anywhere
    DROP all -- 47.88.219.0/24 anywhere

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    I'm not familiar enough with iptables yet to know if this will be sufficient, perhaps only the INPUT rule is needed. Maybe someone who knows can suggest whether this is correct or whether there's a better way.
    VK3KHZ
  • Don't complain to the whois admin. Filter instead. When I get back I want to look in more detail what they're actually doing. I set a trap on my own Kiwi, but it hasn't triggered yet.
  • Looks like they have started on mine too, so I've blocked them at the router.

    Maybe the KiWi needs additional mechanisms to automatically defend against such incursions, or at least flag them up ?

    Regards,

    Martin - G8JNJ
  • Thinking about this still further, I can't imagine any good purpose behind what's going on.

    Maybe it would be a good idea for all KiWi's to have the IP address blocked, at least until it's better understood what's going on, by which time it may be too late.

    Personally I don't want to be assimilated into a Chinese Botnet :-(

    Regards,

    Martin - G8JNJ
  • I've a few ideas but not for posting on a public forum.
  • I have only seen a few of these hits but have added the iptable rule anyway. Better safe than sorry.
  • For those of us unfamiliar with Linux and worried to have their Kiwi become inoperable by entering wrong commands would anyone be willing to give a short step by step instruction how to block an IP on the Kiwi as mentioned above and how to undo this later.

    Thanks, Claire
  • Claire,
    The steps I gave before seem to have fixed the problem for me. I am not an expert in this area either but no one has yet commented that there is a better way. To accomplish the block I first logged into my kiwi as root. I did this using secure shell, ssh, on a Linux host but this is also possible from a Windows machine via PuTTy or similar. Using PuTTy, simply enter the address, port 22, and it should then ask you to OK the connection. After you do, it will ask you who you want to log in as. Answer 'root'. That should get you a command line prompt from the kiwi. Once logged in I executed three lines:

    iptables -I INPUT -s 47.88.219.24/24 -j DROP
    iptables -I INPUT -s 184.22.160.13/24 -j DROP
    iptables-save

    There may be even easier ways but that's all I did and it seems to have worked, the log is no longer reporting these hits. Presumably these could start again from a different IP address and I would need to repeat one of the above first two commands with that address in place of the one shown.

    Glenn n6gn
    VK3KHZ
  • Hi Glenn,

    I do appreciate your time writing down these steps...it helps me and likely other Kiwi users as well that want the apply this temporary fix.

    Thanks again, Claire.
  • Hi Glen,

    I was able to enter these commands directly via the KiWi admin console page.

    I don't know if this is possible, but the responses I got back seem to indicate that it worked OK.

    Regards,

    Martin - G8JNJ
    Brendan_WG0LUJ
  • edited August 2019
    I did the following - make a rule to both log and drop it:

    iptables -N LOG_DROP
    iptables -A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 6
    iptables -A LOG_DROP -j DROP
    iptables -I INPUT -s 47.88.219.0/24 -j LOG_DROP


    then make those rules persistent:

    sudo apt install iptables-persistent

    OR if this package was already installed:

    iptables-save > /etc/iptables/rules.v4

    You can check on the attempts by:

    dmesg | grep INPUT:DROP | tail -10

    and adjust the number at the end for the number of line items you'd like listed; 10 fits within the admin console window.
    VK3KHZ
  • I still think logging to an external syslog server is wise too.
    If some activity managed to crash the Beagle it is easier to review the event if it is recorded elsewhere.

    As said previously, where the device allows, block at the router rather than the Kiwi, assuming an address is in any way malicious, it is better to protect the network than just one device.
    For those who don't want to buy a new router consider using an older pc/laptop (minimum two networks) with PFsense or some other opensource solution, if only for a short while.
  • Martin and W1EUJ,
    Thanks for the good ideas. I tend to do everything from a remote command line so didn't even consider the Kiwi console which is, of course, most accessible. By remoting in I get the advantage of history and easy copy/paste - which I tend to need a lot when I'm fussing around trying to understand something new. But I agree that simply entering W1EUJ's suggestions from the console works just fine and has the excellent benefit of generating a log.
    Hopefully Claire and others followed this.
  • >
    >so didn't even consider the Kiwi console which is, of course, most accessible
    >

    However it only works if you have local access to the KiWi, otherwise you will need to ssh in.

    Regards,

    Martin - G8JNJ
  • Same here: bad w-f and snd parameters commands. Comforting (a tiny bit) to know it's not just my Kiwi.

    To wit:
    Sat Aug 3 06:44:48 01:23:14.672 0... 0 W/F BAD PARAMS: sl=17 50|48|49 [2019/8/3 14:43:54] ip=47.88.219.24 ####################################
    Sat Aug 3 06:44:48 01:23:14.772 0... 0 SND BAD PARAMS: sl=17 50|48|49 [2019/8/3 14:43:54] ip=47.88.219.24 ####################################
    Sat Aug 3 06:45:49 01:24:15.065 0... 0 SND BAD PARAMS: sl=17 50|48|49 [2019/8/3 14:44:55] ip=47.88.219.24 ####################################
    Sat Aug 3 06:45:49 01:24:15.070 0... 0 W/F BAD PARAMS: sl=17 50|48|49 [2019/8/3 14:44:54] ip=47.88.219.24 ####################################

    Using "whatismyipaddress.com" I tracked it to Singapore, and the ip address indicated it was owned by Alibaba Tech (USA). I have only seen this one IP on my log. I'll use my router to block it here. Truly a pain-in-the-a**.

    Brendan WA7HL
  • I'm not convinced about Singapore.
    I used ping and traceroute to find the path from the UK and from a machine in Singapore, from UK 200ms and from Singapore 3ms BUT both packet routes showed a common IP addresses in China (Alibaba maybe).
    It might be that the thing is in Singapore but local (Singapore) traffic has to go through the "great firewall".
    Also using the geographic block list setup at https://mikrotikconfig.com/firewall/ and selecting China+Singapore does not include that range, maybe that tool is out of date.
  • Right, Singapore being an entry point versus origin. The other IP address above comes back to Chiang Mai, Thailand, using the same website, so most likely a deliberate intrusion campaign via VPN or similar.
Sign In or Register to comment.