# fail2ban, sshd, and auth.log

## figueroa

I installed and configured fail2ban (mainly for sshd) on my up-to-date x86, stable, openrc server. However, it would not start with an error messge:

```
# /etc/init.d/fail2ban start

 * Caching service dependencies ...                                       [ ok ]

 * Starting fail2ban ...

2020-08-20 23:07:55,169 fail2ban                [23296]: ERROR   Failed during configuration: Have not found any log file for sshd jail

 * start-stop-daemon: failed to start `/usr/bin/fail2ban-client'

 * Failed to start fail2ban                                               [ !! ]

 * ERROR: fail2ban failed to start
```

I found a hint at github that the missing log file might actually be auth.log so I created a dummy auth.log with "touch /var/log/auth.log"

Sure enough, fail2ban started fine. I don't think it's going to work. sshd logs are actually in a directory /var/log/sshd, not /var/log/auth.log

The sshd section of my /etc/jail.local contains:

```
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:

# normal (default), ddos, extra or aggressive (combines all).

# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.

#mode   = normal

port    = ssh

logpath = %(sshd_log)s

backend = %(sshd_backend)s

enabled = true

maxretry = 3
```

Apparently the default logpath isn't right, but why not? I don't understand the notation. in the configuration file.

When I run "fail2ban-client status sshd" it shows:

```
Status for the jail: sshd

|- Filter

|  |- Currently failed:   0

|  |- Total failed:   0

|  `- File list:   /var/log/auth.log

`- Actions

   |- Currently banned:   0

   |- Total banned:   0

   `- Banned IP list:   
```

It's looking for the sshd logs in /var/log/auth.log.  What's the proper fix?

Why didn't I have an auth.log?

----------

## figueroa

Maybe I got it to work. I changed the logpath configuration in the sshd section to read:

```
logpath = /var/log/sshd/*
```

Then "fail2ban-client status sshd" shows:

```
Status for the jail: sshd

|- Filter

|  |- Currently failed:   0

|  |- Total failed:   0

|  `- File list:   /var/log/sshd/log-2020-08-21-02:47:39 /var/log/sshd/log-2020-08-17-04:07:52 /var/log/sshd/log-2020-08-18-17:44:29 /var/log/sshd/log-2020-08-19-07:12:45 /var/log/sshd/log-2020-08-20-04:22:29 /var/log/sshd/current

`- Actions

   |- Currently banned:   0

   |- Total banned:   0

   `- Banned IP list:   
```

Apparently none of the other jails are going to work either without hand-jamming them somehow.

----------

## araxon

The log path probably depends on your system logger. Syslog-ng logs to /var/log/messages by default.

----------

## halcon

 *figueroa wrote:*   

> 
> 
> ```
> logpath = /var/log/sshd/*
> ```
> ...

 

WIth this configuration (*) you are increasing significantly the amount of logs for fail2ban to read, by "feeding" him not only the current log, but old ones as well.

 *araxon wrote:*   

> Syslog-ng logs to /var/log/messages by default.

 

Syslog-ng has also an easy way to split log into three files:

```
destination d_unix {

    file("/var/log/<some path for syslog-ng logs>/unix-stream"); 

};

destination d_internal {

    file("/var/log/<some path for syslog-ng logs>/internal"); 

};

destination d_kernel {

    file("/var/log/<some path for syslog-ng logs>/kernel");

};
```

And then, in jail.local, in sshd section:

```
logpath  = /var/log/<some path for syslog-ng logs>/unix-stream
```

----------

## figueroa

 *araxon wrote:*   

> The log path probably depends on your system logger. Syslog-ng logs to /var/log/messages by default.

 

Thank you for commenting.

I'm using metalog + ulogd. Generally, my logs are coherent, well ordered, and useful. But, I've been wondering why I don't have certain files like auth.log, syslog or messages.  Furthermore some of the logs are binary unreadable trash, notably lastlog, tallylog, wtmp, faillog. Figuring those out have been on my recent do list.

I thought fail2ban was going to work out-of-the-box with minor configuration as I've experienced on Debian-based machines. The elog message didn't mention the logger. man fail2ban-client doesn't has log related definitions but not helpful.

Changing logger doesn't seem trivial.

----------

## figueroa

 *halcon wrote:*   

>  *figueroa wrote:*   
> 
> ```
> logpath = /var/log/sshd/*
> ```
> ...

 

Thanks for the feedback.  Does it matter that fail2ban is reading all the logs in /var/log/sshd/? Each line in those logs has a date/time. I'm assuming fail2ban will know what to do with them.

----------

## halcon

 *figueroa wrote:*   

> Does it matter that fail2ban is reading all the logs in /var/log/sshd/? Each line in those logs has a date/time. I'm assuming fail2ban will know what to do with them.

 

Yes, he knows what to do, and sees the date/time. But I would limit the configuration entry with the current log only, because it's an extra work for fail2ban, at least at the restart, when it reads all the logs, finds duplicates etc. If the log is large, the restart can take seconds... (Maybe I don't know some tricks; just my experience.)

EDIT:

...since only one file will get new messages, the monitoring of other files is unneeded, especially if polling backend is used.

(from here)

----------

## figueroa

 *halcon wrote:*   

> Yes, he knows what to do, and sees the date/time. But I would limit the configuration entry with the current log only, because it's an extra work for fail2ban, at least at the restart, when it reads all the logs, finds duplicates etc. If the log is large, the restart can take seconds... (Maybe I don't know some tricks; just my experience.)
> 
> EDIT:
> 
> ...since only one file will get new messages, the monitoring of other files is unneeded, especially if polling backend is used.
> ...

 

Thanks for confirming that, and thanks for the link. I've got very aggressive settings in my /etc/fail2ban/jail.local

```
bantime = 72h

findtime = 48h

maxretry = 3
```

so at startup, I need to read more than just the /var/log/sshd/current file.

I have confirmed that it works, at least with ssh. I managed to get myself banned from a remote server experimentally. This is a very useful program. I have a couple of remote desktops I maintain for a school that were getting flooded with ssh hits from usual culprits. These are Debian based, and fail2ban setup was easier. I've managed to get the hacking bots down from a flood to a trickle.

----------

