Tuesday, May 19, 2020

Ubuntu 20 on RaspberryPi with wireless for Science!

For a few years now I have been running BOINC on four raspberry pi - kind of like a poor man's compute cluster.

Most of that time was spent chugging away for Seti@Home (in fact I have been chugging away for Seti@Home for a really long time)

With the shuttering of Seti@Home I needed to discover a new project and stumbled on Science United ( http://scienceunited.org ).
This was great.  I could still support science and it was based on the BOINC compute platform.

This plan all went sideways when I added science united to my raspi pi that was running raspian.
Lots of searching, a hack to use a different repo - because come to find out, science unite requires a minimum version of the BOINC client.  One older than the raspian repo supports by default.

So, the hack I found was fine, but I was not happy.  So I went to setting up Ubuntu Server on my raspberry pis.
Heading over to https://ubuntu.com/download/raspberry-pi I checked the version of my raspi pis and downloaded the correct image.  Uncompressed using 7-zip, and then burned the image using win32diskimager.  Just like I had done 50 billion times before.

I then attached my monitor, small keyboard and booted.
And quickly discovered, no way to set-up the wifi.
Some searching led me to tons of articles describing using the ubuntu image generator and editing network-config.
(Guess how many posts were copies of the original ubuntu tutorial? - I hate that)

Well, that is fine an dandy.  But does not totally work, as some other folks tried to point out.  Plus you have this very specific image generator installed that you will use how often?  Once per year.  ( waste )
Because: guess what?  You just installed a server operating system.  They don't have wireless, on purpose.  You have to add / wireless support.  Just like any server OS (windows too).

Here is how I finally sorted it all out:

  1. Attach your pi to your network using a cable
  2. boot
  3. logon using the logon 'ubuntu' and password 'ubuntu' ( if you have not done this prior and this is the first boot, be patient.  After to logon screen, you have to wait a bit for key generation comments to show up after cloud-init finishes.  After this you can logon and be fored to change your password)
  4. change your password
  5. update the pi:
    1. sudo apt update
    2. sudo apt upgrade
  6. install the wireless tools:
    1. sudo apt install wireless-tools
  7. run iwconfig - notice you have a wlan network interface now, most likely named 'wlan0'
  8. copy a netplan sample wireless config to the netplan folder:
    1. sudo cp /usr/share/doc/netplan/examples/wireless.yaml /etc/netplan/wireless.yaml
  9. edit that sample config file:
    1. sudo nano /etc/netplan/wireless.yaml
  10. set the interface name to 'wlan0'  (the example interface of  'wlp2s0b1' won't get you anywhere)
  11. I am using dhcp on my network, so:
    1. set dhcp4 to yes
    2. remove the addresses, gateway4, nameservers, and addresses lines (ctrl + k does this in nano)
    3. set the name of your access point by replacing network_ssid_name with the name of your wireless network
    4. Set the password for the access point
  12. save the file ( ctrl + x in nano )
  13. test your configuration changes with the command 'sudo netplan try'
  14. then I do 'sudo netplan generate' for safety

Now, I also want to rename my raspi pi ( aka change the hostname )
using 'sudo hostnamectl set-hostname ` it is done.

Now, restart, detach the network cable and test the wireless settings.

Now, if you want to attach to Science United, here is the rest:

  1. install the BOINC client:
    1. sudo apt-get install boinc-client
  2. install the BOINC management utility for command line (I found that I needed this to properly attach to Science United)
    1. sudo apt-get install boinctui
  3. run the boinctui
    1. boinctui
    2. attach to the localhost ( just hit enter )
    3. F9
    4. Projects
    5. Connect to account manager
    6. Science United
    7. Enter your credential for Science United

Watch the status to make sure you attached and begin receiving work.
If all is good, exit the boinctui with F9 -> File -> quit

There you go.  Your old raspi pis being useful, supporting science without any wire except the power.

Tuesday, May 12, 2020

NGINX Plus with ModSec OWASP by Ansible - part 5

Here is the last in this series of using Ansible with the NGINX Ansible Role.
This one was done as a challenge from one of my security peers.

First, the assumptions:
local file system inventory files, Ansible host deployed to the same VPC as the remote machines, variable files, run the playbooks from the same folder as the inventory and variable files.

No long introduction this time.  If you have been following along the scenarios have started to repeat, but become more useful with more complex configurations.

The playbook

This time the OWASP playbook will be used: https://github.com/brianehlert/ansible-nginx-examples/blob/master/nginx_lb_plus_modsec_OWASP_CRS.yaml
Along with that is the same nginx_lb_plus_modsec_vars.yaml variable file as the previous post.
One difference is that the framework file this time is: https://github.com/brianehlert/ansible-nginx-examples/blob/master/modsec_owasp.conf

If you compare it to the modsec_rules file from the previous post it lacks the test rule from last time.
Why?  Because I am going to build the rules on the fly within the playbook.

ansible-playbook nginx_lb_plus_modsec_OWASP_CRS.yaml -i loadbalancers

I am going to skip the basics of inventory and variables file reading.
The meat begins in the post_tasks of this playbook.

The playbook:
pulls the CRS from the SpiderLabs GitHub repository
unzips the archive
copies the example to a new file in the configuration directory
Selects out the rules names
Then writes out the names of the rules to implement into the framework modsec_rules.conf file.
Builds the includes
outputs the rule set just for review
and enables blocking.

After all this the configuration is tested to make sure it will work.  Assuming that passes nginx is reloaded to apply the configuration.

Now, the full OWASP rule set is implemented and working.

I am sure that someone can make that into a nice demo.

Wednesday, May 6, 2020

Getting Started with the Ansible Collection for NGINX Controller

Today, I have a new post.  And a video demo.

I am not going to write it here.  You can go view it at the NGINX blog.

To warn you, the subject line says it all.
I have developed a set of Ansible Roles for NGINX Controller and have combined those into a Collection.

Working with a Collection is slightly different than working with Roles, just like using Ansible Tower is a bit different than using AWX (aka free Ansible).

In the post I cover both at a high level, Collections and Tower with NGINX Controller.

I also have sample repositories that I am maintaining:
And for the series that has been publishing so far: https://github.com/brianehlert/ansible-nginx-examples

I plan on breaking down the NGINX Controller examples as I have been with the NGINX data plane examples.

Tuesday, May 5, 2020

NGINX Plus with modsec - part 4

Last blog we moved from NGINX OSS to NGINX Plus for the load balancer.
This time I am going to add the modsec module and configure a very basic test rule (one more post to get to the complex rules).

Just a reminder for folks entering the series mid stream:
The assumptions: local file system inventory files, Ansible host deployed to the same VPC as the remote machines, variable files, run the playbooks from the same folder as the inventory and variable files.

For this article we will use the following playbook:
And this accompanying variables file:

And we are using the Ansible Role for NGINX.

Running the playbook

Running the playbook is no different than the pattern in the previous posts:
ansible-playbook nginx_lb_plus_modsec.yaml -i loadbalancers

Like the NGINX Plus post before this will:
Read in the webservers inventory file and read in the nginx_lb_plus_modsec_vars.yaml file.
The variable file defines the path to the Plus key and cert, to delete the license and clean up, enable the NGINX Plus API.
The new variable option is: nginx_modules

In this case the waf module is added, which indicates mod security.

The remainder of the configuration is all the same as the two load balancer blogs prior. 
What does start to get unique to modsec is the post_tasks in the playbook.

Setting the waf module

In the post_tasks section of the playbook I am copying a framework config file for mod security rules.
After the framework file is copied into place the Rule is being enabled.
Then the NGINX config is tested (to make sure nothing went pear-shaped).
Assuming the configuration test passes the nginx process is restarted.

At this time some limited traffic should be blocked.
If you take a look at the modsec_rules.conf file, we are blocking a URL with 'test' in it.  As well as logging and returning a 403.

That is the basics of enabling a module with the Ansible Role on NGINX Plus.
In this case with additional settings of enabling a basic mod security rule.