Is there a problem with mudbytes.net or am I actually banned? I tried going there a couple of times now and I get hit with...

You have been banned from viewing any portion of this board.

If my IP is indeed banned, and it isn't a problem for everyone, could someone post or PM me an email addy so I can email the admin to get my IP unbanned if possible.


Thanks,
KeB

I've brought this up with Davion -- hopefully it'll get worked out soon. I don't have any issues with MB.

Keb! Noo! PM me your IP and I'll fix it up for ya .

Sorry to hear that, it works fine for me.

The contact info just says to PM Samson; Davion; Asylumius; Kiasyn. No email info. I suppose you could just wait for Samson to read this or contact him through here easier.


Edit: Or, what they said above. lol, gotta love posting at the same time.

Alrighty, PM'ed Davion with my IP. Thanks for the quick repiles guys.

Peace

Problem was indeed resolved.

Thanks,
KeB

Ah, got caught in the crossfire I guess. Some dufus decided to flood the code comments area with inane garbage so I blocked their IP range last night. Guess you must be using the same ISP since those range bans are usually fairly specific to a certain ISP's allotment.

I've run into that before myself from trying to block spammers at my firewall only to find that I'd inadvertently also blocked a player from my mud or forums or some such too. It's too bad all the spammers and jerks and such can't be auto-relegated to some specific IP range that no one else uses so we could just block that range and never have to worry about it again.

Would be nice, but so far this is the first time range banning has ever snared a legit user along with the intended target. It may be a bit of a wide net to cast but when you're dealing with jerks who will disconnect their IP and reconnect just to evade a specific IP ban what else are you supposed to do?

Well, it's the first time we know about, at least...

Samson said:

Would be nice, but so far this is the first time range banning has ever snared a legit user along with the intended target. It may be a bit of a wide net to cast but when you're dealing with jerks who will disconnect their IP and reconnect just to evade a specific IP ban what else are you supposed to do?

Redesign the internet to require valid ssh keys as part of the tcp/ip negotiation process, so you can choose to only accept connections from registered users?

We might be a tad late on that otherwise most useful bit of input Quixadhal.

We can already choose to only accept stuff from users who registered for the site. The problem isn't in restricting to users who registered, it's in restricting the set of people who can register...

Actually, we can't choose only accept connections from registered users currently, David, that would require a means to establish their identity prior to logon as Quixadhal suggested.

Hmm, I thought we were talking about just preventing people from using a site, not outright blocking connections. (I'm also not sure what the functional difference is, unless we're talking about DOS attacks.)

But, well, don't forget that there's not much difference between doing the negotation as part of the connection, and immediately following it, especially given TCP's heavy implementation costs to begin with.

Nah, we were talking about blocking IP ranges at the firewall, David, not just their accounts once they've logged into the forums. Functionally, the difference is whether they have to connect and then log in before being dropped versus never even reaching the actual forums which has the potential to block the wrong people when the range in question covers more than just the offender.

Most forum software can't do that negotiation as part of the connection so the result is having to go through the firewall where, if negotiation was more defined to individual users rather than just IP addresses/blocks it'd be far more useful.

Conner said:

Functionally, the difference is whether they have to connect and then log in before being dropped versus never even reaching the actual forums which has the potential to block the wrong people when the range in question covers more than just the offender.

I'm not sure how one method will block offenders whereas the other won't. If you only accept registered users, then either you accept them at the firewall level or the forum level; vice-versa for refusing them. If the range is applied at the firewall, it'll block just as many people as if the range were applied at the forum.

Basically if your criterion is matching IPs, you can do that equally well at the firewall as at the forum.
And if the criterion is matching against a known username/password (an SSH key is just another form of password after all) then the forum software is already doing that.

So I might be missing something, but I'm not seeing what we'd be able to do with this new thing that we can't already do.

Well the difference between range blocking them at the form and range blocking them at the firewall is that at the firewall you'd be denying them access to the entire machine and any services currently running on it. That includes things like the Sandbox forum (dead as it may be) and several MUDs running on the box in addition to the actual forum/repository. If all we're trying to do is block someone from abusing the forum, range blocking at the forum is sufficient. If they start abusing the server itself, that's a whole other ball game.

BTW, imposing a range block at the forum doesn't even let someone log in. They lose all access and only get greeted with an empty screen telling them they've been banned. So there's no user authentication involved once things get to that level.

Exactly, the difference would be that as it is, with a range block, we can deny them access regardless of who they are because we're resorting to the IP, but if we had some sort of ssh style authentication, we could determine who they were without letting them get into the system at all.

A range ban at the firewall won't let them into the system at all. SSH would require they have access to the SSH server at the very least, as you need to be able to reach the system before SSH negotiation can even take place.