I would suggest you look at whether or not you can actually do anything with those files on the system you're looking at securing as a regular user. Most likely, you will find out that most of the really important ones (storage devices for example) already cannot be accessed by regular users, because that's the standard configuration on a vast majority of UNIX systems, even as far back as 4.3BSD and SVR4. If you're being truly realistic, disallowing non-root access to these device files is probably sufficient for security (if the attacker has root access, device files don't matter because they can probably get code running in kernel space easily, which doesn't need device files to poke at hardware). If the system in question is configured to use SELinux or another LSM, you can also leverage that (if the default configuration doesn't already) to further limit access.
Even if you hide or block paths under
/dev though, that doesn't really prevent people from creating new device nodes elsewhere with the appropriate major and minor device numbers and arbitrary permissions. You can't easily stop people from creating such files, but you can make them essentially useless by mounting everything except
/dev with the
nodev mount option, which disables special handling of device nodes on the mounted filesystem. Properly doing this requires that your root filesystem be separate from
/dev (which should be either some automatic virtual filesystem provided by the kernel (such as
devtmpfs) or a
tmpfs instance populated by a device manager).
Beyond that, a lot of the really nasty ones (
/dev/msr, as well as
/dev/hpet) can be completely disabled at compile time. This doesn't just keep them from appearing in
/dev, it means that you literally can't ever have working instances of these device nodes on the system. Most Linux distributions explicitly disable
/dev/kmem these days because nothing uses it, and a lot of them also disable
/dev/port because they are largely only used by legacy software.
/dev/msr on the other hand is usually built as a loadable module (and thus can be explicitly blacklisted without rebuilding the kernel) because there are actual practical uses for it that don't involve attacking the system (for example, debugging CPU power-management issues).
Also, as a sight aside, don't block
/dev/urandom, you'll probably break your system if you do, and neither one is a really an attack vector.