Is there any way to block an IP in order to stop someone from bogging down a system with packets? Situation is this: Client sends a packet with username and password to login server. Login server calls recvfrom() to get the packet. Once it has a packet I want it to send the packet off to a structure that groups all packets according to user (probably a list or a map). Then another process can actually handle the packets while the recieve thread can simply block while waiting for more incoming packets. But if a client decides to send out many connection packets in a short time then my handlers will constantly be eating cycles checking whether the connect request packet is from a client who already has a connect request pending (no simultaneous connections allowed). Not only that but the recvfrom() buffer will constantly be full of useless packets from someone who desires to slow down the system. So, aside from first calling recvfrom() then checking the packet and discarding it as necessary, is there a way to stop offending packets from getting to he client buffers? I thought of implementing a time delay (you send more than 5 requests in under a minute and your client is forced to wait a period before it will allow you to try again. But this won''t stop people from making a custom DOS program to send packets. After the login stage it''s easy because if someone sends too many packets you can just kick them out and they''ll have to deal with the login server all over again. So, how do you stop these kinds of attacks? Thanks, Webby

That is basically what I am doing. But I was wondering if there was some underlying way to have a program simply block certain IP addresses for a while. Like a physicaly firewall that simply wouldn''t let packets from XXX.XXX.XXX to get through to the initial server in the first place.

If not then I don''t suppose it''s a big deal as long as they don''t keep the buffers full thereby stopping connection requests from other clients to be processed. It has to work otherwise there would be no MMOs

Sounds like a good reason to find a book on network security

Thanks,
Webby

I heard somewhere that if you use the UDP protocol, it makes it impossible for someone to bog you down with this kind of attack. But I have no idea if that''s true or not, just suggesting it as something yuo might want to research

That would be sweet as I am developing fully UDP and implementing packet order/received guarantees where necessary (as in the case of login).

Thanks,
Webby

> Is there any way to block an IP in order to stop someone from bogging down a system with packets?

The Internet itself is a wonderful packet stopper, as routers are designed to avoid (minimize at least) network congestion coming from a single input node. Nothing can prevent DoS attacks, but the attacker must have multiple attack points in order to fully overload your machine and thus bypass all the routers going to your machine. I remember reading an article a year ago about a DoS attack on the GameSpy (? or Quake, can''t remember) server. In order to do this, the attacker had to have access to an OC3 or better connection, and more than 100 machines. It was apparently easy for the FBI to find out the computer nodes that were used and then find the exact user. The matter is still in courts now. JoeBlow running a PC with a DSL connection from his Arkensas basement will have a tough time overloading your server... |8-}

Thanks,

It''s incredibly difficult to imagine computers being able to handle that many packets before getting bogged down. You''d swear that it would be much lower with the way people rant about keeping network traffic down to a minimum. I suppose the reason for that is mainly the cost of bandwidth.

Anyway, for now I am doing this.Unix server.
Login server
1) have a process that blocks on recvfrom()
2) When a packet arrives then the process first checks the packet to make sure it contains valid information (either login request, server selection, character selection, etc) and then passes it on to another process that first checks if the packet is a duplicate or if it''s coming from a client that is already logged in (in the case of a connection request). If the packet is deemed acceptible then it is placed onto the packet list behind all other packets that belong to that user and then a packet is returned to the client telling it that it''s request has been received. This way the client will know not to send another packet out (as it would if the first is lost).
3) Another process will deal with strictly handling packets on the list in a FIFO order. I need a way to prioritize these but for now it simply iterates through the list and services the first packet available. Next iteration will service the first packet available for the next user. This third thread will do the checking of the actual packet and will handle processing of it. This will entail querying the database to see if this user/password is valid or not, followed by returning the server select screen to the client and will handle all subsequent messages. This seems like it would be fast enough.
I will almost certainly add more threads to the pool in order to be able to service more than one client at a time but for now this will suffice.

I am making the login part of it with a reliability layer added onto UDP. Client needs to know if the server has recieved the login request in order to not send another after the given time has expired. Likewise, the server will have timeouts in the event that it doesn''t get a response from the client after a certain time. This will stop some of the DoS attacks. Order of packets will be handled by having the processing thread look at the packet. The packets should come in a certain sequence but since they can arrive out of order I will first have it parse the available packets and if the required one isn''t present it will send a notice to the client requesting the particular packet. This would happen if say the character select packet arrives before the server select packet (which really could not happen with this setup).

After all this is said and done, the client will be communicating directly with the world server which will simply read all incoming packets and handle them in an as of yet unspecified manner.

Seem ok so far?
Thanks,
Webby