Has anyone successfully used the version of certbot in jessie-backports
to install https certificates from letsencrypt on Apache?
The reason for asking is that I haven't :)
It doesn't help that the version there is older than the one covered by
the documentation at <https://certbot.eff.org/docs/using.html> - there's
no 'certificates' command, for example.
Ian
Hi all,
I was looking to upgrade my VPS to the latest Ubuntu release this afternoon but ran across a problem. Whenever I try to run "do-release-upgrade” I receive the following error:
Checking for a new Ubuntu release
Get:1 Upgrade tool signature [836 B]
Get:2 Upgrade tool [1,265 kB]
Fetched 1,266 kB in 0s (0 B/s)
authenticate 'xenial.tar.gz' against 'xenial.tar.gz.gpg'
gpg exited 1
Debug information:
gpg: Signature made Wed 07 Dec 2016 09:10:01 GMT using RSA key ID C0B21F32
gpg: /tmp/ubuntu-release-upgrader-r7c80csz/trustdb.gpg: trustdb created
gpg: BAD signature from "Ubuntu Archive Automatic Signing Key (2012) <ftpmaster(a)ubuntu.com<mailto:ftpmaster@ubuntu.com>>"
Authentication failed
Authenticating the upgrade failed. There may be a problem with the network or with the server.
Searching online<http://askubuntu.com/questions/842706/how-to-upgrade-ubuntu-if-i-get-authen…>, this looks like it could be a problem with the xenial.tar.gz file on the local repo cache. Has anyone else had similar problems, and if so, how did you resolve them?
I suppose beyond that, has anyone successfully upgraded their Ubuntu VPS to 16.04? Were there any problems along the way?
Thanks,
Paul
Hi,
If you do not use BitFolk's Entropy service and have no interest in
doing so then this email will be of little interest to you can be
safely ignored.
If you haven't heard about the Entropy service before, please see:
https://tools.bitfolk.com/wiki/Entropy
If you *do* use the Entropy service though, I'm interested to know
what software you have that actually uses /dev/random (and not
/dev/urandom).
Some background to this question:
To provide the Entropy service we use hardware entropy generators,
currently exclusively a pair of EntropyKeys manufactured by a UK
company called Simtec Electronics Ltd.
Despite the fact that these were extremely popular little devices
(compared to other fairly niche little gadgets), Simtec always had a
supply problem and then Simtec imploded as a company, so as far as I
know these are now impossible to obtain, the IP is lost forever etc.
Although I have one spare EntropyKey ready to put in service should
one of the two in service ever die (I've not experienced that yet),
that left me slightly worried as to what I'd do if I needed to get
more.
Then I saw the OneRNG kickstarter, and decided to pledge. So now I
have 5 of (the internal USB version of) these:
http://onerng.info/
I've not yet gone any further than verifying that they keep the
entropy pool full on the machine they're plugged into, but that's
good enough for now. Could be a decade before one of my existing
EntropyKeys dies.
I have since heard that this device proved far more popular than its
manufacturer expected (sense a theme?) and they're now extremely
difficult to get hold of because they need to get a new batch made
in China. I've had multiple people contacting me on the basis of a
tweet I did about getting these, asking me to sell them mine (which
I would, but they didn't want internal USB).
The point I'm trying to make here is that the world of hardware
random number generators is not one with reliable supply lines,
unless you want to spend a fortune on some black box.
So when I came across:
http://www.2uo.de/myths-about-urandom/
I was sad that the nerdery that is the Entropy service may be
misguided, but also happy with the possibility that I might never
have to source a hardware RNG again.
Let's just take the argument posited by the article, that all
(Linux) software should just learn to love /dev/urandom¹, as true.
If you don't agree with this claim, you are disagreeing with some
pretty big names in crypto. The Hacker News commentary on the
article may also prove of interest:
https://news.ycombinator.com/item?id=10149019
At the very least, I feel the Entropy article on the BitFolk Wiki
needs an update in light of this. To justify the service's
existence, if nothing else.
Going further, the question becomes, well, what software is there in
existence that forces use of /dev/random with no configuration that
would allow otherwise? Because even if we agree that all software
*should* be using urandom, if some popular software *refuses* to
without recompile, then we're still going to have to provide an
Entropy service, because doing so is easier than running
non-packaged software.
So Entropy service users, what have you got that uses /dev/random?
Cheers,
Andy
¹ A more correct summary of it is probably, "urandom is fine all the
time except for on initial boot when a small amount of entropy
from outside the CSPRNG is desirable."
On shutdown all fairly modern Linuxes save the current entropy
pool to the filesystem and load it up from there on boot, so it's
only essential on first boot.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Two bugs¹ have been discovered in Xen which have serious security
implications, therefore we must patch and reboot every host before
the security advisory comes out of embargo at 12:00Z on 2 May.
We'll be sending out notifications shortly to let you know the exact
window in which the reboot will take place for your VPS(es), but
this is just a short note to let you know that the work will most
likely be taking place in the early hours (UK) of 30 April, 1 May
and 2 May.
A reminder that if you wish you can have your VPS suspended to and
then restored from storage, instead of shut down and booted:
https://panel.bitfolk.com/account/config/#prefshttps://tools.bitfolk.com/wiki/Suspend_and_restore
Cheers,
Andy
¹ XSA-213 and XSA-215 - http://xenbits.xen.org/xsa/
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
I've just done a long-overdue refresh on my VPS. One of the packages
upgraded was Apache, to version 2.4-25. It appears the syntax of the
site conf files has changed since the last version I was running and all
is not totally "well on the farm."
I have two IP addresses bound to the server.
I am trying to achieve:
* Running a number of different web sites on domains I own, each with
its own folder on the filesystem.
* These websites are spread across HTTP a (80) and HTTPS (443) on both
IP addresses.
* I want separate conf files for each site to make taking them up and
down and reconfiguring easy.
* I want Apache to recognise which site to serve from the URL, rather
than the IP address.
* I want to be able to serve different sites from different folders on
some subdomains e.g. example.com serves one site and
mail.example.com serves another.
I've searched online and most of the examples I have found seem to work
on older versions of Apache, not on 2.4. Right now, it's "sort of"
working with most things OK but some URLs serving the wrong site so I'm
pretty sure I've got something wrong.
I would be really grateful if someone who is competent with Apache would
give me an example of how I should be crafting my conf files to make
sure everything is being done properly.
Many thanks,
Paul.
Hi,
Approximately 8 hours ago we were made aware that Cross-Site Request
Forgery (CSRF) could be used to trick a logged-in user of the
BitFolk Panel at https://panel.bitfolk.com/ into carrying out
changes that could allow their account to be compromised.
As there was no checking that requests actually came from forms
generated on the panel site, if a logged-in user was tricked into
submitting an HTTP request from elsewhere then they could
change sensitive details about their account such as:
- Adding SSH keys for console access
- Altering contact email address
- Invalidating/Disabling two factor authentication
- Enabling email password reset, if it was disabled
We have no evidence that any of these actions have ever been carried
out maliciously, but aside from reports we would have no way of
knowing, so we would advise that all customers log in to their Panel
account and check that the list of SSH keys is as they expect.
All of the forms on the sensitive pages, which include everything
under:
* https://panel.bitfolk.com/account/security/
* https://panel.bitfolk.com/account/contacts/
were today secured against CSRF so there is now no way to use this
technique to compromise an account. The vulnerability would have
been there ever since the Panel site existed, or the relevant
features were added.
The remaining forms, which only cover fairly trivial informational
items, will be fixed as soon as possible. You can track that work at
our tracker:
* https://tools.bitfolk.com/redmine/issues/156
Thanks must go to Dominic Cleal <https://m0dlx.com/> who responsibly
disclosed the problem to us today and has assisted with testing of
our fixes.
More general information about CSRF:
* https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
If you have any further questions please do let us know by replying
to the users list (users(a)lists.bitfolk.com) or to
support(a)bitfolk.com if you need to discuss anything specific to your
account.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi, folks,
This may impact some of you:
https://www.pwc.co.uk/issues/cyber-security-data-privacy/insights/operation…
That URL contains two PDFs (linked near the bottom) - one with a narrative
report, and another with indicators of compromise. You may benefit from
searching through your IDS and netflow logs for these IOCs.
On a related note, I've seen a number of examples lately of IT folks being
targeted where they're less on guard (e.g. home/personal infrastructure) as
a vector for gaining access to juicier targets at their employers. You
don't have to be personally wealthy or otherwise of direct interest to be
of use to an attacker.
--
Graham Freeman
https://graham-freeman.info/
Hi,
The BitFolk web site (https://bitfolk.com/) has had a bit of a
refresh - the first one in about 10 years!
No major changes, just a more responsive design that works better on
different devices and is no longer fixed width.
There's still a few bits and pieces that need doing, notably the
order process could do with improving and not being a table layout.
If you have any other constructive feedback please let us know. :)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
A bug¹ has been discovered in Xen which has serious security
implications, therefore we must patch and reboot every host before
the security advisor comes out of embargo on 4 April.
We'll be sending out notifications shortly to let you know the exact
window in which the reboot will take place for your VPS(es), but
this is just a short note to let you know that the work will most
likely be taking place in the early hours (UK) of 30 March, 31 March
and 1 April.
A reminder that if you wish you can have your VPS suspended to and
then restored from storage, instead of shut down and booted:
https://panel.bitfolk.com/account/config/#prefshttps://tools.bitfolk.com/wiki/Suspend_and_restore
Cheers,
Andy
¹ XSA-212 - http://xenbits.xen.org/xsa/
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce