Limiting repeated access to a webserver resource behind specific TCP port

Q

Quanto

Any Linux firewall (iptables/nftables) experts/admins here?

Can this be done on a Linux server with iptables (or nftables) firewall? :

Say I want to make every 5 minutes an updated version of a web page, but need to prevent the server from uncooperative bad users who endlessly make new connection attempts to get the newest version of the file as quickly as possible, instead of trying it only every 60 seconds or so as instructed on the web page.

Protecting (by time-limiting) access to a specific TCP port on our server, like https://www.example.com:8001/index.html
If remote client makes a new connection attempt before 60 seconds have elapsed since the last connection, then the firewall shall redirect the client to another TCP port (say port 8002; this other port will show a warning explaining the access limit plus showing a link for a retry).

Ie. it's normal REST access to a normal standard webserver, w/o any streaming involved.
And the clients (users) are just normal guest users, w/o any login requirement.

Looking for a firewall solution only, not doing it in the webserver source code files etc.
Has someone an example demonstrating this?
Or can give a link dealing with this problem?
 
Last edited:
Quanto said:
Say I want to make every 5 minutes an updated version of a web page, but need to prevent the server from uncooperative bad users who endlessly make new connection attempts to get the newest version of the file as quickly as possible, instead of trying it only every 60 seconds or so as instructed on the web page.
More...
Forget all that firewall nonsense. I would just use the Meta Refresh html tag so that the page content automatically expires and reloads in the browser every 60 seconds. That way, the refreshing is done automatically and end users don't have to feel like they constantly have to attempt page refreshes to get the latest version.

Code: 
<head>
<meta http-equiv="refresh" content="60">
</head>
 
Baron said:
Forget all that firewall nonsense. I would just use the Meta Refresh html tag so that the page content automatically expires and reloads in the browser every 60 seconds. That way, the refreshing is done automatically and end users don't have to feel like they constantly have to attempt page refreshes to get the latest version.

Code: 
<head>
<meta http-equiv="refresh" content="60">
</head>
More...
Thanks, but this still does not prevent from the said abuse.
I would use this on top of the initial requirement.
 
Quanto said:
Thanks, but this still does not prevent from the said abuse.
I would use this on top of the initial requirement.
More...
Are you really having a problem with users hitting refresh too much, or is this just something you're thinking might happen? A basic web server can handle a ridiculous number of page refreshes before there would ever be a problem. You would need tens of thousands of users simultaneously hitting refresh to even come close to the problem you are talking about.
 
Baron said:
Are you really having a problem with users hitting refresh too much, or is this just something you're thinking might happen? A basic web server can handle a ridiculous number of page refreshes before there would ever be a problem. You would need tens of thousands of users simultaneously hitting refresh to even come close to the problem you are talking about.
More...
You are of course right, but this is just a basic concept that can be easily scaled up.
I want to prevent problems of a slow webserver response due to such "abuse attacks" (DoS attacks).

We surely all have experienced some websites that sometimes are very slow (I recently experienced it several times even with my bank. It was very unpleasant and I just want to do it better).

A little bit different example than in the OP would be, for example, to offer an important commercial subscription service for realtime market analysis data. One surely has to think of such possible problems, and possible complaints from paying clients, since they want it timely; delays caused by DoS attacks have to minimized...

Just planning for taking some precautions...

Btw, with the said "ipset" tool it seems relatively easy to realize such a webserver protection,
and also other such public services on the server.
 
Last edited:
You really want to handle that with a HW firewall appliance. Ie Cisco ASA you can do all that and more via service policies etc… you really want to keep the server just doing server things and have a dedicated firewall handling the security role and dealing with managing NAT and TCP flows etc..

You can get a Cisco 5516 used for less than 150 bucks and they are rock solid. For 200 you can build a failover bundle. It will run 9.16.4 which is solid. Just find someone offering up one with the latest ASDM (management GUI) and ASA 9.16.4 already installed.

https://www.cisco.com/c/en/us/td/do...ts and TCP Intercept,of service (DoS) attacks.
 
You must log in or register to reply here.
Back
Top