DEV Community: Neil Bartley

Calming App Jams with Træfik

Neil Bartley — Mon, 29 Oct 2018 10:54:40 +0000

This was originally posted on the FlexMR Dev Blog.

At FlexMR we make heavy use of a ‘prototype-first’ approach. We find it’s easier to produce a stand alone implementation of an integration with a third party tool (or idea) than spend time folding it into what we have, only to decide to throw it away and try a different way.

As you’d expect this can produce a lot of apps. The configuration for NGINX (the ‘junction box’ of the server) started to become more unwieldy. New (and old) server configs and SSL certs started to pile up. Moving NGINX config to a separate git repository was tidier but it didn’t solve the underlying issue. I started to look around for an solution which better fitted our use case.

Our infrastructure setup for prototypes (and as it happens, an internal tool called Hairy Slackbot — more on that in the future) lives on a dedicated server which is running Docker Swarm mode (so it is ready to scale when we need to).

My wish list for a reverse proxy solution:

Minimal configuration, ideally on the app side
Scalable
Easily use LetsEncrypt for certificate generation (provision and renew)
Nice to have (only because we don’t need it right now): Load balancing

I’d looked at the popular nginx-proxy alongside docker-letsencrypt-nginx-proxy-companion however, in the spirit of experimentation I thought I’d give the new one a whirl.

Træfik

Træfik is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Træfik integrates with your existing infrastructure components and configures itself automatically and dynamically. Pointing Træfik at your orchestrator should be the only configuration step you need.

We’re only going to touch a small portion of Træfik’s functionality in the example below. What we’re aiming to achieve here is:

New services can be deployed to our development server without having to make any changes outside of that apps repository.
New SSL certs are provisioned (and renewed) automatically by LetsEncrypt.

Show me some code!

Or, if you’re really keen there is a repository and example walkthrough in the next section.

What we had

In the example I described above, I defined separate stacks for both the hsb and proto1 apps as well as nginx. nginx used to part of the hsb stack by virtue of it being the first stack on the development server, this was split out once we started adding more apps.

Each app has its own git repository in which the docker stack file defines how it runs within the swarm (how many instances, memory and CPU restrictions, network details). We deploy via CI.

The new world

Stack 1: træfik

Deployed with: docker stack deploy --compose-file traefik-stack.yml --with-registry-auth traefik

Stack 2: hsb

Deployed with: docker stack deploy --compose-file hsb-stack.yml --with-registry-auth hsb

Stack 3: proto1

Deployed with: docker stack deploy --compose-file proto1-stack.yml --with-registry-auth proto1

Visual view of configuration

Traefik comes with a rather bonny UI, which we’ve configured to serve on port 8080 of the host. I access this via a SSH port forward eg: ssh -L8080:localhost:8080 ... as I don’t make it available externally (and neither should you!).

The rather pretty traefik UI

Worked Example

The accompanying repo below uses a different setup to the hsb/proto1 setup above. I’ve done this to illustrate multiple services in the same stack and how single services can be assigned multiple domains.

neilbartley / traefik-swarm-example

Traefik Swarm (mode) Example

Please see the accompanying blog post for background.

Running this example

Commands and Video.

View on GitHub

I’m making use of jwilder/whoami.. This provides a web service which just echos its container id.

Stack 1 is traefik, as above.

Stack 2 is proto1, this has admin (proto1.neil.bar) and backoffice (proto4.neil.bar) services.

Stack 3 is proto2, this has a single service, app (proto2.neil.bar and proto3.neil.bar).

As we’ve set up the [acme] block in our traefik.toml then Traefik will automatically request, provision and renew certificates for the hosts defined in the traefik.frontend.rule label in each service from LetsEncrypt.

Adding additional services doesn’t require any changes to the traefik stack and with the LetsEncrypt integration it really does make this task trivial.

asciinema demo

Wrestling Control of my Webcam

Neil Bartley — Tue, 03 May 2016 20:24:01 +0000

This post originally appeared (ages ago) on my personal blog. These devices are certainly still kicking around so the information is still relevant.

