search

haraka / Haraka

A fast, highly extensible, and event driven SMTP server
https://haraka.github.io
MIT License
5.02k stars 662 forks source link

[core] hook=rcpt plugin=limit function=max_recipients not functioning ? #1729

Closed tmechlinski closed 7 years ago

tmechlinski commented 7 years ago

system info

Haraka Haraka.js — Version: 2.8.10
Node v6.9.1
OS FreeBSD haraka 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
openssl OpenSSL 1.0.1s-freebsd 1 Mar 2016

Expected behavior

Disconnect after: limit.ini [recipients] max=20

Observed behavior

Still connected during one SMTP session:

2016-11-23T13:14:15.277Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [spf] identity=mfrom ip=14.221.221.196 domain="abcd.ab" mfrom=oqsv@abcd.ab result=Fail 2016-11-23T13:14:15.277Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [spf] scope: mfrom, result: Fail, domain: abcd.ab 2016-11-23T13:14:15.294Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [rcpt_to.qmail_deliverable] not deliverable 2016-11-23T13:14:19.297Z [NOTICE] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [core] sender oqsv@abcd.ab code=CONT msg="" 2016-11-23T13:14:19.300Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [rcpt_to.qmail_deliverable] not local 2016-11-23T13:14:23.300Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [core] hook=rcpt plugin=limit function=max_recipients params="jijing667@163.com" retval=DENYSOFT msg="Too many recipients" 2016-11-23T13:14:23.301Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [watch] watch deny saw: limit deny from rcpt 2016-11-23T13:14:23.301Z [NOTICE] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [core] recipient jijing667@163.com code=DENYSOFT msg="Too many recipients" sender="oqsv@abcd.ab" 2016-11-23T13:14:23.302Z [INFO] [F088DB06-76CE-4D6E-8856-7FC846E19A26.238] [karma] score: -38, awards: 031,032,113,112,111,115,116,130,133,150, fail:rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, early_talker, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to

Steps to reproduce

During SMTP connection testing many rcpt_to to find valid user name.

msimerson commented 7 years ago

karma is overriding the deny.

By default, karma is configured not to intercept denials by the limit plugin in this section of karma.ini:

[deny_excludes]
; karma captures and scores deny requests from other plugins, permitting finer
; control over connection handling. For plugins that should be able to reject
; the connection, add their name to the plugin list:
plugins=send_email, access, helo.checks, data.headers, mail_from.is_resolvable, avg, clamd, limit, attachment, tls

; hooks whose DENY rejections should be not be captured.
hooks=rcpt_to, queue

Have you altered those settings in your karma.ini?

msimerson commented 7 years ago

Actually, there's one more explanation for this. If the client was SMTP PIPELINING, then all the recipients are sent before we return our first response. The result would look exactly like this sample. In any case, exactly the right thing happened: we returned an appropriate error.

msimerson commented 7 years ago

There is room here though for improvement. During presentation, this:

fail:rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, early_talker, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to, rcpt_to

could instead be presented as:

fail:rcpt_to (236), early_talker
tmechlinski commented 7 years ago

Was missing in my karma.ini ; hooks whose DENY rejections should be not be captured. hooks=rcpt_to, queue

What is default settings in this case ?

msimerson commented 7 years ago

To see any plugins default config file, just look at the file contents in the repo.

smfreegard commented 7 years ago

Actually, there's one more explanation for this. If the client was SMTP PIPELINING, then all the recipients are sent before we return our first response.

FYI - that's not how Haraka's command loop works. When a client pipelines, the commands are buffered and we respond to each in turn, same as we would if they weren't pipelining, so pipelining is transparent to us.

tmechlinski commented 7 years ago

After altered settings in my karma.ini it looks like this:

2016-11-24T09:36:39.913Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3A@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:36:39.955Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:36:43.963Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3B@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:36:44.007Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:36:48.029Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3C@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:36:48.072Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:36:52.085Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3D@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:36:52.126Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:36:56.137Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3E@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:36:56.181Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:37:00.199Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3F@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:37:00.280Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:37:04.291Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3G@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:37:04.335Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable 2016-11-24T09:37:08.355Z [NOTICE] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [core] recipient A3H@abcd.ab code=DENYSOFT msg="Too many recipients" sender="AA9@ala.pl" 2016-11-24T09:37:08.401Z [INFO] [2949D230-A5CF-4E07-9254-66624DE0179B.1] [rcpt_to.qmail_deliverable] not deliverable

When it stops ? Never ?

msimerson commented 7 years ago

@tmechlinski, you seem to be missing the distinction between the maximum number of recipients that Haraka (via limit) will accept versus the number of attempts that a remote can make. The former is limited, the latter is not.

If you wish to restrict the number of recipients a remote can attempt, you can extend the limit plugin to add this feature and disconnect them after N attempts. However, I'd question the wisdom of it. You're already limiting the maximum number of recipients and additional attempts are all going to get the same DENYSOFT response. Let the remote try all day long if they wish.

There really isn't any security benefit to disconnecting after N recipients because the remote can immediately reconnect and try again. Which is why I think it's better not to limit the attempts beyond inserting a progressively longer delay between each attempt. IMO, slowing each connection, in conjunction with connection limits, does far a wonderfully adequate job of deterring bruteforce attacks.

tmechlinski commented 7 years ago

I agree with You but this is an easy way to find out the correct mailing addresses. Of course, while many attempts. How make it more difficult ? Forcing reconecct ? Slowing down answers ? Any other limits ?

msimerson commented 7 years ago

Forcing reconnect just increases YOUR servers cost. The best way I've found to limit bruteforce attacks (password hacking, recipient enumeration, etc..) is to progressively slow down the replies.

The only improvement I've seen upon simply slowing connections is my karma plugin that adaptively slows connections based on the behavior/reputation of the remote. That way Well Known Senders and well behaved senders to my server have no delays at all and unknown and poorly behaved ones have a single progressively slower connection.

tmechlinski commented 7 years ago

Thanks a lot.