[Wylug-discuss] Summary of WYLUG meeting on Monday 29th February 2016

[David Morris]

Hi,

I've done a quick summary of the meeting from last night in the hope it
will encourage some more people to come along. Feel free to nit pick!

I added Wylug on Meetup.com -
http://www.meetup.com/West-Yorkshire-Linux-users-group/ and we always have
quite a few people who say they're coming but rarely do they all turn up. I
wonder if it's because we don't have the meetings in the city centre. We
discussed having the next meeting in the centre so if anyone has any
recommendations please send them to the group.

*Linux security problems*

Since the last meetup we've had the Linux Mint website being completely
owned with the download links to the legitimate ISOs being replaced by
versions including a backdoor and malware. The result of this is that
anyone who downloaded Linux Mint on February 20th should check the blog
post at http://blog.linuxmint.com/?p=2994 to see how they should check if
they might have the hacked version.

There's also been a wider problem with an implementation of one of the core
C libraries built into many linux based devices - glibc. The issue is that
a remote attacker could send a malformed response to a DNS request,
overflow the memory allocated for the response on the target computer and
then get additonal unwanted code to run and take over the computer. the
result is pretty bad - a remote exploit that doesn't require any sort of
access to the target computer, but the method of attack is a bit cumbersome
and requires the attacker to send the malicious DNS packet response before
a real DNS server can respond. This means the attacker needs to preferably
be a man-in-the-middle which could be accomplished if you connect via a
public internet connection (e.g. Starbucks Wifi). There's a sensationalist
write up about this at Ars Technica
<http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/>
and a nice blog about how to achieve this in the real world here:
https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

Home users should patch as soon as possible - for enterprise the same goes
but you could mitigate it by having a local DNS resolver which drops larger
packets than 1024 bytes in the short term whilst you roll out the patch.
The bigger issue is that there'll be a lot of embedded devices with the
same security problem, and not many people have the ability to update them.

*Raspberry Pi3*

Horay - there's a new Pi! Recently announced, at the end of February, the
new Raspberry Pi 3
<https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/>has:

   - 1.2GHz Quad Core Broadcom 64 bit processor
   - Wifi on board - 802.11b/g/n
   - Bluetooth Low Energy on board
   - 1GB Ram @ 900 Mhz
   - 4 x USB 2 ports
   - 40 pin GPIO
   - HDMI, RCA video output
   - Fully compatible with Raspberry Pi 1 and 2.

It's around £24.99 + VAT but already sold out everywhere and available on
back order.

The Pi 3 uses a bit less power when idling than the Pi 2 and the same at
full load so it'll save a few pennies if you're running 10 Pi 2's in a
multi room sound and media serving extravaganza
<http://mailman.lug.org.uk/pipermail/wylug-discuss/2016-February/004476.html>

I wondered if the Pi3 might suit as a replacement server for my current
monolithic Plex server - but I need transcoding at 1080P and the Plex
recommendations are at least Core 2 Duo 2.4GHz for each stream.

Graham suggested I look at the Intel NUC
<http://www.intel.co.uk/content/www/uk/en/nuc/overview.html>range - these
look like they will manage the job of transcoding very well, the small ones
are fanless (and therefore silent in the living room) and they look good so
have the all important WAF (wife agreement factor).

*SSH Keys*

Darren wanted to know how we go about generating and using SSH keys. Andy
and Graham summarised that you create a SSH key pair using the program
ssh-keygen in terminal. Normally you would want to add a few extra flags
for more security and entropy, but for testing you can run ssh-keygen with
no flags.

Once you run ssh-keygen, the program will use some random inputs form your
computer to generate your own unique set of keys - one public and one
private. These are Asymmetrical Keys so one key can always decode something
encoded by the other key (and vice versa), but there's no way to work out
what the other key looks like if you only have one of the keys. For example
if I have one key and I encrypt the word "sausages", then only the other
key can be used to decrypt the enciphered text back to "sausages". This
allows one person to prove that they have the matching key to the other key
as the only key that can be used to decrypt the encrypted text is the
opposite key to the one used to encrypt it.

The private key is a file which is always to be kept safe by yourself and
not given to anyone else (unless you want them to impersonate you or login
as you). The public key is a file which you can put onto a remote server so
that when you want to login to the server you don't have to necessarily
type a password as you can authenticate yourself to the server using your
private key against the public key which you previously sent to the server.
The security benefit of this is that it's  impossible to brute-force a key
using existing hardware technology in the way that someone might
brute-force your SSH password. As long as you keep your SSH private key
secure, where no one can steal it, then no one can login to your servers as
you.

When you want to login to the SSH server it sets up an encrypted tunnel
between you and the server, you provide the user that you want to
authenticate as, the server checks if that user has a public key stored on
the server, it finds the public key which you placed previously on the
server, and it then sends back a message encrypted with the public key.
Your SSH program receives the encrypted message, decrypts it using the
private (aka opposite) key, then re-encodes it with some extra info and
sends a hash of this back to the server to prove that it has the private
key.

