You should bind rpc address to localhost.
That's been the default for a long time.
What else would you take a look at to make sure the node is as secure as possible?
I strongly recommend using a firewall node: Basically you run two bitcoin nodes instead of one.
An exterior one which talks to the outside world (probably no inbound connections, only only with a mixture of random connections and some addnodes), and an inside node which your service runs against. The inside node connects only to the firewall node.
This protects your sensitive internal systems from some possible vulnerabilities in the node software. It also increases your flexibility in dealing with upgrades. E.g. if there is a softfork in bitcoin you can upgrade just the firewall node ... and reduce the risk of disrupting your operations by upgrading the inside node on a relaxed time frame.
If you're accepting low confirm count transactions from potentially untrustworthy users you will need to invest in network stability monitoring. You should know automatically if there are chain forks. You should also have redundant and diverse internet connectivity to make your bitcoin nodes hard to partition.
Seriously consider using encryption so that the system can't come up in a vulnerable state if power-cycled without intervention from your staff. This might result in downtime if there is an unplanned reboot, but that's better than getting compromised. Many methods of compromise result in a reboot-- e.g. social engineering data center remote hands into changing the root password on a host. Several big users have been saved by having an encrypted wallet without the decryption key stored on the host (so they had to log in to unlock the wallet).
Datacenter facilities are often unprepared to handle the security requirement of cryptocurrency are are often shockingly easy to social engineer into tampering with hosts. I know many parties that keep all their interactions with hosts under alternative names so that an attacker impersonating you doesn't know what names to use.
Obviously make sure you have good online AND offline backups and that your backups don't compromise your security.
Since you mention altcoins you should be aware that in the past some altcoins have been outright trojans and many are not maintained anywhere near as well as Bitcoin and have had serious vulnerabilities. You should consider the possibility that someone hacks into one of your nodes and take measures to limit their ability to escalate their access to other parts of your system. If FooCoinD ships a backdoor and everyone's FooCoins are stolen everywhere people might not hold that too harshly against you. If the Bitcoin's you're holding due are also lost due to that attack it may look a lot less good for you.
"RPC allow from: Specific IP" -- if you're running RPC to separate hosts you should setup an encrypted tunnel, unless the connection is otherwise via a physically isolated and secure network.
As far as other security stuff goes... standard host security applies though most advice isn't really made for targets as vulnerable as cryptocurrency users. I'm a fan of remote syslogging onto a system with no remote access (or extremely limited remote access). Disable password authentication, ideally use ssh keys + U2F.
For bitcoincore.org we don't just use sshkey+u2f but we require two different U2Fs so that anyone that logs in has to get another user to help them log in.
Automate everything you can to minimize the number of people and frequency of manual interventions on your highly secure hosts. Don't give staff access that you don't need them to have just because you like them or they're important to the company.
Assume your staff's hosts will get compromised (this is something U2F helps a lot with). It's worth time to setup tripwires-- logging that gets triggered (and sent out as alerts) when various commands get run that legit users would virtually never run but hackers might, selinux is very good at doing this. Make sure you don't flood yourself with false positives for any alarms you put in, however.
Consider pre-authoring sweep transactions that much each of your hot-wallet outputs over some nominal value to some secure cold wallet address(es), then don't broadcast these transactions but store them someplace you can easily get to in the event of a compromise. I've seen some hacked services struggle with tension between locking the hackers out of their systems and keeping their own access in order to move funds somewhere safer. It would be a lot better if you could just have a trip wire cause a fast shutdown of your wallet hosts, while separate systems could start sweeping funds out of harms way.
Consider having a canary wallet: e.g. a wallet.dat you put in a very visible location on every one of your supposedly secure systems, which contains enough funds to be worth stealing... which you monitor for theft. Hopefully a hacker that makes it onto your systems will find that first, rather than the really valuable stuff and can't resist stealing it and alerting you to their presence.
Keeping hackers out is obviously the highest goal but detecting, understanding, and mitigating compromise fast should be a close second.
And finally: forum comments aren't a replacement for competent professional security advice.
