It seems a bit naive of a customer to expect the broker to not rely upon or leverage features of the operating system, but I digress.
Are you tied to ActiveMQ 5.x or could you also use ActiveMQ Artemis? Artemis already has a timeout which will disconnect clients that don't send any data for a protocol handshake. It also supports plugins and in particular interceptors which have direct access to the remote client's connection and can decide whether or not to terminate that connection based on the client's IP address. Justin On Tue, Sep 8, 2020 at 5:48 AM Martin Lichtin <lich...@yahoo.com.invalid> wrote: > In theory, yes, an iptables or firewalld approach would work. > But certain customers doing pen-testing require the solution to be > self-sufficient, so I'll need > this kind of access control as part of the listen-accept logic of the > ActiveMQ broker. > > - Martin > > On 02.09.2020 18:14, Justin Bertram wrote: > > Would a firewall rule be an option here? It seems like that would be the > > best tool to control access to the broker based on IP address. Or is your > > use-case more complex than that? > > > > > > Justin > > > > On Sun, Aug 30, 2020 at 2:19 PM Martin Lichtin <lich...@yahoo.com.invalid > > > > wrote: > > > >> Hi > >> > >> Looking at how to best implement IP-address based access control via a > >> Plugin. > >> > >> I've an implementation based on "addConnection", but this method is > called > >> way too late in the connection setup. > >> > >> Ideally there should be a hook available in TcpConnection.connect() > method > >> to reject rogue connections as early as possible. > >> > >> Note the current behaviour is quite bad, ActiveMQ accepts connections > and > >> doesn't drop them (client doesn't send any data), thus eventually > exceeding > >> the maximum number of allowed client connections and resulting in DoS. > >> > >> - Martin > >> > >> > >
