RSS

January Stable Release, NYC Meetup

Our January release of Flynn includes a variety of bugfixes and minor improvements. The changelog has the details and there are docs on how to update.

§ NYC Meetup

We’ll be at the Downtown NYC Tech Meetup talking about Flynn on Thursday, January 19th. Please RSVP, space is limited!

§ Security Announcement

If have a Flynn cluster on DigitalOcean that was deployed using flynn install, please read this post about an important security issue that affects you.

§ Stay in Touch

§ How You Can Help

Security Announcement: DigitalOcean installer firewall misconfiguration

This is a security announcement that applies to all Flynn clusters that were launched with the flynn install command on DigitalOcean or via SSH prior to CLI version v20170108.1. No other cluster types are affected.

The firewall for clusters launched using these options was misconfigured, leaving all ports defaulted to open instead of closed.

§ Impact

All clusters launched via flynn install with on DigitalOcean or via SSH that have not had additional firewall rules manually applied are vulnerable to unauthenticated remote code execution.

§ Remediation

There are two ways to fix the issue, manually adding the missing rules to an existing cluster, or starting a new cluster using a fixed version of the installer.

§ Start a new, fixed cluster

The flynn install command in versions v20170108.1 and later have this issue fixed. Run flynn update and flynn version to confirm that your CLI version is updated.

If you have apps and data that you’d like to keep, you can take a backup from an existing cluster by running flynn cluster backup --file=flynn_backup.out and restore it when starting a new cluster using flynn install. Make sure that you destroy the old cluster after starting the new one.

§ Manually add firewall rules

The missing firewall rules can be added via SSH to the hosts in an existing cluster.

For single-host clusters

If the cluster only has one server, you can connect to it using SSH and add the corrected firewall rules.

ssh -i ~/.flynn/installer/keys/flynn root@$CLUSTER_DOMAIN

The cluster domain typically starts with several alphanumeric characters and is a subdomain of flynnhub.com, it can be obtained by looking at the output of flynn cluster or git remote -v in a git repository that is configured to deploy an app to the Flynn cluster.

Once connected to the server, run the following commands:

iptables -A INPUT -i eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -i eth0 -j DROP
netfilter-persistent save

If the last command returns an error, the host is running Ubuntu 14.04, and the correct command is:

/etc/init.d/iptables-persistent save

After running these commands, the correct firewall rules will be in place. See the Testing section below for information on how to test this.

For multi-host clusters

If there is more than one host in the cluster, you will need to find the IPs of each host and then connect to each and add the firewall rules.

You can get the list of IPs from the DigitalOcean dashboard, or by running host against the cluster domain.

$ host aaa.flynnhub.com
aaa.flynnhub.com has address 127.0.0.1
aaa.flynnhub.com has address 127.0.0.3
aaa.flynnhub.com has address 127.0.0.5

The cluster domain typically starts with several alphanumeric characters and is a subdomain of flynnhub.com, it can be obtained by looking at the output of flynn cluster or git remote -v in a git repository that is configured to deploy an app to the Flynn cluster.

Once you have the IP addresses of each host, connect to each of them and add the firewall rules:

ssh -i ~/.flynn/installer/keys/flynn root@$HOST_IP

One rule will need to be added to allow access from each host in the cluster:

iptables -A INPUT -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -s 127.0.0.3 -j ACCEPT
iptables -A INPUT -s 127.0.0.5 -j ACCEPT

Replace the 127.0.0.* IP addresses above with the IP address of each host in the cluster, and make sure there is a rule added for each host IP.

After adding the rules for each host, add the general rules and save the configuration:

iptables -A INPUT -i eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -i eth0 -j DROP
netfilter-persistent save

If the last command returns an error, the host is running Ubuntu 14.04, and the correct command is:

/etc/init.d/iptables-persistent save

After running these commands on each host, the correct firewall rules will be in place. See the Testing section below for information on how to test this, and make sure you test each host individually.

§ Testing

If the correct firewall rules are in place, only ports 80, 443, and 22 will be open. You can quickly test if the rules are missing on a host by sending an HTTP request to a host’s IP on a port that should be firewalled:

curl $FLYNN_HOST_IP:1111

If the firewall rule is missing, this will return a response, which means that the issue has not been patched yet:

404 page not found

If the firewall rule is correctly configured, the request will timeout, this is the output that you want to see:

curl: (7) Failed to connect to aaa.flynnhub.com port 1111: Operation timed out

A more extensive test can be done with nmap, this is the output that you should see if the firewall is correctly configured:

$ sudo nmap -p- -sS $FLYNN_HOST_IP
...
Host is up (0.014s latency).
Not shown: 65532 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 108.79 seconds

If other ports are listed as open, then the firewall is not correctly configured.

§ Future Improvements

We are currently working on two projects that will help prevent a misconfiguration like this from having the same impact in the future:

  1. The next version of the installer will have integration tests that ensure that firewall rules are correctly applied to launched clusters.
  2. Internal cluster communications will be encrypted and authenticated so that even if the firewall is misconfigured, exposing internal ports will have no impact. We have a security roadmap that covers this and other issues.

§ Credits

Thanks to @KidkArolis for reporting this issue.

If you encounter anything that you think may impact the security of Flynn, please follow our disclosure process.

December Stable Release

Flynn’s December stable release is here! It includes support for log streaming to remote syslog servers, expanded Ubuntu 16.04 support, and various stability improvements. The changelog has the details and there are docs on how to update.

§ Our Vision

Our vision is to free everyone from operating software. Read more.

§ Managed Flynn

Deploying Flynn is easy, but we can make it even easier by doing it for you! You get a private Slack channel, and we act as your ops team, helping you take advantage of Flynn and optimize your apps.

§ Stay in Touch

§ How You Can Help

November Stable Release

The November stable release is here! It includes many bugfixes and a completely rewritten container image subsystem that significantly improves performance for common actions. The changelog has the details and there are docs on how to update.

§ More Documentation

We’re writing more docs and tutorials, tell us what you want to see using this form!

§ Deploying from Travis CI

Evan Tahler wrote a great guide on doing continuous deployment from Flynn to Travis CI.

§ Managed Flynn

Deploying a Flynn cluster is easy, but we can make it even easier by doing it for you! You get a private Slack channel, and we act as your ops team, helping you take advantage of Flynn and optimize your apps.

§ Stay in Touch

§ How You Can Help

Parse Apps on Flynn

While we were sad to see Parse shut down. We applaud the move to open source the technology behind Parse and provide a clear transition path for users.

We’re committed to making Flynn one of the best ways to run Parse apps.

Flexibility is important to us. We want you to be able to write your apps however you want, using any technologies and run them happily on Flynn. Flynn already makes it easy to run apps written in most languages and frameworks by using Heroku buildpacks and Docker container images. Flynn is also 100% open source and we’re committed to developer tools and infrastructure being as portable as possible.

Because Flynn already has a built-in database appliance for MongoDB, deploying Parse apps is a breeze.

Here’s how to deploy the example Parse app on Flynn:

  1. Clone the repo:

    git clone https://github.com/ParsePlatform/parse-server-example
    cd parse-server-example
    
  2. Create a Flynn app:

    flynn create parse-example
    
  3. Add a MongoDB database:

    flynn resource add mongodb
    
  4. Configure the app (make sure you put your Flynn cluster domain in the SERVER_URL):

    flynn env set MASTER_KEY=myMasterKey SERVER_URL=http://parse-example.demo.localflynn.com/parse DATABASE_URI=$(flynn env get DATABASE_URL)
    
  5. Deploy the app:

    git push flynn master
    
  6. That’s it! At this point you can visit /test to make sure everything is working. Deploying your production Parse apps to Flynn is just as easy, the migration guide is a great reference.

If you need help moving your apps to Flynn drop by our IRC channel (#flynn on Freenode) or tag a question on StackOverflow.

We want you to be able to run every kind of app on Flynn. What other kinds of technologies would you like to see Flynn support?

 RSS



Mailing List