[HN Gopher] Some thoughts on OpenSSH 9.8's PerSourcePenalties fe...
___________________________________________________________________
Some thoughts on OpenSSH 9.8's PerSourcePenalties feature
Author : jandeboevrie
Score : 46 points
Date : 2024-08-14 15:27 UTC (7 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| PreInternet01 wrote:
| PerSourcePenalties-like abuse mitigations are not very subtle,
| but often _very_ effective.
|
| My own experience with this is not as much with SSH as with SMTP.
| If your particular IP emits a single non-deliverable message
| every 30 minutes or so, that's fine.
|
| But: more than a handful of SPF failures for the same
| sender/recipient combo within 10 minutes or so? Yeah, you're now
| on the general-deny-list. And persisting even then? Automagically
| tar-pitted on the firewall, and have fun...
| HL33tibCe7 wrote:
| > But: more than a handful of SPF failures for the same
| sender/recipient combo within 10 minutes or so? Yeah, you're
| now on the general-deny-list. And persisting even then?
| Automagically tar-pitted on the firewall, and have fun...
|
| What is the advantage of bothering to do this?
|
| To me, it seems like you're risking blocking legitimate traffic
| (as two obvious examples, in cases where a sending mailserver
| is temporarily misconfigured, or if a malicious mailserver is
| using a cloud IP that is later recycled to a completely
| unrelated user), for basically zero upside.
| PreInternet01 wrote:
| > What is the advantage of bothering to do this?
|
| For SMTP: log optimization.
|
| Like: yeah, I don't care that you're self-DDOSing if you're
| an actual spammer. But, just in case you're a legitimate
| sender lacking SPF records, and you just need some help, I
| still want some kind of signal.
|
| For SSH, I guess you might want something similar, just to
| catch authorized-yet-misconfigured remotes...
| mdtancsa wrote:
| I suspect the distributed cracking will move to the same pattern
| as the SMTP/pop3 brute force guys did and use one IP per x+1
| seconds where x=the ssh penalty window. We have seen this on our
| customer facing smtp server where we have hundreds of remote
| compromised IPs trying each one password per 30-60min. Still, I
| welcome this change as there are enough single prick attackers
| out there where this will help cut down on the size of the logs
| to process / digest.
| catkitcourt wrote:
| Actually this already is the SOTA of cracking. My honeypot can
| see several different IP is brute forcing concurrently, and
| they seems irrelevant. But once you let one of them login, it
| will quit immediately and all those IPs will quiet after
| ~15sec. Then one of those IPs will login again to deploy miner.
| superjan wrote:
| Next level: let them login and forward the ssh connection to
| the digital equivalent of a room full of mirrors.
| spogbiper wrote:
| reminds me of using the old MIRROR target in iptables back
| in the day. before it was removed because its ridiculous.
| we used to watch script kiddies trying to brute force their
| own hosts but even then we knew it was ripe for abuse.
|
| https://www.linuxtopia.org/Linux_Firewall_iptables/x4448.ht
| m...
| Terr_ wrote:
| Probably for the best, since it sounds like that could be
| used for DDoS amplification and/or reflection.
|
| For example, if an attack could spoof traffic to get two
| different reflectors hall-of-mirror-ing each other, or
| using a botnet that spoofs traffic to get one collection
| of dupes to slam a single victim in response, etc.
| WhatIsDukkha wrote:
| I wish the openssh folks would implement a UDP based "whole auth
| key or no talk at all" protocol.
|
| ie Single Packet Authorization
|
| Wrapping your ssh with wireguard (because wireguard doesn't
| respond without a full key) doesn't feel too good.
| rwmj wrote:
| I've not used it, but this ssh wrapper was mentioned here a few
| days ago: https://github.com/mrash/fwknop
| tptacek wrote:
| Why? What does that get you?
| cedws wrote:
| I've been thinking that we need a new 'WireGuard of SSH' for a
| while. SSH is such a complex behemoth now. Before WireGuard
| came along VPNs were horrible to work with, the cryptography
| was bad and they were too configurable. Just do one thing and
| do it well - provide a way to establish an encrypted remote
| shell. Let others build on top of that if they need more.
|
| Vulnerabilities lurk in overly complex software with a thousand
| bells and whistles. By reducing the code paths you're making
| software that is much easier to audit and fuzz.
| tptacek wrote:
| I agree directionally, but the frankly stunning security
| track record of OpenSSH makes that a hard argument to really
| prosecute.
| mmooss wrote:
| I'm curious about what works and what doesn't: Many experts
| don't trust OpenBSD's security implementation (I don't want
| to raise the issue, just stating fact - many don't). Yet
| many do trust OpenSSH's security implementation, and
| OpenSSH is of course an OpenBSD project.
|
| What works in OpenSSH that doesn't work in OpenBSD? Maybe
| it's as simple as, though under the same umbrella OpenSSH
| uses a different team, methodology, etc.
| tptacek wrote:
| I don't think OpenSSH's affiliation with OpenBSD really
| means anything; it's an accident of history that the
| people most likely to want to build something like
| OpenBSD happened to have been involved with OpenBSD at
| the time. Just my take.
| yourapostasy wrote:
| _> Many experts don 't trust OpenBSD's security
| implementation..._
|
| Does this distrust go to the extent where confronted with
| a public Internet-facing, stock OpenBSD with a TLS-
| secured SSH connection, and a GSA hardened RHEL 8 [1]
| with a similar SSH configuration, they'll pick the RHEL
| instance?
|
| [1] https://github.com/GSA/ansible-os-rhel8
| maayank wrote:
| I'm genuinely interested to hear criticism re: security
| in openBSD if any one has an interesting link or take
| cedws wrote:
| I have written poorly worded criticisms of the OpenBSD
| project on HN before. They boil down to this: from my
| observation, it looks like the approach to security in
| the OpenBSD project is adding _more_ code to solve
| problems when it should be the opposite. Code is a
| liability. You should write as little of it as possible
| to solve the problem at hand. In this case the problem is
| getting a shell on a remote host. Why do you need so many
| configuration options to solve this single problem?
|
| The OP is a prime example of the opposite happening -
| it's adding code to prevent repeated authentication
| failures. Why would this be needed in the first place? If
| you have configured OpenSSH correctly (that is, using
| public key authentication instead of password auth, which
| should not even be an option), then repeated
| authentication failures should not be a problem. At
| worst, they take up some CPU time.
|
| Much of the code in OpenBSD and the wider OpenBSD
| projects also address memory safety issues which would
| not be issues in the first place if they just used a
| memory safe language. Yet they push ahead using C in the
| full knowledge that there are better options available.
| Java, Go, Python, Rust, I literally don't care, anything
| would be better than C. Developers should not need to
| spend hours carefully poring over each others patches to
| find critical mistakes when it comes to memory. They
| should not need to spend hours reading C development
| guidelines or rely on mailing list oracles. By
| eliminating memory errors as a class, mental capacity is
| freed up to identify logic errors.
| formerly_proven wrote:
| SSH (v2) has always been a complex behemoth of a protocol.
| gosub100 wrote:
| Then it would be vulnerable to MITM.
| 10000truths wrote:
| Telnet over WireGuard?
| Vecr wrote:
| You'd really have to think about that, I'd personally reject
| it just on defense in depth grounds. SSH over WireGuard is
| probably the correct solution.
| blueflow wrote:
| That's not easy, if you do a ssh -vvv you will see that its a
| long forth and back of negotiations and information exchanges.
| catkitcourt wrote:
| What's the difference between fail2ban? Though I feel neither of
| those two works now.
| kemitche wrote:
| Seems similar, except that this is built-in to sshd vs having
| to install a separate tool. It's also enabled by default here
| in sshd.
| bbayles wrote:
| How about a service that lets bruteforcers "in" after some number
| of failed attempts, but what they get is just a fake command
| prompt that accepts all of their commands? I'm sure hackers would
| eventually adapt, but it would annoy them for a while.
| mikedelfino wrote:
| I can't tell if that's sarcasm, but that's a thing already,
| called honey pot. Very often, you set it up to let attackers in
| so you can analyze what they're doing and protect yourself
| better.
| teruakohatu wrote:
| They would just connect, issue some command like 'ls' and
| evaluate the response, not sure that would slow them down much
| more than they already are.
| mmsc wrote:
| _the future_ is bleak: Attackers can just rent a /48 ipv6 block
| for a few dollars and have a billion IPs at their disposal.
| vetrom wrote:
| It's certainly an annoying future. I fully expect some sort of
| ASN-reputation map and service to become de rigeur in the next
| decade. Pretty sure heavier-duty SIEM/IPS systems already do
| that.
| kemitche wrote:
| You can control the block size for this, though:
| https://man.openbsd.org/sshd_config.5#PerSourceNetBlockSize
| tsimionescu wrote:
| I'm sure people will quickly start blocking /48s or even larger
| blocks once that becomes common.
| gnfargbl wrote:
| They already do. The IPv6 public routable prefix is the first
| 48 bits, so a /48 is what ~everyone uses as the analogy of
| the v4 /32, for rate limiting purposes.
| lxgr wrote:
| Everyone? I've had ISPs provide me with anything from an
| /48 to a /64. For the latter, you'd be vastly over counting
| with /48-based limiting.
| Sesse__ wrote:
| But the /64 would not be publicly routable (i.e., be
| visible in the global BGP table).
|
| I guess in practice, it's more like IPv4 /24 = IPv6 /48,
| though. The closest analog to an IPv4 /32 would probably
| be an IPv6 /64.
| gnfargbl wrote:
| We have two perspectives, the normal user and the
| scraper. The normal user either acquires a /64, /56 or
| /48, depending on the whim of their ISP. There is
| typically no cost difference between these options, which
| means that the scraper (or their upstream proxy) always
| chooses a provider which offers a /48.
|
| Thus, the default unit of IPv6 blocking must be a /48.
| This situation will persist for as long as /48s are
| readily available at the same price as /64s.
|
| Perversely, the reason we don't have this issue in IPv4
| space is because the address space is of the same order
| of magnitude as the number of potential users. That
| artificial scarcity means that a routable /24 is x256 the
| cost of a end-user /32, so the unit of blocking can be a
| /32.
| gorgoiler wrote:
| Most ISP customers get either a /48 or a /56. The IPv6
| equivalent of a random 1.2.3.4/32 consumer IP address would be
| something like 2001:abcd:1234::/48 or 2001:abcd:1234:ff::/56 in
| IPv6.
| 0x457 wrote:
| Such blocking was always not about protection, but not having
| 100500 error messages in your logs every hour. Attackers that
| are blocked are the kind of attackers that cast a wide net and
| see what get caught.
| jijji wrote:
| I usually just IP whitelist inbound sshd connections and then
| drop all other packets
| kkfx wrote:
| Hem... There is PerSourcePenaltyExemptList to whitelist specific
| hosts so while I agree it might create a bit more complexity (not
| much different than handling fail2ban and co) it's not "blocking"
| like described.
| mscdex wrote:
| For what it's worth if you have control over both client and
| server and don't want to limit access using a strict IP
| whitelist, an alternative solution that will keep your logs
| quieter and add additional protection is to use good old
| fashioned port knocking. knockd on Linux helps with automating
| this on the server side. Client side you can use anything
| (although knockd does include a dedicated client) to send your
| sequence of packets before actually connecting.
| gnfargbl wrote:
| I really think this solution is underrated. Port knocking is
| robust, doesn't use any special technology, and servers using
| it can't reasonably be scanned for. I don't know why OpenSSH
| hasn't implemented it instead of the the silly fail2ban theatre
| we're discussing in these comments.
___________________________________________________________________
(page generated 2024-08-14 23:00 UTC)