
EUD Security Guidance: Ubuntu 18.04 LTS - pmontra
https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts
======
isostatic
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/](https://www.darkwirevpn.com/vpns/ipsec-versus-openvpn/)

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

~~~
angry_octet
IPSec implementations are so complex, I have no faith they are rigorously
debugged. I'm quite partial to Wireguard
[https://www.wireguard.com](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!

~~~
viraptor
> 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)

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

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

~~~
isostatic
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](https://news.ycombinator.com/item?id=17654658)

~~~
wink
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](https://www.open-scap.org)

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

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

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

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

