TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Fail2ban Sucks (2020)

98 点作者 ementally超过 1 年前

39 条评论

macNchz超过 1 年前
&gt; what i&#x27;m saying is, if you&#x27;re fucked, you&#x27;re fucked. fail2ban will not help<p>I see this attitude frequently in online discussions around {security thing}, but it really doesn&#x27;t match my understanding of reality. It&#x27;s not about making any one part of the system perfectly secure, but instead about having all of the pieces of it contribute to a whole. Many real-life stories of caught&#x2F;thwarted attacks include the threat actor successfully breaching&#x2F;moving through multiple layers of a system but ultimately getting stuck on something relatively simple. Defense in depth is not just a catchphrase.<p>In evaluating whether something like this is genuinely useful, it can make sense to look at how difficult it is to operate, and how much it might reduce the probability of a successful attack. In my experience, fail2ban has been extremely easy to install and operate, and I think it brings at least some meaningful impact (particularly if applied to other things than SSH). At the very least it can cause someone making a focused attack to have work more slowly and take alternative approaches–&quot;noisy&quot; behavior that may itself trigger an alarm and get a human involved.
评论 #38836838 未加载
评论 #38836621 未加载
评论 #38840592 未加载
klaushardt超过 1 年前
* changing your SSH port means that you&#x27;ll have to do a bunch of fuckery to get basic functionality working. you will very likely waste hours of your life. you will have to google &quot;rsync ssh non standard port&quot; every time you want to use rsync. you will have to remember scp flags. this is also bad. probably worse.<p>---<p>I dont need to remember non standard ports if i just use my .ssh&#x2F;config.<p><pre><code> Host myhost.tld Hostname 127.0.0.1 Port 333 User MyUser IdentityFile ~&#x2F;.ssh&#x2F;myhost.tld</code></pre>
评论 #38836462 未加载
评论 #38840748 未加载
评论 #38836839 未加载
评论 #38839817 未加载
评论 #38846674 未加载
评论 #38836799 未加载
NateEag超过 1 年前
The author makes a number of good points.<p>In fail2ban&#x27;s defense, it can be used for a lot more than just blocking IP addresses based on SSH failures.<p>At one point in the past I adapted an existing fail2ban setup to ban IP addresses that were running malicious vulnerability scans against a large legacy PHP webapp, using some dumb heuristics that worked and were easy to put in place.<p>Would it have stopped sufficiently motivated expert attackers? Of course not.<p>Did it reduce the load on the legacy PHP app and improve the signal to noise ratio in our webserver logs, while reducing the chance a brute-force attacker would find some hole lurking in a long-forgotten corner of the app&#x27;s unfortunately-large attack surface?<p>Yup.<p>So, I&#x27;d argue it can be useful, even if naive SSH blocking may not offer much improvement.
评论 #38836468 未加载
theginger超过 1 年前
Always use multiple layers of defence. A sturdy 6ft fence and a locked wooden front door can be more secure than a 50m impenetrable stone wall, if it turns out that there is no such thing as an impenetrable stone wall.<p>Brute force protection is completely unnecessary for openssh when you&#x27;ve disabled password authentication because it&#x27;s impossible[really expensive] to brute force. Until you are impacted by an authentication vulnerability which still requires a valid user, then you are brute forcing a user away from being totally compromised. All of a sudden doing all the &quot;unnecessary&quot; things, like brute force protection, disabling root logins and not using default accounts make the difference between you being at the front or back of the line to get compromised in the race to get patched.<p>If you are one of those who believes a vulnerability like that is extremely unlikely rather than inevitable, then consider this. An ssh key gets leaked, the system it has access to is known &#x2F; discoverable, the username is not. Brute force protection is now the main difference between being highly at risk and still reasonable safe. It&#x27;s a contrived scenario, but hardly an outrageous one.
评论 #38836756 未加载
kseifried超过 1 年前
Fail2ban could be potentially useful in an era of passwords, especially when systems allowed anyone to login remotely, and you only had the one server because servers were very expensive.<p>However, the moment the industry went to SSH Keys en masse, and got away from passwords, fail2ban stop serving any real purpose other than to make people feel like they had done something to improve security. Which it didn’t really, especially if you enforced key usage only for logins.<p>Literally, the only argument you can make is that fail2ban might reduce the number of log entries.
评论 #38836080 未加载
评论 #38837050 未加载
zamadatix超过 1 年前
In general I agree with the recommendations here. Though it may be slightly over prescriptive in what security approaches universally make sense (e.g. privileged ports) it carries a very valid conclusion about the applicability of Fail2Ban.<p>The only time I almost used Fail2Ban was with a personal &quot;guaranteed to work from wherever and whatever I&#x27;m on&quot; jumphost which ran SSH on 22 and 443. 443 because, like the post says, outbound filter compatibility (Fun note: to listen on multiple ports simultaneously you can literally just include multiple &quot;Port xyz&quot; lines in your sshd_config). Ultimately I decided for this use case it made more sense to just let bad attempts to fail silently by changing the logging config. If I was ever in a situation I felt I needed the failed attempts logged I&#x27;m not sure I could simultaneously justify username+password login on a public host.
dig1超过 1 年前
I&#x27;m not fond of this writing style without concrete substance; it feels immature. Yes, the author may have tried to be funny, but I don&#x27;t see a compelling reason to stop using fail2ban.<p>Let&#x27;s be clear here - fail2ban will <i>not</i> save you if you have a poorly configured SSH server or widely open Nginx&#x2F;Postfix services, but it will <i>offload</i> traffic blocking to iptables (or whatever firewall you are using). This way, the mentioned services will not have to waste resources just to cancel some connections.<p>Will it save it against large DDoS? Surely not, but it will stop mild DDoS without problems, which it is designed for. We can argue that iptables&#x2F;nftables can do a fail2ban job with rate limiting and other techniques many people have never heard of, but if you are at this level, you already know your craft, and I&#x27;m pretty sure you considered, tried or used fail2ban before.
theandrewbailey超过 1 年前
&gt; * changing your SSH port to non-root port (&gt;1024) means that if the SSH daemon dies, any userland process can take its&#x27; place. this is bad.<p>If you&#x27;re relying on privileged ports, you&#x27;ve already lost the battle.
评论 #38837376 未加载
评论 #38836782 未加载
评论 #38839864 未加载
评论 #38836114 未加载
WesolyKubeczek超过 1 年前
I disagree with just one point.<p>Non-standard ports.<p>They work wonders against lots and lots of traffic from Chinese bots which are too stupid to see that password logins are disabled but there&#x27;s a fucking lot of them, they just won&#x27;t stop knocking, and it does take cycles to fend them off in any way. You stop listening on port 22, and 99% of that shit traffic just goes away.<p>I know, it&#x27;s not by the book, and that well ackchyually I should yak yak this and yada yada that. But it&#x27;s so fucking cheap and simple to do, and it goes brrr, so I just don&#x27;t care.
评论 #38836219 未加载
评论 #38836249 未加载
usr1106超过 1 年前
I have always changed my ssh port and I don&#x27;t see any convincing argument in this rant not continuing to do so.<p>However, scanners have changed drastically during the last 5-10 years. I remember when you saw close to none login attempts when you used a port between 15000 and 20000. Nowdays there are 100s every day. I guess on 22 it&#x27;s much worse, but I have not used 22 just for the sake of comparing.<p>For fail2ban it&#x27;s the same: I know it&#x27;s not a great solution (lightweight code base, better security gains and lower risk to affect legitimate users would be great), but there is no convincing argument and no better alternative in the submission. Good security for the whole installation is not an alternative, it&#x27;s a precondition for connecting anything to the internet anyway.
unixhero超过 1 年前
I use fail2ban. It is a mild security control which I know can fail. I install it, use its defaults and get on with my life.<p>At times, for bastion hosts, I use crowdsec instead.<p>I could not capture why the author was so bitter. I guess I would be the same if I was supporting some product, and its users were getting problems because of fail2ban - and I had to support it for them.
michaelt超过 1 年前
<i>&gt; at worst, fail2ban: causes you massive inconvinience or total lockout [...] it&#x27;ll probably block you out.</i><p>I agree that fail2ban is useless once you&#x27;ve disabled password login, which you should have done.<p>But is anyone really getting locked out of their own systems by fail2ban unless they&#x27;re doing something pretty weird? I thought it gave you about 5 password attempts, and then blocked you for 10 minutes - doesn&#x27;t seem that draconian to me.
评论 #38836105 未加载
评论 #38836166 未加载
评论 #38836091 未加载
plz-remove-card超过 1 年前
On {Free,Net}BSD[1][2] you get Bl*cklistd which is a much better approach than parsing log files.<p>[1] <a href="https:&#x2F;&#x2F;man.freebsd.org&#x2F;cgi&#x2F;man.cgi?query=blacklistd&amp;sektion=8&amp;format=html" rel="nofollow">https:&#x2F;&#x2F;man.freebsd.org&#x2F;cgi&#x2F;man.cgi?query=blacklistd&amp;sektion...</a><p>[2] <a href="https:&#x2F;&#x2F;man.netbsd.org&#x2F;blocklistd.8" rel="nofollow">https:&#x2F;&#x2F;man.netbsd.org&#x2F;blocklistd.8</a>
评论 #38836094 未加载
评论 #38848761 未加载
bioneuralnet超过 1 年前
If you can&#x27;t prevent some users from having passwords, it&#x27;s a decent, low-effort way to discourage intrusion attempts. One place it DOESN&#x27;T necessarily work great is in k8s.<p>A few years ago I had to migrate an ancient VM running OpenSSH (for SFTP only) to our k8s cluster. 99% of the users had passwords instead of keys. Easy enough to run sshd in a container with a mounted volume, but I wanted <i>something</i> to recognize and block repeated bad login attempts (the old VM had no such protections).<p>sshd doesn&#x27;t do it natively, fail2ban wasn&#x27;t a good option since you generally don&#x27;t want a pod messing with a k8 node&#x27;s iptables. What I ended up with was a Ruby script with 3 threads: One to monitor the auth log for failed logins, a second to lock accounts with repeated failures during a given window, and a third to unlock them after some period (and in the darkness bind them). Definitely some caveats in there, but it was an improvement over the status quo.
out-of-ideas超过 1 年前
close the port open if you dont want ssh to be used. i think i read once the rsync.net dude uses port-knocking and maybe f2b? what was the other note from rachaelbythebay, mac os updates always revert changes sshd settings or something like that; maybe they stopped?<p>i do hate the idea of ip whitelisting; IP&#x27;s should be more dynamic and less able to fingerprint an individual - but that is opening another can of wurms. Generally never trust ANY ip; dont use whitelists, and the blacklists should never be &quot;forever&quot;. if your app is secured by a keypair like openssh then thats the route to take.<p>honestly though fail2ban is great in that it does silence some noise in the logs - there will still be an unbareable amount - but at least some less; but still regular log maint is required. Also the groups Ive seen never recommend f2b for use to fight against a DoS attack; not even for &quot;cleaning up logs&quot; - i dont see where that point was created other than from this page
评论 #38836572 未加载
评论 #38836333 未加载
kazinator超过 1 年前
I use something that I made almost exactly ten years ago: txrban.<p><a href="https:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txrban&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txrban&#x2F;</a><p>It&#x27;s way simpler. There is a tiny core to it, and a couple of modules specific to Exim, Apache, SSH. These just run as daemons on the machine.<p>I tried using fail2ban at that time, but it wasn&#x27;t at all what I expected. It was way overcomplicated for what it achieves, and poorly documented. Just getting it running at all was fiddly, never mind the custom behaviors I had in mind.<p>I should review the Apache module; some of it is quite out of date, due to the changing landscape. Also, that webserver it is used with is now behind a reverse proxy, which only receives connections for specific applications.
评论 #38837473 未加载
rigid超过 1 年前
fail2ban is fine for effectively slowing brute-force attacks for services that can&#x27;t by themselves or where significant complexity would be needed.<p>it&#x27;s easy to setup and can stop multi stage attacks that generate quirky log output.<p>EDIT: fail2ban vulnerabilities? what is this guy talking about?
评论 #38836318 未加载
kuon超过 1 年前
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.
评论 #38836125 未加载
shishcat超过 1 年前
I remember having a friend with an extemely sluggish server. Turns out the reason behind this sluggishness was that he set a permanent fail2ban bantime, which added thousands of records to iptabes; any packet, even not SSH, the server had to check the source IP against thousands of records. After purging the rules and switching the bantime the server was usable again.
评论 #38837396 未加载
pepa65超过 1 年前
I think ssh on a non-standard port is a no-brainer, have been doing this for years.<p>But at some point I got too many log entries of failed ssh access attempts. So I looked into fail2ban, but found the system too involved, and I don&#x27;t like python for this kind of thing to start with. Then I started looking for alternatives, because I figured you only need something very simple, that checks certain log files and then instructs the kernel through netfilter to drop traffic from all infracting IPs. I like single-binary applications, especially for things installed outside the normal package manager. Found a skeleton of a golang app that claimed to work (it didn&#x27;t), but I managed to rework it, and it serves my use cases: <a href="https:&#x2F;&#x2F;github.com&#x2F;pepa65&#x2F;fail2drop">https:&#x2F;&#x2F;github.com&#x2F;pepa65&#x2F;fail2drop</a>
ufmace超过 1 年前
I agree with this viewpoint. IMO, a lot of these types of threads fill up fast with gimmicky things that sound good at first but do nothing to increase security against realistic threats, plus are at least inconvenient to set up and maintain, if not prone to misfiring and blocking you.<p>The real advice for setting up new servers IMO is, SSH pubkey auth is perfectly adequate security. Set it up normally on the default port logging in as root, disable password login, and don&#x27;t worry about the noisy failed bot logins. This is a lot more convenient for automated setup and maintenance and has no practical loss of security.
评论 #38836075 未加载
mgkimsal超过 1 年前
&gt; you will have to remember scp flags. this is also bad. probably worse<p>Worse? How?<p>Hrm... If I don&#x27;t use commands for a while, yes, I may have to remember them. If that&#x27;s the tradeoff for one extra layer providing even a modicum of security... why is this a bad thing?<p>We have things like bash scripts... where you can just store the common flags you use for common things.<p>I wonder how often the author port tunnels over ssh? I usually have to go search for the syntax for ... 30 seconds. Then I have it. Or it might be in my history already.<p>&quot;You might have to remember something&quot; seems about the weakest argument against changing ssh ports I&#x27;ve ever read.
patja超过 1 年前
Every attack of significance I see these days uses rotating IP addresses.
评论 #38837527 未加载
egberts1超过 1 年前
One time I had an inadvert DDoS against my non-recursive authoritative DNS server and no way to stop the flooding of log file.<p>Problem is DNS query can come from anywhere so latching to the top-level domain (TLD) name became a must.<p>Fail2ban, to the rescue.<p><a href="https:&#x2F;&#x2F;egbert.net&#x2F;blog&#x2F;articles&#x2F;troubleshooting-regex-in-fail2ban-during-bind9-ddos.html" rel="nofollow">https:&#x2F;&#x2F;egbert.net&#x2F;blog&#x2F;articles&#x2F;troubleshooting-regex-in-fa...</a>
BSDobelix超过 1 年前
First blacklistd would be better, because as written the applications knows better what to &quot;ban&quot; than a log-scanner.<p>I often use a combination of:<p>-blacklistd and fail2ban (for applications who don&#x27;t support blacklistd)<p>-pfbadhost (nearly always)<p>-CrowdSec (just sometimes, but atm pretty happy with the free service)<p>I use those to have clean logs, block spammers at ip level, and &quot;marketing&quot; crawlers...well and other stuff.<p>And no, ssh is never on 22, i like clean logs to better find the real &quot;interesting&quot; stuff.
devaiops9001超过 1 年前
The approach my team takes is we put Wireguard gateways running on OpenBSD in front of network services. We go a step further and very carefully select what chips are used for the network interfaces and also attach a hardware random number generator to add to entropy.<p>Internal users&#x27; machines have these tunnels transparently loaded and running, configured by our internal GitOps-driven config management (SaltStack).<p>Has been pretty comfy so far.
评论 #38836419 未加载
mkasberg超过 1 年前
On a related note, the number of HTTP 404 errors I see to &#x2F;wp-login.php on my static website is ridiculous. (But absolutely not security risk.)
评论 #38837519 未加载
lamontcg超过 1 年前
I&#x27;ve used fail2ban and a nonstandard ssh port before, for like 12 years. Never had any of the issues this article screams at you about, didn&#x27;t take any time to setup. I spent a lot more time locking down the sshd_config itself and maintaining that over time. I do agree that is more important to do. Fuck me, I guess.
pierat超过 1 年前
This article sucks.<p>Fail2Ban can prevent password spraying from working, since an eventual good password will still be blocked if done within the fail2ban block period. And those block periods aren&#x27;t publicized.<p>And given appropriate configuration, is another layer of security a potential threat has to deal with.
ofrzeta超过 1 年前
&gt; you will have to google &quot;rsync ssh non standard port&quot; every time you want to use rsync.<p>I have not the best memory but after using it several times I managed to remember &quot;rsync -e &#x27;ssh -p 223&#x27; ...&quot; and &quot;scp -P 223&quot;. It wasn&#x27;t that hard really.
kazinator超过 1 年前
FreePBX&#x2F;Asterisk comes with a default fail2ban setup that will lock out your SIP connections (from phones) while you&#x27;re just fiddling to get it working, adding to the frustration.
throwaway892238超过 1 年前
I&#x27;ve stopped trying to convince people against using things like Fail2ban. As long as it&#x27;s not a company or government where security is important, let them waste their time.
评论 #38840360 未加载
j45超过 1 年前
Fail2ban is better than nothing at all.<p>Fail2ban has never seemed to be the sophisticated or final solution, just a bare minimum.<p>Inconvenience to users is definitely a form of the security vs. Convenience debate.
lostmsu超过 1 年前
Would you call fail2ban essentially an application firewall?
评论 #38837551 未加载
aborsy超过 1 年前
It’s unnecessary, at least for SSH, in the first place.
LAC-Tech超过 1 年前
Having full logs sucks more.
hwpky超过 1 年前
This post is accurate, fail2ban does suck.<p>But that&#x27;s not a reflection on the fail2ban maintainers, the engineering work that&#x27;s gone into building it, its usability, bugs or indeed anything else connected to its implementation.<p>It sucks simply because it&#x27;s solving the problem in the wrong way. There is no sensible security onion, or defence in depth model for open ports in front of private systems.<p>If the technical solution for keeping private, or limited access systems actually and effectively private on the public Internet requires open ports, it&#x27;s the wrong solution.<p>Unless we&#x27;re running services designed for public and anonymous access, exposing technologies like VPN servers, SSH or any other software for private consumption to the Internet is a mistake.<p>When we do this we&#x27;re putting out invitations for abuse and pulling the burden of security responsibility onto ourselves. I&#x27;d argue however, that unless it&#x27;s a full time concern for us, we&#x27;re close to the project or maintainers, and able to contribute security fixes to source code, we&#x27;re probably ill equipped to directly handle that responsibility and remain dependent on engaging with the surrounding security eco-system to remain secure.<p>I&#x27;m not knocking those security eco-systems, I&#x27;m just pointing out that there&#x27;s a time lag inherent on depending on best-efforts from third parties which creates windows of vulnerability, and open ports on infrastructure ALWAYS puts us on the back foot. From getting patches applied in a timely fashion to the time and convenience cost of updating ACLs each time IPs change. Even if we get the maintenance tasks right 100% of the time, we&#x27;re still open to the risks of something outside of our control happening, like zero day being sprayed across open ports.<p>The U.S. Government correctly issued an executive order mandating Federal Agencies move to adopt Zero Trust principles just six days after the Colonial Pipeline ransomware attack in 2021. Despite the marketing hype which has followed, if we take nothing else away from this motion, it should be that opening ports in our networks to access private systems using the public Internet is over.<p>There are at least 90 projects and businesses today dedicated to building modern private access technologies which allow secure remote connections and access to private networks without opening firewall ports. Many are commercial options serving businesses, but there are also lots of compelling open source offerings for non-commercial use too.<p>There&#x27;s a directory of vendors and technologies here <a href="https:&#x2F;&#x2F;zerotrustnetworkaccess.info&#x2F;" rel="nofollow">https:&#x2F;&#x2F;zerotrustnetworkaccess.info&#x2F;</a> which attempts to dispense with some the Zero Trust marketing BS and instead focus on technical discourse, architecture and approach which some might find helpful.<p>Disclosure; founder of one of the businesses (enclave.io) with a commercial interest in this space.
tzs超过 1 年前
A particularly fun combination is Fail2Ban on a mail server and Apple&#x27;s Mail desktop email client when you need to change your password. We&#x27;ve got to change passwords every 90 days at work, and probably 90% of the times I try to do this I end up getting banned by Fail2Ban.<p>The problem apparently is that Apple Mail is pretty aggressive at retrying if a login fails, and so if it tries to connect before you have finished changing the password in the client it can try enough times in quick succession to trigger Fail2Ban.<p>There are at least 3 places you can change your password(s) for Apple Mail.<p>• Invoke &quot;Mail&#x2F;Settings...&quot; in Mail to open the settings dialog. Select the &quot;Accounts&quot; tab. Then for the account you want to change go to the &quot;Server Settings&quot; pane. That has password fields for your incoming mail server and your outgoing mail server.<p>• Invoke &quot;&#x2F;System Settings...&quot;, then go to the &quot;Internet Accounts&quot; settings. (You can also get there from &quot;Mail&#x2F;Account...&quot; in Mail). Select you mail account, click the &quot;Detail...&quot; button, and you&#x27;ll get a dialog that has a password field.<p>Note it only has one password field. I&#x27;m not sure what you are supposed to do if you have different passwords for you incoming and outgoing mail servers.<p>• Open &quot;Keychain Access&quot;, and search for your incoming mail server. Look for an entry whose kind is &quot;application password&quot; named com.apple.account.IMAP.password. (I assume that IMAP would be POP3 if you use a POP3 server). Open it, verify that the Account field is you@that_server. Then you can click &quot;Show password&quot; to reveal the current password. Change that to the new password and save.<p>Do the same for your outgoing mail server, looking for com.apple.account.SMTP.password.<p>My current procedure is to first disable my work mail account in &quot;Mail&#x2F;Settings...&quot;, then change the password on the server, then update the client side passwords via Keychain access, and then via &quot;Mail&#x2F;Settings...&quot;, then enable my work mail account. That seems to usually work, although once it didn&#x27;t until I also changed it in &quot;Internet Accounts&quot; in the system settings. I also had a time where I just could not get the new password to take until I rebooted.<p>Apple Calendar is also a pain with password changes, but we don&#x27;t have Fail2Ban on our calendar server (it is not on a public facing network so there would be no point) so it is not as annoying as Mail.<p>For Calendar what I&#x27;ve found to mostly work is:<p>1. In &quot;Calendar&#x2F;Settings...&quot; in the settings for my work account in the Accounts tab turn off all delegates. Then disable my work account. The quit Calendar.<p>On MacOS prior to 13 find and kill the CalendarAgent and CalNCService processes. On 13 they went away.<p>2. Change the password on the server.<p>3. Change the password in &quot;Keychain Access&quot;. I find the entry by searching for name@calendar_server. The right entry is the &quot;application password&quot; named &quot;com.apple.account.CalDAV.password&quot;.<p>4. Then change the password in &quot;Internet Accounts&quot;. As with Mail, Calendar provides convenient access to this via &quot;Calendar&#x2F;Accounts...&quot;.<p>5. Open Calendar, reenable the account, and turn back on delegates.<p>All of the above comes from trial and error and I have no idea how much of it is actually necessary. I haven&#x27;t had the patience to do the time consuming experimentation it would take to figure out the actual simplest way to change these passwords reliably and without hitting the server with the old password during the changing.
评论 #38837578 未加载
solarpunk超过 1 年前
hell yeah, brother