Can you elaborate on the nature of the bottleneck which is preventing new, good connections, etc.? Is it related to CPU, network bandwidth, or something internal to the code, etc.?
By default the broker caches the result of both successful and failed authentication in order to reduce strain on the broker and any underlying systems (e.g. LDAP). Have you disabled this caching? You mention that "some broker versions (e.g. 2.27.1) are very sensitive." Does that mean that other versions are *not* sensitive in the same way? If so, which versions? Ultimately just about any software serving clients on a network is susceptible to denial-of-service (i.e. DOS) issues like this. If you get into a situation where a particular host is causing problems and impacting other clients your only option may be to block that host even if it means blocking well-behaving clients. Are there any logging improvements you'd like to see in this kind of situation? We will probably implement authn/z metrics soon (via ARTEMIS-4306 [1]) at which point it may be viable to reduce the logging for authn failures. Ultimately we want to minimize the impact of clients like this as much as possible, but it will never be 0. Lastly, I'm not aware of any simple way to "pre-authenticate" clients. Off the top of my head the only thing I can conceive is that if the broker is using a centralized resource like LDAP then the client could talk to LDAP before talking to the broker to ensure it had valid credentials. That, of course, would be a lot of extra work for the client and would pose a potential problem for the LDAP server itself. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-4306 On Mon, Jul 24, 2023 at 1:31 AM Shiv Kumar Dixit <shivkumardi...@eurofins.com.invalid> wrote: > We would like to know if there is any mechanism to pre-authenticate broker > users first (basic authentication or certificate authentication) and if the > credentials/certificate is valid then only connection attempt is made on > the broker. We are seeing a case where some users are either using invalid > user-name password or invalid certificate (expired/missing private key or > different cases of SSL handshake failure) to connect to brokers. > > Since such applications keep running with invalid authentication and take > lot of time to fix from client side, we are seeing too many connection > attempts being made which subsequently failing on the broker. Broker logs > also get filled very fast due to it. We can't just block those erring IP as > same IP can host a good and a bad application. Blocking the IP will also > block well behaving application. > > Some broker versions (e.g. 2.27.1) are very sensitive to such errors and > it impacted normal broker operations where new good connections were denied > or delayed, existing consumers were not able to pull messages or clustering > and movement of messages across cluster was impacted. > > We would like to explore any proxy or pre-authentication where such erring > consumers are not allowed to make any connection attempt itself thus > safeguarding the broker. Any input or lead will be very useful. > > Thanks > Shiv >
