Fred Morris:
> Hello everyone, and the 10 people who care. On Friday I wrote hoping for
> contact with someone interested in discussing security risks pertaining
> to TCP maps and there's been no response.
>
> Let me offer you some Monday morning entertainment with this:
>
> # postmap -q "foo-mtausers-0t3" tcp:athena.m3047.net:3047
> foo
Snip.
> From an opsec perspective I wouldn't recommend running a service which
> enumerates accounts and email aliases for all the world to see,
> encrypted or not. However the risks and mitigations of doing so on
> loopback or in a VPC are fairly well understood, moreso by people who
> architect with such information available by design as a matter of course.
>
> What's the chief security concern with TCP tables, and does the
> operational environment impact it? Is there an underlying vulnerability
> in postfix itself, or is it a general allergy to running unencrypted
> internet services even on loopback?
As documented in the tcp_table manpage, the connection is not
protected and the server is not authenticated, meaning that the
client has no certainty that the data it receives is the same as
the data that would have been sent by the intended server.
There is also the issue of publishing data to unauthenticated
clients, but that issue would also exist with TLS.
I don't recall that tcp_table has the equivalent of
smtp_per_record_deadline and smtpd_per_record_deadline, meaning
that a hostile server could trickle bytes very slowly and keep a
connection active for $daemon_timeout seconds before triggering a
watchdog timeout on the Postfix side. But fixing that seems a low
priority, because no-one should introduce a critical dependency in
this way.
Wietse
