4 ms·

While I agree with most of the points, I think the most important one is: your time is precious. Spending hours setting up things is are really high price to pa

by kuon 3y ago

While I agree with most of the points, I think the most important one is: your time is precious. Spending hours setting up things is are really high price to pay for something that might never be of use.

GuB-42 3y ago
Setting up fail2ban is essentially just "apt install fail2ban", it already comes with sensible defaults. That's on Debian, I think it is the same on most distros. For me, it is less of a hassle than looking at logs flooded with failed connection attempts.
- justsomehnguy 3y ago
  > it already comes with sensible defaults Just two days ago I found out the sensible defaults doesn't include automagically enabling even the basic jails. The machine run for a year (or more) with enabled fail2ban which... did nothing. Not a Debian machine and it's entirely on me, but fail2ban setup is not "just apt install". You need to be at least somewhat familiar with it's lingo and the minimals on working with it.
- zamadatix 3y ago
  Genuine question: Why not just tell the daemon to stop logging failed attempts? I personally have a hard time reconciling local username+password authentication and the need to audit failed attempts in the same use case but that may just be because I haven't run across the right use case.
  - justsomehnguy 3y ago
    If someone would fail to properly code something you can find your basic auth is slow to a crawl or even not responding but you would have no idea what is going on. [0] ie Morris worm
  - GuB-42 3y ago
    The simplest reason is that installing fail2ban is just as easy. Also, I sometimes want to know about failed attempts, mostly for legitimate attempts that failed and shouldn't have. As in: "why couldn't bob connect the the server?", and failed attempts would just show that he used the wrong password, or at least, that it is a password related problem.
- diarrhea 3y ago
  Setup in a containerized environment and with structured logging is a nightmare. Last time I checked structured logging was entirely unsupported. Fail2ban has fallen out of times.
  - dawnofdusk 3y ago
    I'm surprised no one has ported it to some container-friendly runtime. In any case your threat model for container workflow is already 100x more complicated than some one-server blog with an open SSH port, I would give up on fail2ban immediately

by kuon 3y ago

GuB-42 3y ago

Setting up fail2ban is essentially just "apt install fail2ban", it already comes with sensible defaults. That's on Debian, I think it is the same on most distros. For me, it is less of a hassle than looking at logs flooded with failed connection attempts.

justsomehnguy 3y ago
> it already comes with sensible defaults Just two days ago I found out the sensible defaults doesn't include automagically enabling even the basic jails. The machine run for a year (or more) with enabled fail2ban which... did nothing. Not a Debian machine and it's entirely on me, but fail2ban setup is not "just apt install". You need to be at least somewhat familiar with it's lingo and the minimals on working with it.
zamadatix 3y ago
Genuine question: Why not just tell the daemon to stop logging failed attempts? I personally have a hard time reconciling local username+password authentication and the need to audit failed attempts in the same use case but that may just be because I haven't run across the right use case.
- justsomehnguy 3y ago
  If someone would fail to properly code something you can find your basic auth is slow to a crawl or even not responding but you would have no idea what is going on. [0] ie Morris worm
- GuB-42 3y ago
  The simplest reason is that installing fail2ban is just as easy. Also, I sometimes want to know about failed attempts, mostly for legitimate attempts that failed and shouldn't have. As in: "why couldn't bob connect the the server?", and failed attempts would just show that he used the wrong password, or at least, that it is a password related problem.
diarrhea 3y ago
Setup in a containerized environment and with structured logging is a nightmare. Last time I checked structured logging was entirely unsupported. Fail2ban has fallen out of times.
- dawnofdusk 3y ago
  I'm surprised no one has ported it to some container-friendly runtime. In any case your threat model for container workflow is already 100x more complicated than some one-server blog with an open SSH port, I would give up on fail2ban immediately