Rate limiting websocket messages #12

Open
opened 2024-07-07 16:00:50 +02:00 by awiteb · 9 comments
Owner

Now, the websocket server is not rate limiting the messages. This can be a
problem if a user sends a lot of messages in a short period of time. This can be
used to spam the server and cause a denial of service.

I think about storing the connection ratelimit data in the SocketUserData
struct, and then check if the user has reached the limit before handling its
message.

Now, the websocket server is not rate limiting the messages. This can be a problem if a user sends a lot of messages in a short period of time. This can be used to spam the server and cause a denial of service. I think about storing the connection ratelimit data in the `SocketUserData` struct, and then check if the user has reached the limit before handling its message.
awiteb added the
Kind/Feature
Reviewed
Confirmed
Good First Issue
labels 2024-07-07 16:00:50 +02:00
Author
Owner

@Amjad50, what do you think is better, using limit and period_secs from the ratelimit section in the config file, or creating a new configuration for the websocket rate limit?

@Amjad50, what do you think is better, using `limit` and `period_secs` from the `ratelimit` section in the config file, or creating a new configuration for the websocket rate limit?
Member

it seems fine to use the same config file, since its the server config. why would you want to use a new file specifically for rate limiting?

Also, if this is per connection, maybe its better to include this in the name, like connection_ratelimit.

it seems fine to use the same config file, since its the server config. why would you want to use a new file specifically for rate limiting? Also, if this is per connection, maybe its better to include this in the name, like `connection_ratelimit`.
Member

Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks

Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks
Author
Owner

why would you want to use a new file specifically for rate limiting?

Not new file, new configuration, like you say connection_ratelimit under ratelimit section.

So the new configurations will be

  • connection_limit under ratelimit section
  • connection_period_secs under ratelimit section
> why would you want to use a new file specifically for rate limiting? Not new file, new configuration, like you say `connection_ratelimit` under `ratelimit` section. So the new configurations will be - `connection_limit` under `ratelimit` section - `connection_period_secs` under `ratelimit` section
Author
Owner

Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks

There is an issue for this: #11

> Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks There is an issue for this: https://git.4rs.nl/OxideTalis/oxidetalis/issues/11
Member

So the new configurations will be

  • connection_limit under ratelimit section
  • connection_period_secs under ratelimit section

The current configuration is

[ratelimit]
enable = true
limit = 1500
period_secs = 60

So it would be like this?

[ratelimit]
enable = true
connection_limit = 1500
connection_period_secs = 60

or keep the old fields and add these new ones?

> So the new configurations will be > > - `connection_limit` under `ratelimit` section > - `connection_period_secs` under `ratelimit` section > The current configuration is ```toml [ratelimit] enable = true limit = 1500 period_secs = 60 ``` So it would be like this? ```toml [ratelimit] enable = true connection_limit = 1500 connection_period_secs = 60 ``` or keep the old fields and add these new ones?
Author
Owner

So it would be like this?

[ratelimit]
enable = true
connection_limit = 1500
connection_period_secs = 60

No, it will be:

[ratelimit]
enable = true
# For http requests
limit = 1500
period_secs = 60
# For websocket messages
connection_limit = 1500
connection_period_secs = 60
> So it would be like this? > ```toml > [ratelimit] > enable = true > connection_limit = 1500 > connection_period_secs = 60 > ``` No, it will be: ```toml [ratelimit] enable = true # For http requests limit = 1500 period_secs = 60 # For websocket messages connection_limit = 1500 connection_period_secs = 60 ```
Member

ah, sorry got confused
then, I think we can put them separate, and we can even use the same structure to make it clear which is websocket and which is http, the name connection isn't clear, something like this

[ratelimit.http]
limit = 1500
period_secs = 60

[ratelimit.websocket]
limit = 1500
period_secs = 60
ah, sorry got confused then, I think we can put them separate, and we can even use the same structure to make it clear which is websocket and which is http, the name `connection` isn't clear, something like this ``` [ratelimit.http] limit = 1500 period_secs = 60 [ratelimit.websocket] limit = 1500 period_secs = 60 ```
Author
Owner

and we can even use the same structure to make it clear which is websocket and which is http

I like this, agreed

> and we can even use the same structure to make it clear which is websocket and which is http I like this, agreed
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: OxideTalis/oxidetalis#12
No description provided.