A few months [now years] ago I ordered a generic IP webcam from Amazon. A COOLEAD L610WS arrived the next day. The reason behind this purchase was to act as a baby monitor for our new daughter.

Paranoid much?

There has been much discussion about the security of IoT devices such as this webcam. This even broke out of the confines of geek sites and into the mainstream press.

I knew that this device would be insecure when I purchased it. My view was that securing it was just a matter of changing the default passwords and updating the configuration — as I would do on any device I purchased.

This was not the case and the more I dug, the more fail I found.

Danger!

“I also use telnetd”

This webcam is massively insecure if you just plug it in and use.
Even if you spend some time updating passwords and configuration, it is not much better.
The firmware and set-up do not look to have seen any form of quality control.
By default this webcam is immediately accessible from the internet and due to some bad code, can’t be disabled.

External Access

In an attempt to make it easy for people to view the webcam from outside the confines of their home network, a number of options are typically offered by these sorts of device:

The webcam will use a p2p system and open up ports on your router via UPnP.
You can upload images to an FTP site.
You can send images via email.
The documentation will suggest opening up ports on your router to allow access.
A dynamic domain name service (DDNS) will ensure you can always connect, even if your router changes IP.
An even scarier alternative is that the webcam will upload images/footages to the manufacturer’s servers for you to view from their website.

My webcam offers a p2p system, a dynamic name service, FTP upload and email.

Software

Browser

Plugging in the webcam and browsing to the IP address serves me a standard HTTP authentication screen.

Note ‘Your connection to this site is not private’. This means that your user name and password are sent over the network (or internet) in cleartext and can be trivially intercepted.

After authentication, you are presented with a number of options to view your camera based on your OS/browser (IE, not IE, mobile).

The IE option offers the download of some software via a link which helpfully includes your username and password. I’d go nowhere near any software bundled with this webcam — I don’t need it and would not trust it anyway.

So far, nothing I have seen is instilling any confidence in the software. Let’s inspect the page which displays the video/image from the webcam:

That looks like commented out development code. It also betrays the default admin user and password (admin, with no password).

Configuration

I tried locking down the DDNS configuration on this device but I can’t. The option is there, but my choice is not actioned or even saved after clicking either of the mislabelled buttons.

A look at the source shows more commented out code, this time its JS.

Thanks to that code snippet, the following request would disable DDNS. I don’t trust this device though.

There is no option in the admin section to turn off the p2p option. I’d guess it probably would not have worked anyway!

The script declarations at the top of the index file reference a couple of cgi files. These are used to set variables for every configuration option for each page. Let’s take a look at them.

get_status.cgi

get_params.cgi

Highlights:

Username and passwords for all other users.
Network configuration, including the SSID and WiFi password.

(I’ve stripped out some consecutive variables to save some lines).

set_alias.cgi

This script is used to set the alias of the device — to give it a friendly name. I decided to pick on this particular cgi as it is simple (one value) and is displayed on most (if not all) pages outside of the admin area.

What I was looking for was a cross site scripting (XSS) vector.

