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@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/