Limit messages sent per unit time?
Is there a way to limit messages sent per unit time? Thank you, Paul
Re: Limit messages sent per unit time?
On 2023-12-06 19:47, Paul Pace wrote: Is there a way to limit messages sent per unit time? Maybe it's just not possible in OpenSMTPD? My use case is I have a small cluster of servers that use a single server as an SMTP relay. One of the servers hosts stuffs that have a somewhat higher probability of being compromised, so one method I would like to use to limit the potential damage done by a compromised server is to rate limit messages sent, ideally by some number of messages per unit time (probably 1 per 10 seconds, since it isn't expected to send much mail). Thank you, Paul
Re: Limit messages sent per unit time?
So your question made me curious to read more of the source... and there are actually multiple undocumented knobs, and there might be this one that maybe works for you, e.g. put this in you smtpd.conf for a minimum of 10s delay between MTA transactions: mta limit session-transaction-delay 10 This would not start any new transaction before 10s passed since the last one. I just gave it a try - submit n mails, observe that the first one goes out right away, watch via smtpctl show queue that the other ones are delayed (or use the tracing and debug flags when running smtpd). If nothing was scheduled for longer than that, any new one gets sent right away. There are quite a few more knobs, unsure why they aren't documented but this might be intentional, as you can probably seriously shoot yourself in the foot changing some of those. Hope this helps, but no guarantees there are no side effects. PS: can't help but point out that if I understand your use case correctly, this won't really prevent abuse, b/c if your system is compromised, the attacker might also just modify the config, no? On Sat, Dec 09, 2023 at 07:09:16AM -0800, Paul Pace wrote: On 2023-12-06 19:47, Paul Pace wrote: Is there a way to limit messages sent per unit time? Maybe it's just not possible in OpenSMTPD? My use case is I have a small cluster of servers that use a single server as an SMTP relay. One of the servers hosts stuffs that have a somewhat higher probability of being compromised, so one method I would like to use to limit the potential damage done by a compromised server is to rate limit messages sent, ideally by some number of messages per unit time (probably 1 per 10 seconds, since it isn't expected to send much mail). Thank you, Paul
Re: Limit messages sent per unit time?
This is very helpful, thank you. On 12/9/23 8:26 AM, Tassilo Philipp wrote: So your question made me curious to read more of the source... and there are actually multiple undocumented knobs, and there might be this one that maybe works for you, e.g. put this in you smtpd.conf for a minimum of 10s delay between MTA transactions: mta limit session-transaction-delay 10 Is there any way to limit where this is implemented? Such as only sessions from a specific server (via tag, action, match, etc.)? This would not start any new transaction before 10s passed since the last one. I just gave it a try - submit n mails, observe that the first one goes out right away, watch via smtpctl show queue that the other ones are delayed (or use the tracing and debug flags when running smtpd). If nothing was scheduled for longer than that, any new one gets sent right away. There are quite a few more knobs, unsure why they aren't documented but this might be intentional, as you can probably seriously shoot yourself in the foot changing some of those. Hope this helps, but no guarantees there are no side effects. PS: can't help but point out that if I understand your use case correctly, this won't really prevent abuse, b/c if your system is compromised, the attacker might also just modify the config, no? My current understanding is we could consider some different levels of compromise: 1. Only the service is compromised (e.g., PHP) - this would limit message sending to how the server is configured to send mail. 2. The root user is compromised - this would limit message sending with the server, itself. In scenario 1, only the mail relay server can be used for sending messages. The service compromised does not have root privileges and there are not other configured methods for sending mail (the firewall does not allow destination port 25 on the external interface). In scenario 2, the compromised server can be used for sending spam because root has been compromised so the firewall rules can be rewritten, but the separate mail relay server still can be used for sending spam and likely has a decent reputation. In both scenarios I would like to limit the damage done to the mail relay server. Even if the above rule is only applied to client server, at least in the event an attacker only compromises a service I can still limit damage to the mail relay server IP address reputation. On Sat, Dec 09, 2023 at 07:09:16AM -0800, Paul Pace wrote: On 2023-12-06 19:47, Paul Pace wrote: Is there a way to limit messages sent per unit time? Maybe it's just not possible in OpenSMTPD? My use case is I have a small cluster of servers that use a single server as an SMTP relay. One of the servers hosts stuffs that have a somewhat higher probability of being compromised, so one method I would like to use to limit the potential damage done by a compromised server is to rate limit messages sent, ideally by some number of messages per unit time (probably 1 per 10 seconds, since it isn't expected to send much mail). Thank you, Paul
Re: Limit messages sent per unit time?
mta limit session-transaction-delay 10 Is there any way to limit where this is implemented? Such as only sessions from a specific server (via tag, action, match, etc.)? From my limited understanding of the few bits of code I read, around this and other mta options, those "limit" options seems to be global. There are other (global) knobs that maybe do something to the scheduling per domain or host, but I haven't tried any of those and I think they rather apply to retries. Check out ./usr.sbin/smtpd/limit.c, function limit_mta_set(). I ran a few rough grep(1)s through the sources, by guessing related strings, but I didn't find anything related to action or match. My current understanding is we could consider some different levels of compromise: 1. Only the service is compromised (e.g., PHP) - this would limit message sending to how the server is configured to send mail. [...] at least in the event an attacker only compromises a service I can still limit damage to the mail relay server IP address reputation. Mh... good thinking, I agree. I appreciate you sharing your reasoning :)