UK cyber security boffins dispense Ubuntu 18.04 wisdom The UK’s National Cyber Security Centre (NCSC) has dispensed advice aimed at securing Ubuntu installs and followed it up with help for Dixons customers. The NCSC, part of the UK’s Government Communications Headquarters (GCHQ) exists to make the UK a safer place to do business online and, in an unusual step for a Government …
... Really wish I hadn't.
Usually, it takes me 10-20 minutes to get a new VM up and running. After 2 hours of xrdp crashing causing the Ubuntu Desktop, I decided to junk it and try Server instead, which had a completely different set of problem.
I was spitting blood... so much in fact, I actually downloaded Fedora! (that's how desperate things got).
Strange. I've been running 18.04 for a few months with no problems.
However I usually do a nice clean reinstall - copy all my files off to the NAS box and then wipe and install from freshly downloaded media. I've found upgrading ubuntu releases in place is... well... not always a good idea.
I didn't find desktop too bad; it worked for the limited use case I wanted it for. Some 'interesting' decisions made by the devs but it basically works.
18.04 Server is a turd; it's one thing to completely change the way you do network configuration, quite another to have the new complicated method not work properly. I blame fiddling for the sake of it by bored inept devs for that mess.
Then I found a whole set of basic configuration options wouldn't work properly whichever of a dozen methods I tried to use, rendering the whole thing useless.
16.04 at least worked.
Eh?
Vmware workstation 12. Download as fast your internet will allow. Install I think is 4 lines of text might have been 5.
Time to create is about five minutes of a few sliding scales and some numbers then next next. Then depending on your install it takes as long as it did with a disk. For windows 7 I think mine took about 20 minutes to go through the normal install wizard.
Once setup install time is a double click and watch it load, maybe twenty seconds for windows 7. This is on Ubuntu on my dell XPS 13.
Sounds like you had a bad experience but VMWare workstation 12 also passes through 3D graphics, much better than virtualbox.
Twas ever thus. CESG, now part of the UK NCSC, is the UK government’s National Technical Authority for Information Assurance, providing advice on protecting information and systems. Other parts of GCHQ - I'm not familiar with their org chart - try to break the cyber and crypto security of comms and systems.
Similar to the NSA and their NCSC, in the USA.
Go read the linked page at www.ncsc.gov.uk.
"To meet the principles....Use a Prime or Foundation Grade IPsec VPN client configured as per that product’s security procedures to give data-in-transit protection."
This contains a link to "approved" software including IPSec VPN clients.
Now guess how many are listed for Linux. Or just follow the link and have a look for yourself.
"cut down on the admin rights..."
Yes, that's one thing that has always puzzled me about Debian based systems. Why is it that sudo is used instead of su? To me that looks like an invitation to meddling and the chance of doing serious damage to your system.
I use PCLinuxOS and their forum has a piece on the potential abuse of sudo and why sudo is not recommended for use in PCLOS.
Why is it that sudo is used instead of su?
Several reasons. Firstly, sudo logs all its invocations. (If you use sudo -i, that log becomes less useful). Secondly, sudo can be configured to only allow a user to run a certain subset of commands. su is an all or nothing command. Finally, su requires the destination user's password (e.g. root) whereas sudo requires the current user's password (or not at all). One benefit of this, is that when an employee leaves, you don't have to change all the root passwords, you just delete their account.
Is sudo perfect? No. As your linked article mentions, the user's password becomes the keys to the kingdom rather than a separate root password.
Know the facts and make your choice.
"Firstly, sudo logs all its invocations. Secondly, sudo can be configured to only allow a user to run a certain subset of commands."
Those, in my view are because sudo is a kludge to overcome:
"su is an all or nothing command."
Which it has become as a kudge because root is now used for a great many purposes which could and should have separate administrators: e.g lpadmin to manage printers, bin to install and upgrade S/W. But that was too inconvenient so root got handed all the powers.
"Finally, su requires the destination user's password (e.g. root) whereas sudo requires the current user's password (or not at all). "
You say that as if it's an advantage. If the user has adopted a weak password that's all that stands between anybody who cracks it and root permissions. Requiring a second password provides an extra layer of protection.
"One benefit of this, is that when an employee leaves, you don't have to change all the root passwords, you just delete their account."
Again, it's the convenience thing.
I harbour suspicions about that (convenient)option to enter further sudo commands within a given period. It opens the door to an exploit.
"Requiring a second password provides an extra layer of protection."
See rootpw and targetpw configuration options.
"to enter further sudo commands within a given period"
See timestamp_timeout
It's a little harsh to condemn a useful tool just because its default configuration isn't to your liking. My preferred method is to keep root's password secret (and in the DR firesafe) and require long and strong passwords for administrators (audited by actually running John the Ripper).
"If the user has adopted a weak password that's all that stands between anybody who cracks it and root permissions."
This should not be an issue.
With roughly 2,000 employees, about a dozen can get root access on servers, infrastructure devices, etc. The rest, including developers, vendors, etc, cannot. That dozen knows better than to use weak passwords.
Just make sure you keep the sudo group small and aware.
I once worked for a tech firm where the Director of IT insisted he be allowed to use a 2-letter password, and that I covered this up in the logs and audits.
In my experience those who should know better are often the worst offenders and more likely to get caught out though their own cockiness and over-confidence.
A major factor is there is no root account. So you have to guess both the account name(s) that have sudo rights AND a matching password. If you ever look at your SSH/auth logs without any tight IP restrictions you will see lots of attempts to log in with names such as: root, admin, pi, test, oracle...
As others have mentioned, sudo gives you much more fine-grained control over who is allowed to do what. But there are other advantages over plain su:
- You have an audit trail of who ran which admin command when. For some of us, that is a compliance requirement.
- Communicating a shared password is difficult. Tends to happen via e-mail which is NOT secure.
- When you have 20+ servers, changing the administrator password because Joe Admin left the company is not so simple.
- Passwords can be cracked or leaked, so a security compromise of one server quickly becomes a site-wide problem (unless you use unique passwords, which complicates the distribution issue further).
I try to avoid passwords as much as possible, to the extent that my personal servers do not have passwords (a '!' for the password field in /etc/shadow). Logins can only happen via ssh using SSH keys or certificates, and sudo is setup to require a one-time password or physical token (Yubikey). If you must use passwords, at least make sure you keep them centralized (ldap directory or similar).
In other words, think about how you implement security instead of just bashing some random tool based on a 7 year old forum post.
"When you have 20+ servers, changing the administrator password because Joe Admin left the company is not so simple."
I think the word you were looking for was "convenient". Do not trade security for convenience.
"Passwords can be cracked or leaked, so a security compromise of one server quickly becomes a site-wide problem (unless you use unique passwords, which complicates the distribution issue further)."
Just so. If an admin's personal password is cracked what stands between the cracker and root? If you have multiple admin users the cracker only has to get lucky with one of them.
"In other words, think about how you implement security instead of just bashing some random tool based on a 7 year old forum post."
I don't have to base my dislike of sudo on any thing as recent as a 7 year old forum post. I can make up my own mind.
The problem with putting security above convenience is that people are lazy, and if it's 'too hard' to stay secure, then, well, you won't stay secure.
For example, in this case, if you're relying on changing the root password on multiple servers because someone has left, and then a few weeks later someone else leaves, it's all too easy for that task to be postponed until it's forgotten about.
The easier you make it to be secure, the more likely people are going to stay secure.
Presumably ordinary users are urged to use a password-store program with long passwords because it's a good idea, and not just to annoy them. But what do I know?
I have a password-store at work; I have to input 3 passwords to open it. One of those is "password". I don't actually use it to store passwords in. If I did, then they wouldn't be behind "password".
You have 20+ servers, and you want to change passwords by hand? SW guy here. This is why devops has become a thing.
------------------------------------------------------------------------------------------------------------------------------
We have 400+ servers, and local root passwords are *always* set by hand... then never used.
Root access is by sudo, or by privileged individual Windows accounts.
Using root passwords is very discouraged except in extreme emergencies when access to central authentication servers is broken, as it muddies up tracking by logging multi-user accounts.
So, which is it.."never used" or only used in "extreme emergencies"? The policy implications of the two use cases are substantially different.
If it is in fact never used, then what matters what it is? Disable it & be done. Heck, this is an exception to the "never hard coded" rule I just mentioned.
If it is in fact held in reserve for "extreme emergencies", then you have a problem: how do you know that one of the 400 by-hand settings was not mis-typed? This is a serious amount of toil you are bragging about. Would you still be proud to set 8000 root passwords by hand? 160000?
We use software because we are stupid & because unnecessary energy expenditure is a bad thing. You can continue to manage 400 root passwords by hand because you consider it to be "secure", but I can all but guarantee that the actual failure rate you experience will be significantly higher than if this were managed by good software.
I don't know how you can say that. HMRC did a pretty good job of finding an email address I'd never given them and, only yesterday, wrote to tell me I'd got a tax rebate.
Just felt a need here to even things back out.
HRMC did a pretty good job of losing a new home address I'd given them, and wrote to me telling me I was getting surcharged for not doing my self-assessment!
@Adair:
Why do you call it 'smearing', when I'm just stating facts? Trying to downplay these facts as if they are not true, that's truly disingenuous.
I like free software and I certainly like Linux. What I don't like is companies that spy on people, thereby limiting their freedom, while justifying it by arguing the product doesn't cost money, even calling it free in the perverted sense of the word.
Remember Ubuntu boss Shuttleworth's response when they got caught out on the data leakage: "Erm, we already have root.".
@nonnijaturtle
"Why do you call it 'smearing', when I'm just stating facts? Trying to downplay these facts as if they are not true, that's truly disingenuous."
Because that was fucking ages ago, and blew such a stink that they removed it and havent done it again..
So unless you live under a rock with no news source, it's irrelevent to version 18.04 , it looks like your bringing it up as a smear
May just be me, but with Ubuntu actuall getting the lions share of mainstream linux (actually coming pre-installed on some machines) have Cannonical made a rod ofr their own backs, much like Apple did with MacOS?
IE has its market share now made it a target, and consequently all the other Debian/Ubuntu based distros?
Makes sense as it becomes more popular it'll become more of a target but Ubuntu and linux in general represent a fairly tiny proportion of desktops and that's where the money is, either hitting home users or as a gateway into the DB servers irrespective of what those run on.
The installer somehow trashed the apt dependency tracking so it spewed errors, said my computer was in an inconsistent state, then the system crashed. Thanks! Some time in the console got the installation resuming. After that, I noticed that live services had their configuration files significantly changed. It wasn't secure at all and I cleaned up as fast as I could. AT&T even sent me an email saying unsafe ports were open. The installer should have turned off every service that received major configuration updates but it left them on. The worst was Samba. Samba was supposed to offer only encrypted CIFS, and it was set to all interfaces. The update turned on all the DNS junk while Samba was still on all interfaces.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
