The Aspire app needs to be setup to mitigate DDOS attacks and other similar issues related to findings Jira vulnerability issue.
Quick and straightforward solution can be done by Nginx server, which is setup as proxy server to Aspire.
Prerequisite:
Install Nginx server
Install Aspire 5
Aspire should be not available out site directly but always using Nginx or similar technology (Apache, AWS WAF ...).
Nginx will be setup as proxy server with https certificates, request limit and other necessary security.
Internally Aspire 5 with cooperation with internals apps can be connected directly (localhost:50505).
We will avoid with this approach to have some limitations between internal applications.
You can limit the rate at which NGINX accept incoming requests to a value typical for real users. For example, you might decide that a real user accessing a login page can only make a request every 1 second.
You can configure NGINX to allow a single client IP address to attempt POST requests to API endpoints only every 1 second (equivalent to 60 requests per minute):
To enable POST requests limitations open nginx.conf and put:
http { # Maps ip address to $limit variable if request is of type POST map $request_method $limit { default ""; POST $binary_remote_addr; } # Creates 10mb zone in memory for storing binary ips and limit requests to 60 per minute. limit_req_zone $limit zone=one:10m rate=60r/m; ... server { ... location / { ... #limit post request 60 requests per minutes limit_req zone=one; } }
You can limit the number of connections that can be opened by a single client IP address, again to a value appropriate for real users. For example, you can allow each client IP address to open no more than 10 connections to the ASPIRE 5 area:
server { # ... location / { limit_conn addr 10; # ... } }
More can be foundnd directly in Nginx documentation .
To configuring HTTPS connection needs to be prepared ssl certifications for current domain or IP, here is example only for localhost.
server { listen 443 ssl; server_name localhost; keepalive_timeout 70; ssl_certificate certs/localhost.crt; ssl_certificate_key certs/localhost.rsa; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_session_cache shared:SSL:1m; ssl_session_timeout 5 ... }
More can be found directly in Nginx documentation.
First Line of Defense: Blocking Bad POST Requests Using NGINX Rate Limiting.
The three most important AWS WAF rate-based rules