Credit to Lud for beating me to it [_here](http://www.drolez.com/blog/?category=Hardware&post=jw0004-webcam)._

Now look what happens when I log in:

I expect the other forms which take text input are equally as susceptible, but are likely limited to the admin pages.

The XSS injected here is a harmless popup but it is not inconceivable that something much more malicious could be cooked up. As Lud points out, the lack of cross site request forgery (CSRF) protection could allow the users browser to be taken over.

Device

Firewall Logs

I'm going to guess the latter three servers are something to do with the p2p functionality of this webcam. I’ll maybe investigate these further with Wireshark at some point.

54.247.103.91

This looks to be a box hosted with AWS (in Ireland).

Hitting this on port 80 returns the following from a very online Apache 2.2.22 instance.

54.217.201.148

This looks to be an Ubuntu box, also hosted with AWS (in Ireland).

Port 80 gives up a default configured Apache 2.2.22 instance.

Others

128.138.141.172 — This is an NTP server at the University of Colorado.
54.245.98.57 — Another AWS box located in the US.
123.56.159.92 — This is a box located in Hangzhou, Zhejiang, China and is hosted by Aliyun Computing Co.

Services

Let’s see what services are running on the device. We’ll use the stalwart of network scanners, nmap.

The options used are;

-sS — Scan TCP ports (SYN)
-sU — Scan UDP ports
-sV — Try and figure out what version of the service is running

Telnet

Telnet has no place on this device. It certainly shouldn't be enabled by default and I wonder why it is. Its worth noting that the username and password which is set for the web interface does not work here.

Let’s point Metasploit at this and see if we can get a login.

Metasploit is a framework for developing and executing exploit code against a remote target machine. It comes bundled with a bunch of scanners. We’ll make use of auxiliary/scanner/telnet/telnet_login.

I've presumed that the root account is going to be accessible (and not locked down by disabling its access). This presumption is based on what I have seen so far.

It took less than 3 minutes to find that ‘123456’ was the root password.

Lots of people have beat me to this!

PenTestPartners — Hacking the IP Camera: part 1 | part 2
Krebs on Security — This is Why People Fear the ‘Internet of Things’
Lud’s open source corner — Wanscam JW0004 IP Webcam hacking

Conclusion

The IoT is great — you can pick up a wireless infra-red webcam for under £30. However, you get what you pay for.

The firmware makes use of insecure technologies (telnet, FTP, no SSL on web, SMTP) which allow for data to be easily intercepted.
The software seems to have been clobbered together without any thought for best practices, security, review or testing.
The infrastructure the device talks to doesn't give me any confidence — a service which displays a default (Apache) page has not been configured correctly. I’d not fancy trusting it with my personal information.

It seems that these devices, which look to be essentially the same but made by different companies, all use a similar software base. This is then tweaked occasionally at the whim of the given manufacturer.

These devices are not aimed at tech-savvy individuals and most people won’t know how easily these can be exploited by inquisitive or malicious parties.

The only way I can see to safely use this webcam is to prevent the device from accessing the internet at all.

At this point my ‘Internet of Things’ device is more accurately an ‘of Things’ device.

Ghosts?

This is a question which I’d not considered when making my choice.

A really simple Slack integration in Rails

Neil Bartley — Wed, 06 May 2015 22:17:00 +0000

I’m a big fan of Slack. One of its strengths is the large list of integrations that it provides ‘out of the box’. I’ll cover another strength later (when I get my soap box out!).

Clearly, there isn’t likely to be an integration for ‘my bespoke rails webapp’ but Slack have you covered by supplying a framework to allow incoming notifications.

I’m going to take advantage of this to send event details from ‘my bespoke rails webapp’ to Slack.

Real life use case

The application which I develop, has a bunch of internal mailers hanging off it. These send mails to specified people when certain actions have occurred. In this example we’ll take the case of ‘someone clicking the wibble button’.

Soap Box

Creative Commons by Brandon C. No changes were made.

Email sucks. I get too much of it (I probably send too much as well). By allowing these mailers to exist (and by adding new ones), I’m perpetuating this pain.

Setup

In the ‘DIY Integrations’ section of the Slack admin interface you’ll see the option to add ‘Incoming Webhooks’. Select this and choose the default channel you’d like your notifications to appear in (this can be overriden on a case by case basis).

What we need from this is a unique ‘Webhook URL’. Once we have this, we can start putting together a payload.

Integration

Specification

I’m not going to copy-paste the fine documentation produced by Slack. Instead, here are some links!

At last, some code!

Add your webhook URL and test channel to your development application.yml.

The webhook URL will likely stay the same in your production environment, but you may want to update the channel name.

{gist https://gist.github.com/neilbartley/f1ac92cf40f79a789e64 %}

I’ve created a service for our our SlackBot, which could simply be called from the controller.

{gist https://gist.github.com/neilbartley/87bbcb97c67617d16344 %}

To demonstrate, lets call from rails console:

{gist https://gist.github.com/neilbartley/21d1d6e1d4ffb09700c9 %}

Line two will produce the following notification in the #events_test channel:

Lines four and six illustrate overriding the default channel to another channel or user.