Inactive [SEC/ADMIN] LogOres v0.7 - log ores to look for cheaters - MOVED TO dev.bukkit.org [1.2.5-R4.0]

LogOres now hosted on http://dev.bukkit.org, please go over there for download files, to open enhancement requests or ask for support. Direct link:

http://dev.bukkit.org/server-mods/logores/

 

Thank you for this wonderful plugin.
Been running this for a couple of days on my server, which is a dual core machine, no performance impact noticed.

 

Great, this is exactly what Iv been looking for in found diamond. Im gona test it. I think yours algorithm is based on verry smart idea. One tip. If we could be able to produce some kind of time based stats it could eliminate all false positives. One can triger prehaps few false alarms but Im sure if we get lets say 5 entries in log per one hour one user it wont by just lucky person. Or at least making log pipe delimited values could alow people to do some manual stats by importing this into excel in the meentime.
Would be also nice to have option to not log not flaged entries. Its good for kind of debug or tuning stage only.

 

@Kozzy68 the in-game notifications allow you to set a repeat-count threshold before notifications are sent. I've been thinking of adding this to the [flagged] tag, something like [flagged x2], so that it would be easy to grep/search for your threshold in the logs.

Interesting idea on having it time-based, I will think more on that.

Regarding pipe-delimited for excel, probably wouldn't be hard to add, although I have no use for that feature myself (I prefer grep/awk/Perl). I may add it at some point when I'm in there making other changes.

Last regarding not flagging entries, just set the flag ratio to 0 and nothing will ever be flagged.

------------------

And a general update for everyone else: I check my logs regularly and though I've caught a few cheaters, I see a lot more instances of false positives. Though this was the same w/ FoundDiamonds for me and now it's just automated, I am continually thinking about ways to tune out legitimate mining behavior from cheaters. It's a tricky balance, because if I tune too much, we might end up missing real cheating happening because we've tuned too much.

I don't think it will ever get to the point that it can automatically determine and kick/ban without human intervention, which was never really my intent anyway. It is just supposed to help you sift through the noise and focus on most-probable cases of cheating. However I will continue to think on ways to tune the algorithm to weed out false positives as I see patterns emerge in my own logs that I can then filter out.

 

Thanks for reply and considering my imputs. Btw I like grep and awk also but Im not so geeky to make stats like from db using it . + delimited flat file makes also much smaller log.
Im still wating for that expected 1.7.9 RB to put new plugins on server, so I have not tested plugin properly yet but my gues is that by fine tuned time based stats this has to be 99.9% accturate. Seems like dificult part is to determine lucky person running in a cave and slow xray user. I will try to test it. I think result will show clear diffrence but not sure. (diamond veins found) /(15 mins) should determine it even without distance and ore mined metric I hope.
In this case shorter time frame means higher chance of false alarm but also less chance to capture xray user that is mining only few mins. I think 10-20 should be optimal interval.

 

@morganm Could you please comment on the effect with OnMove. I Heard a lot of horror stories related to it. Thanks!

 

@Kane I have no idea what you're talking about. This plugin does not use the OnMove event at all. The only event it hooks is onBlockBreak.

 

I gave this plugin a test run by xray mining, but it seems to have thought most of my finds to be in variance, more than xray behavior.

What variance settings would you suggest that would be properly sensitive, but not entirely off?

 

@NuclearW variance was designed to weed out false positives from "normal" mining activity. The default value of x=2 and y=3 will weed out normal horizontal strip mining activities. Is it possible someone could just regular strip mine and grab ores within a few blocks distance that weren't actually visible from their tunnel (ie. cheating, but not blatantly so; doing normal strip mines but just grabbing nearby ores)? Yes. If you're worried about this, set both variances to 0. Be warned, however, you'll get a lot of flagging from players who just like to mine a lot.

I assume in your testing, you were trying to fly under the radar as above, but just doing normal strip mining and grabbing ores that were only immediately nearby?

------
One thing I'm noticing is that diamonds are still the best indicator of cheating. Iron ore is plentiful enough that it generates a lot of false positives. I still log Iron Ore because I like having the full picture, but when I look for cheating I focus on diamond ores because they aren't nearly as plentiful, so cheating activities show up much more common on diamonds.

 

In my testing, (and a few more I have done since), I first tried simple xray mining, going from nearest ore cluster of any type to nearest ore cluster, this is where I received most of the variance messages. Mining for diamonds and gold only raised more alarms, though.

I'm considering throwing in lapis and redstone to the picture, as they are popular targets of xray on our server as well, and seeing how it does then.

 

Well, like I said, if your testing proves out that you prefer to be alerted and not have variance checks, just set them to 0. That's why I made them all configurable, so admins can fine-tune the settings to either dial in or out more alerts. On my server, I have some hardcore miners that were tripping alarms quite regularly even though they were just regular horizontal strip mining (no cheats). So for me, the default variance check values weed out most of those alerts and allows me to focus on the more blatant ore hacking that goes on.

But, it's also important to note that even though the entries are flagged [variance], it's all still there in the log so I can grep out a given players name and see all of his/her activity in context. The variance settings just control whether or not it gets the '[flagged]' tag added to it based on the variance settings.

 

Same problem... Server works, but LogOres blocks the onBlockBreak event. (Chatting and so works!)

 

@MiHo thanks for the report. Can you share the Bukkit version you are using and maybe pastebin your plugin list? I find this behavior very bizarre since it runs fine on mine (and others) servers. Also are you getting any errors in the logs?

 

