Start with the Basics: Secure the Server
PLP isn’t enough if the hardware housing our application is riddled with holes. Attackers are looking for any way in and will target both the production and development servers hosting the application. If we forget to secure the server itself in the rush to code a secure application, all the things we’re going to discuss in later chapters will no longer matter.
What good is session management in our application if the server has a weak password? Does it matter if we implement a rock-solid authentication scheme if the server is running old and vulnerable software? No. Remember, we need to lock the front door before we password-protect the computer.
Since this book is about Node.js security and not server security, we’ll keep things brief and basic.
The first step is authentication, because it’s the most important aspect of server security. Keep the following guidelines in mind for a secure authentication scheme:
-
Do not use the root account all the time. Using an ordinary account and sudo to elevate permissions when required minimizes the attack vector by limiting the timeframe and execution rights.
-
Do not give the same account to everyone. It makes it hard to separate permissions of individuals or determine a point of attack later on.
-
Use dedicated machines. Having the production site running on a machine otherwise used for email or web browsing opens up so many attack vectors that anything that you might save on hardware would be gobbled up by balancing security.
-
Keep access to the production server to a minimum. There’s no reason for someone from accounting to have root access to the production server hosting your web application. Let access be limited to the minimum number of people possible.
-
Change the default password or use key-based authentication. Most cloud services provision machines with default root accounts and send the passwords by email. Change those!
The application server should be single purposed. Running a pet development app on the same server as a business-critical application is a great idea—if you want to sabotage your production environment. (That was sarcasm.) Don’t do it, because you’re just offering up a buffet of attack vectors to break into the server and the resident applications.
Set up a proper firewall. Block all network traffic that should not be occurring in the first place. If necessary, you can also set up a reactive firewall to block denial-of-service attacks when they occur.
Another basic step, but an important one, is to make sure all the software installed on the server is up to date. If the history of computers has shown us anything, it’s that complex software without bugs is like a miracle—some say they have seen it, some even say that they have made such a program, and the rest of us just shake our head in disbelief. Keep your system up to date to limit exposure time to vulnerabilities as they’re found.
In 2014 alone, two serious bugs were found in commonly used networking software and required a software update for almost all servers around the world: Heartbleed[7] and ShellShock.[8] Make sure you’re running updated server software to ensure these two and other security bugs don’t affect you.
Securing the server operating system, setting up firewalls, and hardening the environment are all broad topics and out of scope for this book. I recommend taking the time to understand network and OS-level security. Here are a few good online tutorials and lists to get you started: