I recently mounted a new partition and moved /home and /var/lib/mysql to the new drive and did a symlink to them.
Now I've noticed that the entropy (using munin) has dropped from around 3000 to around 100-200. Could the data mount and move caused this?
I use this as an apache webserver to host a site facing public users and I've noticed an increase in load as well (could the low entropy caused this?)
If this is a big issue, I would like to figure out a way to solve the low-entropy problem.
I've read that I can add entropy by using rng-tools and switching to using urandom. People say this is not a good approach for security-conscious systems. But would this be fine for a web app? How much less secure would that make my web app (we utilize encryption (hashing) for things like passwords and confirmation links and such, but I'm not sure how much of that falls under as "security-conscious")
Any ideas?
I'm using a cloud instance CentOS 5 (virtual machine).
If you have sufficient entropy to seed your pseudo-random number generator (PRNG), it should be more than an adequate source for most purposes.
Using rng-tools you can feed /dev/random with entropy from /dev/urandom using:
(replace the
-f
with-b
to daemonize; centos doesn't have an init-script for rngd, but you should be able to modify an existing one easily enough.)(The rationale being that /dev/random (true random) is blocking, whilst /dev/urandom (pseudo-random) is not - increasing the entropy of /dev/random can have a performance impact if you are often very low on entropy.)
You can verify the impact on your entropy via:
If you are concerned about the 'quality' of the PRNG, you can test its entropy, using:
Since you are using a virtual-server, it is often harder to come by entropy (no mouse/keyboard, sound/video card, etc). If you are concerned about the quality of entropy from /dev/urandom, you can try this timer entropy daemon, which uses inaccuracies in sleep time to generate entropy.
I would say that unless you are concerned about a determined and sophisticated attacker with a great deal of resources compromising your site by breaking the pseudo-random algorithm used in the Linux kernel, urandom is probably okay.
You'll find that anything encryption related, including cryptographic hashing (salts are random, even if the hashing function doesn't involve randomness itself), will deplete your supply of entropy. Also, a virtual machine will tend to have less entropy, as entropy is acquired from a variety of things that VMs just don't have, or can't securely get entropy from (e.g. physical mouse, keyboard, or clock).
I'm also not sure why you consider 100-200 a small amount. I'd consider 0-10 to be small, but keep in mind the maximum size of the pool (/proc/sys/kernel/random/poolsize) may be as little as 4096. Unless you're at 0 a fraction of the time, you're probably not using it up too fast (you might already be using urandom without knowing it). As best I know, reads from /dev/random won't block until the entropy pool is 0.