understanding the logs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

understanding the logs

Geert Mak
Hi,

We had a user account hacked (weak password) and our SMTP server was used for sending spam. We discovered it after our mail server IP began to show up in RBLs. We improved the passwords, however the question is how best to watch the server in case a similar thing happens again.

We created a small regex based log analyzer and received the following result (see below) -

The question is: is there somewhere a description what each entry means?

If not: which number shows the number of e-mails sent by the mail server? Or should we dig deeper into some of the entries or combine some or both? Our current idea is that if we watch this number for unusual increase, we will be able to discover abuse this way before we discover it by the means of RBL.

Geert

RESULT:
-------

LINES TOTAL: 4328247

LINES_LOGIN: 20353
LINES_LOGOUT: 0
LINES_AMAVIS: 0
LINES_CYRUS_CTL_CYRUSDB: 749
LINES_CYRUS_CYR_EXPIRE: 11397
LINES_CYRUS_IMAP: 6874
LINES_CYRUS_LMTPUNIX: 8711
LINES_CYRUS_MASTER: 2182
LINES_CYRUS_TLS_PRUNE: 4
LINES_DOVECOT: 960
LINES_IMAPPROXYD: 0
LINES_POSTFIX_ANVIL: 999
LINES_POSTFIX_BOUNCE: 193
LINES_POSTFIX_CLEANUP: 1446
LINES_POSTFIX_ERROR: 974
LINES_POSTFIX_LMTP: 902
LINES_POSTFIX_LOCAL: 221
LINES_POSTFIX_PICKUP: 443
LINES_POSTFIX_QMGR: 3096601
LINES_POSTFIX_VERIFY: 0
LINES_POSTFIX_POSTMAP: 0
LINES_POSTFIX_TLSMGR: 0
LINES_POSTFIX_MASTER: 0
LINES_POSTFIX_SCACHE: 261
LINES_POSTFIX_SMTP: 20346
LINES_POSTFIX_SMTPD: 1154379
LINES_SPAMD: 0
LINES_POSTFIX: 0
LINES_POSTFIX_POSTFIX_SCRIPT: 0
LINES_POSTFIX_TRIVIAL_REWRITE: 252

LINES NOT PROCESSED: 0




Reply | Threaded
Open this post in threaded view
|

Re: understanding the logs

Stan Hoeppner
On 11/8/2011 1:13 AM, Geert Mak wrote:

> We had a user account hacked (weak password) and our SMTP server was used for sending spam. We discovered it after our mail server IP began to show up in RBLs. We improved the passwords, however the question is how best to watch the server in case a similar thing happens again.

1.  Create and enforce a minimum password complexity policy, preferably
on your web based account creation page, something like:

http://www.webresourcesdepot.com/10-password-strength-meter-scripts-for-a-better-registration-interface/

2.  Install/configure http://www.policyd.org/
Create an outbound policy limiting users to 30 messages/hour, or one
message every 2 minutes.  This will mitigate the damage the next time an
account is hijacked.

Season to taste.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: understanding the logs

Robert Schetterer
In reply to this post by Geert Mak
Am 08.11.2011 08:13, schrieb Geert Mak:

> Hi,
>
> We had a user account hacked (weak password) and our SMTP server was used for sending spam. We discovered it after our mail server IP began to show up in RBLs. We improved the passwords, however the question is how best to watch the server in case a similar thing happens again.
>
> We created a small regex based log analyzer and received the following result (see below) -
>
> The question is: is there somewhere a description what each entry means?
>
> If not: which number shows the number of e-mails sent by the mail server? Or should we dig deeper into some of the entries or combine some or both? Our current idea is that if we watch this number for unusual increase, we will be able to discover abuse this way before we discover it by the means of RBL.
>
> Geert
>
> RESULT:
> -------
>
> LINES TOTAL: 4328247
>
> LINES_LOGIN: 20353
> LINES_LOGOUT: 0
> LINES_AMAVIS: 0
> LINES_CYRUS_CTL_CYRUSDB: 749
> LINES_CYRUS_CYR_EXPIRE: 11397
> LINES_CYRUS_IMAP: 6874
> LINES_CYRUS_LMTPUNIX: 8711
> LINES_CYRUS_MASTER: 2182
> LINES_CYRUS_TLS_PRUNE: 4
> LINES_DOVECOT: 960
> LINES_IMAPPROXYD: 0
> LINES_POSTFIX_ANVIL: 999
> LINES_POSTFIX_BOUNCE: 193
> LINES_POSTFIX_CLEANUP: 1446
> LINES_POSTFIX_ERROR: 974
> LINES_POSTFIX_LMTP: 902
> LINES_POSTFIX_LOCAL: 221
> LINES_POSTFIX_PICKUP: 443
> LINES_POSTFIX_QMGR: 3096601
> LINES_POSTFIX_VERIFY: 0
> LINES_POSTFIX_POSTMAP: 0
> LINES_POSTFIX_TLSMGR: 0
> LINES_POSTFIX_MASTER: 0
> LINES_POSTFIX_SCACHE: 261
> LINES_POSTFIX_SMTP: 20346
> LINES_POSTFIX_SMTPD: 1154379
> LINES_SPAMD: 0
> LINES_POSTFIX: 0
> LINES_POSTFIX_POSTFIX_SCRIPT: 0
> LINES_POSTFIX_TRIVIAL_REWRITE: 252
>
> LINES NOT PROCESSED: 0
>
>
>
>
Hi, there is lees you can do about pirating accounts
check your password mechs and other stuff which is involved at
account/password creation/changing, monitor this, monitor and ban
brute force attacks to your accounts ( i.e. fail2ban )
perhaps slow down outgoing deliver rates, as workaround use
clamav-milter with sanesecurity antispam/pish signatures with hold, so
you get aware
be deliver out spam, at last what is needed is some "intruder detection"
based on monitoring anomalies at outgoing smtp traffic , we are working
on some milter which does this, but we are not in production stage yet
however looking at log is daily work, so no magical software will help
you get out of this in total, anyway good log parsers will help ( i.e
pflogsumm etc )
for understanding log stuff, read postfix faqs and search list archives
for log entries you dont understand, and/or ask here

--
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria
Reply | Threaded
Open this post in threaded view
|

Re: understanding the logs

Simon Brereton-2
In reply to this post by Stan Hoeppner
On 8 November 2011 02:53, Stan Hoeppner <[hidden email]> wrote:
> On 11/8/2011 1:13 AM, Geert Mak wrote:
>
>> We had a user account hacked (weak password) and our SMTP server was used for sending spam. We discovered it after our mail server IP began to show up in RBLs. We improved the passwords, however the question is how best to watch the server in case a similar thing happens again.
>
> 1.  Create and enforce a minimum password complexity policy, preferably
> on your web based account creation page, something like:
>
> http://www.webresourcesdepot.com/10-password-strength-meter-scripts-for-a-better-registration-interface/

For password strength, I'm not sure the conventional wisdom of numbers
and punctuation are relevant any more.  They help when the attacker is
known to you, but password length is a much better indicator of
entropy resistance.

http://xkcd.com/936/

Simon