[SOLVED] Linode server, and fail2ban --> finds no matches.

baumei · 06-01-2022, 10:44 AM

A few days ago I created a Linode server instance, using Linode's Slackware 15.0 image-file. Shortly thereafter I downloaded from SlackBuilds the "fail2ban" files, created a Slackware package, and installed the result:

Code:

fail2ban-0.11.2-x86_64-1_SBo

I soon discovered that the SSH "jail" is not enabled by default, and enabled it, and restarted fail2ban. Running this command "fail2ban-client status sshd" gives:

Code:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/secure
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

After a while it seemed to me at least some lines should have been added to the rules in "iptables", and after quite a bit of reading and studying I became convinced the output below indicates a problem.

Code:

root@darkstar:/etc/fail2ban# fail2ban-regex /var/log/secure sshd

Running tests
=============

Use   failregex filter file : sshd, basedir: /etc/fail2ban
Use         maxlines : 1
Use      datepattern : {^LN-BEG} : Default Detectors
Use         log file : /var/log/secure
Use         encoding : UTF-8

Results
=======

Prefregex: 49991 total
|  ^(?P<mlfid>(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel:\s?\[ *\d+\.\d+\]:?\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID \d+ \S+\]\s+)?)(?:(?:error|fatal): (?:PAM: )?)?(?P<content>.+)$
`-

Failregex: 16484 total
|-  #) [# of hits] regular expression
|  14) [16484] ^<F-NOFAIL>pam_[a-z]+\(sshd:auth\):\s+authentication failure;</F-NOFAIL>(?:\s+(?:(?:logname|e?uid|tty)=\S*)){0,4}\s+ruser=<F-ALT_USER>\S*</F-ALT_USER>\s+rhost=<HOST>(?:\s+user=<F-USER>\S*</F-USER>)?(?: (?:port \d+|on \S+|\[preauth\])){0,3}\s*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [49991] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-

Lines: 49991 lines, 16484 ignored, 0 matched, 33507 missed
[processed in 10.44 sec]

Ignored line(s): too many to print.  Use --print-all-ignored to print all 16484 lines
Missed line(s): too many to print.  Use --print-all-missed to print all 33507 lines

Given my server's "/var/log/secure" file, I think 49991 hits is a reasonable number to be found by the date-regex, and I think 16484 hits is a reasonable number to be found by the fail-regex. There is no regex to use for finding hits to be ignored, so I think zero is reasonable.

What seems very strange to me is the line saying

Code:

Lines: 49991 lines, 16484 ignored, 0 matched, 33507 missed

I think the line should be saying

Code:

Lines: 49991 lines, 0 ignored, 16484 matched, 33507 missed

Is anyone here running the 0.11.2 version of fail2ban on a Linode server, and if so, does fail2ban work in your instance?

ponce · 06-01-2022, 10:50 AM

have you enabled

Code:

SyslogFacility AUTHPRIV

in your /etc/ssh/sshd_config ?

if you don't do it fail2ban sshd filter cannot work...

baumei · 06-01-2022, 11:23 AM

In my Linode server's file "/etc/ssh/sshd_config" is:

Code:

# Logging
#SyslogFacility AUTH
#LogLevel INFO

As I understand the instructions, these are the defaults for SSH, and they are ON even though commented out.

Did you mean "AUTHPRIV"? The reason I ask is I do not see this listed as a possible value in the sshd_config manpage.

ponce · 06-01-2022, 11:30 AM

Code:

SyslogFacility AUTH

is the default for sshd and that means that it logs failed logins in /var/log/messages via syslog.

fail2ban instead looks for failed logins in /var/log/secure and to have sshd send them there via syslog AUTHPRIV is needed.

kjhambrick · 06-01-2022, 11:35 AM

Interesting ...

I see an sshd SyslogFacility = AUTHPRIV option in the man pages for sshd_config versions 5.3 and 7.4 but it doesn't seem to exist anymore in sshd_config version 8.8

-- kjh

ponce · 06-01-2022, 11:36 AM

Quote:

Originally Posted by kjhambrick

Interesting ...

I see an sshd SyslogFacility = AUTHPRIV option in the man pages for opensshd_config versions 5.3 and 7.4 but it doesn't seem to exist anymore in sshd_config version 8.8

-- kjh

it's probably undocumented but I can guarantee that it works (I'm using it in production with that version).

Code:

# iptables -L -n | grep reject-with\ icmp-port-unreachable | wc -l
1474

baumei · 06-01-2022, 11:39 AM

Hi ponce,

Thank you for the recommendation. :-) I changed "AUTH" to "AUTHPRIV", and restarted sshd, and already fail2ban has found four matches!

kjhambrick · 06-01-2022, 11:47 AM

Looking at Slackware64 14.2 with openssh version 7.4 AUTHPRIV isn't mentioned there either.

But it does work.

Thanks ponce !

-- kjh

p.s. the other sshd version 7.4 was from a CentOS 7 Machine

p.p.s. a new Alma 9 Machine with sshd version 8.7 does mention AUTHPRIV in `man opensshd_config`

tramtrist · 06-01-2022, 12:13 PM

That's a good tip. Thanks !

P.S. After using knockd my fail2ban logs have gone silent

baumei · 06-01-2022, 12:24 PM

Now that fail2ban is generating rules for the iptable --- I see they say "REJECT", and so I have a follow-up question.

Back when I reading in hope of figuring out my fail2ban problem, I came across where a fellow had said about iptable rules (I paraphrase):
In a world of well-intended people, REJECT is a good choice, because it informs the person at the other end there is a problem. However, in this world some nefarious people will spoof the source address and send a small packet to your/my server, and the nefarious people expect your/my server to send a larger REJECT packet to the spoofed address (their intent being to flood the spoofed address), and DROP may be a better choice.

Which is better for fail2ban to do: REJECT or DROP?

=-=-=

Edit: I remembered where it was that I read what I paraphrased above: a post by astrogeek https://www.linuxquestions.org/quest...6/#post6065704

ponce · 06-01-2022, 01:03 PM

there's a discussion about it in the following link, I'm not sure this forum is the proper place to discuss this

https://github.com/fail2ban/fail2ban/issues/507

FWIW, while, in general, I agree that DROP as a firewall rule is better, in this specific case I definitely agree with the first answer there that's also specific to the fail2ban behavior

Quote:

common sense "provide as little information as possible" concept. DROP is NO information.

The block occurs after a failure attempt. The person or script already knows there is a service there.

in other words, giving the bad guys the finger is better that going silent when they already know that you have something listening.