Yes, it is cryptographically secure, pseudo random output, seeded by retrieving secure random data from the operating system.
If it is random or not depends on the fact if the OS RNG is random. This is usually the case on normal desktops, but you'd better be sure for e.g. limited embedded systems. If no truly random data can be retrieved - according to
RAND_bytes - then
rand will exit with an error. In a similar note: you may need to include the client toolset on VM's to retrieve true random data, especially when duplicating environments.
Added note: Of course you are dependent on the implementation. Famously OpenSSL was broken for Debian because a maintainer ran a program to find memory errors and disabled all entropy sources rather than the one that was (deliberately) failing the property that no uninitialized memory should be used. So it is of importance to review security reports and keep your system up-to-date / on long term support.
Any random source that you add using
-rand [file][:file]* is used as additional seed data - in other words, the output will always be random, even if you supply the same seed.
As the pseudo random generator provided by OpenSSL generally runs in the application space on the main thread, it may be faster than asking a lot of data from
/dev/urandom. But to be honest, most of the time using
/dev/urandom suffices (and current implementations are pretty fast as well).
You can see that it is random when you look at the link to the
RAND_bytes manual page which is the function that lies behind command line
rand and is linked to from the manual page (in the "see also section, but yeah"):
num cryptographically strong pseudo-random bytes into
buf. An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence.
RAND_bytes() is used can be found in the source file for the
rand.c, so yes, this is indeed the function that is called.