Answer the question
In order to leave comments, you need to log in
How to create a "smart" firewall for a server?
Everyone knows that filtering packets by ip is outdated, since ips are constantly changing and you need to at least replenish the database of these ips, and some may even be deleted. And how else can you protect the site and the server on which it is located from bots and hacking, without using blocking by ip, but by analyzing incoming packets? Is there something in the requests by which you can recognize that this is a suspicious request and not let this request go to the server at all, so that the site does not even respond to it, as when using iptables? Is this possible and where can I watch this topic?
Answer the question
In order to leave comments, you need to log in
fail2ban from plain
snort, suricata from l7 packet sniffing....
Traditional security methods:
WAF - mod_security for apache/nginx rules e.g. from Comodo
fail2ban - tuned to logs from mod_security and other logs (ftp, ssh, etc)
Everyone knows that packet filtering by ip is deprecated
Well, let's say you have a regular http - then you can see the contents of the packages, but how to understand that the package was generated by a bot and not by a real client?
In my opinion, this is not realistic - because it is difficult to distinguish a bot from a real client.
You can try to give a short html with a picture and redirect - if the picture is not loaded then - reject such clients.
Try fail2ban, but you will have to somehow analyze the requests and isolate those that are suspicious from them yourself. Entire companies are specialized in this. It all depends on how smart the bots are. Some just hammer into one url, then you can limit the number of requests from one ip on reverse-proxy, some have the same useragent, you can parse the logs of the same proxy and draw up rules based on this, it happens that bots sort out passwords, there often some 401 is issued to them, you can block everyone who has typed a lot of 401 on one url , there are much more complex attacks and not only http. It is blocked by the same iptables, only better immediately in conjunction with ipset, since with a large number of rules, iptables will start to slow down.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question