Ok. So, I'm making a program to act as a TCP Server for client verification. Now, the only scenario I have absolutely no idea how to go about handeling is a spam attack.

Now, here's what I mean by "spam attack". Multiple users make rapid connection requests causing several possible problems to arise: Buffer overflows, server lag, etc. I have a few ideas to help this already: A connection request queue, and a check to immediately refuse connections to IP's that are already connected or send multiple requests and ban them.

This however leaves the worst possible scenario: 100 people, each with 20 proxies and one broadband internet connection each send 21 concurrent connection requests and cycle this. Does anyone have any ideas for this? Also, I'm looking for ways for the program to handle it without user interaction so it requires as little manipulation as possible.

[quote author=Dyndrilliac link=topic=11105.msg106408#msg106408 date=1112226467]
A connection request queue, and a check to immediately refuse connections to IP's that are already connected or send multiple requests and ban them.[/quote]

Not an answer to your original question, but given this information, I would get banned if my mom's computer was already online with you and I tried to get online from my computer.  We share the same public IP address.

Well the server is being creating for a purpose that the probability of a single-user needing to be verified on 2 computers on the same connection at the same time is very, very, unlikely. Also, you would be banned regardless as multiple instances of the same verification key would get you, as well, unless you had two different keys.

[quote author=Dyndrilliac link=topic=11105.msg106414#msg106414 date=1112227253]
Well the server is being creating for a purpose that the probability of a single-user needing to be verified on 2 computers on the same connection at the same time is very, very, unlikely. Also, you would be banned regardless as multiple instances of the same verification key would get you, as well, unless you had two different keys.
[/quote]

Well -- so what if two people in a large company want to use your program (or whatever) from work?

In general I think it's a bad idea to auto-ban connections from the same IP.  It could easily be entirely different people - the entire Maricopa County internet from which our library gets online has one public IP address.  The entire Town of Gilbert internet from which I chat here has one public IP address.  Both are very wide-area networks and can encompass thousands of people.

That situation is extremely unlikely. Let me tell you why.

The server application I'm creating is to verify legitimate, payed for copies of a game hack. Therefore, each person using it will have their own key, and most probably their own IP, and not be on two different computers using the hack at the same time on the same IP. The only situation I foresee a possible problem is if two people in the same household each buy a copy and use the same connection.

In the case of one service encompassing thousands of people under one IP, well then I'm afraid the risk of server attacks and defrauding the people for which I am writing the server application is too great.

[quote author=Dyndrilliac link=topic=11105.msg106459#msg106459 date=1112237290]
The server application I'm creating is to verify legitimate, payed for copies of a game hack.[/quote]
The company(ies) that produce the game(s) you want to hack will be all over you like a fat kid is cake.

But that point aside...

What VB are you using?  With VB .NET, this would be a very easy-to-scale program.  It would certainly involve multithreading, but that isn't particularly difficult in VB .NET.

I'm somewhat ignorant of the way a socket's Listen (or equivalent) method works in VB6, but generally, if you're on VB .NET, the Listen method accepts a parameter that specifies how many pending incoming connection requests to queue (after which connection requests will be ignored, I believe) -- and you can choose to accept or block methods as they come in.  The standard way to manage these types of incoming connections is through a connection manager object that maintains state for an individual connection, and then to store the connection manager object inside of a collection.

[quote author=MyndFyre link=topic=11105.msg106464#msg106464 date=1112239319]The company(ies) that produce the game(s) you want to hack will be all over you like a fat kid is cake.[/quote]

I'm not producing the gamehack - just the verification system. As soon as I am payed for my work, my employers legal battles are no longer my concern. The only scenario I don't know how to handle is in my first post, everything else is pretty much done as far as release stability is concerned. I am using VB6, and the Listen method does not accept parameters(AFAIK), so I will have to create my own queue and connection manager objects.

Simple, Use GettickCount in the ConnectionRequest() sub, and set it for say .5 seconds, and if there is a connection within .5 seconds of the last one, simply ignore it.
Or what you could do, Is set it up to use UDP, and then simplky ignore large packets(make a packet header specifing length) and the same idea with the GTC()
But anyways, bye.
~-~(HDX)~-~

[quote author=Dyndrilliac link=topic=11105.msg106587#msg106587 date=1112293254]

I'm not producing the gamehack - just the verification system. As soon as I am payed for my work, my employers legal battles are no longer my concern. The only scenario I don't know how to handle is in my first post, everything else is pretty much done as far as release stability is concerned. I am using VB6, and the Listen method does not accept parameters(AFAIK), so I will have to create my own queue and connection manager objects.
[/quote]

Your getting paid to write a server app in VB6?

Yes. However, I don't see how your post is relevant to the topic.

HDX: I don't see how that will serve my purposes, that seems like it would block rapid connection requests, not necessarilly rapid connection requests from a spammer. I need to maximize customers access to the server and minimalize spammers access to the server.

Well then my only suggestions are use UDp, jsut cuz, umm it's fun, And Upon ConnectionRequest() (if your not using UDP) simply do a loop through your active winsocks, checking the RemoteHostIP() and if it's already present close the connection, Then when you revive the Key or w/e simply check if any other connections are using that key. Other then that, jsut use some fail-checks to stop buffer overflows, and as for multiple connections forma spammer, jsut make your program able to withstand atleast 1k every 5 seconds, and youll be fine. (It's easy to do)
~-~(HDX)~-~

UDP has no connection requests, so that event is never fired

Just force them to do login through a product key or auth key of some sort. If the attempts number over 10 or so, just block them from the server for 30 minutes.

I already am forcing them to use an auth key.

My problem is from people lagging the server with tons of connection requests which the server will have to waste time checking to see if they can connect, and if not, refuse the connection. I was just wondering if anyone had any good ideas for that, but I suppose not.

[quote author=Dyndrilliac link=topic=11105.msg106707#msg106707 date=1112358974]
My problem is from people lagging the server with tons of connection requests which the server will have to waste time checking to see if they can connect, and if not, refuse the connection. I was just wondering if anyone had any good ideas for that, but I suppose not.
[/quote]

One possible option would be to move the connection handling code into a high performance C/C++ application. That way you will be handling connections in the same language as the OS, which will obviously be faster. If the actual verification code isn't too big, you could consider moving that over as well.

It really shouldn't lag too much if they can only check for auth and product key.

Well there really isn't a 'best' solution to your problem simply because it's somewhat a contradiction in itself. 

You're trying to offer a service (connection) that is publicly accessible and at the same time trying to prevent certain users from accessing it.  The only way you could really prevent an attack is by disabling the service.  But that unfortunately is usually the goal of those 'certain users'.

As we've seen in the past with Blizzard and even this website, there is no perfect way  to prevent users from flooding a server with requests when given the scenario in your first post you can't identify them uniquely.

But to be more helpful, I recommend you have two obstacles for allowing a valid user though.  The first would be a connection validation to verify he isn't an attacker from a list of IPs.  There are several ways to make this process more efficient (binary searching, hash tables, etc).  Then go through your validation procedure....You shouldn't be allowing everyone a chance to go through your validation procedure.



 

[quote author=Dyndrilliac link=topic=11105.msg106459#msg106459 date=1112237290]legitimate [...] game hack[/quote]PAH!

Well here's how the process is gonna work.

- Client sends connection request to  the server.
- Server requests the Encryption CodeKey for the rest of the transmission's encryption.
- Client replies.
- Server then requests the clients MD5 Hash signature and authorization key for verification.
- Client replies.

Depending on if the information is good, the server sends the client a success or failure message. If the client recieves a failure message, it shuts down.

Owned@modifing hosts file.

[quote author=Dyndrilliac link=topic=11105.msg107032#msg107032 date=1112477004]
Well here's how the process is gonna work.

- Client sends connection request to  the server.
- Server requests the Encryption CodeKey for the rest of the transmission's encryption.
[/quote]

That's gonna be sent using an assymetrical cipher?

I was also wondering what you meant by those two lines Adron is pointing out.

Are you only encrypting one end of the stream or are you using one key to encrypt for both the client and the host (symmetrical).  If you're not using an asymmetrical cipher to send the key over, I don't understand why the encryption would be useful at all to begin with...

Regardless, I still don't see how this would prevent an attacker from 'flooding' the server with verification requests.  Also, if your server asks for a key first, wouldn't you be forcing the server to go through a tedious encryption algorithm only to find out the user was never valid afterwards?

@Rabbit: If the client cannot connect, the client shutsdown.

@Adron: The encryption key is sent using RSA-256.

@Lenny: I never said this solved my problem. That was the point of asking the question in this thread. The encryption's purpose is to keep people from reversing the packet structure, and finding out the correct md5 hash.

[quote author=Dyndrilliac link=topic=11105.msg107154#msg107154 date=1112544051]
@Adron: The encryption key is sent using RSA-256.
[/quote]

RSA is an OK cipher, but shouldn't you be using something a bit stronger than 256-bit?

[quote author=Dyndrilliac link=topic=11105.msg107154#msg107154 date=1112544051]
@Rabbit: If the client cannot connect, the client shutsdown.
[/quote]So?  Somone can write a basic server which follows protocol (sort of) and always returns a positive acceptance, then shuts down.  Modifying the hosts file to point to localhost then running the self-made server fixes the disconnect problems.

Also, to add to what Adron has said, I don't think VB is a good language to implement RSA.

[quote author=Lenny link=topic=11105.msg107172#msg107172 date=1112553184]
Also, to add to what Adron has said, I don't think VB is a good language to implement RSA.
[/quote]

why?  just use cryptoapi stuff

He's using an API to handle his encryption?

Well, that does take care of not having to implement the RSA algorithm which involves a good amount of complicated math.  Most of which is beyond my understanding.

But it is nice to know what RSA does, and it does add a good amount of overhead to a program.

[quote author=Lenny link=topic=11105.msg107313#msg107313 date=1112640145]
Well, that does take care of not having to implement the RSA algorithm which involves a good amount of complicated math.  Most of which is beyond my understanding.

But it is nice to know what RSA does, and it does add a good amount of overhead to a program.
[/quote]

RSA is pretty easy to understand and doesn't require "complicated math," whatever that means. I agree that it's implementation may be difficult though depending on what you have at your disposal (e.g. an arbitrary integer library).

Well the algorithm is fairly simple, but why the algorithm is so secure is beyond me.  Knowing how relative primes, phi's, euler algorithms work is not a problem, but why they were used is completely different.

Notice I said 'what RSA does', not how or why it works.

Perhaps I should restate my earlier post, let's replace 'complicated' with monotonous...

[quote author=Lenny link=topic=11105.msg107332#msg107332 date=1112648408]
Well the algorithm is fairly simple, but why the algorithm is so secure is beyond me.  Knowing how relative primes, phi's, euler algorithms work is not a problem, but why they were used is completely different.

Notice I said 'what RSA does', not how or why it works.

Perhaps I should restate my earlier post, let's replace 'complicated' with monotonous...
[/quote]

It's secure because it's hard to factor large integers, atleast when the integer is a product of 2 very-large primes. Your second sentence makes no sense, what is the difference?

That's a general statement for any encryption or authentication scheme that utilizes prime numbers.  That's simply the reason why prime numbers are used, not how or why RSA goes through the number theorems for its key generation.

Knowing what RSA DOES is simply knowing what the algorithm goes through to encrypt and generate keys.  Knowing HOW or WHY it's effective is knowing why it uses such algorithms (Fermat numbers, congruent modulo, etc)...

To give a more concrete example, a majority of us know what gravity does, but why does it occur?