Mailing List Archive

Given the most recent security scare with distribution-patched sshd having
a backdoor because it indirectly linked to xz, I'd expect sentiment to be
strongly against adding any integrations.

While there is some utility to what you are suggesting, maybe it makes more
sense to split apart the fail2ban log parsing from its jail functionality
and use it to parse logs onto D-bus. Let's keep sshd as simple and secure
as it can be.

--Gregory

On Thu, Apr 11, 2024 at 05:01:37PM +0200, Krzysztof Kowalski wrote:
> Dear OpenSSH developers,
>
>
> I was looking at the fail2ban project and had an idea that instead of
> parsing log files it could be possible to notify interested parties (like
> fail2ban) via (for instance) D-bus about a failed login attempt.
>
> Other application could also use this protocol to notify about suspect
> behaviors. A central functionality will allow for other (new) projects to
> integrate without much effort.
>
> What do you think?
>
>
> Best regards
>
> Krzysztof Kowalski
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> I was looking at the fail2ban project and had an idea that instead of
> parsing log files it could be possible to notify interested parties
> (like fail2ban) via (for instance) D-bus about a failed login attempt.
>
> Other application could also use this protocol to notify about suspect
> behaviors. A central functionality will allow for other (new) projects
> to integrate without much effort.
>
> What do you think?

Apart from the current trend of minimizing attach surface,
this would need some kind of queue in case the analyzer
was stopped, temporarily busy, or whatever.

I guess that should use stable storage instead of RAM
(to not go OOM just because of external events) -
and now we're at the current solution already,
with sshd logging to disk and fail2ban reading these files.


Sure, we might be able to ease parsing by dropping JSON
instead of text files -- but that would be _additional_ IO,
and the "problem" of parsing is already solved,
so it doesn't seem to be any real improvement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On 11 Apr 2024, at 17:01, Krzysztof Kowalski <krzysztof.kowalski@hashmx.com> wrote:
>
> Dear OpenSSH developers,
>
>
> I was looking at the fail2ban project and had an idea that instead of parsing log files it could be possible to notify interested parties (like fail2ban) via (for instance) D-bus about a failed login attempt.
>
> Other application could also use this protocol to notify about suspect behaviors. A central functionality will allow for other (new) projects to integrate without much effort.
>
> What do you think?

Just use sshguard - very effective and much more light weight than fail2ban

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On 11 Apr 2024, at 17:01, Krzysztof Kowalski <krzysztof.kowalski@hashmx.com> wrote:
>
> Dear OpenSSH developers,
>
>
> I was looking at the fail2ban project and had an idea that instead of parsing log files it could be possible to notify interested parties (like fail2ban) via (for instance) D-bus about a failed login attempt.
>
> Other application could also use this protocol to notify about suspect behaviors. A central functionality will allow for other (new) projects to integrate without much effort.
>
> What do you think?

Just use sshguard - very effective and much more light weight than fail2ban

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Gregory Seidman wrote in
<ZhiabssA26w1CDDz@peterbilt.lan>:
|Given the most recent security scare with distribution-patched sshd having
|a backdoor because it indirectly linked to xz, I'd expect sentiment to be
|strongly against adding any integrations.
|
|While there is some utility to what you are suggesting, maybe it makes more
|sense to split apart the fail2ban log parsing from its jail functionality
|and use it to parse logs onto D-bus. Let's keep sshd as simple and secure
|as it can be.

There is blacklistd, now, for asylumatic read and golden yellow
reasons, blocklistd. It does this for a decade.
Part of FreeBSD and originally from Christos Zoulas, NetBSD.
(Though, last i looked, it really only notifies failed login
attempts.)
I do agree strongly, in that i personally very much think so, that
recreating state from parsing log files is an atrocity. Ie, for
the purpose of filtering out bad actors at least, for interacting
with the firewall that is, *live* and for operational purposes
that is, lastly.
Granted there are deep-inspecting firewalls and such which look
into protocols; i think all Microsoft Virus stuff works like this,
and Kaspersky is no longer allowed to do so, if i got this right.
I dunno, as can be seen.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Maybe this (putting login success/failure notifications onto D-bus) would
be a good thing for a PAM plugin to handle.

-Travis

>
> Gregory Seidman wrote in
> <ZhiabssA26w1CDDz@peterbilt.lan>:
> |Given the most recent security scare with distribution-patched sshd
> having
> |a backdoor because it indirectly linked to xz, I'd expect sentiment to be
> |strongly against adding any integrations.
> |
> |While there is some utility to what you are suggesting, maybe it makes
> more
> |sense to split apart the fail2ban log parsing from its jail functionality
> |and use it to parse logs onto D-bus. Let's keep sshd as simple and secure
> |as it can be.
>
> There is blacklistd, now, for asylumatic read and golden yellow
> reasons, blocklistd. It does this for a decade.
> Part of FreeBSD and originally from Christos Zoulas, NetBSD.
> (Though, last i looked, it really only notifies failed login
> attempts.)
> I do agree strongly, in that i personally very much think so, that
> recreating state from parsing log files is an atrocity. Ie, for
> the purpose of filtering out bad actors at least, for interacting
> with the firewall that is, *live* and for operational purposes
> that is, lastly.
> Granted there are deep-inspecting firewalls and such which look
> into protocols; i think all Microsoft Virus stuff works like this,
> and Kaspersky is no longer allowed to do so, if i got this right.
> I dunno, as can be seen.
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, 11 Apr 2024, Krzysztof Kowalski wrote:

> Dear OpenSSH developers,
>
> I was looking at the fail2ban project and had an idea that instead of parsing
> log files it could be possible to notify interested parties (like fail2ban)
> via (for instance) D-bus about a failed login attempt.
>
> Other application could also use this protocol to notify about suspect
> behaviors. A central functionality will allow for other (new) projects to
> integrate without much effort.
>
> What do you think?

As others have mentioned, we're really not in the mood for more library
dependencies right now. However, some people have asked for platform
features that would require D-bus support. I don't know much about the
D-bus protocol, but if a small D-bus client is just opening a unix domain
socket and writing a message to it then we could possibly support it
using a standalone implementation, like we just did for systemd.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> I don't know much about the
> D-bus protocol, but if a small D-bus client is just opening a unix
> domain
> socket and writing a message to it then we could possibly support it
> using a standalone implementation, like we just did for systemd.

Afraid not, D-Bus is a stateful protocol with client authentication and
so much more, it's not something you really want to reimplement
locally, using one of the available libraries is the only reasonable
approach.

There are de-facto two usable libraries for C projects, the first one
is GDBus, provided by the GLib library, and pretty much requires buying
into the whole GLib model of main loop and event processing. The second
one is sd-bus, which is smaller and can be used in other event/main
loops implementation and, I'm sure you'll be delighted to know, it's
from libsystemd ;-)

https://www.freedesktop.org/wiki/Software/DBusBindings/

--
Kind regards,
Luca Boccassi
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> I don't know much about the
> D-bus protocol, but if a small D-bus client is just opening a unix
> domain
> socket and writing a message to it then we could possibly support it
> using a standalone implementation, like we just did for systemd.

Afraid not, D-Bus is a stateful protocol with client authentication and
so much more, it's not something you really want to reimplement
locally, using one of the available libraries is the only reasonable
approach.

There are de-facto two usable libraries for C projects, the first one
is GDBus, provided by the GLib library, and pretty much requires buying
into the whole GLib model of main loop and event processing. The second
one is sd-bus, which is smaller and can be used in other event/main
loops implementation and, I'm sure you'll be delighted to know, it's
from libsystemd ;-)

https://www.freedesktop.org/wiki/Software/DBusBindings/

--
Kind regards,
Luca Boccassi
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On 14 Apr 2024, at 14:54, Luca Boccassi <bluca@debian.org> wrote:
>
>> I don't know much about the
>> D-bus protocol, but if a small D-bus client is just opening a unix
>> domain
>> socket and writing a message to it then we could possibly support it
>> using a standalone implementation, like we just did for systemd.
>
> Afraid not, D-Bus is a stateful protocol with client authentication and
> so much more, it's not something you really want to reimplement
> locally, using one of the available libraries is the only reasonable
> approach.

Which tells me all the reasons to not implement it inside/with OpenSSH, other than a side client handling things asynchronously….

some other challenges listed with d-bus in an attempt to do something beterer:
https://dvdhrm.github.io/rethinking-the-dbus-message-bus/


>
> There are de-facto two usable libraries for C projects, the first one
> is GDBus, provided by the GLib library, and pretty much requires buying
> into the whole GLib model of main loop and event processing. The second
> one is sd-bus, which is smaller and can be used in other event/main
> loops implementation and, I'm sure you'll be delighted to know, it's
> from libsystemd ;-)
>
> https://www.freedesktop.org/wiki/Software/DBusBindings/
>
> --
> Kind regards,
> Luca Boccassi
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev