activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.com>
Subject Re: [VOTE] Apache Artemis 1.0.0 (RC2)
Date Thu, 14 May 2015 18:07:10 GMT
> The security issue is a valid argument, but like you say if its not common for users to
unzip and deploy into production then its actually a moot point.

"Production" systems are not the only systems on which security is important.  Consider a
casual user who starts the broker just to play around with it and then forgets to turn it
off.  Now that unsuspecting user has an additional attack vector on their machine.  Oftentimes
black-hats will compromise a "lesser" (i.e. non production) system in order to get to the
real target.

I'm not trying to be some kind of security alarmist or saying our distribution has to be 100%
air-tight.  All I'm saying is that the default configuration should be conservative from a
security/access stand-point.  I don't think it's acceptable that if I start the broker then
anybody who can connect to my machine remotely now has the ability to start filling up my
disk with messages.  If the consensus is to bind to public network interfaces by default then
we should likewise modify the configuration to be read-only by default at the very least.


Justin

----- Original Message -----
From: "Andy Taylor" <andy.tayls67@gmail.com>
To: dev@activemq.apache.org
Sent: Thursday, May 14, 2015 12:21:24 PM
Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)

On 14/05/15 17:11, Justin Bertram wrote:
>> However, it is doubtful this is the way any broker will ever be run for real.
>
> Yes, of course.
>
> As I see it, the default configuration is for users (mostly developers) who want to start
up a broker quickly, run a few examples, look at the console, etc. All that would typically
be done locally since that is the simplest, fastest use-case.  To move beyond that use-case
(e.g. to one with remote clients) hopefully the user would have reviewed a bit of the documentation
and come to understand more of how the broker works, the importance of security, etc.
>
> I don't think it's common for users to unzip the broker and deploy to production with
no changes. IMO, the broker configuration is typically tailored for the application and environment.
Binding the network transports to the proper interface is just part of that process.
The security issue is a valid argument, but like you say if its not 
common for users to unzip and deploy into production then its actually a 
moot point.

There are arguments to and for it but personally im happy to open the 
broker up to remote clients. Maybe we just improve the management 
functionality(and write) and only allow local clients for admin stuff.
>
>
>> It's like having a web server start up without the ability to server web pages by
default.
>
> If the web server was 100% read-only then I'd probably be find with it binding to a public
interface by default. However, if there was any way for remote users to impact my machine
through that server (beyond a DOS attack) then I would want the server to bind to localhost
by default or be secured with e.g. a username/password.  That just seems like common sense
to me.
>
> In short, I think we should take a pretty conservative approach with our user's security.
 I think binding the server to 0.0.0.0 (i.e. all network interfaces) by default with the current
configuration is too liberal.  If we were to bind to 0.0.0.0 by default I'd want to either
remove the default user account altogether or change it so that the default user could only
consume messages (i.e. couldn't produce messages, create queues, or perform management operations).
>
>
> Justin
>
> ----- Original Message -----
> From: "Jim Gomes" <e.semog@gmail.com>
> To: "ActiveMQ Dev" <dev@activemq.apache.org>
> Sent: Thursday, May 14, 2015 10:28:15 AM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If it was done on purpose for security reasons, that's cool. However, it is
> doubtful this is the way any broker will ever be run for real. The whole
> purpose of a broker is to integrate disparate systems. It's like having a
> web server start up without the ability to server web pages by default.
> Kind of silly.
>
> Anyway, I will log the bug with the NMS clients, and I do think the release
> should be held up because of this problem. It's a show-stopper for NMS
> clients.  Here's the server exception being thrown:
>
> ERROR [org.apache.activemq.artemis.core.server] error decoding:
> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
> {commandId = 0, responseRequired = false, consumerId =
> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
> false, start = false, flush = false, prefetch = 32766, destination =
> topic://UnitTest.Status}
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> [artemis-server-1.0.0.jar:1.0.0]
>      at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> [artemis-core-client-1.0.0.jar:1.0.0]
>      at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>
>
>
> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jbertram@apache.com> wrote:
>
>> IMO the broker correctly binds to localhost only and does not, by default,
>> allow connections from remote machines.  This is a simple security/sanity
>> measure to prevent access to default (i.e. unsecured) instances.
>>
>> The merit of this configuration is obviously up for debate, but it's worth
>> noting it was done on purpose.
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e.semog@gmail.com>
>> To: "ActiveMQ Dev" <dev@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:05:55 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> -1
>>
>> Two reasons:
>>
>> 1. The default configuration of localhost for the broker does not allow
>> connections from off-machine. For some reason, socket connections are
>> refused from non-local clients. I had to change the broker.xml config to
>> use the machine's actual IP address, and then non-local clients could
>> connect.
>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>> unknown response IDs from the broker. I don't think the OpenWire protocol
>> is being negotiated correctly. I am running with the latest NMS trunk
>> version (1.8.0).
>>
>>
>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mtaylor@redhat.com>
>> wrote:
>>
>>> Hello all.
>>>
>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>> the
>>> initial RC feedback from community members.
>>>
>>> This is a first release of the Artemis project with protocol support for
>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>
>>> The release notes can be found here:
>>>
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>
>>> The binary distributions can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The source archives can be found here:
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>
>>> The Maven repository is here:
>>>
>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>
>>> The source tag:
>>>
>>>
>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>
>>> The project website for that version has been staged to:
>>> http://people.apache.org/~martyntaylor/
>>>
>>> The vote will remain open for 72 hours.
>>>
>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>>
>>> Here's my (non-binding) +1
>>>
>>> Regards
>>> Martyn
>>>
>>

Mime
View raw message