 Show Posts
|
|
Pages: [1]
|
Pretty sure ol' Kano has it figured out...  Of course. I've full confidence. I only post when I care and feel I can be additive; I appreciate the work and am happy to be part of the pool |
|
|
|
Firstly, the banning is working fine, and this is the first time I've enabled this extra blocking, that already existed in the code when I first wrote it all, and it's working fine also.
This banning might ban someone, while it's active, who makes a mistake, but I think that's way better than stopping everyone logging in.
... and anyone who gets on by mistake, can always contact me to get off the ban list very quickly.
There's only been about 700 banned IPs, but I did completely block a bunch of large subnets before hand that were all bots.
Most of the previous banning has been either IP subnets that had very large numbers of bots, or simply disabling logins for a short while until they got bored having no effect on anything.
This one has sorta gone on all day, so this solution is the best in this case, in my opinion.
Lastly, most people with more than a few miners, have a different place/places for their miners.
If the banning is happening in your apache script, perhaps you could just ban for a day. If the blocks are happening in your firewall, that also can be done but not as easily since you would have to allow the apache server to have access to the ban list and manually parse through the logs to get the time. Ok, I just read all the previous and see it is in your code and it sounds like you are doing a day. Personally in my code, I allow 3 attempts, then lock for 5 minutes then 15 on the next, then 60 on the next and a day one the next. I have detection for all kinds of hacker things (injection, arrays, etc) and if the server detects those, then the ip is blocked for a day. As with yours, I do most in my code although my servers also have a firewall that blocks on ssh attempts, etc. It seems that it would be good if you had something in place all the time rather than manually turning on and off your systems when threats are detected. I suspect that even you need to sleep once in a while. This is precisely the kind of solution and motivation I meant earlier. It's up to you (Kano) how you want to manage your system as it's your time and property, but the point is not about the code quality but rather the process: As noted you can get careless humans as well as bots. Newbies may also think that UX is a bug. The manual aspect of enabling/disabling plus dealing with individuals is a side effect of that process. Automating this process is an added efficiency that should solve both UX and operational concerns. Of course that means changes to working code, and depending on the code it may not be so straightforward, I get that. Not trying to pile on or argue, but merely suggest - small manual processes add up over time, enough of those compounding take away time from getting real work (or sleep) done. |
|
|
|
Good plan but I do have one suggestion... maybe show a message when you ban them that tells them how to get unbanned - something like wait 24 hours or contact you or something.
This one today has gone on for well over 2 hours so far ... I don't want to be giving them any hints about "best bot practices"  Better yet can you redirect them to an infected site with malware or something?  Heh - no - probably need to redirect them to microsoft defender web page ... They already have a virus  Edit: seems to have trickled down to only one or two bans every minute or so, (instead of every second) so that always-ban change seems to work ok. Of course I wont post when I've set the setting back to normal, but no doubt that will be soon Awesome. It's like an advanced game of whack-a-mole. Actually - it's exactly that  I coded in the event/ovent ban code to KanoDB long ago, but every so often some new bot comes along and I have to think of how I can change the settings in the ban code (i.e. modify the limits via the KanoDB API) to best match the bot. I've ended up mainly relying on the "no logins" switch, but that's a problem when it goes on for a long time and no one can login normally. I think from now on I'll rely on switching on/off the "zero tolerance" ban, since it doesn't affect anyone logging in normally unless they forget their password or can't type their own username Most people don't have the problem, and the few that do can always contact me to check why they were banned and clear their ban if they weren't part of the bot attack Maybe obvious, but exponential backoff in addition to whatever screening you do could probably weed out bots vs humans actually fat-fingering as efficiently without requiring manual switching or locking the fathands out. There's also an nginx module to rate limit by filter if you want to avoid putting it on your backend. People should be using password management systems these days though... edit: ah yea as @dracora suggested, fail2ban++ |
|
|
|
@dstm - Didn't see this reported, apologies if it was. I think I found a small reporting bug with the server and logging info. It's a super edge case but I don't know the implications as it seems to retain application start values. The use case was that the miner started before the power setting init ran, and after the power settings changed (see  ), zm seems to misreport power stats (see  ). This could be corrected after restarting zm (see  ) This system is running on ubuntu desktop 16.04.3, nvidia-smi v384.98, miner version 0.5.4. I can run through the logs too but they show the same info. I realize I should've included the server timestamps for reference, but they're within minutes of each other in the above order. ZM reports averages for power consumption and efficiency - since that's the most accurate way. So it reports correctly the average power consumption of your system. It will converge after some time. Ah, I thought it was sampled live stats rather than averages, that wasn't clear to me. I actually analyzed logs a few days ago and noted the lack of variance for zm, that puts it into perspective ! edit: I also should've paid more attention to the first post's description on logs ^^ |
|
|
|
@dstm - Didn't see this reported, apologies if it was. I think I found a small reporting bug with the server and logging info. It's a super edge case but I don't know the implications as it seems to retain application start values. The use case was that the miner started before the power setting init ran, and after the power settings changed (see ), zm seems to misreport power stats (see ). This could be corrected after restarting zm (see ) This system is running on ubuntu desktop 16.04.3, nvidia-smi v384.98, miner version 0.5.4. I can run through the logs too but they show the same info. I realize I should've included the server timestamps for reference, but they're within minutes of each other in the above order. |
|
|
|
|
