[syslog-ng] proftpd, blog

[Peter Czanik]

On 10/06/2010 04:03 PM, Balazs Scheidler wrote:
> On Tue, 2010-10-05 at 16:50 +0200, Peter Czanik wrote:
>   
>> Hello,
>>
>> Attached is a pre version of proftpd login/logout/failure events and the
>> samples I used. As usual, new application, new problems.
>>
>> The first problem is, that out of box proftpd uses its own log files
>> instead of syslog. This poses a couple of problems:
>> * it resembles syslog logs, but looking closer it is not
>> * it does not have all the logs
>> So for collecting logs I commented out the SystemLog line, so syslog is
>> used, and also enabled anonymous ftp.
>>
>> I could not find a perfect message suitable for 'logout'. There are two
>> related lines:
>>
>> proftpd[6848]: ubuntu (::ffff:192.168.2.179[::ffff:192.168.2.179]) - FTP
>> session closed.
>> But this is used any time a TCP/IP connection is closed, even when there
>> was no actual login. And even if there was a login, it has no user
>> information...
>>
>> proftpd: pam_unix(proftpd:session): session closed for user czanik
>> This one has the user name, but no information at all about the session
>> or IP address.
>>     
> do you have any identifying information that you could possibly use to
> correllate the two entries?
>   
The "session closed" message has the IP address, but many companies, not
just SoHo, have many users behind a single IP address, so it does not help.

> PID for instance?
>   
The "session closed" has PID, but the pam message, where the user name
is available, there is no PID :-(

> I've doubts doing correllation just for the sake of the logout event,
> because the length of the session can be quite long. (so what timeout
> would you specify for the correllation engine 1 day? 7 days?)
>   
In a webhosting environment I have often seen multiple day ftp
connections. With thousands of ftp connections an hour it's better not
to think about the memory requirements of correlating this :-)

> I'd use the PAM generated event (e.g. session closed for user ...) and
> the IP address is not that important in this case, because it is present
> in the login event. you'd only need to make sure that the login/logout
> events can be correllated at query time somehow. e.g. usracct.sessionid
> should be the same for the two messages.
>   
PAM only has the usracct.username, no sessionid. And one user can login
many times, for example AFAIR windows explorer opens two different
connections, and the second one is not necessarily terminated at the
same time. Or some download managers open 5-10 simultaneous connections
with the same username.

Summary: neither information seems to be useful in real life situations...

>   
>> What do you think? Could any of these be useful for creating name -
>> value pairs?
>>
>> Also: if I discard some messages, like opening/closing a session, is it
>> enough if I handle it with one rule (omitting checking the end of
>> message) or it should be handled with two separate messages?
>>     
> I don't understand this.
>   
Consider these lines:

Oct  5 03:10:46 ubuntu proftpd[6820]: ubuntu
(::ffff:192.168.2.179[::ffff:192.168.2.179]) - FTP session opened.
Oct  5 03:10:54 ubuntu proftpd[6820]: ubuntu
(::ffff:192.168.2.179[::ffff:192.168.2.179]) - FTP session closed.

Both of these are parsed, but no name value pairs are created for either
of these. Should they be in separate rules, or could be handled with a
single:

@ESTRING:: @(@ESTRING::[@@ESTRING::]@) - FTP session

Notice the missing opened./closed. at the end. And the same goes for:

Oct  5 03:12:00 ubuntu proftpd: pam_unix(proftpd:session): session
opened for user czanik by (uid=0)
Oct  5 03:12:03 ubuntu proftpd: pam_unix(proftpd:session): session
closed for user czanik

Which could be handled with a single:

pam_unix(proftpd:session): session

Instead of having a separate rule for both cases.

Bye,
CzP

>   
>> And finally some self marketing, hoping that it might be useful some
>> someone: please check my blog (URL in my signature), I have already have
>> two blog posts about pattern writing. Please comment on them here on the
>> mailing list, as if you find something problematic, it should be
>> discussed, and without an additional blog comment login...
>>     
>   


-- 
Peter Czanik (CzP) <czanik at balabit.hu>
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/