| 1 |
On 2/5/21 6:57 AM, William Kenworthy wrote: |
| 2 |
> Use fail2ban to target active abusers using your logs. (recommended) |
| 3 |
|
| 4 |
I've had extremely good luck using Fail2Ban in a distributed |
| 5 |
configuration* such that when one of my servers bans an IP, my other |
| 6 |
servers also (almost) immediately ban the same IP. |
| 7 |
|
| 8 |
*I'm using Fail2Ban's (null / reject) "route" option. I have BGP |
| 9 |
sessions between my servers synchronizing the banned routes. |
| 10 |
|
| 11 |
> Leverage the cloud with something like: |
| 12 |
> http://iplists.firehol.org/?ipset=firehol_level1 (loaded to shorewall |
| 13 |
> with ipset:hash) to preemptively ban via blacklists - recommended. |
| 14 |
> There are many good blacklists out there - this one is a meta-list |
| 15 |
> and has fast and responsive updates. |
| 16 |
|
| 17 |
That's an option. |
| 18 |
|
| 19 |
I personally have some trouble swallowing the pill that is other |
| 20 |
people's ban lists. -- It's one thing with adding to a spam score. |
| 21 |
It's another when IPs are out and out blocked. |
| 22 |
|
| 23 |
Aside: Make use of Fail2Ban's ignore feature to white list (or ignore |
| 24 |
problems from) known good IPs. |
| 25 |
|
| 26 |
> Snort (in IDS mode triggering a fail2ban rule) is a bit heavier |
| 27 |
> resource-wise but quite useful. Snort in IPS mode is better, but it |
| 28 |
> can impact throughput. (if you are commercial, consider a licence to |
| 29 |
> get the latest rules as soon as they are created/needed.) |
| 30 |
|
| 31 |
Another option in the same vein is to use the IPTables variants of the |
| 32 |
Snort rules. |
| 33 |
|
| 34 |
|
| 35 |
|
| 36 |
-- |
| 37 |
Grant. . . . |
| 38 |
unix || die |
Archives