W/F and SND Bad Params

Comments

• Powernumpty

  July 2019 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
• n6gn

  July 2019

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

  July 2019

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

  July 2019

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

  July 2019 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)
• ChrisSmolinski

  July 2019

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

  July 2019

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

  July 2019

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

  July 2019

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

  July 2019

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

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

  
• n6gn

  July 2019

  Chris,
  I wish I could find a good argument against what you suggest...
• KA7U

  August 2019

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

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

  
• jks

  August 2019

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

  August 2019

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

  August 2019

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

  August 2019

  I've a few ideas but not for posting on a public forum.
• sesykes71

  August 2019

  I have only seen a few of these hits but have added the iptable rule anyway. Better safe than sorry.
• Claire

  August 2019

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

  August 2019

  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

  
• Claire

  August 2019

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

  August 2019

  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

  
• W1EUJ

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

  
• Powernumpty

  August 2019

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

  August 2019

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

  August 2019

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

  August 2019

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

  August 2019

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

  August 2019

  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.