OpenWRT and PIA

I use an OpenWRT travel router to deal with public WiFi access security and geolocation concerns. I have written extensively prior  and ran into an issue with the latest OpenWRT release.

For those struggling with PIA using the luci-app-openvpn please see the below for a working config you can place in /etc/config/openvpn.

config openvpn 'piaEU'
               option dev 'tun'
                option nobind '1'
                option verb '3'
                option fast_io '1'
                option persist_tun '1'
                option persist_key '1'
                option client '1'
                option proto 'udp'
                option tls_client '1'
                option remote_cert_tls 'server'
                option cipher 'aes-256-cbc'
                option auth 'sha256'
                option ca '/etc/config/ca.rsa.4096.crt'
                option keepalive '10 120'
                list remote ''
                option comp_lzo 'adaptive'
                option auth_user_pass '/etc/openvpn/authuser'
                option resolv_retry 'infinite'
                option reneg_sec '0'
                option disable_occ '1'
                option enabled '1'
                option crl_verify '/etc/config/crl.rsa.4096.pem'
                option port '1197'

The port is a biggie. Make sure it is the correct one for the new secure settings!


Ring Doorbell Security

The Ring Doorbell has been invaluable as we travel the world. The reactions of people are often times pretty funny as the doorbell they just pressed begins talking to them and asking them to do some action in our absence. Even over our very low-bandwidth WiMax link it is usable. The most annoying part of the device, until now, is that our dog Bentley goes crazy when the device rings the multitude of devices. Even when we are abroad if he hears the phone notification he goes ballistic instinctively knowing someone is in his yard…from a few hundred/thousand miles away.

I started getting some odd alarms on my internal network Snort sensor indicating that my doorbell was attempting to use Base64 encoding for basic auth over port 80. Possibly it was just my doorbell and I reached out to support to ask:


Okay so with the answer from support I needed to look into things more. I started by performing a packet capture between the device and my firewall. I was able to capture the port 80 communication path without much issue. It appears that events (motion, button press, etc.) are communicated to home base over Port 80 via a JSON blob. The JSON structure is at the end of this post.

We can see from the above that the ID value is temporally consistent as the session control mechanism for the SIP server to identify the doorbell being rung. I logged into their website to see if the same JSON ID followed me there, but it seems the ID is temporal and possibly controlled as part of the authentication server instead of the button press itself. The SIP from address is always the MAC address of the device Having now captured multiple events, I can safely say that the JSON ID information changes between the sessions.

After the press the SIP server accepts the “push” as a call event and then sends out the group call to the various iPhones and iPads logged in to start a call as needed. It is an interesting concept to use a SIP Group to handle the communications path. Once the call is “answered” no other device can join the session so it is very much 1:1.

I find it interesting, as someone who does VOIP software, that they chose to use G.711 PCM as the media format with H.264 RTP with DynamicRTP Type 97. It seems there are much more resilient protocols you could have chosen for dealing with the latency/bandwidth constraints. Alas I digress…

Further down the SIP communication channel I finally found what was triggering my Snort alarms. There in clear text was the Basic Auth using a Base64 encoded stream.

Decoded: 001dc91e20a2:6f28e1c7da43bc11ff55f0f058036556

I recognised the first part of the decode as the MAC address of the device itself 00:1d:c9:1e:20:a2. The remaining 32 alphanumeric characters seem to be a MD5 hash best I can tell. I ran the MD5 hash through my usual suspect sources for collisions in the basement with no luck. My hope is that the MAC serves as the ID and the MD5 hash as the password which would be my guess. Why you would pass this over HTTP is beyond me though.

I stopped short of actually probing the API endpoint with JSON. Without allowance from the company and security team I didn’t think this prudent. Wanted to head-off the question as to why I didn’t dig deeper.

In the security world we always evaluate the vulnerability against the risk. Additionally we focus on a defence-in-depth approach to make sure that multiple protections are in place versus relying on one. For us we have multiple camera identification rings before you make it to our front door with physical access identification at the road. Within our internal network I segment the Ring doorbell device on a private VLAN to make sure any communication channel is limited to the device and its home servers versus my greater network. This, plus 802.1x on our home network, ensures that even with the unsecure authentication and settings passing, you can do little harm to us.

For this case, in our configuration, the usability outweighs the risk. I would make a few recommendations to Ring though:

  1. Switch to something like Opus for your audio encoding. This would be better for users like myself who live on poor WAN links.
  2. Move your video streaming to VP9 or something more bandwidth efficient.
  3. Once you implement more efficient audio and video codecs, you should be able to migrate your SIP sessions to TLS without much issue.
  4. Secure your authentication and JSON configuration streams with HTTPS at the very least! COME ON!

