Some interesting bits of information here, like "connectivity checker", but you have to go a long way down the page before the specific ubuntu stuff crops up -- most of it is the usual enterprise stuff about locking it down so the users can't actually use the computer.

They don't think LUKS is good enough for full disk encryption

They don't like OpenVPN -- IPSec is the only approved vpn. That led me to https://www.darkwirevpn.com/vpns/ipsec-versus-openvpn/

I fully agree with no "curl http://blah | sudo bash " though. If software is worth deploying, it's worth deploying as a package (deb, snap, container, whatever. Versioned. Repeatable. Signed)

IPSec implementations are so complex, I have no faith they are rigorously debugged. I'm quite partial to Wireguard https://www.wireguard.com.

As to the guide overall, it suffers from the typical delusions of enterprise IT, which delivers a castrated platform with marginal security improvements. Users will still suffer XSS from crappy Oracle corporate applications, phishing, buffer overflows etc. But at least they won't be able to use grep! Nasty bash programs!

> Users will still suffer XSS from crappy Oracle corporate applications, phishing, buffer overflows etc.

Buffer overflows - the guide mentioned both sandboxing (snap/apparmor) and remote low level data collection (auditd). If you don't trust the app, that's about as much as you can do.

Phishing - There's not much the OS can do. 2fa is required on the service itself, but that's not in scope for this doc.

XSS - Since you're connecting through a proxy in the recommended networking setup, there's a chance some known endpoints will be blocked. Again, that's in scope for the remote service, not really the OS setup.

I think they did a good job of describing what can you do as far as end-user workstations go. You could do some improvements by getting a grsec kernel, but that's not really Ubuntu 18.04 anymore. (I wish they mentioned it as an option though)

My point is they are crippling the functionality of the computer to achieve a marginal security improvement. The insecurity largely resides on the applications, which it barely touched on. Snaps are great, but anything that can touch X is a problem. Profiles for AppArmor are tricky to get right. If they want to do confinement then dockerised apps is much more effective than treating the end user as the primary threat to guard against. All the effort to prevent end users running binaries won't stop ROP gadgets or prevent kernel breaks. Adding 2FA for login, decent firewall and container networking rules, and syslog reporting, would be far more useful than their bizarre paranoia about users running scripts.

The complaint about LUKS is also bizarre, because the work function for trying one passphrase is enormous by default, and easily configured to be stupendously costly (e.g 30s). Its also quite feasible to boot from a USB key, which has a passphrase wrapped key; when separated from the computer this is very secure. TPM isn't foolproof either, so it comes across as rather ill informed.

There's also zerotier https://www.zerotier.com/ if you want something nicer to configure and potentially need to handle double-nat. The implementation is not as minimal, but will pretty good.

I really like their Edge devices, particularly the ability to enforce a distributed firewall. However, it really isn't clear to me how their crypto works. They use PK to do something, and traffic is encrypted with a symmetric cipher. How are nodes authenticated to join? It isn't clear from their description. They don't do PFS, it seems like there is no key rollover at all? Maybe I'm just obtuse, but I don't think they have explained it very well.

I've only skimmed it but for a government policy document it's refreshingly good. I've not seen the typical "doh" things and I'll definitely give it a closer look.

Be sure to read this comment [0] alongside it. My feeling is this sort of document is fine to dip into it as a guide, and select what makes sense to you, but it feels very 'depth first'. It goes to extreme lengths to stop people using a computer, and neglects that fact people will simply bypass this and do their own thing anyway. The typical IT-first 'enterprise' solution to that is disciplinarys etc. Very few companies are (or should be) run by enterprise IT departments.

If you have to implement half the suggestions they make, you're probably doing it wrong. If you're that paranoid about giving a user access to a computer, you shouldn't give them access, not jump around locking down their access to bash once they are on there.

While the attitude of people who believe these documents still exists (in a few companies), people will simply avoid enterprise IT. A far better solution would be "sure, use ubuntu, just ensure that you install this package (which does a few sensible things -- syslog, package version reporting, etc)

[0] https://news.ycombinator.com/item?id=17654658

Had this exact discussion today :)

party a said: let people read it and be educated

party b said: let's install OpenSCAP[0] and get some reporting

That said, I didn't mean to say "this is awesome, do it like they say" - but I'd definitely liberally use some parts of it if I were to write such a doc for my org. I'm not with BigCos usually so I'm no fan of clamping down root access, etc. I think developers basically need admin access on their machines except at the scale of Google where you have a dedicated force of people just caring for the tooling and that everyone can actually work instead of filing "please install libbzip2" tickets...

[0]: https://www.open-scap.org

A weird thing occurred to my installation a month ago. I was on previous ubuntu version (17).

According to a wireshark scan, there was a strange UDP continous stream, even with all applications closed. My computer was reaching several IP in Europe. The text of the stream was encrypted, I was just seeing "...token..." or thing like that.

I formatted and installed Ubuntu 18, the network is clean now.

I'm pretty sure I add some kind of malware, I have no idea what it was, it's very suspicious.

sudo netstat -planut would have shown what process was sending udp (and any other connections)

If I run up an iperf stream from one AWS server to another and run that command, one line that's out is this:

  udp        0      0 172.26.4.22:44142      52.56.147.150:5001      ESTABLISHED 20114/iperf

If the process actually tries to be stealthy you won't see open UDP sockets like this. If the data is only sent out, or the all is using polling, the socket can be created and destroyed as needed.

A better approach could be systemtap which has a whole system visibility.

Presumably it would show up in a netstat, but only while the packet was being written to the network stack?

  open(SOCK)
  // now visible 
  write(SOCK, contents)
  close(SOCK)
  // no longer visible

It would have been pretty easy to track down what was doing that at the time, using netstat and similar.