Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
|
Feb
|
Mar
(15) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jim S. <jse...@Li...> - 2026-04-23 16:58:14
|
On Tue, 21 Apr 2026 22:20:41 -0700
Kevin Zheng <kev...@gm...> wrote:
> Jim,
>
> Thanks for the release. Sorry I've been pretty busy and haven't had
> an opportunity to take a good look.
No worries, Kevin. We're all volunteers :)
>
> You mentioned that you are tracking changes in a Git repository
> somewhere? Is that publicly cloneable?
It's a private Git repo, but you're welcome to a cloneable bundle of
the repo with full history. I can:
- email it to you as an attachment
- upload it somewhere
- put it on my FTP server
- put it somewhere on my web server
your choice. It's ~87k.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.
|
|
From: Kevin Z. <kev...@gm...> - 2026-04-22 05:20:53
|
Jim, Thanks for the release. Sorry I've been pretty busy and haven't had an opportunity to take a good look. You mentioned that you are tracking changes in a Git repository somewhere? Is that publicly cloneable? I haven't gotten around to writing the multi-sshg-parser wrapper but I should probably try to get the ball rolling just by importing atre. Regards, Kevin |
|
From: Kevin Z. <kev...@gm...> - 2026-04-10 17:34:24
|
Jos, On 4/10/26 1:40 AM, Jos Chrispijn wrote: > When I set in sshguard.conf > > MaxAuthTries4 What you are likely looking for is: THRESHOLD=40 Each auth attempt is counted with a score of 10, so 4 auth attempts would result in a block at THRESHOLD=40. Regards, Kevin |
|
From: Jos C. <ssh...@cl...> - 2026-04-10 09:15:05
|
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#060606" bgcolor="#FFFFFF">
<font face="Courier New, Courier, monospace">[sshguard-2.5.1,1]<br>
<br>
Hi,<br>
When I set in sshguard.conf<br>
<span class="typ"><br>
MaxAuthTries</span><span class="pln"> </span><span class="lit">4<br>
<br>
it results in:<br>
<br>
/usr/local/etc/sshguard.conf: MaxAuthTries: not found<br>
<br>
Can you tell what I overlook here?<br>
<br>
Thanks, <br>
Jos</span></font>
</body>
</html>
|
|
From: Jim S. <jse...@Li...> - 2026-04-07 17:28:47
|
On Sun, 22 Mar 2026 19:17:00 -0700 Kevin Zheng <kev...@gm...> wrote: > Hi Jim, > > Thanks for your comments. I had an opportunity to take a look at > the code. Thank you for your extensive documentation and comments. > It looks fairly easy to understand and review. (Of course, the > devil is always in the details...) [snip] Hi Kevin, As you’ll probably see, I've finally managed to get the next version out the door. It would've been sooner, but a few things intervened. The upside is that the current version had additional soak time on my own server. I've exercised this version pretty thoroughly in a variety of scenarios and haven’t been able to break it beyond expected failure modes, all of which were handled cleanly. Looking forward to your feedback and suggestions. Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://athena.LinxNet.com/contact/scform.php>. |
|
From: Jim S. <jse...@Li...> - 2026-04-07 17:18:36
|
Hi All,
Attack Parser RE v0.1.0 has been released. This is a Beta release
that supersedes the prior, un-versioned release from 2022.
NOTE: Please update any bookmarks or feed subscriptions. The
project page and download URLs have moved from Jimsun to Athena,
and the Atom feed URL has changed accordingly.
>From the ChangeLog:
rel-0.1.0 2026-04-07
First formal release under Git.
Code has been in production use for several years but was
previously maintained outside a formal version control system.
- Improved robustness in edge cases
- Improved resource cleanup on configuration errors
- Fixed potential crash when removing a faulty regexp entry
- Improved type safety and compiler warning coverage
- Corrected regression test expectations
- Refactored two large, complex functions into smaller, focused
helpers to improve readability and maintainability
- Removed PCRE POSIX compatibility build option as superfluous
- General build cleanups and portability improvements
- Added embedded version information -- visible via `atre-parser
-V` and `strings attack_parser_re.o`
- Added PCRE guard rails (match and recursion limits) to prevent
pathological input from DoS’ing the system (verified graceful
handling when limits are exceeded)
- Added PCRE2 build-time support
- Relicensed from GPL to ISC for compatibility with SSHGuard
- Added LICENSE file to distribution
No functional changes in normal operation. Behavior is consistent
with the prior release.
Feedback and suggestions are welcome.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.
|
|
From: Jim S. <jse...@Li...> - 2026-03-23 19:09:57
|
On Sun, 22 Mar 2026 20:00:37 -0700
Kevin Zheng <kev...@gm...> wrote:
> It sounds like there is a need to maintain context over multiple
> lines.
[snip]
>
> I'm open to adding this functionality to sshg-parser. I will be
> taking a look at some point, unless someone wants to beat me to it.
My first reaction is that once you cross into multi-line matching,
the challenge becomes less “pattern matching” and more “stateful
inspection.”
I would expect the rule language would need some additional way to
express:
• that a rule is stateful,
• which step in a sequence a given pattern represents,
• how steps are correlated with one another,
• and when an incomplete match should expire.
For example, something along the lines of:
<rule part> <g1:s1:t2>
<rule part> <g1:s2:t2>
where g is a rule group, s is the sequence number, and t is the total
number of steps.
That's the easy part. The bigger challenge is correlation.
If multiple partial matches can be in flight at once, the parser
needs some reliable way to determine that a later log entry belongs
to a particular prior partial match. If the log format provides a
reliable, unique correlation token—such as Postfix's queue ID—that may
be doable. Without such a token, interleaved activity would make
matching ambiguous.
Even with a reliable means of positive correlation, there is still
the problem of devising rule syntax—and the underlying parser
logic—to express and manage state for arbitrary logging formats. That
strikes me as a likely significant increase in both syntactic and
implementation complexity.
There also has to be some mechanism to terminate stale state when an
expected follow-on log entry never shows up.
In short, this seems doable in principle, but I can see it getting
tricky very quickly.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.
|
|
From: Jim S. <jse...@Li...> - 2026-03-23 18:00:17
|
Hi Kevin,
Thanks for taking the time to review it, and for the kind words about
the documentation. I’m currently in the middle of a
cleanup/refactoring pass, and the next release should be
substantially easier to read, so you may wish to wait for that
version before spending much review effort.
That administrator-extensible rule capability was the primary impetus
for the project. Because of that, a lot of the effort went into
making rule loading, validation, matching, and reload behavior as
robust and defensive as I knew how.
That said, I expect there’s more I can do on the hardening front, and
I’ll take a closer look there.
To your enumerated points:
1. The ISC license is acceptable. I'll add it to the next release.
2. For integration, my instinct is to keep the initial path simple:
Let sshg-parser run first, and if it finds no attack, pass the line
to a secondary parser.
Longer term, there may be value in a clean, extensible, pluggable
parser architecture, but I don’t think that needs to block an
initial integration.
It’s always been my expectation that sshg-parser would remain the
out-of-box default. My aim hasn’t been to replace it, but to
complement it by covering signatures that are difficult or
impractical to express in the existing yacc/lex-based parser.
3. I’m not (yet) familiar with Capsicum/pledge(), and don’t currently
have a *BSD system available. (Though I am considering a new build
for an experimental box, so that may change.) I appreciate the
offer to help there.
4. I'll leave the CUSTOM_RULES question entirely in your hands, but
it seems like a reasonable approach.
Btw: I’m considering renaming the project to something like "logreap"
("LOG Regular Expression Attack Parser"). Typing
"attack_parser_re.[ch]" every time I need to refer to or edit those
files has become a bit unwieldy.
I’m currently thinking along the lines of:
• logreap (from logreap.c — currently atre_parser.c / atre-parser)
• logreap_core.c and logreap_core.h (currently
attack_parser_re.[ch])
I may or may not leave the internal structure and variable names
as-is.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.
|
|
From: <gi1...@gm...> - 2026-03-23 13:47:07
|
Thanks Kevin. It may be good to post this on the sshguard website. For simple use cases the not-smart algorithm may suffice for many users. In my case I have 3 computers. I need sshguard's "smartness" on one, and it looks like the simple rate limiting algorithm works well on my other two computers. Thanks again, GI -- 'School' -- Place where people learn how to copy textbooks, for that common situation in later life when the photocopier breaks and you really need part of a book you aren't allowed to borrow. |
|
From: Pietro C. <ga...@ga...> - 2026-03-23 06:11:15
|
> On 23 Mar 2026, at 04:01, Kevin Zheng <kev...@gm...> wrote: > > It sounds like there is a need to maintain context over multiple lines. While OpenSMTPD seems like the current most popular culprit, I'm sure there will be other examples as well. Since I started this thread, there's been progress on OpenSMTP's side to restore single-line context: https://github.com/OpenSMTPD/OpenSMTPD/pull/1303 If (when?) this lands, we can get back to a usable state wrt OpenSMTPD with a simple fix to the lexer/parser. -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos. |
|
From: Kevin Z. <kev...@gm...> - 2026-03-23 03:00:45
|
It sounds like there is a need to maintain context over multiple lines. While OpenSMTPD seems like the current most popular culprit, I'm sure there will be other examples as well. I'm open to adding this functionality to sshg-parser. I will be taking a look at some point, unless someone wants to beat me to it. Regards, Kevin |
|
From: Kevin Z. <kev...@gm...> - 2026-03-23 02:32:17
|
GI,
Thank you for your question. I should post something to the website
answering it, but for now, here is my answer:
1. Legitimate users sometimes exceed the rate limit, e.g. when doing
something involving multiple connections with rsync. SSHGuard does
not block legitimate users.
2. Rate limiting is not particularly smart. The example given in the
linked article is "6 or more connections in the last 30 seconds", or
720 attempts per hour. SSHGuard uses a geometrically-increasing
factor of 2. So after 3 failed attempts, the wait time is 2 minutes,
then 4, 8, 16, 32... or about 5x3=15 attempts per hour.
Regards,
Kevin
|
|
From: Kevin Z. <kev...@gm...> - 2026-03-23 02:17:07
|
Hi Jim,
Thanks for your comments. I had an opportunity to take a look at the
code. Thank you for your extensive documentation and comments. It looks
fairly easy to understand and review. (Of course, the devil is always in
the details...)
Of course, I would like to keep sshg-parser as the out-of-box default.
It is faster and theoretically more secure because it doesn't use PCRE
(though I noted that there is a POSIX-regex-only version). This, I
think, differentiates SSHGuard from other tools, e.g. fail2ban.
On the other hand there is a clear and obvious improvement for an
administrator to be able to add their own attack signatures and have
them update on-the-fly without recompiling and restarting SSHGuard.
So, if you are interested in integrating your work into SSHGuard, that
would be welcome. A path forward would roughly be:
1. Clarify license terms. SSHGuard is currently available under the ISC
License. I don't know how many SSHGuard users care about this
license, but I would like to keep the main tarball licensed this way
for now. Would you be willing to relicense your work under these
terms? If not, there are still other options.
2. Either sshg-parser would need to be modified, or a new parser wrapper
that distributes attack signatures to multiple parser processes needs
to be written. The idea is that sshg-parser is run first, and then if
no attack is found it passes it to subsequent parsers. This helps
avoid duplicates. And, in theory, it is faster, but computers are
pretty fast these days.
3. Add Capsicum/pledge() sandboxing to atre-parser. If you are not
familiar with these or don't have FreeBSD/OpenBSD available, I can
help with this part.
4. Finally, add something to sshguard.conf, e.g. CUSTOM_RULES that turns
launches atre-parser when configured.
Let me know your thoughts.
Regards,
Kevin
|
|
From: Jim S. <jse...@Li...> - 2026-03-22 19:43:23
|
On Thu, 5 Mar 2026 13:58:25 -0800 Kevin Zheng <kev...@gm...> wrote: > Hi Pietro, Jim: > [snip] > > There is already a mechanism in sshguard.conf by which you can > elect to run a filter that isn't the default "sshg-parser". One can > imagine an "octopus" parser that gives attacks to atre, > sshg-parser, and others in parallel and collects the detected > attacks. Is that of interest? Hi Kevin, I meant to mention this before... There's a solution to the above: Run-time-loadable modules—perhaps with an associated config file that tells sshguard whether to run them sequentially, and in what order, or in parallel. Though ISTM running multiple parsers in parallel could be a recipe for confusion, but ICBW. Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://athena.LinxNet.com/contact/scform.php>. |
|
From: <gi1...@gm...> - 2026-03-20 18:16:34
|
Hi All,
I've been using SSHGuard for some 10 years now; thanks a lot.
Recently when upgrading my config I noticed that my firewall (ufw,
backend nftables) supports rate limiting SSH connections. It's explained
nicely here:
https://wiki.archlinux.org/title/Uncomplicated_Firewall#Rate_limiting_with_ufw
Does doing this have any advantages / disadvantages over sshguard?
Thanks and best,
GI
--
I have a few jokes about unemployed people but it doesn't matter.
None of them work.
|
|
From: Jim S. <jse...@Li...> - 2026-03-20 16:29:13
|
On Thu, 5 Mar 2026 13:58:25 -0800
Kevin Zheng <kev...@gm...> wrote:
> Hi Pietro, Jim:
>
[snip]
>
> I have been slow to integrate contributions like these into the
> SSHGuard distribution proper. I think it's because I feel like I
> want a well-integrated core in SSHGuard that fits together well and
> has certain security guarantees.
>
> But I'm also aware that folks want faster attack signature updates,
> and maybe even the ability to add their own without mucking around
> in flex/yacc.
[snip]
Hi Kevin,
I can understand your reluctance to integrate something the size and
complexity of the regular-expression-based attack parser I wrote. It
is, admittedly, a fairly involved piece of code.
It ended up that way because I was trying to satisfy two specific
goals:
• To be as robust as possible
• Tolerant of misconfiguration—even actively broken user input
That led to some of the added complexity—particularly around careful
processing of RE configuration files, disabling faulty expressions at
runtime, and very defensive memory management.
For what it’s worth:
• It has been running without incident for several years on four
Internet-facing systems I administer
• After revisiting the code in light of your comments and
conducting a fresh review with AI assistance, I identified and
fixed a few weaknesses
The new code has been regression-tested and is currently deployed on
three of those systems, with the fourth scheduled shortly. Assuming no
issues arise, I plan to publish a 0.1.0 release soon.
I completely understand the desire to keep SSHGuard’s core tight and
well-integrated. My intent here isn’t *necessarily* to push for
inclusion as-is, but to offer an approach that might help address the
“custom signatures without touching flex/yacc” problem space you
mentioned.
If you think it would be useful, I’d be happy to walk through the
design or discuss how something like this could be adapted to better
fit SSHGuard’s architecture.
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://athena.LinxNet.com/contact/scform.php>.
|
|
From: Pietro C. <ga...@ga...> - 2026-03-06 07:41:02
|
> On 5 Mar 2026, at 22:58, Kevin Zheng <kev...@gm...> wrote: > > There is already a mechanism in sshguard.conf by which you can elect to run a filter that isn't the default "sshg-parser". One can imagine an "octopus" parser that gives attacks to atre, sshg-parser, and others in parallel and collects the detected attacks. Is that of interest? Hi Kevin, yeah, I'd like to think of a protocol that could be implemented by 3rd party parsers. Perhaps sshguard would launch the provided program which would simply emit one offending address per line. Pietro -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos. |
|
From: Darren S. <pha...@gm...> - 2026-03-05 22:01:40
|
I also took a little stab at it and ended up with this: https://github.com/dspruell/opensmtpd-filter-reportlogger My effort puttered out in late 2024 when I couldn't verify that I saw authentication failures in the filter's output, even though they were present in smtpd's logs. The other note (as Kevin basically remarked) is that the context for a failed authentication "attack" is split across different lines, so you have effectively a simple correlation use case requiring tracking state, which is a different sort of engine. This is what I drafted but never sent to the list at that time: ----- I also had interest in progressing this effort, and started to prototype something toward a solution as well. This is my starting point: https://github.com/dspruell/opensmtpd-filter-reportlogger This filter is basically a proof of concept to register for report events and log events received from smtpd(8) out to a file on disk. I wanted to start to understand the level of detail that is present (or not present) in the filter events. The first thing I notice, if I'm not mistaken, is that the report stream doesn't currently include signals that various types of authentication events occur. In other words, there are remote client authentication attempts that are captured in the standard syslog stream for smtpd(8) that aren't included in the report events for smtpd-filters(7). For example: 2024-12-26T10:40:25.834Z mailserver smtpd[7134]: c326c2035a3936ca smtp connected address=94.156.177.116 host=94-156-177-116.virtualine.org 2024-12-26T10:40:25.836Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735209625.834172|smtp-in|link-connect|c326c2035a3936ca| 94-156-177-116.virtualine.org|fail|94.156.177.116:55291|x.x.97.55:25<< 2024-12-26T10:40:26.030Z mailserver smtpd[1975]: senderscore: link-connect addr=94.156.177.116 score=127 2024-12-26T10:40:26.043Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735209626.042628|smtp-in|link-identify|c326c2035a3936ca|EHLO|User<< 2024-12-26T10:40:26.528Z mailserver smtpd[7134]: c326c2035a3936ca smtp failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported" 2024-12-26T10:40:26.791Z mailserver smtpd[7134]: c326c2035a3936ca smtp disconnected reason=quit 2024-12-26T10:40:26.792Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735209626.791303|smtp-in|link-disconnect|c326c2035a3936ca<< 2024-12-28T07:15:07.659Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp connected address=44.220.185.247 host= ec2-44-220-185-247.compute-1.amazonaws.com 2024-12-28T07:15:07.661Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735370107.659126|smtp-in|link-connect|c326ce9baeaf2b15| ec2-44-220-185-247.compute-1.amazonaws.com|pass|44.220.185.247:46964 |x.x.97.55:25<< 2024-12-28T07:15:07.829Z mailserver smtpd[1975]: senderscore: link-connect addr=44.220.185.247 score=127 2024-12-28T07:15:13.645Z mailserver smtpd[1975]: dnsbl: c326ce9baeaf2b15 not listed 2024-12-28T07:15:13.710Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735370113.709076|smtp-in|link-identify|c326ce9baeaf2b15|EHLO|localhost<< 2024-12-28T07:15:13.772Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp failed-command command="AUTH NTLM" result="503 5.5.1 Invalid command: Command not supported" 2024-12-28T07:15:13.835Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp disconnected reason=disconnect 2024-12-28T07:15:13.836Z mailserver smtpd[1975]: reportlogger: info: received line >>report|0.7|1735370113.835095|smtp-in|link-disconnect|c326ce9baeaf2b15<< 2024-12-30T01:03:13.570Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp connected address=154.203.197.53 host=<unknown> 2024-12-30T01:03:13.572Z mailserver smtpd[28705]: reportlogger: info: received line >>report|0.7|1735520593.570254|smtp-in|link-connect|1f37facfcf1e594d|<unknown>|fail|154.203.197.53:55934 |x.x.97.55:25<< 2024-12-30T01:03:13.696Z mailserver smtpd[28705]: senderscore: link-connect addr=154.203.197.53 score=127 2024-12-30T01:03:13.716Z mailserver smtpd[28705]: reportlogger: info: received line >>report|0.7|1735520593.715930|smtp-in|link-identify|1f37facfcf1e594d|EHLO|User<< 2024-12-30T01:03:13.859Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported" 2024-12-30T01:03:14.004Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp disconnected reason=quit 2024-12-30T01:03:14.005Z mailserver smtpd[28705]: reportlogger: info: received line >>report|0.7|1735520594.004235|smtp-in|link-disconnect|1f37facfcf1e594d<< As you can see in the above logs, smtpd logs in the syslog stream an indication that the remote client attempted to authenticate, but this event doesn't come across in the currently implemented report event stream. That might make sense in one way, given that it's a NOOP due to being an invalid command at that stage (client likely didn't issue AUTH after STARTTLS), but it makes me question the utility of the currently implemented report stream for this purpose. link-auth: result username This event is generated upon an authentication attempt by the client. result contains the string "pass", "fail" or "error" depending on the result of the authentication attempt. username contains the username used for the authentication attempt. Darren On Thu, Mar 5, 2026 at 2:01 PM Jim Seymour via sshguard-users < ssh...@li...> wrote: > On Thu, 5 Mar 2026 20:27:04 +0000 > Pietro Cerutti via sshguard-users > <ssh...@li...> wrote: > > > Hi, > > > > apparently this thread didn't produce any good outcome: > > > https://sourceforge.net/p/sshguard/mailman/sshguard-users/thread/42d11423-0c81-0cb0-87cc-065c1e6bc8ea%40gmail.com/ > > > > I'm interested in learning how people are dealing with it. > [snip] > > I deal with patterns sshguard doesn't support natively with this: > > https://athena.linxnet.com/atre_parser.html > > I haven't gotten around to adapting it to sshguard 2.x, yet, but that > should be relatively trivial. > > I've submitted it to Keven for inclusion into sshguard, but I guess > he's uninterested *shrug* > > Regards, > Jim > -- > Note: My mail server employs *very* aggressive anti-spam > filtering. If you reply to this email and your email is > rejected, please accept my apologies and let me know via my > web form at <http://jimsun.LinxNet.com/contact/scform.php>. > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > -- Darren Spruell pha...@gm... |
|
From: Kevin Z. <kev...@gm...> - 2026-03-05 21:58:39
|
Hi Pietro, Jim: Thanks for sharing. I suppose I should start a section on the website that collects useful scripts and parsers and the like. OpenSMTPD is a bit different because the context necessary for blocking an attacker is spread across multiple lines; so therefore a line-by-line parser simply won't work. It has to remember state from previous lines, which is what the awk script does. I'm not sure atre can do this? I have been slow to integrate contributions like these into the SSHGuard distribution proper. I think it's because I feel like I want a well-integrated core in SSHGuard that fits together well and has certain security guarantees. But I'm also aware that folks want faster attack signature updates, and maybe even the ability to add their own without mucking around in flex/yacc. There is already a mechanism in sshguard.conf by which you can elect to run a filter that isn't the default "sshg-parser". One can imagine an "octopus" parser that gives attacks to atre, sshg-parser, and others in parallel and collects the detected attacks. Is that of interest? Regards, Kevin |
|
From: Jim S. <jse...@Li...> - 2026-03-05 21:00:41
|
On Thu, 5 Mar 2026 20:27:04 +0000 Pietro Cerutti via sshguard-users <ssh...@li...> wrote: > Hi, > > apparently this thread didn't produce any good outcome: > https://sourceforge.net/p/sshguard/mailman/sshguard-users/thread/42d11423-0c81-0cb0-87cc-065c1e6bc8ea%40gmail.com/ > > I'm interested in learning how people are dealing with it. [snip] I deal with patterns sshguard doesn't support natively with this: https://athena.linxnet.com/atre_parser.html I haven't gotten around to adapting it to sshguard 2.x, yet, but that should be relatively trivial. I've submitted it to Keven for inclusion into sshguard, but I guess he's uninterested *shrug* Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>. |
|
From: Pietro C. <ga...@ga...> - 2026-03-05 20:27:18
|
Hi, apparently this thread didn't produce any good outcome: https://sourceforge.net/p/sshguard/mailman/sshguard-users/thread/42d11423-0c81-0cb0-87cc-065c1e6bc8ea%40gmail.com/ I'm interested in learning how people are dealing with it. Also, here's my solution, in case it's useful to anyone. It's a simple awk script that keeps track of initiated connections and emits an old-style log whenever an error or auth failure occurs. To be used as: LOGREADER="tail -F /var/log/maillog | /usr/bin/awk -f /path/to/script" The script: function session(line) { return substr($0, match($0, "[0-9a-f]{16} smtp"), 16) } function keyed(line, key) { prefix = key "=" start = match($0, sprintf("%s[^ ]+", prefix)) return substr($0, start + length(prefix), RLENGTH - length(prefix)) } function address(line) { return keyed(line, "address") } function hostname(line) { return keyed(line, "host") } function cleanup(sess) { delete cached[sess "-addr"] delete cached[sess "-host"] } /[0-9a-f]{16} smtp connected/ { sess = session($0) cached[sess "-addr"] = address($0) cached[sess "-host"] = hostname($0) } /[0-9a-f]{16} smtp (failed-command|bad-input)/ { sess = session($0) addr = cached[sess "-addr"] host = cached[sess "-host"] cleanup(sess) printf "%s smtp event=failed-command address=%s host=%s ", sess, addr, host print "command=\"AUTH PLAIN\" result=\"535 Authentication failed\"" } /[0-9a-f]{16} smtp disconnected/ { cleanup(session($0)) } Cheers, -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org |
|
From: hvjunk <hv...@gm...> - 2025-09-21 18:34:05
|
Thank you, I’ve asked/included the Debian SSHGuard maintainer to request that update :) > On 21 Sep 2025, at 19:56, Kevin Zheng <kev...@gm...> wrote: > > Hi Hendrik, > > Thanks for bringing this to our attention. > > These build failures in GCC 15 were fixed since the 2.5.0 release. Can Debian update the package to 2.5.1? > > Regards, > Kevin > > > _______________________________________________ > sshguard-users mailing list > ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Kevin Z. <kev...@gm...> - 2025-09-21 17:56:27
|
Hi Hendrik, Thanks for bringing this to our attention. These build failures in GCC 15 were fixed since the 2.5.0 release. Can Debian update the package to 2.5.1? Regards, Kevin |
|
From: hvjunk <hv...@gm...> - 2025-09-21 09:05:00
|
Good day, Seems GCC15 following C23 is.. well… requiring code changes :0 > Begin forwarded message: > > From: Debian testing autoremoval watch <no...@re...> > Subject: sshguard is marked for autoremoval from testing > Date: 06 September 2025 at 06:40:24 SAST > To: <ssh...@pa...> > > sshguard 2.4.3-1 is marked for autoremoval from testing on 2025-09-19 > > It is affected by these RC bugs: > 1097932: sshguard: ftbfs with GCC-15 > https://bugs.debian.org/1097932 > > > > For more information on the autoremoval process, including hints to prevent > autoremoval can be found on the wiki: https://wiki.debian.org/Autoremoval > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl |
|
From: Hendrik V. <hv...@he...> - 2025-09-21 08:52:54
|
Good day, Who is the Debian package maintainer to perhaps comment on this? Begin forwarded message: From: Debian testing autoremoval watch <no...@re...> Subject: sshguard is marked for autoremoval from testing Date: 06 September 2025 at 06:40:24 SAST To: <ssh...@pa...> sshguard 2.4.3-1 is marked for autoremoval from testing on 2025-09-19 It is affected by these RC bugs: 1097932: sshguard: ftbfs with GCC-15 https://bugs.debian.org/1097932 For more information on the autoremoval process, including hints to prevent autoremoval can be found on the wiki: https://wiki.debian.org/Autoremoval This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl --- Hendrik Visage hv...@he... HeViS.Co Systems Pty Ltd https://www.envisage.co.za |
2 messages has been excluded from this view by a project administrator.