Video of Bentley flipping out with the doorbell:

JSON blob:

JavaScript Object Notation: application/json
        Member Key: "motion"
                Member Key: "id"
                    String value: 640791565
                Member Key: "state"
                    String value: ringing
                Member Key: "motion_snooze"
                    Number value: 2
                Member Key: "sip_server_ip"
                    String value:
                Member Key: "sip_server_port"
                    String value: 15063
                Member Key: "sip_server_tls"
                    String value: false
                Member Key: "sip_session_id"
                    String value: 665021697-1469363028
                Member Key: "sip_server_tls_port"
                    String value: 15064
                Member Key: "sip_from"
                    String value:
                Member Key: "sip_to"
                    String value: sip:665021697-1469363028@
                Member Key: "button_press_path"
                    String value: /doorbots_api/motions/640791565/button_pressed
                Member Key: "mic_volume"
                    Number value: 11
                Member Key: "voice_volume"
                    Number value: 11
                Member Key: "stream_profile"
                    Number value: 2
                Member Key: "udp_ping_server"
                    Null value
                Member Key: "udp_ping_port"
                    Null value
                Member Key: "enable_recording"
                    Number value: 1
        Member Key: "settings"
                Member Key: "utc_offset"
                    String value: -04:00
                Member Key: "keep_alive"
                    Number value: 15
                Member Key: "doorbell_volume"
                    Number value: 8
                Member Key: "enable_chime"
                    Number value: 1
                Member Key: "enable_vod"
                    Number value: 0
                Member Key: "exposure_control"
                    Number value: 2
                Member Key: "theft_alarm_enable"
                    Number value: 0
                Member Key: "pir_sensitivity_1"
                    Number value: 10
                Member Key: "pir_sensitivity_2"
                    Number value: 5
                Member Key: "pir_sensitivity_3"
                    Number value: 5
                Member Key: "pir_zone_enable"
                    Number value: 7
                Member Key: "use_cached_domain"
                    Number value: 0
                Member Key: "use_server_ip"
                    Number value: 0
                Member Key: "server_domain"
                    String value:
                Member Key: "server_ip"
                    Null value
                Member Key: "enable_log"
                    Number value: 1
                Member Key: "keep_alive_ms"
                    Number value: 15000

Apache and HTTP Headers with Underscores

Starting with Apache 2.4, headers were dropped that contained items to include underscores and expects dashes instead. Red Hat backported this change into the Apache 2.2 that ships with 6.7. You can read more here:

If you run into the issue where your REMOTE_USER or similar is not being passed to your WSGI application or similar, it is most likely due to the above. Good news, easy fix. I came across this issue with the wonderful Oracle Access Manager (OAM) 10g. Side note: what a crappy piece of code and a disgrace to authentication mechanisms everywhere.

In this example I am looking for OAM_REMOTE_USER.

In your virtualhost config:

SetEnvIfNoCase ^OAM.REMOTE.USER$ ^(.*)$ fix_accept_encoding=$1
RequestHeader set OAM-REMOTE-USER %{fix_accept_encoding}e env=fix_accept_encoding

If you are using mod_wsgi for Django or Flask, you will need to add:

WSGIPassAuthorization On


Lenovo Yoga Tab 3 Pro Review

After the unfortunate loss of my 2014 Nexus 7 tablet I was on the prowl for a replacement. I prefer to keep an Android tablet due to the flexibility to use it as a mini Linux workstation if the need arises. The USB OTG support means the tablet is capable of taking on most of the tasks I use my Linux laptop with in the event I am stuck somewhere. Additionally I wanted a tablet that really excelled at media consumption as that is the primary use for a tablet in my workflow.

  • Great battery life
  • Android based
  • Media centric
  • USB OTG Support
  • SD Card support12556023_539159696241066_1175203354_n

Truth be told I prefer iOS-based devices for the security aspect, but I remove all sensitive and work related accounts from my tablets and accept Androids still broken security model.

I ended up looking at the latest and greatest from each vendor and ruled out most of them due to lacking some part of my requirements list. The one that really piqued my interest was the Lenovo Yoga Tab 3 Pro due to the projector, integrated stand, and great battery life. I had a heck of a time tracking one down stateside, but was able to order one directly from Lenovo.

Now having traveled with the device (the true test of a tablet) I feel I can offer my overall feedback on the device.

The good

  • Battery life is easily the best for screen-on I have seen in a tablet. The iPad has MUCH better standby, but for watching TV shows and Movies it is hard to beat
  • I like the hand grip more than I expected
  • The projector is enough for watching TV shows while we fall asleep in hotel rooms. We learned from this trip though we need a better mechanism to stand it up in odd-shaped hotel rooms
  • The SD card works as advertised and we brought tons of media
  • Lenovo didn’t muck up the Android build with too much crap, but they did severely limit the device
  • Screen is beautiful and the front-facing speakers are incredible. Why any tablet ships without front-facing speakers is beyond me

