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

W/F and SND Bad Params

2»

Comments

  • I see the same on my Kiwi & it first started from an AWS IP in USA.
  • edited August 2019
    I have been getting those log entries for the last couple of weeks or so as well
    I had been into my router to try to block the address but found no way to do it in a Virgin router.
    Just entered the itables stuff using cut and paste into the KiWi admin console page and the response did not show up anything that suggested it had not worked ( however I know nothing about Linux)
  • You clicked connect on the top of the console page? Should see the prompt when you do that.
  • I may have worded my message poorly W1EUJ and I just realized there was also a typo that I have corrected now.

    I was trying to say that it accepted my entries and that the response to my entries had nothing in it that looked like there was any problem with anything.
  • Gotcha!
  • This is the current block lists in the firewall command section of my DD-WRT router.
    iptables -I FORWARD -s 47.88.219.24 -j DROP
    iptables -I FORWARD -s 71.169.0.244 -j DROP
    iptables -I FORWARD -s 24.237.116.127 -j DROP
    iptables -I FORWARD -s 47.26.254.99 -j DROP

    Looks like it will take ongoing vigilance to block the odd connection requests.
    Ron
    KA7U
  • I'll have an automatic solution built-in to the Kiwi software after I return.

    The little bit of decoding I've done is really inexplicable. I can see the beginnings of what they're trying to do. But it's incomplete and the end result is that absolutely nothing of value is gained. Except for adding a bunch of log messages and causing general annoyance.
    KA7U
  • Confirming the access attempts from 47.88.219.24 on my own Kiwi, which has been online ~18 days. I've ~690 attempts logged starting Aug 5th, last one on Aug 8th.

    I do like iptables for these kinds of things, though dropping address ranges is a game of whack-a-mole.

    (Just make sure to have your passwords updated, and keep an eye on the usage and logs on your devices, in case of an exploit in any part of the software - especially as the kiwi daemon runs as root..)
  • edited August 2019
    Is there any relationship of this issue to how folks like the Marco (IS0KYB) get waterfall and audio data?

    http://sibamanna.duckdns.org/sdr_map.html
  • No. Marco follows the Kiwi connection API using code similar to kiwiclient (see microkiwi_waterfall.py in the kiwiclient repo). His connection is in-and-out so fast he doesn't appear in the log, which is probably the right thing in that case.
  • jksjks
    edited August 2019
    v1.311 has an IP blacklist interface on the network tab of the admin page. IP addresses or IP ranges entered here will become entries in a user-defined iptable chain named "KIWI". This chain is called via an append command applied to the INPUT chain. This will hopefully minimize interaction with existing iptable rules you may already have. No iptables persistence or saving is done. The rules are cleared (if any) and setup each time the Kiwi server starts.

    There are two new shell aliases for the iptables command:
    ipt     does an "iptables -L"  (lists all iptables rules)
    iptc    does an "iptables -D INPUT -j KIWI; iptables -F KIWI; iptables -X KIWI"  (i.e. removes the KIWI chain entirely)
    
    Our friend at 47.88.219.24/24 is setup as the default.
  • "His connection is in-and-out so fast he doesn't appear in the log, which is probably the right thing in that case."

    If someone connects to a Kiwi but bogs off after doing something so fast that the connection isn't logged, did they even connect to begin with?

    With apologies to trees that fall without making a sound. ;^)
  • This is my current "bad params" IP drop list on my SPI firewall in the router. Most of the bad connects have been on the 8073 port, but all of them have had some attention.
    iptables -I FORWARD -s 47.88.219.24 -j DROP
    iptables -I FORWARD -s 71.169.0.244 -j DROP
    iptables -I FORWARD -s 24.237.116.127 -j DROP
    iptables -I FORWARD -s 47.26.254.99 -j DROP
    iptables -I FORWARD -s 98.144.32.35 -j DROP
    iptables -I FORWARD -s 59.95.51.207 -j DROP
    iptables -I FORWARD -s 5.53.115.182 -j DROP
    iptables -I FORWARD -s 176.59.37.28 -j DROP
    iptables -I FORWARD -s 173.81.75.174 -j DROP
    Ron
    KA7U
  • Do all of those exhibit the same behavior as 47.88.219.24?
    On my Kiwis I've only ever seen traffic from 47.88.219.24 and once 184.22.160.13
  • Thanks jks. The blacklist is useful for other purposes as well :smile:
  • Most of the IP addresses I've blocked generate bad params 2 or 3 times in a day. So not as busy as 47.88.219.24. If a legitimate purpose is determined for these bad parms log entries, I'll unblock them.
    Ron
    KA7U
  • Latest:

    Aug 19 18:55:03 15:55:46.062 0... 0 SND BAD PARAMS: sl=15 83|69|84 [SET no WebAudio] ip=46.101.40.25 ####################################
    Mon Aug 19 18:55:03 15:55:46.062 0... 0 SND BAD PARAMS: sl=106 83|69|84 [SET Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36] ip=46.101.40.25 ####################################

    Mon Aug 19 19:03:51 16:04:34.096 0... 0 SND BAD PARAMS: sl=15 83|69|84 [SET no WebAudio] ip=87.119.179.109 ####################################
    Mon Aug 19 19:03:51 16:04:34.096 0... 0 SND BAD PARAMS: sl=106 83|69|84 [SET Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36] ip=87.119.179.109 ####################################
  • Those particular messages occur when someone uses a very old browser that doesn't support WebAudio. As of v1.314 these errors are displayed in a different way to hopefully prevent confusion.
  • What's the logic behind not logging _anything_ when a user connects to a Kiwi?

    And exactly what all isn't being logged?

    The proverbial fecal matter hit the rotating member here whilst I've been away & to put it politely (since humor didn't work), I'm not comfortable not knowing what's going on with me Kiwi as instead of rule-of-law, it appears we now enjoy the same rule-by-law of Bravoland.

    Even without TDoA, my Kiwi can reveal state secrets. That some user activity _isn't_even_logged_ is B*LL*CKS.
  • edited August 2019
    It must be a bit of trade off, verbosity against CPU cycles and flash memory writes (if logging locally to disk).
    I'm sort of with you on the "tell me I'm an adult" level of logging but I doubt it has been intentionally done to obscure connections (but may be why we are now seeing people stress testing the web services knowing it's hard to detect by default).

    My Kiwi's are currently private simply because my main (longest public) one started bogging down around the time we started seeing strange traffic and I've not go to the bottom of it yet. In my case it might be BeagleBone hardware having had a hard life, but for me once something is suspect I am reluctant to present it publicly for access. I wiped the image from another Kiwi over it last night, still seemed a bit slow will swap out the BeagleBone next.

    So verbose logging to an external server would be my vote if the BeagleBone can keep up.

    ---Maybe off-topic---

    G0LUJ did you ever find out why your setup went down while you were away?
  • Powernumpty - No, I did not find a reason why my system went down last month, but my suspicion was network or power supply issues rather than external factors. I've reconfigured everything and I'm now keeping a close eye on it.
    Powernumpty
  • How about (especially if we are going to be logging even more things) some sort of option(s) to limit what is being logged? There's already a lot of stuff that is superfluous to my needs. Besides the CPU cycles and flash writes, if you log everything, even the mundane stuff, then the important stuff becomes hard to spot.

    I understand others want to see more detail, hence the ability to control what gets logged.
  • There are other options for externally logging traffic too like the packet sniffer in the Mikrotik routers.
    Set it to "streaming", filter on SDR IP(s), then set Wireshark to read the stream and filter as required.
Sign In or Register to comment.