It sounds a bit messy but in practice it's really easy to do - ssh-keygen
generates the keys for you, you need to send the public one to the server
you want to automate the login to, then next time when you connect using
SSH you tell your SSH client where to look for your private key. There's a
great, and much more thorough, explanation about it here
<https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process>

*Ubuntu 16.04 LTS*

The newest version of Ubuntu with Long Term Support (LTS) is nearly ready.
This is a major release and the LTS badge means that ubuntu will support
the system for 5 years with updates and patches - after which it's normally
recommended to upgrade to the newest LTS.

The 16.04 LTS beta is finally available to test out, but non of us had
actually tested it so we have no news to report on what it's like in
practice.


*Amazon Dash button with embedded Linux*

I went to the Amazon AWS Leeds meetup a few weeks ago. It was very good,
definitely recommended, and there was an Amazon representative there who
gave a great demonstration and explanation of how the Amazon dash button
works and then replicated it's functionality on a Raspberry Pi 2.

We don't have the dash button yet in the UK, but I had heard of it before.
It's a small oval shaped button, supplied for free from Amazon, using
embedded Linux, linked to your Amazon account and allows you to to do only
one thing - to order one specific product without doing anything except
pressing a physical button. For example if I had a Amazon Dash button for
washing powder, I would stick the dash button on my washing machine and
when I noticed I as running out of washing powder, I press the button and
the next day Amazon deliver more washing powder. Here's a picture of how it
looks.
<http://s3.amazonaws.com/media.wbur.org/wordpress/11/files/2015/04/0401_amazon-dash-button-624x421.jpg>

When you press the button this boots the device and starts a small LED
blinking. After the device boots it connects to the local Wifi, connects to
Amazon and then uses the MTQQ protocol <http://mqtt.org/faq> to send a
packet to Amazon AWS with the device ID and the state of the button (e.g.
it was pressed or it was pressed and held down). Amazon  processes the
incoming packet to see if the device is allowed to order or not. If it is
then it orders the product and sets the device to not be allowed to order
any more, and sends back a packet to say it was successful in ordering. If
the device isn't allowed to order then a packet is sent back saying the
order failed. If the order was successful the LED turns solid green (or
maybe blue, I cant remember which he said) to let the user know that it was
successful, and red if not.Then after a few seconds the devices powers off.

When the product is confirmed as received by you (e.g. on signed delivery
or delivery note from the shipment company) then the device logic at Amazon
is changed to allow it to order again. this means you can't accidentally
order a ton of product, but you can order the product again as soon as it's
delivered.

There's a teardown here
<https://mpetroff.net/2015/05/amazon-dash-button-teardown/>and an of how to
get it to run your own bare metals code. Apparently you can order the
devices form ebay and then reprogram them yourself if you feel inclined to
do this.

*Dropbox alternative Tresorit unintsall script will delete everything in
the directory it is run*

A few months ago I moved from Dropbox to Tresorit in a bid to provide
end-to-end encryption for my backups and shared folders/files.

I tried to uninstall the Tresorit client on my Ubuntu laptop and
unfortunately the uninstall script completely removed *everything* in my
home folder. The result of this is that it wiped all my user settings, my
pictures I had saved in my home folder, some work I had saved only at home,
all the SSH keys and SSH config file for remotely connecting to servers and
the desktop customisation I had spent a bit of time on to get Ubuntu's
Unity interface looking a bit nicer.

The Tresorit support team wasn't very understanding and confirmed that the
uninstaller runs rm -rf in the current folder which results in all your
files being wiped. There's no warning that this will happen and no way to
recover the files

This is a good example of why we should always check the source code of any
script file (e.g. those ending with .sh) before running them.

*Dropbox alternative Seafile*

Andy has been running the open source Seafile
<https://www.seafile.com/en/home/> file synchronisaiton and cloud backup
software at his place of work, serving thousands of subscribers using the
community edition hosted inside their network. Seafile runs on Linux (can
run on a Raspberry Pi) and Andy recommended it - it apparently runs great,
has client-side encryption, Linux clients, iphone/Android clients, file
snapshots (aka scheduled backups) and the community edition has a lot of
features. I'll certainly be looking at moving to it from Tresorit.

*Other discussions*

Darren was using an a browser I hadn't seen before called Abrowser. This is
based on the Firefox source but it removes the Firefox copyrighted logo and
turns Firefox into completely free software.
https://trisquel.info/en/wiki/abrowser-help

William Hill have been in contact to see if we would like any sponsorship.
I raised this at the meeting and we all agreed that it might be worthwhile
to ask them to provide a talk of how they use Linux and what sort of things
they do at William Hill. I'll get back to them and see what we can come up
with.

I'm sure there was a lot more that we discussed but I never remember to
make notes so apologies if I've missed something out which was important!

*Next Meeting*

The next meeting is scheduled for Monday 28th March. There's been a few
suggestions that we should have the meeting in Leeds City centre as this is
easier for more people to attend than the Lord Darcy pub. Any suggestions
please let us know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/wylug-discuss/attachments/20160301/5992f0ba/attachment-0001.html>