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)
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.
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.
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..)
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.
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.
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
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
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.
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.
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.
Comments
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)
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.
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
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.
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..)
http://sibamanna.duckdns.org/sdr_map.html
There are two new shell aliases for the iptables command: Our friend at 47.88.219.24/24 is setup as the default.
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. ;^)
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
On my Kiwis I've only ever seen traffic from 47.88.219.24 and once 184.22.160.13
Ron
KA7U
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 ####################################
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.
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?
I understand others want to see more detail, hence the ability to control what gets logged.
Set it to "streaming", filter on SDR IP(s), then set Wireshark to read the stream and filter as required.