Most proxy servers on the internet only proxy a given protocol, for example there are many HTTP proxy servers.
I've never heard of UDP proxies (free ones anyway).
Maybe they just restart their internet connection. Unless you have a static IP from your ISP (usually costs extra) you will get a different IP every time. There is little you can do about this.
Remember by banning a subnet you can end up banning other users too.
This is a difficult topic, as I'm sure you are aware. I know of no game that can ban a specific player, not banning others, without some massive infrastructure (eg steam and steamids). Even these are not infallible (players can steal others login information).
I'm confused though. You are a server admin, but are you a developer of the program? If not, how would you plan on adding to the game, does it support plugins to its networking subsystem?
IP ranges
Author
I am a programmer with the company. I was brought on to help with game modes and some other stuff. However we have a list of must fixes to do first. I am trying to help out on the list.
We are fully aware of the problem with banning a range but we figured most of the addies would be proxy addies and not real addresses.
We are fully aware of the problem with banning a range but we figured most of the addies would be proxy addies and not real addresses.
The reason we are confused (and not being as helpful as we would like to be) is that it seems you are confused.
If you have a program that correctly bans an entire subnet given a line int he config file like "ban 24.67" (which I assume means the same thing as ban 24.67.x.x with subnet mask 255.255.0.0) than we (the people who don't have access to the program you are working on) cannot tell you how you would invoke the same exact feature from the console that is being invoked from the config file at load time.
I assume you currently support the user types something like "ban 24.67.1.34" at the console and just want to improve your console feature.
I recommed you add a console feature called something like "banall" and let them type 2 arguments, an ip and a mask ... like "banall 24.67.0.0 255.255.0.0" and offer an overload (if you can) that defaults the final subnet mask to 255.255.255.0 (because this is the most common subnet mask for routers and such to be able to use). Realize that banning 24.67.0.0 or 24.67.1.34 or whatever is exactly the same because the subnet mask is simply saying ban all that match these first set of bits. (in this case the first 16 bits).
If you have a program that correctly bans an entire subnet given a line int he config file like "ban 24.67" (which I assume means the same thing as ban 24.67.x.x with subnet mask 255.255.0.0) than we (the people who don't have access to the program you are working on) cannot tell you how you would invoke the same exact feature from the console that is being invoked from the config file at load time.
I assume you currently support the user types something like "ban 24.67.1.34" at the console and just want to improve your console feature.
I recommed you add a console feature called something like "banall" and let them type 2 arguments, an ip and a mask ... like "banall 24.67.0.0 255.255.0.0" and offer an overload (if you can) that defaults the final subnet mask to 255.255.255.0 (because this is the most common subnet mask for routers and such to be able to use). Realize that banning 24.67.0.0 or 24.67.1.34 or whatever is exactly the same because the subnet mask is simply saying ban all that match these first set of bits. (in this case the first 16 bits).
I still fail to see the exact problem
Is it finding the actual part in code where to insert the ban condition?
Is it parsing the console string to determine whether it's single or range ban?
Is it the UDP related socket API?
Is it understanding what IP addresses represent and how they relate to netmasks and IP ranges?
Or what?
Banning is done by discarding the packets that match certain filter. As someone who labels themself as a programmer you should be able to find where packets are received in the code and find a way to discard the packets, especially since this functionality is already in the game.
But keep in mind that there's plenty of other issues with IP banning, and that IP range bans are extremly risky, and for most part unacceptable for any serious server provider. You'll quickly ban whole ISP ranges, and prevent perfecly legit users from loging in. There's also the NAT issue which allows several users to play from same IP.
You'd be much better off by banning accounts. Then you ban the user. IP bans are typicall viable only at network level to counter DoS or other malicious attacks.
Is it finding the actual part in code where to insert the ban condition?
Is it parsing the console string to determine whether it's single or range ban?
Is it the UDP related socket API?
Is it understanding what IP addresses represent and how they relate to netmasks and IP ranges?
Or what?
Banning is done by discarding the packets that match certain filter. As someone who labels themself as a programmer you should be able to find where packets are received in the code and find a way to discard the packets, especially since this functionality is already in the game.
But keep in mind that there's plenty of other issues with IP banning, and that IP range bans are extremly risky, and for most part unacceptable for any serious server provider. You'll quickly ban whole ISP ranges, and prevent perfecly legit users from loging in. There's also the NAT issue which allows several users to play from same IP.
You'd be much better off by banning accounts. Then you ban the user. IP bans are typicall viable only at network level to counter DoS or other malicious attacks.
Author
The overall problem is I can't type in ban 25.36.xxx.xxx and have it ban the entire range.
As far as the .cfg file goes, it isn't suppose to work. It never was intended for it to work. No one knows why it does. It was never looked into. We do not have the orignal programmers any more. Our new main programmer is busy adding a large new function that takes all his time.
I need to add the function so I can type it in the console. A standard ban on one IP works. I can not ban a range from the console. People are using proxy servers or somehow changing their IP to get around the ban. We need to stop this.
We started to ban CD-keys however the new game will be free and not have cd-keys plus it only took a couple of months for a key gen to hit the net. We use gamespy and many people know how to hack their software.
So far talking to all the games server owners and looking into the problem, it was decided to allow an IP range ban. Someone stumled on a way to type in manually into a .cfg file to ban a range. It does not work in console.
My intent was to copy the ban function and change it so you type in
banrange 25.154 and then the program would simply ban 25.154 then iterate 1-255 for the 3rd group and the same for the 4th group. Then it would ban all the addresses. I figured there might be a better way to handle it so I decided to ask here.
As far as the .cfg file goes, it isn't suppose to work. It never was intended for it to work. No one knows why it does. It was never looked into. We do not have the orignal programmers any more. Our new main programmer is busy adding a large new function that takes all his time.
I need to add the function so I can type it in the console. A standard ban on one IP works. I can not ban a range from the console. People are using proxy servers or somehow changing their IP to get around the ban. We need to stop this.
We started to ban CD-keys however the new game will be free and not have cd-keys plus it only took a couple of months for a key gen to hit the net. We use gamespy and many people know how to hack their software.
So far talking to all the games server owners and looking into the problem, it was decided to allow an IP range ban. Someone stumled on a way to type in manually into a .cfg file to ban a range. It does not work in console.
My intent was to copy the ban function and change it so you type in
banrange 25.154 and then the program would simply ban 25.154 then iterate 1-255 for the 3rd group and the same for the 4th group. Then it would ban all the addresses. I figured there might be a better way to handle it so I decided to ask here.
hplus's solution is the one you want.
It sounds like the fact that you can ban ranges from the config file at all is a bug, however welcome.
Unfortunately we cannot help you further without seeing source, which you may be reluctant to do (remember though: the only security you can count on is one that works even if the hacker has the source, like RSA encryption).
How is your ban list organised? How is it represented in memory? Obviously the in-memory version is capable of supporting range based bans, its just a mater of finding why your console command acts differently to your config file. Look at the parser for the config files and compare it to the command line parser and see if they differ.
It sounds like the fact that you can ban ranges from the config file at all is a bug, however welcome.
Unfortunately we cannot help you further without seeing source, which you may be reluctant to do (remember though: the only security you can count on is one that works even if the hacker has the source, like RSA encryption).
How is your ban list organised? How is it represented in memory? Obviously the in-memory version is capable of supporting range based bans, its just a mater of finding why your console command acts differently to your config file. Look at the parser for the config files and compare it to the command line parser and see if they differ.
Author
Yes I think I will go with his solution.
Here is some more detail. Sorry I can't post code do to my NDA I had to sign to join the company. I know it is a pain most of my Q's go unanswered.
I obtain the Ip addy with a command. I type ban Ip addy. Then it will check to see if it is in address form. No letters, set of 4 groups with numbers 1-254. I believe this is part of my problem as I can not shorten the address. After this check, it checks to see if it is already in the ban list. If not it then it does this:
ban_list.push_back(address);
Next it goes to server_process.cfg file to store the addy.
There are 2 .cfg files: server.cfg and server_process.cfg
The server.cfg is the default .cfg file to load when the server is started or reboots. This is where people can define the ban range. There is no check the server assumes it is legit and it is already entered into the ban_list. Banning from the console bans it to server_process.cfg. This file can not be edited. After the server reboots this file clears out and starts with the server.cfg file. Which in turns causes all the bans, that were typed into the console, to be lost. IF they are not typed into the server.cfg file then after a server reboots then the ban is no longer. This is the next problem I have to tackle.
So here is what is going on.
Player X joins the server screws around gets banned. Changes IP some how and comes back in. After a while they use a script that simply uses the say command to spam the server. Then it crashes the server causing a reboot and clears the ban list and now they can start all over with all their IP addy's. The only way to stop it is have the server owner shut down the server enter the range in the server.cfg file and start the server. When this happens everyone is booted and most people go onto a new server.
I already fixed the spamming issues but the owner of the game wants to ban a range from console.
Here is some more detail. Sorry I can't post code do to my NDA I had to sign to join the company. I know it is a pain most of my Q's go unanswered.
I obtain the Ip addy with a command. I type ban Ip addy. Then it will check to see if it is in address form. No letters, set of 4 groups with numbers 1-254. I believe this is part of my problem as I can not shorten the address. After this check, it checks to see if it is already in the ban list. If not it then it does this:
ban_list.push_back(address);
Next it goes to server_process.cfg file to store the addy.
There are 2 .cfg files: server.cfg and server_process.cfg
The server.cfg is the default .cfg file to load when the server is started or reboots. This is where people can define the ban range. There is no check the server assumes it is legit and it is already entered into the ban_list. Banning from the console bans it to server_process.cfg. This file can not be edited. After the server reboots this file clears out and starts with the server.cfg file. Which in turns causes all the bans, that were typed into the console, to be lost. IF they are not typed into the server.cfg file then after a server reboots then the ban is no longer. This is the next problem I have to tackle.
So here is what is going on.
Player X joins the server screws around gets banned. Changes IP some how and comes back in. After a while they use a script that simply uses the say command to spam the server. Then it crashes the server causing a reboot and clears the ban list and now they can start all over with all their IP addy's. The only way to stop it is have the server owner shut down the server enter the range in the server.cfg file and start the server. When this happens everyone is booted and most people go onto a new server.
I already fixed the spamming issues but the owner of the game wants to ban a range from console.
I'm not going to offer advice on how to fix this (because of the points already pointed out, that it's kind of hard to offer advice without really seeing what's going on). What I'm going to mention is the fact that, banning an entire IP range is a bad idea. 24.* is one of several IP ranges that is most (if not entirely) consumed by cable internet providers. 24 is pretty much half and half Comcast Cable and Charter Communications if I'm not mistaken. Simply by doing blanket bans on 24, 68, 69, 71, 72, and 76 - you would effectively have prevented every one of the millions of Comcast subscribers from doing anything with your game. If the game is going to do any sort of redo that forces an upgrade, I would seriously consider burying something deep and hard to find (that changes everytime the client is updated) that makes a client uniquely identifiable. Maybe a way to create a GUID based on hard drive serial, that becomes part of the games logon packet.
Probably not a suggestion you were looking for but, it'd be something I would consider if I was in the same position.
Probably not a suggestion you were looking for but, it'd be something I would consider if I was in the same position.
Author
Well it isn't my choice to make. I can make the suggestion but that is all. I am fully aware of banning IP ranges. However we discovered that the ranges we banned seem to belong to proxy server companies. We have no problem doing this type of ban. We are only going to ban the last 2 groups of numbers. These seem to be the only ones that change. So 69.65.xxx.xxx would be banned but 69.66.xxx.xxx would not be. This ban would be controlled by the server admins and you could simply join another server if you were banned on one.
We did just add an auto update feature to the game. It will force downloads to keep everything insync.
We did just add an auto update feature to the game. It will force downloads to keep everything insync.
Pardon the question, but for how long have you been a software developer? It seems to me that the main thing you lack is not necessarily IP knowledge, or even string parsing knowledge, but basic software diagnostics and design knowledge. It's important to know how to go about finding the answers when you don't already have them, and "posting on gamedev.net" isn't at the top of that list :-)
It sounds like you would do well to put a breakpoint in the configuration parsing routine, track down the part where the IP range is banned, and check what the parser is doing. Then put a breakpoint in the console banning routine, check what that is doing, and compare. It may be that you need to first breakpoint on the parsing part, and then separately breakpoint on the testing part, to get the whole picture.
Once you understand how the system works, you should then be equipped to add the features that you want, such as suggested above. Do not attempt to add features to a system you do not yet understand; that way you'll just create more bugs. Yes, this will take time and effort -- that's why they call it "work" and have to pay you to do it :-)
Quote:It never was intended for it to work. No one knows why it does. It was never looked into.
It sounds like you would do well to put a breakpoint in the configuration parsing routine, track down the part where the IP range is banned, and check what the parser is doing. Then put a breakpoint in the console banning routine, check what that is doing, and compare. It may be that you need to first breakpoint on the parsing part, and then separately breakpoint on the testing part, to get the whole picture.
Once you understand how the system works, you should then be equipped to add the features that you want, such as suggested above. Do not attempt to add features to a system you do not yet understand; that way you'll just create more bugs. Yes, this will take time and effort -- that's why they call it "work" and have to pay you to do it :-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
