[HN Gopher] Brute.Fail: Watch brute force attacks fail in real time
       ___________________________________________________________________
        
       Brute.Fail: Watch brute force attacks fail in real time
        
       Author : mike_d
       Score  : 228 points
       Date   : 2023-06-02 19:49 UTC (3 hours ago)
        
 (HTM) web link (brute.fail)
 (TXT) w3m dump (brute.fail)
        
       | vsviridov wrote:
       | For this reason I've put `endlessh` on port 22 and moved actual
       | ssh elsewhere...
       | 
       | Also started using Crowdsec recently, but not sure about if it's
       | worth it...
       | 
       | fail2ban out of the box works fine for SSH, but for dovecot and
       | postfix it's somehow broken, and the configuration scripts are
       | just too obtuse.
        
         | sltkr wrote:
         | That seems like overkill. I just disable password
         | authentication, and use SSH public keys only. It prevents brute
         | force attacks completely.
        
           | BrandoElFollito wrote:
           | This, and move the endpoint on an uninteresting port to lower
           | the noise in the logs
        
             | NoZebra120vClip wrote:
             | I suppose it may do that, but naively switching to an
             | alternate port may lull one into a false sense of security:
             | https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SSHAltPor
             | t...
             | 
             | Shodan will find and fingerprint you easily enough.
        
             | KMag wrote:
             | ... and avoid automated attacks in case a 0-day in the pre-
             | authentication OpenSSH server code shows up
        
         | kenniskrag wrote:
         | Nice idea. From the docs:
         | 
         | Endlessh is an SSH tarpit that very slowly sends an endless,
         | random SSH banner. It keeps SSH clients locked up for hours or
         | even days at a time. The purpose is to put your real SSH server
         | on another port and then let the script kiddies get stuck in
         | this tarpit instead of bothering a real server.
         | 
         | Since the tarpit is in the banner before any cryptographic
         | exchange occurs, this program doesn't depend on any
         | cryptographic libraries. It's a simple, single-threaded,
         | standalone C program. It uses poll() to trap multiple clients
         | at a time.
         | 
         | https://github.com/skeeto/endlessh
        
           | artursapek wrote:
           | That's hilarious
        
           | operator-name wrote:
           | I'd be cautious about stuff like this - if you annoy the
           | wrong person that could paint a target on your back.
        
             | capableweb wrote:
             | Realistically though, they'll probably timeout by
             | themselves automatically if they haven't seen a password
             | prompt after N seconds. TCP connections can hang overall,
             | so having that would be basics anyway.
        
             | Zetice wrote:
             | They're impotent little weasels who couldn't hit a target
             | the size of a barn, so the risk is minimal.
        
             | dylan604 wrote:
             | Don't discourage someone else from doing it and risk their
             | not coming back to update us on the results. This popcorn
             | is not going to eat itself.
        
             | internetter wrote:
             | Ah where's your sense of fun ;)
        
           | jhartwig wrote:
           | Wow. That is pretty brilliant.
        
       | koromak wrote:
       | Its just stupid at this point. You can put up a wordpress site
       | with 5 daily visitors, and you'll still get thousands of SSH /
       | xmlrpc hits per day.
        
       | nonethewiser wrote:
       | Are these really failures though? This is just how brute force
       | works.
        
       | ok_dad wrote:
       | I kinda want to know the server's address so I can send a
       | "hello_hn" message in the passwords there.
        
         | spuz wrote:
         | I tried the IP resolved by the domain "brute.fail" but it
         | doesn't accept SSH connections :)
        
           | sltkr wrote:
           | I tried mikedamm.com (the author's domain) and it does accept
           | SSH but my failed login attempts don't show up.
        
           | dmurray wrote:
           | The Internet is not that big, though. You could potentially
           | try all 2^32 IPv4 addresses with your password of choice and
           | see when it came up here.
        
         | seabass-labrax wrote:
         | Fun idea, but the data for this site (which is streamed via a
         | WebSocket) doesn't contain that information :)
        
         | fragmede wrote:
         | Upthread the author says one of the three servers is in Digital
         | Ocean, which gives you an AS to target. Reverse engineer the
         | web page so you can capture the websocket to your terminal,
         | grep it for your IP, and search all of DO's ipv4 address space.
         | use Shodan to limit your targets to only machines with an open
         | port 22 to make it go faster.
        
       | chrismorgan wrote:
       | A remark on your fail.js, since you're engaging here and I figure
       | this could interest you or others:
       | 
       | Once there are more than thirty rows, you fade rows in like this:
       | row.style.opacity = 0;       let intervalId =
       | setInterval(function() {           opacity =
       | Number(window.getComputedStyle(row).getPropertyValue("opacity"));
       | if (opacity < 1) {               opacity = opacity + 0.1;
       | row.style.opacity = opacity;           } else {
       | clearInterval(intervalId);           }       }, 100);
       | 
       | This would be better done with a CSS animation or transition--it
       | takes less code, and is smoother.
       | 
       | My suggestion: use animation. Replace the JavaScript with this:
       | row.classList.add("fade-in");
       | 
       | And add this CSS:                 .fade-in {           animation:
       | 1s fade-in;       }            @keyframes fade-in {
       | from { opacity: 0; }       }
       | 
       | This _does_ behave a little differently, as if the window isn't
       | visible, it'll (roughly) wait until you focus the window before
       | playing the animation. Frankly this is even mildly more
       | desirable.
       | 
       | The alternative: use transitions, which are a tad more involved
       | because you have to trigger the value change one frame later, so
       | that it recognises that something has _changed_ and interpolates
       | to it, rather than it just being the initial value and applied
       | instantly. This JS would do:                 row.style.transition
       | = "1s opacity";       row.style.opacity = 0;
       | requestAnimationFrame(() => {           row.style.opacity = 1;
       | });
       | 
       | Or you could express it with more CSS, like with this CSS + JS:
       | tr {           transition: 1s opacity;       }
       | .invisible {           opacity: 0;       }
       | row.classList.add("invisible");       requestAnimationFrame(() =>
       | {           row.classList.remove("invisible");       });
       | 
       | --***--
       | 
       | You might also like `vertical-align: middle` on your spin.svg.
       | 
       | --***--
       | 
       | On the flag icons, here's a cool alternative technique:
       | https://en.wikipedia.org/wiki/Regional_indicator_symbol. Lets you
       | avoid needing even images. Unfortunately, I think Windows still
       | doesn't ship flags, so you'll get the two-letter country code
       | there. You can get around this by packaging a web font. It'd be
       | nice if someone would neatly package a flags-only font so others
       | can easily use it. Here's what I did a few months back for
       | https://ganintegrity.com/country-profiles/, resulting in a single
       | 77KB font file:                 /**       Copyright 2020 Twitter,
       | Inc and other contributors       Graphics licensed under CC-BY
       | 4.0: https://creativecommons.org/licenses/by/4.0/       Twemoji
       | Mozilla packaging via https://github.com/mozilla/twemoji-colr,
       | subset to only include country flags.       */       @font-face {
       | font-family: flag;           /* (Generated with `pyftsubset
       | /opt/firefox-nightly/fonts/TwemojiMozilla.ttf
       | --unicodes="U+1F1E6-1F1FF" --output-
       | file=static/TwemojiMozillaFlags.woff2 --flavor=woff2`.) */
       | src: url(/static/TwemojiMozillaFlags.woff2) format("woff2");
       | }              /* Why do we do this? Because at the time of
       | writing Windows doesn't do flags, so <guzzled by HN> will look
       | like "" rather than an Australian flag. (macOS and major browsers
       | on Linux do.) */       .flag {           font-family: flag;
       | }
        
         | mike_d wrote:
         | Thanks! This is incredibly helpful! I searched around a bit at
         | like 3 AM while I was building it, but couldn't find a simple
         | clean example like what you provided. Once traffic dies down
         | i'll swap it out.
        
       | boringuser2 wrote:
       | Thinking about it, fail2ban is almost entirely a placebo given
       | that your password should be basically impossible to brute force
       | anyways if you have the knowledge to implement fail2ban.
        
         | awestroke wrote:
         | It can conserve server resources to just stop responding to
         | brute force attacks
        
           | veave wrote:
           | If your server is a Gameboy, maybe.
        
             | blueflow wrote:
             | Also disk space - i don't want to keep 500 MB of failed
             | login attempts just to have a week of syslog available.
        
             | boringuser2 wrote:
             | A Gameboy would probably have the computing resources to do
             | a thousand such calculations a millisecond.
        
         | alexchamberlain wrote:
         | Better: just ban password logins, and use cryptographic keys
         | instead.
        
       | artursapek wrote:
       | be careful, this website is easy to vandalize
        
       | ChuckMcM wrote:
       | So funny story, for a while I worked on a 'reverse' exploit.
       | Which is to say morphing the response from ssh to the client with
       | large malformed packets. The idea was to crash the _client_
       | making the request. In my case I found these attacks would have
       | like 6 to 10 attempts from the same source address. By time
       | stamping the requests, I could evaluate if the next attack from
       | the same address came more quickly or more slowly. I then had my
       | server  "morph" the return payload somewhat randomly and keep the
       | three responses that caused the most slowdown. When I got to 100
       | variants that had "won" this selection criteria I took the three
       | best and started over from there. After a couple of months of
       | this I finally got a response where after one request I would not
       | get a second.
       | 
       | I felt extremely pleased with myself for about another month, and
       | then my server address got hit with a massive DDOS attack (for me
       | anyway) over my 6MBPS DSL line. So clearly I had hit a nerve
       | somewhere :-). Anyway, I moved my server to a different address
       | and used fail2ban to just note source IPs and put them into the
       | IP tables as banned addresses. That works great and hasn't
       | resulted in the same sort of drama as last time.
        
         | DougMerritt wrote:
         | Nice. Also an illustration that its good to establish one's
         | inner motive first, like here might range from a desire for
         | simple solutions, to another dimension of drama, which might
         | indeed be desirable sometimes, for entertainment or for
         | snapshots to use in a book one is writing. :)
        
         | daniel-cussen wrote:
         | [dead]
        
         | sneak wrote:
         | Disable password authentication and fail2ban becomes completely
         | unnecessary.
        
           | BrandoElFollito wrote:
           | This. I really do not understand why people use fail2ban when
           | the threat is somewhere else.
           | 
           | It won't stop a ddos but will certainly, at some point,
           | prevent you from logging in.
        
             | bandrami wrote:
             | 20 years ago port-knocking was supposed to solve this issue
             | for good but it seems to have been never really been taken
             | up. I'm not sure why.
        
             | theamk wrote:
             | It keeps the logs cleaner. If you either don't look at the
             | logs at all, or have fancy log analysis systems, then it
             | does not matter. But if you are in the middle, and just
             | manually look at the logs every once in a while, this would
             | be a great help.
             | 
             | If you are logging in via ssh, the chances of being locked
             | out arr low - using password auth is a bad idea, and once
             | you set up ssh keys, the connection will always succeed.
             | And in case of rare event like new system setup, you can
             | always ssh via some other system, -J is great for that.
        
               | admax88qqq wrote:
               | > the connection will always succeed.
               | 
               | Not from my experience. If you have too many keys and
               | certain ssh agents like gnome keyring don't pick up the
               | key intelligently and will try a all the keys in some
               | order often resulting in the server giving rejecting you
               | due to too many failures.
        
             | thelopa wrote:
             | I disable password authentication and use fail2ban. It's
             | unlikely they will be able to brute force my key, but no
             | server is perfect. sshd might be compromised one day. I'd
             | rather have an extra layer of defense just in case.
        
           | [deleted]
        
           | nico wrote:
           | You still get the attacks and they show in the logs
           | 
           | Also, it's not just ssh, there are brute force attacks for
           | pretty much any service that you run
           | 
           | Our logs show automated attempts to run exploits on our web
           | servers everyday
        
         | mike_hock wrote:
         | You still got the response packets?
        
       | slater wrote:
       | looks like it's getting hn-hugged to death.
        
         | technics256 wrote:
         | Guess it got brute forced
        
       | gambiting wrote:
       | I have an RDP server open to the internet(on a custom port) and
       | it just receives an absolutely relentless stream of login
       | attempts with all kinds of random logins. That's a private server
       | on a private home IP, not associated with a known domain or
       | anything. Changing the port stops it for about 24 hours then it
       | starts again.
        
         | omgmajk wrote:
         | Yeah, we have the same problem. I made a custom firewall rule
         | and a python script that watches the windows logs for multiple
         | failed logins to combat this and it seems to work pretty well
         | but there's always new ips.
        
           | SlavikCA wrote:
           | IPBan does that:
           | 
           | https://github.com/DigitalRuby/IPBan
        
         | Solvency wrote:
         | I know nothing about networking, so pardon the ignorance:
         | 
         | Why isn't there (or is there) some kind of service you can use
         | to map some crazy URL to your personalip:port, like...
         | 
         | http://obscuremyshit.com/393nnasjhf83u98723401 =
         | personalip:port
         | 
         | And only when a connection is referred from that source, does
         | the RDP server even expose itself? And for all other traffic
         | that hits personalip:port, it does absolutely nothing?
        
           | fragmede wrote:
           | There are numerous ways ways around it (port knocking, VPN)
           | that gambiting (for whatever reason) is choosing not to
           | employ. Your idea is a good one though
        
           | KMag wrote:
           | Is there some referrer field in the RDP protocol handshake
           | that I'm not aware of?
        
         | throwaway742 wrote:
         | Why not VPN?
        
       | jonfairbanks wrote:
       | This is cool... is it open source? :)
        
       | blakesterz wrote:
       | This is fun to watch, seeing all the passwords is pretty
       | interesting.
       | 
       | Just curious, why x out the IP at all?
        
         | zeta0134 wrote:
         | Presumably many brute force attempts come from compromised
         | residential PCs, whose owners may not be aware that they are
         | participating in an attack. It's not especially polite to
         | expose all of that personal info.
        
         | mike_d wrote:
         | > Just curious, why x out the IP at all?
         | 
         | Trying to avoid being a jerk. The sources are likely hacked
         | boxes where the owner has no idea.
        
           | Filligree wrote:
           | And since they don't get called out, they won't _get_ an
           | idea. Unless the infection is retargeted against themselves.
        
             | mike_d wrote:
             | I also scan the internet quite a bit. Trust me, they (or
             | the ISP rather) are getting a few emails an hour.
        
           | TacticalCoder wrote:
           | > Trying to avoid being a jerk.
           | 
           | There are lists updated in real time by white hats, sharing
           | exact IP of machines known to be engaging in bad behavior.
           | You can, if you want, update your servers in real-time from
           | these lists and then act accordingly: drop the traffic,
           | reject the trafic, serve a "your IP address is participating
           | in brute forcing attempts" page, etc.
           | 
           | FWIW some ISPs may be monitoring these looking for IPs on
           | their subnets and acting accordingly.
           | 
           | It's not about "being a jerk". It's about giving attackers
           | the middle finger.
        
       | nubinetwork wrote:
       | This sounds interesting. When it comes to my setup, I don't even
       | answer their connection attempts. I just log the IP and call it a
       | day.
       | 
       | You'd think that would be enough for them to stop, but I have
       | some IPs with 25k connection attempts over a 90 day span. (Of
       | course it had to be someone using digitalocean)
        
       | msephton wrote:
       | Server down
        
       | nico wrote:
       | This is amazing!
       | 
       | Are you open sourcing this?
       | 
       | Can others stream their logs to your servers and have a
       | crowdsourced list of attackers in real time together with their
       | activity?
        
         | creeble wrote:
         | See abuseipdb.com if you care about this.
        
       | omgmajk wrote:
       | I like that I'm not alone in the world of obsessively looking at
       | my log files.
        
       | mardifoufs wrote:
       | Seems like some of them are residential IP addresses! I guess
       | parts of a botnet or a compromised device?
        
         | jabroni_salad wrote:
         | "residential proxy" is a very popular black market service,
         | since it's less straightforward for website owners to block
         | than other common vpn termination points. These applications
         | market themselves as free VPN services, get loaded by special
         | offers bolted onto legitimate software installers, or are added
         | to trojanized pirate distributions of popular applications.
        
         | jethro_tell wrote:
         | Internet of things.
         | 
         | Lets put 20 unpatched linux computers on every network and see
         | how that goes.
        
       | menotyou wrote:
       | I put on my firewall a block for incoming traffic for all IPs
       | outside Europe which helped a lot with the quantity of attempts.
        
       | fullspectrumdev wrote:
       | Oh that's pretty fucking cool.
       | 
       | Is code available anywhere?
       | 
       | I run a slowly growing network of SSH honeypots that do central
       | logging (Greylog), that I've been meaning to document the setup
       | of for here somewhen.
       | 
       | Bolting something like this onto that would be pretty funny.
        
         | mike_d wrote:
         | No code yet, it was literally pieced together last night.
         | 
         | It is only processing SSH attempts from 3 hosts right now (one
         | in colo, one EC2, one DigitalOcean) because when I pointed the
         | full firehose at it the user experience of the website wasn't
         | great.
        
       | m00dy wrote:
       | Realtime honeypot
        
       | slater wrote:
       | Man, that one Brazilian IP really going hard
        
         | mdaniel wrote:
         | it bugs me that they're not trying the passwords in
         | lexigraphical order :-D
         | 
         | also, who has sshd without `PermitRootPassword=no`? they need
         | to broaden their horizons and try `admin`, `ec2-user`, and
         | `ubuntu` /s
        
           | BrandoElFollito wrote:
           | I do on my home servers where I am the only one and do not
           | need traceability?
           | 
           | Why do you ask, because it is dangerous?
           | 
           | I would love to learn something here.
        
           | varenc wrote:
           | The people with PermitRootPassword=no are also the ones
           | that'll have weak default password. It's probably actually
           | saving the attackers time that allowing root password login
           | and bad password choice occur together. If everyone with
           | randomized high-entropy root passwords actually allowed root
           | password logins that bruteforcers would have to spend so much
           | more time!
        
           | jovial_cavalier wrote:
           | Even if you disallow root login with a password, the user can
           | still try to log in, and the attempt still gets logged
           | 
           | If you're asking why it would ever be worth it, there's
           | always valuable stuff online with incompetent configuration.
           | I don't know if shodan is still up, but I remember going on
           | there in high school and getting access to random webcams
           | (sometimes in peoples' homes)
        
             | omgmajk wrote:
             | https://www.shodan.io/ is still up, if that's what you
             | mean.
        
           | tjohns wrote:
           | Who still allows password-based login for _any_ SSH account,
           | root or not? Keys, certificates, or Kerberos for all users.
        
             | banana_giraffe wrote:
             | You'd think, but yet one still sees one or two posts a week
             | to SO or whatever forum asking how to enable password-based
             | login to AWS EC2 instances. Often with screenshots showing
             | '0.0.0.0/0' as the allowed incoming range.
        
             | Enginerrrd wrote:
             | I do. For some reason ssh keys became the group-think
             | security advice to repeat ad nauseam. I often find people
             | have only considered this very shallowly, and their
             | reasoning is just "But OMG, entropy lolz" without actually
             | seriously considering the available entropy and likely
             | attack vectors and failure.
             | 
             | Why?
             | 
             | The benefits are largely theoretical if you choose
             | sufficiently strong randomly generated passphrases, with
             | some symbols and numbers mixed in, which I set my password
             | manager to do. (Actually, I have a couple of super
             | important, super long ones I keep only in my head.)
             | 
             | The draw-backs however are several:
             | 
             | 1. I find that its not uncommon I find myself having to
             | chain together ssh tunnels and other strange things to
             | debug networking issues and need to login to another
             | machine from a new machine that doesn't have the ssh-key.
             | Treating servers as cattle exacerbates this issue since
             | it's more likely to occur.
             | 
             | 2. If a machine or server I use to manage stuff as a
             | gateway/proxy/vpn entry to my network has all my ssh keys
             | on it, and it becomes compromised because of some 0-day,
             | the attacker now basically has access to... multiple entire
             | networks. Now, this is technically true of my password
             | manager as well, except that the context / IP addresses,
             | etc, is not going to be as obvious as it will be on the
             | server where the attacker can see the running services,
             | check logs, command histories, etc. With the password-based
             | management, sure I could get hit by a keylogger, but
             | everything won't be compromised by default.
             | 
             | 3. In my experience, you're more likely to lock yourself
             | out than let an attacker in. You basically still have to
             | have your keys managed via some type of password manager
             | anyway because otherwise you run the risk of getting locked
             | out of everything in case you're away from your primary
             | machine and need to address some emergency or something.
        
               | rhaps0dy wrote:
               | > ... need to login to another machine from a new machine
               | that doesn't have the ssh-key.
               | 
               | > gateway/proxy/vpn entry to my network has all my ssh
               | keys on it, and it becomes compromised because of some
               | 0-day, the attacker now basically has access to...
               | multiple entire networks
               | 
               | That's why you use SSH agent forwarding
               | https://docs.github.com/en/authentication/connecting-to-
               | gith..., so you never need to copy the private keys to
               | other computers, and thus they can't be stolen from
               | there.
        
               | duskwuff wrote:
               | On the other hand, SSH agent forwarding means exposing
               | your SSH agent to the bastion host. If _that_ gets
               | compromised, an attacker may be able to move laterally to
               | other systems your personal computer had SSH keys for.
        
               | megous wrote:
               | ...May not be stolen, but may be abused from there via
               | ssh-agent connection.
        
               | ikiris wrote:
               | All of your items are just "i'm doing this wrong"
               | combined with not understanding how keys even work.
               | 
               | Your private keys shouldn't even be accessible to you,
               | they should be on a secure enclave like a yubikey, and
               | you should forward the token along the chains. No risks,
               | and basically painless, especially if you switch to certs
               | so you don't even have to know the public keys ahead of
               | time on the servers, just all trust the same private PKI.
        
             | sspiff wrote:
             | I do on my local network. Nothing that's on the Internet. I
             | think it's still enabled by default on Fedora and Debian.
        
             | kenniskrag wrote:
             | Sometimes the default after creating the VM. Sometimes it
             | is, if you start in the recovery mode (usually with a
             | random long password)
        
         | channel_t wrote:
         | This is a pretty excessive amount of SSH brute force but it
         | honestly doesn't seem as bad as some of the cloud machines I
         | run. There are always like at least 3 different IPs going
         | relentlessly hard 24/7/365.
        
         | czbond wrote:
         | That's what a typical attempt looks like unless they're
         | progressively timed out with fw blocks
        
         | OptionX wrote:
         | Yes, someone got a word list. Shame it's a Chinese one.
        
       | koolba wrote:
       | That's neat. What's the total volume per day? Are the passwords
       | themselves being escaped in the final UI rendering? Otherwise
       | you'd have an XSS for a password like "<script>/* code
       | */<script>".
       | 
       | EDIT: Unless it's happening on the server side where it's being
       | saved, I don't think they're being escaped:
       | col1.innerHTML = '<span class="fi fi-' + msg.cc + '" title="' +
       | msg.cc + '"></span> ' + msg.src;         col2.innerHTML =
       | msg.proto;         col3.innerHTML = '<code>' + msg.u + '</code>';
       | col4.innerHTML = '<code>' + msg.p + '</code>';
        
         | mike_d wrote:
         | It is escaped server side. Anything long enough to be a useful
         | payload is trimmed.
        
           | koolba wrote:
           | How short we talking?
           | 
           | Since there's multiple opportunities to inject code, it's
           | possible to split out the payload across multiple fields:
           | https://www.highseverity.com/2011/06/xss-in-confined-
           | spaces....
           | 
           | Ten characters per block is enough for:
           | <script>/*         */eval(/*         */'....'+/*
           | */'....'+/*         */'....'+/*         ...         */)/*
           | */</script>
           | 
           | Best to escape everything at render time.
        
             | mike_d wrote:
             | Everything is escaped server side before it is sent to the
             | client. Shoot me an email and I will let you play with it
             | after the HN traffic dies down.
        
       | Elrecoal wrote:
       | Damm, the same brazilian IP is trying really, really hard
        
       | avodonosov wrote:
       | Some of these credentials could be of legitime users who have
       | just mistyped the IP address.
        
         | rabuse wrote:
         | The odds of that are slim to none.
        
       | OptionX wrote:
       | If this doesn't get to install fail2ban don't know what will.
        
         | mdaniel wrote:
         | I was actually thinking about that: OT1H, fail2ban would really
         | clean up the list, so it's not monopolized by the one joker,
         | but OTOH given sufficient spans of time it would make the
         | output go quiet, which for this specific case defeats the
         | purpose
         | 
         | I actually much prefer the projects that give the caller a fake
         | shell, and watch what they type after "breaking in." It'd be
         | the Kitboga of ssh attacks :-D
        
           | Sodman wrote:
           | I would 100% watch the Kitboga of ssh attacks, is that
           | something that exists today? The closest I've seen so far is
           | password purgatory - https://www.troyhunt.com/sending-
           | spammers-to-password-purgat...
        
         | firstlink wrote:
         | I don't see the point of fail2ban on a server without password
         | login, except to keep the log file tidy. That isn't worth risk
         | of locking out legitimate users due to misconfiguration or user
         | error. CMV.
        
           | fragmede wrote:
           | Keeping the log file tidy isn't just an OCD thing. If you're
           | searching for a needle in a haystack, where needle is
           | "suspicious login", and the haystack is "all of the login
           | attempts from the past the months", your job is made much
           | easier when the haystack is much smaller.
           | 
           | That said, the fail2ban defaults are way too low and I've
           | locked myself out with them. They can be turned way up (ban
           | after way many more attempts) so that there's no risk of
           | locking out legitimate users. (Assuming your users didn't
           | forget their exact password and then generated a small
           | dictionary to try with.) On a server with potential
           | misconfiguration, accepting passwords is one of them.
        
         | lloydatkinson wrote:
         | And SSH key only login
        
       | ztgasdf wrote:
       | Getting PR_END_OF_FILE_ERROR on Firefox, anyone else?
        
         | drewg123 wrote:
         | I was too.. I then disabled DNS over https (which was pointing
         | at nextdns) and it started working. Not sure if that was
         | coincidence or an actual fix
        
       ___________________________________________________________________
       (page generated 2023-06-02 23:00 UTC)