New samp fail ?
#21

but here it's not a "standard" flood but like a bots/players invisible. Flood incoming = "server is full retrying" I seen it like a exploit samp. To talk to iptables but when there are thousands and thousands ips...and how to detect this flood orther that to update the r2 to r3...
Reply
#22

This is right.
We are the 2nd server in the FR community, we receive several attack of that kind.
The 1st french server is also down because of these stupid attacks.
Thousands of ip are flooding you want some logs ? Alright : http://pastebin.com/0ZW87JJx

143 lines of incoming connections in one second, the older versions of SA:MP didn't have this problem
Don't say we don't use iptables ^^
Our iptables -L is full of CIDR ranges

Please, do something to prevent that exploit, this is annoying for us and our players
Reply
#23

Use iptables and set a rule so all IP's can have a max of 2 connections.
Reply
#24

Each IP address have 1 connection ..
Reply
#25

Quote:
Originally Posted by Nicow
View Post
Each IP address have 1 connection ..
Exactly, is IP spoofing with packets of incoming connection and query, none of the IP repeats, are many falses IP.
Reply
#26

We just have to wait.

When LSRP will receive those type of attack, we will have an update.

I remember few moth ago. our firewall was able to contain all the flood.

Since 0.3z, it isn't able to. So i think it came from SAMP.

Max
Reply
#27

Quote:
Originally Posted by Nicow
View Post
Each IP address have 1 connection ..
So? Unless the server is restarting it is unlikely that this much people connect at once. Put a limit on connections per second GLOBALLY instead of per player (upper limit being 10% of your server slots or so). Block any connection that exceeds this limit for a few minutes, with BlockIPAddress.

Furthermore, it is possible to catch the query packets with iptables string matching.
Reply
#28

The packet are the same that the legitimate players send when they join the server (an ovh tech confirmed it)

And for the connection rate limit :

Quote:
Originally Posted by IvanAyuso
View Post
Exactly, is IP spoofing with packets of incoming connection and query, none of the IP repeats, are many falses IP.
Theses IP are false.
We'll block "fake" ips and we may block legitimate players ips that try to connect
When we're being attacked our players all try to connect, like on a restart because generally the server is empty (people are disconnecting because of spam bot and lags)


Like scott1 said, i think samp needs a fix
Reply
#29

There isn't much SA-MP can do to stop DDoS attacks (attacks coming from multiple IPs).

DDoS isn't blocked at the application level. It has to be blocked at the firewall/router level. This is true for any game server, or any service you run online; including web server, mail server etc.

SA-MP can address DoS attacks (from a single IP/player). Those are the sort of attacks that get fixed in the server updates.

It's possible SA-MP could make certain types of flood attacks more difficult by having several levels of verification. But in that case it just comes down to how determined the attacker is to flood the server. If they have access to a large botnet, it's likely they could disrupt your services without even targeting the SA-MP server port.
Reply
#30

Kalcor, thank you for answering
This is not a DDoS attack, the attacker don't want to crash our server, our server can handle all the incoming requests.
For example our sql server is able to respond the users's requests even if we get attacked because like i said it's not DDoS, the server can handle the packets.

The attacker launch several requests to make our server full, this have to be checked in the application layer.
Reply
#31

Quote:
Originally Posted by Nicow
View Post
Is it possible to release a beta-update or to get this version ?
We could try the update and give you feedback~logs from the attacks to get a R3 (public) release that works.
This (test-)update wouldn't help you. The current R3 test server has nothing to do with this attack, but it will be looked into before release
Reply
#32

Yes you're right, Kye must combine your idea (including the key per IP/Port) and his own.

Quote:
Originally Posted by Kalcor
View Post
I will add a server console variable in the 0.3z R3 server to place a time limit between accepting new connections to the server. For example, 1 second between accepting new connections. This will fend off the attack but I don't recommend servers enable this unless you are under attack because there are cases where lots of players do connect at the exact same time (during restarts etc).
So we can solve the "server full attack" and reduce the memory consumption with the key generation.
Reply
#33

There's no point discussing that. Dealing with spoofed connection packets was solved 20 years ago with TCP SYN cookies. The server can insert a known number in to the packet which the client must return to complete the handshake and gain a full connection.

Although the problem was solved in TCP 20 years ago, it is not solved in RakNet or SA-MP, mainly because nobody has bothered using it as an attack before.

The slot consumption isn't the real issue here. Losing slots during an attack is obviously bad. But the high processing caused by all the packets is knocking existing players out of the game. That is what I'll look to solve initially.
Reply
#34

Quote:
Originally Posted by Kalcor
View Post
There's no point discussing that. Dealing with spoofed connection packets was solved 20 years ago with TCP SYN cookies. The server can insert a known number in to the packet which the client must return to complete the handshake and gain a full connection.

Although the problem was solved in TCP 20 years ago, it is not solved in RakNet or SA-MP, mainly because nobody has bothered using it as an attack before.

The slot consumption isn't the real issue here. Losing slots during an attack is obviously bad. But the high processing caused by all the packets is knocking existing players out of the game. That is what I'll look to solve initially.
That seems reasonable, just do whatever you can to stop this. I believe I've encountered this once, but I may be wrong.
Reply
#35

Quote:
Originally Posted by Kalcor
View Post
There's no point discussing that. Dealing with spoofed connection packets was solved 20 years ago with TCP SYN cookies. The server can insert a known number in to the packet which the client must return to complete the handshake and gain a full connection.

Although the problem was solved in TCP 20 years ago, it is not solved in RakNet or SA-MP, mainly because nobody has bothered using it as an attack before.

The slot consumption isn't the real issue here. Losing slots during an attack is obviously bad. But the high processing caused by all the packets is knocking existing players out of the game. That is what I'll look to solve initially.
Well, it was solved, but as I mentioned, "completing handshake" causes new kind of attack: http://en.wikipedia.org/wiki/SYN_flood

And it could be the issue if it would be implemented in samp.

If I am not wrong, that high processing thing when server is flooded with "incoming connection" packets is caused by protection against "server full attack". Now with ip spoofing attack there is another "server full" exploit and new DoS attack caused by protection against "server full attack"...

Anyway, good luck.
Reply
#36

We can't wait kalcor. What do you don't understand? Some Kids are ruining our work, your in the same time ...

Max
Reply
#37

Quote:

I will add a server console variable in the 0.3z R3 server to place a time limit between accepting new connections to the server. For example, 1 second between accepting new connections. This will fend off the attack but I don't recommend servers enable this unless you are under attack because there are cases where lots of players do connect at the exact same time (during restarts etc).

It is not a solution. Other player will not to join a game while flooding
Reply
#38

They will join as soon as the attack stops, but players already playing there won't be affected
Reply
#39

Quote:
Originally Posted by Nicow
View Post
Could you do it as a rcon command ?
Then we could do something like this :

if we detect flood incoming connections
then SendRconCommand(here the command to set time limit to X)

..after some time when the attack has stopped
then set the time limit to default value
Kalcor can you do it in this way ?


This is not a solution clearly, but it'd help a lot
Reply
#40

Quote:
Originally Posted by Nicow
View Post
Kalcor can you do it in this way ?


This is not a solution clearly, but it'd help a lot
Quote:
Originally Posted by Kalcor
View Post
I will add a server console variable
You can set server console variables in the server console, server.cfg and RCON.
So it will be possible to set this variable with SendRconCommand
Reply


Forum Jump:


Users browsing this thread: 4 Guest(s)