IP address blacklist seemingly doesn't [true only for proxied Kiwis, fixed in v1.336]

VR2BGVR2BG
edited October 2019 in Problems Now Fixed
x.0.0.0/16 isn't preventing user access from IP within defined range.

Can't tell if other blacklisted IP addresses are being blocked or no attempts are being made from those addresses anymore. Am suspecting attempted connections from blacklisted address aren't logged as don't see anything about 47.88.219.24 in the log anymore.

So user access has to be turned off. How do I continue to access my Kiwi from outside?

-VR2BG.

Comments

  • VR2BGVR2BG
    User access also cuts off local access, so have set inactivity time limit to 1 minute & 24 hour per IP time limit to 1 minute. I still have access from outside with time limit override password.

    So now how to allow continued TDoA server access, whilst continuing to make all users suffer because of the one guy who just wouldn't stop taking the piss?

    -VR2BG.
  • VR2BGVR2BG
    After once successfully accessing from outside & experiencing the time out timer, I then accessed the Kiwi from outside & successfully overrode the timer.

    But after having connecting as admin from outside, the timers seem to no longer work. I've restarted server & then tried again (still no timer), done a Beagle reboot & tried again (still no timer) & also a power off & still no timer cutting me off from an outside connection.

    Grrrrr.

    -VR2BG.
  • jksjks
    I tried it again and it works fine.

    The blacklist on the admin network tab uses Linux iptables to do the filtering. This means traffic is filtered long before it even gets to the Kiwi server and no indication of successful filtering will appear in the Kiwi log. Instead, on Kiwi admin console tab, you have to use a "ipt -v" command to see an incrementing "pkts" count that tells you traffic is being filtered (use "ipt -Z" to zero the stats).
  • jksjks
    If you give the timeout exemption password correctly to the password prompt when the 24hr timeout expires then that password is saved in a browser cookie. That means you don't have to give the password again until the cookie is erased. That's why it looks like the timeout feature is no longer working.

    The same cookie saving is currently not done when you bypass the timeouts by giving "&pwd=..." in the URL. I'm thinking about changing this to be more consistent.
  • VR2BGVR2BG
    "The blacklist on the admin network tab uses Linux iptables to do the filtering."

    Okay, so will not be expecting anything to be logged.

    x.0.0.0/16 doesn't block the guy behind all this. He's local & apparently has his own Kiwi, but uses mine a lot.

    Because masked labels didn't stop him from listening to local MW stations for extended periods of time (they seem to just prevent the receiver from working if tuned by clicking on the labels), he stepped up his game & would sit & listen to WWV/JJY/BPM or 0.0 MHz. And using multiple IPs. But that particular one still gets through.

    Now I can't tell if the timers set for 1 minute are working as when I access the Kiwi from outside, the timers no longer cut me off.

    -VR2BG.
  • jksjks
    edited October 2019
    Are you really wanting to filter [one of: 0-255].0.xxx.xxx/16? i.e. the second octet is zero and you want to filter out 64k addresses?
  • VR2BGVR2BG
    The user is at x.0.a.b - and since from other IPs he's used the third & fourth octets have varied, I'm blocking everything from the first two octets. What's different about this address is the second octet is a zero - all the others, it is a number >0. And I can see from the log he's still able to connect, so blacklisting x.0.0.0/16 seems to blacklist nothing.

    -VR2BG.
  • jksjks
    I entered a 1.0.0.0/16 into the blacklist and the correct iptables commands were generated (look at the Kiwi log tab). And doing a "ipt -v" in the console tab shows a correct iptables rule entry. So it should be working.
  • VR2BGVR2BG
    From log saved early 2019-10-24 GMT:

    Oct 23 12:33:59 kiwisdr kiwid: 3d:11:23:20.232 0123456. 6 0.00 kHz am z0 "www.paulrowe.com" 210.0.147.10 Central, Hong Kong (ARRIVED)
    Oct 23 12:39:45 kiwisdr kiwid: 3d:11:29:06.149 01234567 7 14100.00 kHz cw z0 "101.70.93.40" (ARRIVED)
    Oct 23 12:47:21 kiwisdr kiwid: 3d:11:36:42.904 01234567 UPDATE: exiting because admin update check not enabled
    Oct 23 12:47:22 kiwisdr kiwid: 3d:11:36:42.956 0123456. 7 15250.00 kHz am z0 "101.70.93.40" Huzhou, China (LEAVING after 0:07:49)
    Oct 23 12:47:22 kiwisdr kiwid: 3d:11:36:42.959 0123456. UPDATE: exiting because admin update check not enabled
    Oct 23 12:50:41 kiwisdr kiwid: 3d:11:40:02.111 01234567 7 0.00 kHz am z0 "www.paulrowe.com" 210.0.147.29 Central, Hong Kong (ARRIVED)
    Oct 23 12:51:00 kiwisdr kiwid: 3d:11:40:21.122 012345.7 6 5000.00 kHz am z0 "www.paulrowe.com" 210.0.147.10 Central, Hong Kong (LEAVING after 0:17:01)
    Oct 23 12:51:00 kiwisdr kiwid: 3d:11:40:21.126 012345.7 UPDATE: exiting because admin update check not enabled
    Oct 23 13:00:49 kiwisdr kiwid: 3d:11:50:10.164 012345.. 7 5000.00 kHz am z0 "www.paulrowe.com" 210.0.147.29 Central, Hong Kong (LEAVING after 0:10:09)

    Blacklist as displayed now:



    Blacklisting 210.0.0.0/16 isn't blocking 210.0.147.29

    73, Brett.
  • VR2BGVR2BG
    Correction: blacklisting 210.0.0.0/16 isn't blocking 210.0.147.29 or 210.0.147.10

    -VR2BG.
  • VR2BGVR2BG
    I've now managed to connect from outside using a different IP address & I'm still not getting cut off by either the inactivity or 24-hour time limits, both of which I've set to 1 minute (so if the Kiwi was remembering & still applying limit override or admin access rights from before presumably should no longer apply).

    I can't completely block an unwanted abuser's IP, setting limits to effectively hobble all external user use (but still allowing password access for me whilst outside) isn't working, which leaves turning off user access - but that also cuts local access. Alternatively, I pull the plug on the reverse proxy service - but I've exceeded the mobile data quota for the month on my phone & remote access of the local computers using the Kiwi doesn't work with the hobbled data rate I now have.

    ???.

    73, VR2BG.
  • jksjks
    edited October 2019
    You're using the proxy? Yeah, I realize now that none of the blacklist stuff will work if you're using the proxy.

    This is something I'll have to fix. The reason I used iptables is that it's very efficient at filtering. I can't do nearly as well in the Kiwi code and I didn't want to impose a penalty on everyone since there is currently one default blacklist rule on every single Kiwi.

    But when the proxy is in use from the Kiwi's perspective all the connection attempts appear to be coming from the single proxy ip (by definition). The reason you still see the actual user's ip in the log messages is that there is an extra step to uncover the true ip address when the proxy is in use. But this step is not visible to iptables. So for the proxy case I'm going to have to find an efficient way to filter in the Kiwi code..
    n6gn
  • jksjks
    Okay, today's v1.336 release now applies the ip blacklist to incoming connections made via the proxy. Because the filtering in done in the Kiwi server instead of iptables a Kiwi log entry is made when the blacklist filter hits. iptables is still used for non-proxy connections for performance reasons.

    The "ipt" shell alias now automatically includes the "-v" argument so you can see the packet counter for the iptable filtering rules. I.e. an incrementing packet count means the blacklist filter has been hit. Use "iptz" or "iptc" to clear the counters. These aliases can be used on the admin page console tab.
    PowernumptyG0LUJVR2BG
  • jksjks
    I tested the inactivity and 24hr timeouts very carefully using a proxied Kiwi. It worked correctly -- same as with a non-proxied setup.

    The best confirmation to see that the timeout are in effect and counting down is to look at the "user" tab of the control panel (for regular connections) or on the "status" tab of the admin page. If there is a timeout in effect the remaining time will appear in orange at the end of the user information for each channel. A timeout will not occur precisely when the countdown hits zero. There can be a delay of 10 to 20 seconds before the connection is actually kicked.

    To see if timeouts have been suppressed because a correct exemption password is in effect look in the admin log tab for a message like: 
    Sun Oct 27 02:14:38 00:07:56.683 0... 0      TLIMIT exempt password from 118.148.233.160
    You will see other messages for other time limit conditions: 
    Sun Oct 27 02:06:51 00:00:10.135 0... 0      TLIMIT-IP connecting LIMIT OKAY cur:0 < lim:1 for 118.148.233.160
Sun Oct 27 02:14:04 00:07:22.908 0... 0      TLIMIT-IP connected LIMIT REACHED cur:1 >= lim:1 for 118.148.233.160
Sun Oct 27 02:06:55 00:00:14.093 0... [02]   TLIMIT exempt local connection from 192.168.1.2
    These messages only appear on the admin page log tab. They are not logged to the Linux syslog to help prevent dead Tesla syndrome.
  • VR2BGVR2BG
    Sorry for belated follow through - been a bit distracted here as of late. Working FB now that I can ?? my abuser.... cheers, mate.

    73, VR2BG.
Sign In or Register to comment.