Selective and efficient logging of auth/connection information

[Christian Winter]

Peter Stuge wrote:
> Christian Winter wrote:
>   
>> aim is to circumvent expensive and delayed mechanisms like
>> tail()ing syslog to get to the required info
>>     
>> and be able to take appropriate action (like blocking
>> a host via the firewall) as quick as possible.
>>
>> So I thought about implementing a simple daemon that listens on a
>> Unix Fifo and gets fed
>>     
>
> The above is exactly what syslog does. There are many different
> syslogds out there, I particularly like syslog-ng because it's easy
> to create filters, and it can log selectively to pipes. This makes it
> very easy to accomplish what you want.
>   
I'm aware that syslog is capable of that, but I'm not very fond
of the thought of feeding all information unassorted to a monolithic
dinosaur only to pick them apart afterwards. I've done filtering
and parsing in syslog or written my optimized alternatives to that,
but in the long run, disassembling what shouldn't be mixed together
in the first place turned out to be PITA, and nothing more. I don't
want to have to make up my mind each time anew with each minor update and
check whether some odd change has been introduced into the log format.
And the whole mix-and-filter setup brings with itself performance
penalties which, in my personal opinion, could and should be reduced
by a huge number.
>> the neccessary parts from opensshd in a concise single-line format.
>>     
>
> So this would be the real addition - that sshd contains policy on
> what the system should do.
>   
Forgive me if I sound a bit harsh, but you're seriously misinterpreting
what is clearly written. sshd should neither contain anything policy-
like, nor should it even be aware that there might be something like that.
All I want is a performant, clean interface where I can fetch well-formated
and -defined status changes.

> This has been brought up several times, and always rejected for good
> reason; It's not the job of sshd to implement e.g. a firewall policy.
>   

Though it should be the job of sshd to make its information available
selectively, concisely and in a performance optimized and secure way.

In a perfect world, I'd be able to tell sshd I want to be notified
of successful logins, failed logins and perhaps other things like
failed connection attempts. In that perfect world, I'd have all
the crucial information which define such an event available, like
client and server ip, the attempted user name and a timestamp. In
that perfect world, even a bot net attacking my server on all open
ports with invalid data and causing syslog to almost freak wouldn't
immediately cause things to go haywire, because my listening daemon
would still get the information for every connection in time and
react accordingly. In the perfect world, even syslog running out of
disk space wouldn't kill me, because I'd fetch all the neccessary
information in-memory.

In the imperfect world I'm now in, I have syslog as a single point
of failure and a constantly changing set of patterns that I have to
monitor to become aware of attacks, sometimes with quite a delay too.
The only place to change that seems to be in sshd, so for me the question
is how, not if.

Best Greetings
-Chris