Report from February’s Meeting

Thanks to David Morris for the following report on February’s meeting

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 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 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

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 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

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.

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 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 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 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.

_______________________________________________
Wylug-discuss mailing list
Wylug-discuss@wylug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/wylug-discuss

Comments are closed.