The bad

  • Slow and jerky. I kid you not. It makes using an iPad an absolute joy compared to Android. 2GiB RAM appears to be the biggest hinderance, but I blame it more on the Lenovo kernel build (~800MiB in use after fresh boot) as well as Android’s piss poor memory management. I type my pin in wrong all the time due to the numbers not registering
  • Android 5.1.1 is tough to use after having Android 6. It appears that Lenovo will slowly update this device as they do all others. They have released a series of patches the past month, but none that actual fix the systemic issues
  • No accessories as it isn’t a Samsung, Apple, or Google device. Lenovo needs to build an ecosystem around their flagship devices with simple things like cases and similar
  • The screen is incapable of staying at full brightness while playing intense games like Atlantic Fleet which leads me to question what the QA process was for the device
  • It feels…cheap…the stand creaks and the edges don’t align as much as I would have hoped for a device at this price point

Overall I’d say unless you really want a projector and stand built-in; buy an iPad. I keep hoping that Google will fix their atrocious tablet OS and hoping Android vendors actually focus on delivering a quality product versus churning out SKU. If it were not for my geekiness and needing to run dual mobile OS for things I would not be tossing my dollars at them until they can get their heads on straight.

Links on the issues with the tablet:


You are “dev” to me


The idea of keeping a production and development network always wears on me. Unless the change management  is in place to offer some assurances that both threads are kept exactly in sync, they inevitably turn into a game of “not good enough to buy down risk.”

That was the rationale behind creating a system that allowed rapid captures of running machines, transitioning to a closed network, and with no changes to the network/systems have them be as they were just minutes earlier. Thanks to technology from EMC, Cisco, VMware, and VyOS this is all very possible.

Enter “Test Network”

The number of VLANs and separate network complicates things. The goto configuration would be to simply generate a new VLAN and dump the machines into it, but what happens when the machine you copying over expects routing in place?

The entire point of test is to reduce the risk that your changes will have adverse effects. Your test configuration should always have sufficient fidelity to mitigate the level of risk you and leadership are willing to accept.

Yippie for software routers! Yeah for Linux!

Vyatta unfortunately got gobbled up by Brocade a few years ago. Luckily a very talented team continued forward with the last open-source version and have marched forward VyOS.

Using VyOS to mimic an expansive Cisco vSwitches/Routing architecture allows you to not worry about the rest. A single VLAN can be spun-up to keep it “physically” separate while attaching sufficient interfaces to the VyOS box to make it the new core.

The process then becomes (either HITL or scripted) the below:

  1. Identify the systems to test
  2. Take latest VMware Snapshot or EMC Avamar in this case and deploy BMR on machine attached to VLAN of Test Network
  3. Deploy peripheral machines for support
  4. Start!

Simple Diagram Overview


Blank Flowchart - New Page

Lessons Learned

Some things to keep in mind if you decide to move forward with a similar configuration:

  • Be aware of software licensing before moving systems. Ensure the vendor provides support for testing with the license you now run.
  • Servers are often supported by peripheral services such as AV, AD, and others. Be sure for a clean environment you include those in your scripts for copying over.
  • VMRC helps a ton in Vsphere 5.5 and higher, but in lieu of this ability you will need some means to transfer files back and forth.
  • 10 NIC is the most you can attach to a VM. This will complicate things with VyOS. Keep in mind you only need the 10 networks you are using and not ALL of them at once. So A, C, E, F instead of A-F.
  • This can be replicated a thousand times over with only your capacity being the hinderance. Test Network 2-7 are okay too. Just replicate the configuration.
  • Active Directory Tombstones will bite if you are not careful. 60 days and you should plan on dumping and starting fresh.
  • Nothing stipulates you cannot migrate a Test Network to Prod. Keep in mind that in this method the copy goes both ways.
  • Systems with external interfaces will need simulators to mimic those connections. Especially important in manufacturing scenarios.
  • System load is usually a big impact point to keep in mind when testing configurations. Be sure to include ways to force system load to match enterprise. Maybe I will write a blog post on the various SQL, HTTP, SSH, etc. ways to do this with some python code..


  • You are guaranteed to have a test network that represents your production network.
  • The on-demand nature ensures that storage and CPU cycles are only used when needed.
  • Depending on the size of the machine this can take any where from 30 minutes to 2 hours, but it is quicker than spinning a new environment.
  • Serves as a great disaster recovery test.