brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [PROPOSAL] Disable Automatic Open Ports
Date Tue, 05 Jan 2016 12:20:04 GMT

graeme, all-

i like the idea of increasing transparency of security configuration.

but i'm against a default position of no ports opened.  this would make 
blueprints significantly harder to use and it would break backwards 

however one big improvement which is safe would be to add a config key 
to SoftwareProcess governing the opening of ports based on sensor names, 
so it is explicit when you look at the config keys for the relevant 
entities.  ie, SoftwareProcessImpl.getRequiredOpenPorts could use a 
config key whose default value is this:


and we should ensure that we have good interlinked documentation for 
SoftwareProcess setup, and on the config keys themselves -- 
SoftwareProcess.requiredOpenLoginPorts and 
CloudLocationConfig.inboundPorts.  while this would not change the 
default behaviour -- so the "kibana.elasticsearch.port" would still be 
opened in Graeme's example -- it at least makes explicit and 
configurable *why* it is being opened and how to change it, for a config 

can we go for this proposal instead?

for background i think that the behaviour as it stands -- opening a 
sensible collection of ports -- is the *right* thing for us to do at the 
level of the SoftwareProcess entity.  unlike other systems which require 
a user to specify absolutely everything, brooklyn's philosophy is that 
the user specifies the essentials, and it then tries to make sensible 
decisions beyond that.  i think this philosophy serves us well and our 
blueprinting format seems to resonate with users.  disabling the 
automatic port opening mechanism will significantly raise the barrier of 
getting started (which is already too high in my view) and will break 
many existing blueprints so i am opposed to it.  to me it is better to 
have ports work right nearly all the time with the reasonable security 
of nearly all ports closed by default, rather than require opened ports 
to be specified explicitly in all cases (which will make blueprints 
significantly more cumbersome to work with!).  graeme's use case is a 
complicated software configuration and without any custom network 
configuration the blueprint got everything right with the exception of 
one unnecessary port opened; that feels like a good balance between 
usability and locking everything down.  i disagree with you graeme that 
a developer could be "unaware" of the automatic port opening; in your 
example the kibana port was opened without your doing anything so it is 
clear that some config would be required to opt out of port opening.  
the bigger problem i think is that it wasn't obvious (and not 
configurable!) *how* that was happening, which the revised proposal 
above fixes.

furthermore in a high security environment, private networks should be 
used and explicit port forwarding required for any service which should 
be exposed publicly.  this is already possible and more sophisticated 
ways of specifying ports accessible only to specific other services are 
in the works.  that seems the right level at which to solve the problem 
graeme raises:  as these are *additional* and more expressive 
constraints on top of the "inboundPorts" list, it would be a step in a 
wrong direction to have blueprints explicitly list all sensors to be 
opened in inboundPorts.

on a side note graeme in your blueprint the strategy of the ES target 
using a config key "kibana.elasticsearch.port" seems odd; more usual is 
for target endpoints to be specified as URLs (and this would avoid the 
problem you encountered).


ps.  geoff, i get your point, but just so you know brooklyn goes to 
great lengths to lock systems down and block the "open defaults" attack 
vector:  the default config for cloud machines is to disable the 
cloud-provided machine login, set up a new secured login account, and 
close all ports apart from 22.

On 05/01/2016 10:18, Geoff Macartney wrote:
> hi Graeme,
> +1 to that.  My 2 cents-  I strongly agree with your point about doing security configuration
explicitly.  Behaviours like leaving open default ports or accounts are a common cause of
breaches, and this Brooklyn feature seems to pose similar risks.
> Geoff
> ————————————————————
> Gnu PGP key -
>> On 5 Jan 2016, at 10:07, Graeme Miller <> wrote:
>> Hello,
>> Just before the new year, I discovered an interesting feature of Brooklyn.
>> If an Entity has config with a name ending in "port" that can be coerced to
>> a PortRange then Brooklyn will automatically open that port range in the
>> firewall.
>> So, for example, if you have the following in YAML for an app deployed to
>> AWS:
>> brooklyn.config:
>>   kibana.elasticsearch.port: 9200
>>   kibana.port: 5601
>> Then Brooklyn will open both 9200 and 5601 by adding them to a security
>> group and authorising all traffic to use those ports.
>> I would like to propose that we disable this feature. The primary reason
>> for this is that when developing a secure system, any security
>> configuration should be explicit, rather than automatic. This is to ensure
>> that there are no accidental security mis-configurations (number 5
>> <>
>> the OWASP top 10 security problems)
>> It is too easy to be unaware of Brooklyns automatic port opening and
>> accidentally expose a port you would have otherwise kept secret. The above
>> YAML example is from a piece of code where this has happened. This YAML was
>> for a Kibana deployment. The developer wanted to open kibana.port to listen
>> on, and also to have a configurable elasticsearch.port it can send traffic
>> to. However, because of the automatic port opening, the elasticsearch.port
>> was also opened on the Kibana instance.
>> The upside to removing this is that there will no longer be ports that are
>> accidentally opened. The downside is that YAML config files will be more
>> verbose, requiring the developer to explicitly open the ports (I.E. by
>> adding the required.ports config).
>> What are your thoughts?
>> Regards,
>> Graeme

View raw message