i totally forgot about this one, and I even wrote a reply to it, man I AM getting old an confused
thanks for the reply blastbeat,
And to tell you the truth I do not know how much work it would take to create the things I wrote about, but when it comes to hub hosting and protecting a hub from floods and other attacks I think that there are a few things that
the hub should deliver.
Today in most hubsofts we have two options, either we restrict, and this means that we make our hub more robust against attacks but less responsive to users, or we dont restrict and let the hub & computer handle it as best it can during an attack.
What I would like to see is a hub that is normally not very restricted at all, and that automatically adjust its restrictions if/when it detects something that looks like an attack.
I think you can agree that this would be a good thing?
As you and Toast both pointed out, some of todays methods is not very effective to protect the hub. My idea was that instead of looking at the message, or the ip, I think its better to keep stats on some of the relevant data and use that to modify the hubsoft settings (how and which parameters to monitor is ofcorse another matter, I am by no means an expert on hub/client communication protocol but I do know my way around statistics).
I realize it takes some time before the stats are useful, during hub start they can of course not be trusted, and if I have a large hub and I restart the hubsoft it can take many minutes before all users have reconnected again. But I dont see that as a reason why my idea should not work. I do not mean it as a hubs
only defence against attachs, but as an automated way of letting the hubsoft adjust the level of protection on a sliding scale. What would be good start values I have no idea (there probably should not be any), but I believe that when the hub has been running for 5 - 10 minutes the stat values should have "settled" and then they could be trusted enough to be used.
I understand what you say but I don't actually see it as something that cant be handled quite effectively in the hub soft. My major concern really is whether it will create a too large overhead in the soft so it is making it into a huge resource hog instead of a nice and smooth hub
Im actually not interested in random, I'm just interested in what is normal for that specific hub, and sporadic peaks dont have to cause a problem if there are a few safe guards in place (so that for example the first to speak in a hub thats been quiet for a day wont get kicked
)
in reply to your points:
0) yes this is a real possibility.
1) It is not possible to know if a connecting user is an attacher or not, but that is hardly the point, what the hubsoft should do is protect the ones already in the hub by slowing down the connection of new users if the rate of new connections is getting too high (for the computer/connection) to handle. Or in case of message floods it should simply drop those and not send them out to all users (only an example of possible methods).
2) This can be handled by different means, and I don't know if anyone is more effective than the other (one way would be to gradually impose a longer time before a user actually can send messages after login).
3) Yes I agree there is a problem here, but the hub server should be able to handle some abuse so if the detection is a little slow is not a major issue, after all there must be an attack before it can be detected
.
It also depends on what kind of settings there are to adjust, lets say that for main chat messages we have the following possibilities:
* global time between each mc message normal this is not limited, when attacked it would be possible to start dropping and only keep 1 per sec - 1 per 2sec - ... etc
* time between each mc message per user same as above but more agressive limiting perhaps
* lenght of message normal is some owner setting, if attacked cut it down to 128 or someting even smaller
* message content normal could be unfiltered, when attached drop everything that looks like it has ip or addys or characters outside the a-z 0-9 range (to make it language protected the hubowner should probably add a list of allowed characters outside that range, like åäö for swedish).
The first three items there could all be adjusted on a sliding scale, all or separate while the last is more of an on/off thing (and I do realize parsing the data is also something that takes resources, but I believe that is already done in the hubsoft so there should not be that much extra processing involved).
4) Yes I think that this is a useful feature, to be able to warn other hubs in a net that something might be up. And yes the simpler the better
5) I did not mean that the hubsoftware should provide interface to lots of different firewalls, I mereley meant that if the scripting part of the hubsoft includes functions that the owner (or another scripter) could use to write those script it would be a good thing.
7) hmm, CAPTCHA-type pattern is an idea, I'll try that and see if users actually understand what to do
. I have seen hubs where the simple +regme causes issues
When it comes to methods of preventing or blocking attacks I am quite sure there are plenty that has already been tried and tested, some of them are probably very good against certain attacks and I see no reason for me to (try to) invent the wheel once more. What I instead would want to have is a hub that I feel I can leave alone in the knowledge it will take care of it self if some dude decides he doesnt like my hub
looks like I like to repeat myself a lot, but as I still think this is a good idea (until proven otherwise) I will not be offended if you all point out the weaknesses of it all.