Linux

Firewalla – Allowed IP Addresses for Ring Camera Devices

, 0 Comments

My initial setup of Ring Camera’s with my Firewalla was pretty lacklustre! They were isolated in a device group from all other networks, but had free outbound access to the internet. So, at first I got a few alerts for domains like ring.com and added these as allow rules. Everything was generally good, but I constantly got “unusual upload” alerts on the Firewalla for my Ring cameras, these were always Ireland based IP’s associated with Amazon. Each time I got an alert, I added it to the mute/ exclusion list, but this was burdensome!

Then as mentioned in my last post (https://blog.oholics.net/s3-amazonaws-com-dns-resolution-and-firewalla/), I started locking stuff down, including my Ring cameras, following the same process as I used for my PiHole. I googled “allowed IP addresses for Ring cameras” previously and got the gist that there is no easy way.

After the success I had with my previous use of Target Lists on the Firewalla , I looked to use the same approach for this issue. After locking down the device group, I noted that the target IP’s were nearly all West EU based IP’s for the AMAZON service, so needed to add some more arguments to my jq query – I needed the ranges for the AMAZON service in eu-west-1, eu-west-2 and eu-west-3. To do so, I used the test argument, as follows:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r ‘.prefixes[] | select(.region|test(“^eu-west.”)) | select(.service==”AMAZON”) | .ip_prefix’

I added those ranges (574 in total) to 3 Firewalla Target Lists, each can hold a maximum of 200 CIDR ranges.

Then, I created rules to allow traffic from the Ring Camera’s group to the IP ranges in these Target Lists.

Then, after a few days I checked to see what was still being blocked and noted a handful of East US based Amazon IP’s, some were EC2 Service ranges, so  I grabbed them with:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r ‘.prefixes[] | select(.region|test(“^us-east.”)) | select(.service==”EC2″) | .ip_prefix’

Then I noted that some ranges were from the AMAZON service, so I grabbed them too:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r ‘.prefixes[] | select(.region|test(“^us-east.”)) | select(.service==”AMAZON”) | .ip_prefix’

However, after I had the files containing the ranges, I realised that there was some duplication between the sets; some Amazon services share IP ranges, where the AMAZON service list covered EC2 as well. I added these ranges to new Target Lists using the Firewalla web interface.

Back on my phone, I added rules to allow traffic to the IP ranges in these allow lists:

And then added those same Target Lists to the mute list for Abnormal Uploads, targeting the Ring Cameras group only.

 

 

 

 

 

 

 

Since I made these changes, I’m no longer seeing any blocked outbound traffic from my Ring cameras or any alerts relating to Abnormal Uploads 🙂

s3.amazonaws.com DNS Resolution and Firewalla

, , 0 Comments

A few years ago I bought a Firewalla Gold device to help provide some additional protection to my home network, but more importantly to control what my kids had access to and when they had internet access.

My initial setup was fairly basic, but did the job. I’ve also been running PiHole and Unbound on a Raspberry Pi Zero 2, which has been very effective at black-holing advertising and other undesirable DNS traffic.

Over the Christmas/ new year holiday, I got hold of a Cisco switch which was capable of VLAN tagging, so set about having a bit of a tidy up/ isolation of devices/ networks.

I made the following changes:

  • Created a VLAN for the PiHole, the Zero 2 is hardwired via an Amazon Firestick network adaptor.
  • Created a device group on the Firewalla, which only contains that Zero 2.
  • Allowed incoming port 53 connections from all internal networks/ VLANs to the Zero 2.
  • Blocked all inbound and outbound traffic from the PiHole VLAN.
  • Permitted port 53 outbound traffic (public) from the Zero 2.

Now the network is isolated, I updated gravity on the PiHole to see what is now blocked, then added allow rules for all desired traffic.

One allow rule added was for s3.amazonaws.com as two of the blocklists were hosted in S3 buckets. That is the back story, now onto the problem and my solution.

The problem: When Gravity ran on the PiHole, it always failed to get the two blocklists that were hosted on s3.amazonaws.com, even though I had an allow rule on the Firewalla for that domain.

Why: Amazon services are massive and widely distributed! Resolution of DNS will provide a different set of IP’s every time you try. The image below shows my Pihole on the left and the Firewalla console on the right:

The Firewalla was supposed to learn the IP’s of the domain to honour the allow rule. However, after making all the changes requested in my support ticket with Firewalla, the issue remained. Note that some IP’s were trusted and (most) others were not, see:

 

So the fix… Initially I figured that I would just pick a “trusted” IP and add it to the PiHole local DNS, that worked but wasn’t very resilient! So, then I looked at how I could tell Firewalla to trust all IP’s associated to the S2 namespace.

How to do that? Amazon provide a good article on identifying the IP addresses used for their services here: https://repost.aws/knowledge-center/s3-find-ip-address-ranges. Using this method, I obtained 298 IP ranges in CIDR format. I then added these to Firewalla Target Lists, via the browser interface.

Then, back on my phone, added an allow rule for each set of Target Lists:

Now I can freely get the block lists from any s3.amazonaws.com IP address 😉

Sure I have added a lot of “trusted IP’s”, a lot more than planned, but these rules apply only to that device and are outbound only.

Ldapsearch Syntax for Simple LDAP and SLDAP

, 5 Comments

Another case of “I’ve done this before, but never wrote it down”, so revisiting this took far longer than it should have. But now it is here, that won’t happen again.. right?? I’ll probably never need it again now… typical..

OK, so a straight forward non-secure ldapsearch command, obtains everything (-h can be IP or FQDN):

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”

A secure ldapsearch command, using TLS on port 389, obtains everything (Note the use of the -Z switch and the use of FQDN):

ldapsearch -h dc.oholics.net -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” -Z

A secure ldapsearch command, using SSL on port 636, obtains everything (note the use of -H and the LDAP Uniform Resource Identifier):

ldapsearch -H ldaps://dc.oholics.net:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”

These commands all work just fine. Just for fun, make the last query type find something in particular – Look for a user account by its DN:

ldapsearch -H ldaps://dc.oholics.net:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” “(&(objectclass=User)(distinguishedName=CN=John E Smoke,OU=Users,DC=oholics,DC=net))”

Now for some errors!

For both TLS and SSL on port 636, using the IP as the host (-h or -H) fails. It MUST use the FQDN of the target system. Why? because the certificate on the DC only refers to the FQDN of the server.

SSL/ 636 – The error “Can’t contact LDAP server (-1)” was really stumping me as there is little to go on in the error message. Doing a network capture, just shows the handshake start, but the DC ultimately just says “Go Away!”. It resets the connection attempt.

A few things learnt:

1. Using -h FQDN and -p 636 results in Can’t contact LDAP server (-1) (the URI method above must be used)

ldapsearch -h dc.oholics.net -p 636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

2. Using -h IP Address and -p 636 results in Can’t contact LDAP server (-1)

ldapsearch -h 192.168.1.201 -p 636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

3. Using -H with IP Address in URI and -p 636 results in Can’t contact LDAP server (-1)

ldapsearch -H ldaps://192.168.1.201:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

Additionally, for TLS connection. Using the IP address of the DC, resulted in a different, but much more helpful error message:

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” -Z
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate

Also, where a Domain Controller has the setting “Domain controller: LDAP server signing requirements” set to Require signing. When trying to initiate an insecure LDAP query with ldapsearch, it fails as follows:

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_bind: Strong(er) authentication required (8)
additional info: 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580

Well that was a fun day 🙂

U2F Login for WordPress – OPENSSL_VERSION_NUMBER Undefined

, 0 Comments

While looking to get this working: https://github.com/shield-9/u2f-login/, I was seeing errors in the http logs referring to OPENSSL_VERSION_TEXT. These were being generated by the following lines in the u2f.php file:

After running a few more tests, it seemed that this PHP Constant should have been defined, but was not. Goggling didn’t provide any quick answers, but I soon worked it out for myself.

In the php.ini file (under arch in /etc/php/), uncomment the line: “extension=openssl.so” and restart httpd. Once the extension is enabled, the Constant is then available.

In the end I did not use this plugin, I was unable to register my Yubikeys. The plugin seems to have been superseded by this one: http://github.com/georgestephanis/two-factor/. In order to have the ability to use U2F login using this plugin, the openssl.so extension has to be enabled; otherwise, the U2F login option is not available.

Getting PiGlow working on Arch Linux with Raspberry Pi 2

, , 0 Comments

It initially seemed like a trivial task; after all getting the PiGLow working under Raspian was very simple!

But under Arch the method is significantly different…So, after digging about, getting all the pieces together – this is what I have and it works!

Now to get this to run on start-up…