> Am 17.12.2024 um 16:33 schrieb Wietse Venema via Postfix-devel > <postfix-devel@postfix.org>: > > 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.
Yes, policy delegation might be okay, but it lacks username and password. Either a service would run in smtpd_client/helo_restrictions or earliest possible stage would be smtpd_sender/recipient_restrictions. The authentication is in the middle of both and there for lacks full meta data. Am I right? Dovecot itself provides all meta data and so policies can be done directly in the authentication step, leaving an attacker unknown, if he/she was actually successful with login/credentials. By the way: Thank you very much that you spend some time here thinking and discussing. > 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. Here is my first work: https://github.com/croessner/pfxhttp Still untested. But wanted to share it with you. > 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 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