Thanks for plugin, you have fixed the bug. (I'm so stupid, I still don't understand the flagging system.) As I understand I will only see the message if the same entry in log file is flagged?
Would you add the function (can be turned on/only flagged entries/off) like in FindDiamonds that on every loggedOres break it show the message to admins (also who have a permission) with light level. It would be great! And thanks for your plugin!

 

@VADemon if you want it to work like FoundDiamonds where you get notified on every Diamond break: First, I would suggest to only log diamonds (other ores would be very spammy). Then, set ratio very high (50000 or something). This will result in every diamond break being "flagged" and therefore triggering a notify. Then set "flagsBeforeNotify" to 0. This will notify on the very first break.

Personally, that would be way too spammy for me. But if that's how you want to set it up, that's your choice. The config options are there so you can do that if you want.

@MiHo I just reviewed the code and I don't see any way that it could be preventing blocks from being broken unless it is throwing an exception, which I'm not aware of being possible (the code is small and tight, I don't see any exception-worthy lines in it and have never seen an exception on my prod server). If you are getting an exception in the logs, please pastebin it to me so I can look into it further.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Wow, this sounds great. Will be installing this shortly!

 

No, I do not found any exceptions. I've reviewed your code too before installing it (clear coding style by the way) and I can not find a reason for that too. I can only say the fact that my server gets much slower when running the plugin some minutes, and get much faster again when disabling it.

 

@MiHo hmm. Must be something about your environment that you and @embty have that is different from the rest of us that it works fine for. I would find it of great value if you could pastebin the plugins you are running, so if I get any future reports of slowness, I can try to correlate any conflicting plugins.

In addition, knowing a little more about your environment would also help. What Bukkit build? What OS? What java version? Single core or multicore?

Since I'm intentionally punting the bulk of the work onto another thread and utilizing newer threaded capabilities of Java, it's certainly possible there's a bug in a specific version, or with a specific OS, and knowing this information I might be able to design a workaround for those of you who are affected by it.

 

Does this plugin save the the ore information straight to the log file as soon as someone mines? Because there isn't a log file being generated in /plugins/logores/

 

@d00ba it does. Look for the directory with the config.yml in it and you should see logfiles in the same directory. Make sure you have ores configured (default is iron,gold and diamonds) and no exceptions in your server log. Have you changed lany configs from the default? If so feel free to pastebin it here if its still not working for you.

 

I changed the loglightlevel to true in the config, the rest is default. I left it overnight and it seems to be working now. The log file is there, along with tons of information.

So, just to get my head around this, if someone is being flagged over and over again, with a radius sometimes as low as 40, I can safetly conclude that they're cheating?

Take a look at this guy for example: http://pastebin.com/yUxDh2bM
This looks very suspicious to me. (I've removed all the other entries for simplicity.)


Thanks for the awesome plugin btw, very handy.

 

so if this does move to mysql I would like to ask for a normal log file as well or at least a three way toggle (mysql,logfile,both)

 

@d00ba its always worth verifying In-game, you can walk the same path using the locs (and a tool like logblock is handy) to see if the ores would have been discovered via normal mining or not. In general, based just on the flagged entries and the very rapid ore aquisition in a very short time, you most likely have a cheater on your hands.

@mrvertigo27 if/when I do choose to add mysql support and/or alternate log format support (excel), it most certainly will be able to do any combination of them.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

for your awesomeness you have earned

 

Nice plugin so far.
I do have one request though, could you make it move the logfile each few days / as soon as it reached a certain filesize? Right now it's growing and growing and growing. And manually moving it is a) a bit annoying and b) having to shut down the server for this, well.

 

We followed him around while invisible and confirmed he was infact cheating, which shows logores was correct in flagging him xD.

In response to your earlier post: We haven't had any performance issues with this, we're running many many other plugins alongside it aswell.

Thanks again,

d00ba

 

I gotta say, this plugin has been an eye-opener for me. It's actually unbelievable how many players are using the xray mod. It's even more unbelievable how bad the Anti-Xray plugin is at stopping them. It only seems to stop the xray texture packs. Mods on the other hand, are completely unphased by Anti-xray making it practically useless.

 

Code:

2011-07-23 23:46:19 [INFO] [LogOres] version [0.6.3] unloaded
2011-07-23 23:46:19 [SEVERE] java.lang.NullPointerException
2011-07-23 23:46:19 [SEVERE] 	at org.morganm.logores.LogOreLogger.flushWriters(LogOreLogger.java:467)
2011-07-23 23:46:19 [SEVERE] 	at org.morganm.logores.LogOreLogger.run(LogOreLogger.java:442)
2011-07-23 23:46:19 [SEVERE] 	at org.bukkit.craftbukkit.scheduler.CraftWorker.run(CraftWorker.java:34)
2011-07-23 23:46:19 [SEVERE] 	at java.lang.Thread.run(Unknown Source)

Is this anything to be concerned with?

 

Thanks for the report. This means it had a problem flushing the I/O to one of the log file. Not sure if the LogFile got moved, removed, disk was full, error on write, etc. Actually, I notice just beforehand the 'unloaded' message, so it's entirely possible this is just a shutdown bug.

I wouldn't worry too much, worst case you might have lost a few queue'd log entries at the time of shutdown. I'll see if I can reproduce it and fix it so it doesn't give the error and/or lose any log entries on shutdown.

 

Yeah, seems to happen pretty consistently on shutdown. If you need me to test anything, just let me know.

 

Request to have an option to log separate files per player.