mirror of https://github.com/jrbrtsn/ban2fail
Change README to reflect current practice
This commit is contained in:
parent
dd8c9cbfa8
commit
6964958f13
11
README.md
11
README.md
|
@ -9,9 +9,10 @@ iptables filtering. As the name implies, *ban2fail* was inspired by the popular
|
|||
*ban2fail* started with a few hours of frenzied C hacking after my mail server
|
||||
was exploited to deliver spam for others who had cracked a user's SMTP send
|
||||
password. After inspecting the log files I realized that crackers are now using
|
||||
widely distributed attacks, and that I would need an app that could run several
|
||||
times a minute on my rather modest Linode virtual server to have a chance of
|
||||
stopping them. Here are the timing results for a typical scan on my wimpy server:
|
||||
widely distributed attacks, and that I would need an extremely efficient tool
|
||||
that could run in a fraction of a second on my rather modest Linode virtual
|
||||
server to have a chance of stopping them. Here are the timing results for a
|
||||
typical scan on my wimpy server:
|
||||
|
||||
```
|
||||
real 0m0.269s
|
||||
|
@ -19,7 +20,9 @@ user 0m0.108s
|
|||
sys 0m0.134s
|
||||
```
|
||||
|
||||
Currently I am running *fail2ban* every 5 seconds. I hope you find this code useful.
|
||||
Currently I am running *ban2fail* from a *systemd* service file which triggers
|
||||
*ban2fail* whenever a watched log file is modified. This gives attackers at
|
||||
most a 0.4 second window to do their worst. I hope you find this code useful.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
Loading…
Reference in New Issue