Christian R??ner via Postfix-devel: > > > > Am 17.12.2024 um 13:57 schrieb Wietse Venema via Postfix-devel > > <postfix-devel@postfix.org>: > > > > Wietse Venema via Postfix-devel: > >> Christian R??ner via Postfix-devel: > >>> Hello, > >>> > >>> I wanted to ask you about an idea that came up in my mind. I am > >>> developing a central authentication server (https://nauthilus.org > >>> <https://nauthilus.org/>). It can be used everywhere (currently > >>> tested with Dovecot, FreeRADIUS, OpenVPN, GitLab and many other > >>> applications), where authentication is required (and it has a bunch > >>> of anti-attack features builtin like complex brute-force detection, > >>> block lists, RBLs, Lua-Hooks). The server talks HTTP REST (mainly > >>> HTTP header based or JSON). > >>> > >>> When I looked at a way to bind Postfix to this server (Submission), > >>> I only found some undocumented Cyrus-SASL plugin, which lacks > >>> IP-address support. In fact you only get the local part, the domain > >>> and the password. No other meta information is available (like IP, > >>> SSL infos, anything else that you can get from a client connect). > >>> A current workaround is to proxy Postfix behind Dovecot. Works, > >>> but this is a dependency to another service. > >>> > >>> My question is, if you see some possibility to add some HTTP REST > >>> to Postfix to talk to such an authentication server. > >>> > >>> Furthermore I thought about HTTP-support in tables as well to > >>> communicate with modern micro services and get information for > >>> i.e. relay-domains, -recipients, check_* etc... something like a > >>> http_table? My feeling is that HTTP as a general purpose interface > >>> would enhance Postfix. > >>> > >>> Maybe you have real good reasons to not do so, but I thought I > >>> could ask here for your feedback. What do you think about HTTP > >>> REST and as an enhancement for Postfix? Do think it is a good idea > >>> or not? > >> > >> I hope that you're talking about using the Postfix lookup table > >> mechanism (a simple interface to query indexed files, LDAP or SQL > >> databases, and special-purpose tables such as regexp:, pcre: and > >> cidr:) and adding support to talk to a REST server. > >> > >> If that is not the case, and instead the idea is to add a REST > >> client to talk to your service, then such code would not be reusable, > >> in addition to all the problems that come with parsing JSON in C, > >> and to a lesser extent, parsing HTTP(S)). > > > > Or were you looking at adding a new XSASL adapter to the existing > > ones for Cyrus SASL and Dovecot? That would indeed involve a bunch > > of new C code for parsing JSON and HTTPS. I don't really trust C > > parsers for doing this, other than google.protobuf.struct. Converting > > Postfix to C++ (and Google Test) is an option that I still have not > > ruled out for the future (my work at Google was mostly C++). > > For SASL this looks more complicated. My main problem is that there > are currently either dependencies to Dovecot or only few information > for cyrus-SASL. When it comes to authentication, I cannot build > reputation without metadata like IP (ASN, country, ...), service > (in terms of Postfix: submission or smtps for example), Hostname, > SSL (ciphers, protocol, ...), etc.
The Dovecot AUTH protocol passes IP address information, ampmng other things > Many decisions could happen directly while authenticating and not > after it in the SMTP-protocol. If you do so later in MAIL FROM or > RCPT TO, the attacker already knows that her probably got correct > credentials. This is the main power of Nauthilus to early decide > on metadata. Today, people would delegate this to a postfwd policy service that receives all available sesssion state information: TLS protocol, cipher, keysize; IP address and port (server and client); SASL login, name, method; and more. https://www.postfix.org/SMTPD_POLICY_README.html#protocol For links to examples, see https://www.postfwd.org/ or https://www.postfwd.org/doc.html for the gory details. The Postfix policy delegation protocol is an extended Postfix table lookup API. The difference is that a query contains all session context information instead of just one piece. The reply is still the same as in https://www.postfix.org/access.5.html#accept_actions > >> Assuming that the idea is to use the Postfix lookup table mechanism > >> to plug in a REST client: > >> > >> The easiest way to add a REST query support to Postfix is to not > >> write Postfix code. Instead, write a small adapter and plug it into > >> an existing Postfix interface. > >> > >> For example, a local tcp_table(5) server or socketmap_table(5) > >> server that receives a query and that generates the necessasy JSON > >> and HTTP encapsulation, and vice versa for the response. > >> > >> https://www.postfix.org/tcp_table.5.html > >> https://www.postfix.org/socketmap_table.5.html > > I am writing a little Server in Go that can deal with socket-maps > as a proof-of-concept right now... > > As soon as this is ready for reviewing/testing, I will send the > Github-link. I really like the idea with socket maps for this part > of my first mail. Wietse > >> I suppose that someone could implement a robust prototype in a few > >> hours time, and productize it in a couple of days. Python or Go > >> should be up top the job. Both have mature library support for > >> JSON and HTTP(S). > >> > >> Adding this as C code is unlikely to happen, not even as a donation. > >> Postfix has a strong reputation to lose. > >> > >> Note: the current tcp_table and socketmap_table implementations do > >> not authenticate the server, and therefore refuse to be used for > >> security-sensitive queries. So a little code may be needed to wrap > >> the communication over TLS. No biggie. > >> > >> Wietse > >> > >>> Maybe Patrick-Ben Koetter likes also to answer here, as I had a > >>> phone call earlier these days with him concerning this idea. > >>> > >>> Many thanks in advance > >>> > >>> Christian R??ner -- R??ner-Network-Solutions Zertifizierter ITSiBe > >>> / CISO Marburger Str. 70a, 36304 Alsfeld Fax: +49 6631 78823409, > >>> Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website > >>> PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5 > >>> > >>> _______________________________________________ Postfix-devel > >>> mailing list -- postfix-devel@postfix.org To unsubscribe send an > >>> email to postfix-devel-le...@postfix.org > >>> > >> _______________________________________________ > >> Postfix-devel mailing list -- postfix-devel@postfix.org > >> To unsubscribe send an email to postfix-devel-le...@postfix.org > >> > > _______________________________________________ > > Postfix-devel mailing list -- postfix-devel@postfix.org > > To unsubscribe send an email to postfix-devel-le...@postfix.org > > > Christian R??ner > -- > R??ner-Network-Solutions > Zertifizierter ITSiBe / CISO > Marburger Str. 70a, 36304 Alsfeld > Fax: +49 6631 78823409, Mobil: +49 171 9905345 > USt-IdNr.: DE225643613, https://roessner.website > PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5 > > _______________________________________________ > Postfix-devel mailing list -- postfix-devel@postfix.org > To unsubscribe send an email to postfix-devel-le...@postfix.org > _______________________________________________ Postfix-devel mailing list -- postfix-devel@postfix.org To unsubscribe send an email to postfix-devel-le...@postfix.org
