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
    # postmap -q "foo-postfix-0f2" tcp:athena.m3047.net:3047
    foo
    # postmap -q "griselda-postfix-xip" tcp:athena.m3047.net:3047
    foo
    # postmap -q "postfixismymta.75" tcp:athena.m3047.net:3047
    baz

(I don't promise to leave that running on the internet forever, but
there it is for now.) It's running https://github.com/m3047/trualias and
in particular the rules defined in python/trualias.conf.sample.

As you've probably figured out, this is a service which converts aliases
into delivery accounts with some kind of alias validation, as opposed to
stemming accounts or wildcarding an entire domain. (Although it supports
that too, read the docs.)

Instructions on how to recompile local(8) without the security
restrictions which prevent the use of TCP maps for alias lookups are
also provided.

>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?

Respectfully...

--

Fred Morris


Reply via email to