Re: Drop connection after N errors?
On Mon, Aug 02, 2021 at 04:11:42PM -0400, John Levine wrote:
> People in the web world are in a kerfuffle about an attack called ALPACA
> which (leaving out
> a lot of details) gets a web browser to send requests to a non-web server and
> then get the
> browser to interpret the responses in unfortunate ways. Most of the
> unfortunateness comes
> from the server replying to invalid commands and including parts of the
> commands in the reply.
> Since most mail servers will let you send a lot of invalid commands, the bad
> guy can splice
> a lot of bits of invalid command response together.
>
> It occurs to me that real mail clients almost never send invalid commands, so
> if a server
> sees more than, say, two of them, it's not a real client, so it's better to
> disconnect.
>
> I don't see a parameter to limit the number of bad commands in a session. Is
> there one?
> Would it be hard to add?
>
> R's,
> John
>
> PS: I know this is not our problem but the web crowd can be awfully pushy.
It's already there, and it stops at the first invalid command:
smtpd_forbidden_commands (default: CONNECT GET POST regexp:{{/^[^A-Z]/
Bogus}})
Perhaps other HTTP reqeust methods could be added
(i.e. HEAD PUT DELETE OPTIONS TRACE PATCH) but it's
probably enough as it is.
cheers,
raf
Re: Drop connection after N errors?
John Levine:
> People in the web world are in a kerfuffle about an attack called ALPACA
> which (leaving out
> a lot of details) gets a web browser to send requests to a non-web server and
> then get the
> browser to interpret the responses in unfortunate ways. Most of the
> unfortunateness comes
> from the server replying to invalid commands and including parts of the
> commands in the reply.
> Since most mail servers will let you send a lot of invalid commands, the bad
> guy can splice
> a lot of bits of invalid command response together.
>
> It occurs to me that real mail clients almost never send invalid commands, so
> if a server
> sees more than, say, two of them, it's not a real client, so it's better to
> disconnect.
>
> I don't see a parameter to limit the number of bad commands in a session. Is
> there one?
> Would it be hard to add?
Postfix wasn't 'usable' for an ALPACA attack because it drops the connection
after receiving what looks like an HTTP command, whether before STARTTLS
or after. The Postfix hard error limit is more forgiving, with a default of
smtpd_hard_error_limit = ${stress?{1}:{20}}
Wietse
Re: Drop connection after N errors?
The ALPACA paper (table 2+3)/website explain that postfix is not vulnerable to this problem - postfix drops the connection immediately on common HTTP commands. -- Please don't Cc: me, use only the list for replies.
Re: Drop connection after N errors?
I don't see a parameter to limit the number of bad commands in a session. Is there one? http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit
Drop connection after N errors?
People in the web world are in a kerfuffle about an attack called ALPACA which (leaving out a lot of details) gets a web browser to send requests to a non-web server and then get the browser to interpret the responses in unfortunate ways. Most of the unfortunateness comes from the server replying to invalid commands and including parts of the commands in the reply. Since most mail servers will let you send a lot of invalid commands, the bad guy can splice a lot of bits of invalid command response together. It occurs to me that real mail clients almost never send invalid commands, so if a server sees more than, say, two of them, it's not a real client, so it's better to disconnect. I don't see a parameter to limit the number of bad commands in a session. Is there one? Would it be hard to add? R's, John PS: I know this is not our problem but the web crowd can be awfully pushy.
