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,
As you may be aware there are a few things that we (or third party
services on our behalf) scan for on our own network. A
non-exhaustive list of these things are:
- Open SNMP servers
- Open DNS resolvers
- Open portmapper services
- Open MongoDB / Memcached / Elasticsearch / Redis
- Open Remote Desktop
- Open multicast DNS (Avahi)
- Open TFTP server
- SSLv3/Poodle vulnerable services
…and so on.
Where these can only negatively affect the operator of the service
(e.g. SSLv3/Poodle or an open MongoDB), we are content to just email
you forever.
However, many of these problems are worth scanning for because they
are easily and frequently used to attack other hosts. For example,
any "chatty" UDP protocol like portmapper or DNS can receive spoofed
requests which will amplify, making for a DDoS on a third party.
So, when we email customers about these it's because we need them
fixed.
Unfortunately some customers are either not receiving these emails
or are happy to ignore them, for months at a time, basically until
we open a support ticket with them and ask why they aren't dealing
with it. This is taking up too much human time.
"We did not receive the email" is now no longer a valid excuse
because there is provision in our web panel for an
emergency/alternate contact:
https://panel.bitfolk.com/account/contacts/#toc-address-book
If we've been emailing a customer for weeks about this then we will
have also sent a copy to the emergency/alternate contact at some
point.
So, I would like your opinions on how you think we should deal with
this. Two proposals I can think of are:
a) After at least 21 days of sending email alerts to the main
contact and the emergency contact and receiving no response, a
firewall rule will be added to block the problematic service and
an invoice will be raised for a managed firewall service, which
will be a monthly recurring charge. This will be quite expensive.
Or:
b) After at least 21 days of sending email alerts to the main
contact and the emergency contact and receiving no response, the
VPS's networking will be suspended. Networking will be re-enabled
when contact is re-established and a plan for securing the
problem service is agreed by both BitFolk and the customer.
I have already broached this question on IRC and basically no one
was in favour of (a) because they did not feel that surprise
invoices would go down well.
If you have other suggestions for how it should be handled I would
be happy to read and consider them. Ideas that involve either not
dealing with the problematic services or that aren't suitable for
automation are not likely to be acceptable though.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
I have signed up for the Bitfolk backup service and have to admit I didn't
spend too much time thinking what I should back up.
I'm interested in a survey of what people choose.
Personally I've got:
/home/ - because it obviously has files I want there
/etc/ - because there are config files in there I don't want to have to
recreate
/root/ - similar to /home, although I could probably move that
/srv/ - this is from when I migrated from a previous provider and I haven't
moved it elsewhere.
/var/ - I think this is probably the cause of the problem. I initially
thought /var/log would be useful and things like that. Do I need all of
/var? Probably not.
Is there anything obvious I've missed? Do many people just do /?
Thanks,
Paul
Just want to say thank you to Andy for taking care of our interest
throughout the year and to say hello to all the former HantsLUG guys
and gals who are still around, quite a few using bitfolk.
--
John Lewis
Debian & the GeneWeb genealogical data server
Hello,
The documentation for BitFolk's backups service was really in need
of an update so I rewrote it and moved it to the wiki here:
https://tools.bitfolk.com/wiki/Backups
If you use other services to backup your VPS then please feel free
to add them to the section at the end:
https://tools.bitfolk.com/wiki/Backups#Alternative_backup_strategies
If you do something more than "just use Foo service" to backup your
VPS and feel like writing up a separate article then linking to it
from there would also be welcome.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
A bunch of alerts were just sent out regarding backup3.bitfolk.com.
I am doing some work on this host and forgot to disable alerts.
There is no need for concern. Apologies for the confusion.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
I think just turning the dropdowns into radio buttons (so all are visible
immediately) would solve the immediate UX problem.
--scott
On Dec 19, 2016 9:32 AM, "Richard Dignall" <richard(a)dignall.co.uk> wrote:
On Mon, Dec 19, 2016, at 02:30 PM, Roger Light wrote:
> It makes sense to me now that you've said that. I think it's confusing
> as it is. For those people with only a single person on the account I
> imagine there is a tendency to ignore the "add another contact" option
> because I'm already the contact and so there should be no need.
This. At some point I probably clicked to add a new contact, saw that
there were no obvious fields that linked to anything different that
wasn't in the main contact, and clicked Cancel.
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
Hi,
There was a consultation earlier regarding what to do about
customers who do not react to the alerts we send about serious
security issues we have found during regular scans of our IP space:
http://lists.bitfolk.com/lurker/message/20161215.152008.2ee18732.en.html
Dealing with that was becoming quite a time sink and I was also
getting concerned about potentially inconsistent handling of these
issues when not working to any kind of documented process.
The consensus seemed to prefer the idea of network suspension after
21 days, so this has now been documented along with a bit more
information about the things we (or partners) scan for:
https://tools.bitfolk.com/wiki/Vulnerability_scanning
This will now allow for some more automation.
I've also updated the Terms and Conditions page:
https://bitfolk.com/policy/terms.html
with a new paragraph that points to that page:
BitFolk and its partners regularly scan BitFolk's IP space for
well-known vulnerabilities and misconfigurations, some of which
are serious enough that BitFolk will insist that The Customer
fixes them within a reasonable timescale.
Although the paragraph above that one is the usual blanket "reserve
the right to suspend service", so perhaps technically not necessary
to list particular things, it does however seem like useful info to
have there.
Normally we try to have changes to T's&C's not take effect for 30 days but I
don't see this as a change, since we have always used the "reserve
the right to suspend service" clause if necessary with things like
this. So if it is unfortunately necessary to suspend someone's
network we won't be waiting until 30+21 days to do it. And happily
there currently isn't anyone who's been receiving alerts for
anything like that long.
If you have any questions or feel the article (or process) could be
improved please let us know.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
"The electric guitar - like making love - is much improved by a little
feedback, completely ruined by too much." — The League Against Tedium
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
If you don't use BitFolk's backup service then you can ignore the
rest of this email.
For a very long time we have allowed customer backups to go past the
quota and still continue working, arranging at a later time to fix
that situation (by the customer asking for some backed up data to be
deleted or else ordering more storage for backups).
This is now changing so that backups will stop happening once the
quota is exceeded.
Nagios alerts have always been sent out as WARNING at 95% of quota
and CRITICAL at 99% of quota. There is also a Nagios check for age
of backups and that will start to fire when there has been no
successful backup for a certain amount of time¹. Those whose backups
get suspended for being over quota will start to receive that one.
So, if you are currently receiving these alerts you do need to do
something about it.
Customers who are already over their backup quota at the moment have
already been contacted via support ticket, but in future we may
leave it down to you to get in touch.
Cheers,
Andy
¹ The time scales for those alerts depend on the backup schedule in
use. For those having a backup run every 4 hours (the default)
it's a WARNING after 10 hours and CRITICAL after 24 hours.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
Rather disappointingly there's been another round of security
advisories for Xen, some of which affect the configuration in use at
BitFolk:
http://xenbits.xen.org/xsa/
So unfortunately that means another round of "patch and reboot
everything" for us.
We will send out direct emails informing you of a two hour window in
which the work affecting your VPS is going to take place, but that
won't be sent for a week or so as testing of the patches will be
necessary first.
I am going to try to get a checkbox added to the panel website so
that those of you who are brave enough to try it can indicate that
you'd prefer for your VPS to be suspended and restored rather than
shutdown and booted.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce