And sure, a lot of admins won't have the level of access to the OS required to secure things, however if the server gets hacked, then instead of looking at the admin, I'd look at the host instead - it's their job to secure their machines, after all.
We came up with this idea, I might as well say it. We have a software now that tunnels the attacks through tor. Which means unlimited IP addresses and theoretically unbannable.
We came up with this idea, I might as well say it. We have a software now that tunnels the attacks through tor. Which means unlimited IP addresses and theoretically unbannable.
Unless the person you're trying that against is running some software which will detect anything looking like a tor exit node; there are ways to find out if the IP where a connection originates from is running tor or not...
Then again, the idea behind being "secure" is that it's impossible to be secure. Theoretically speaking some random guy can walk up to you, put a gun to your head, and get any kind of access he wants. It's all about setting the bar high enough where the script kiddies and bored 13 year olds have to put too much effort into it and will go looking for softer targets.
Personally I really don't see the point behind griefing, in the sense that it's going to take all of 3 minuets to undo what was done, and life goes on as usual.
Looking for a friendly community? Look no further, and join the BlockStackers! We run a Vanilla whitelisted server, a Feed The Beast server, and a Survival server with some twists.
Unless the person you're trying that against is running some software which will detect anything looking like a tor exit node; there are ways to find out if the IP where a connection originates from is running tor or not...
Then again, the idea behind being "secure" is that it's impossible to be secure. Theoretically speaking some random guy can walk up to you, put a gun to your head, and get any kind of access he wants. It's all about setting the bar high enough where the script kiddies and bored 13 year olds have to put too much effort into it and will go looking for softer targets.
As far as the console is confirmed. The IP address isn't mine. If anything, we can recode the program so that it runs through tor multiple times. It is a spambot for cracked servers. It logs in and logs out at mach speed (spamming login/logout messages.) When the ip is banned, it will switch and run the process over and over again.
As far as the console is confirmed. The IP address isn't mine. If anything, we can recode the program so that it runs through tor multiple times. It is a spambot for cracked servers. It logs in and logs out at mach speed (spamming login/logout messages.) When the ip is banned, it will switch and run the process over and over again.
Okay I thought you were talking about proxying your connection to grief on a server For the login/logout it goes back to that earlier statement of mine where I said it's basically the software's fault it lets itself get abused in that manner. The problem is that the client hasn't got much work to do for authentication and logging in, and the server does. It should, usually, be the other way around to prevent this kind of thing in the first place (e.g. if you have to spend a second or two generating the auth key for example, doing this kind of flooding is no longer going to be "effective").
There's also the whole detection of this process, where regardless of the IP messages originate from, if the rate of logins/logouts exceeds a certain value, the server should start adding a delay to responses or accepting a connection, or start flat out rejecting them. Sure, the server is still "down", but in a more recoverable state.
But now we're getting into a whole different story altogether which maybe deserves it's own thread
Rollback Post to RevisionRollBack
Looking for a friendly community? Look no further, and join the BlockStackers! We run a Vanilla whitelisted server, a Feed The Beast server, and a Survival server with some twists.
So far, this time of proxy-flooding hasn't been implemented. When the software is complete, only my friends and I will use it. Bukkit will probably not patch it with only a handful of incidents of its usage. It is in the incorrect thread, though. Add your replies to my anti-hacking thread as that is more relevant.
So far, this time of proxy-flooding hasn't been implemented. When the software is complete, only my friends and I will use it. Bukkit will probably not patch it with only a handful of incidents of its usage. It is in the incorrect thread, though. Add your replies to my anti-hacking thread as that is more relevant.
Sounds like PWN4G3, which is old news. Very old news. IIRC it used to support exactly that, but an update broke it, and I have no clue if the dev readded the feature.
(by the way, those types of flood/spam bots are EXTREMELY easy to block)
“Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” — Albert Einstein
"Never try to teach a pig to sing; it wastes your time and it annoys the pig." — Robert Heinlein
Sounds like PWN4G3, which is old news. Very old news. IIRC it used to support exactly that, but an update broke it, and I have no clue if the dev readded the feature.
(by the way, those types of flood/spam bots are EXTREMELY easy to block)
I don't understand how you can block a limitless supply of proxies? When one IP is banned, there are still 1000s more in the tor network it can switch to. The only thing I could see happening is a login timer. With thousands of login attempts being ran from the attack server(s), It would still be an effective DoS if not flood.
I don't understand how you can block a limitless supply of proxies? When one IP is banned, there are still 1000s more in the tor network it can switch to. The only thing I could see happening is a login timer. With thousands of login attempts being ran from the attack server(s), It would still be an effective DoS if not flood.
MCBans and several other plugins have _very_ effective methods of detecting and getting rid of any bots like this, usually via some exceedingly clever throttling methods.
Automated bots could be thwarted by something as simple as requiring players to type in a password when they log in, and getting kicked if they don't do it within a few seconds.
“Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.” — Albert Einstein
"Never try to teach a pig to sing; it wastes your time and it annoys the pig." — Robert Heinlein
We came up with this idea, I might as well say it. We have a software now that tunnels the attacks through tor. Which means unlimited IP addresses and theoretically unbannable.
-Eleven
Unless the person you're trying that against is running some software which will detect anything looking like a tor exit node; there are ways to find out if the IP where a connection originates from is running tor or not...
Then again, the idea behind being "secure" is that it's impossible to be secure. Theoretically speaking some random guy can walk up to you, put a gun to your head, and get any kind of access he wants. It's all about setting the bar high enough where the script kiddies and bored 13 year olds have to put too much effort into it and will go looking for softer targets.
Personally I really don't see the point behind griefing, in the sense that it's going to take all of 3 minuets to undo what was done, and life goes on as usual.
Care to elaborate?
As far as the console is confirmed. The IP address isn't mine. If anything, we can recode the program so that it runs through tor multiple times. It is a spambot for cracked servers. It logs in and logs out at mach speed (spamming login/logout messages.) When the ip is banned, it will switch and run the process over and over again.
Okay I thought you were talking about proxying your connection to grief on a server For the login/logout it goes back to that earlier statement of mine where I said it's basically the software's fault it lets itself get abused in that manner. The problem is that the client hasn't got much work to do for authentication and logging in, and the server does. It should, usually, be the other way around to prevent this kind of thing in the first place (e.g. if you have to spend a second or two generating the auth key for example, doing this kind of flooding is no longer going to be "effective").
There's also the whole detection of this process, where regardless of the IP messages originate from, if the rate of logins/logouts exceeds a certain value, the server should start adding a delay to responses or accepting a connection, or start flat out rejecting them. Sure, the server is still "down", but in a more recoverable state.
But now we're getting into a whole different story altogether which maybe deserves it's own thread
Sounds like PWN4G3, which is old news. Very old news. IIRC it used to support exactly that, but an update broke it, and I have no clue if the dev readded the feature.
(by the way, those types of flood/spam bots are EXTREMELY easy to block)
"Never try to teach a pig to sing; it wastes your time and it annoys the pig." — Robert Heinlein
I don't understand how you can block a limitless supply of proxies? When one IP is banned, there are still 1000s more in the tor network it can switch to. The only thing I could see happening is a login timer. With thousands of login attempts being ran from the attack server(s), It would still be an effective DoS if not flood.
MCBans and several other plugins have _very_ effective methods of detecting and getting rid of any bots like this, usually via some exceedingly clever throttling methods.
Automated bots could be thwarted by something as simple as requiring players to type in a password when they log in, and getting kicked if they don't do it within a few seconds.
"Never try to teach a pig to sing; it wastes your time and it annoys the pig." — Robert Heinlein