Category: IT Security

  • Server Security: Minimizing Risk in 3 Steps

    Server Security: Minimizing Risk in 3 Steps

    Servers located directly on the internet run one of the highest risks of being compromised. It’s just too easy for hackers to find an open “door” or “window” into those servers and then tap into confidential data, systems and information. Companies can’t afford to put their private information at risk, but an increasing move to cloud-based business solutions inherently increases the risk associated with data.

    The good news is, if your organization leverages cloud infrastructure, there are ways to mitigate the risk.

    It takes vigilance—and constant upkeep—but cloud-based data on internet-based servers can be just as safe and protected as on-premises servers.

    In this post, we highlight three steps you can take to significantly protect your infrastructure from being compromised and ensure that you are properly securing your servers.

    Step 1: Shut Down Access

    As admins install appropriate software packages and applications onto servers, invariably ports are opened and services are enabled. This makes a security breach for a hacker easier and easier. Essentially, the more ports and services you tamper with, the more surface area there is available for hackers.

    Depending upon your architecture, see if you can keep ports open “behind” the firewall in a VPC environment. This helps ensure that the fewest possible ports are opened to the public-facing internet, but you’re still able to accomplish your job. You can also specify which servers or services communicate with your AWS machines if you happen to use them (or with your IaaS provider of choice).

    Step 2: Patch Your Servers

    If you have ports or services that are open publicly, it is imperative that they are patched to ensure you are securing your servers. Admins should be updating patches on their servers as often as new data or systems allow them to, for the most attainable risk-mitigated servers. To make effective patches, there are four main steps you can take:

    1. Stay informed about the most crucial updates to cloud computing (Microsoft releases updates monthly).
    2. Automate your patch process.
    3. Test your patches thoroughly and frequently to maintain the highest level patch and to anticipate any errors in your system that hackers could get around.
    4. Verify that all your patches are functioning as designed (this last step could include periodic scans with Microsoft Baseline Security Analyzer, or another vulnerability assessment tool, to make sure all servers are patched and up to date and/or spot-checking individual machines for proper patches).

    Step 3: Tightly Control User Access

    Finally, consider tightly controlling user access to all of your servers. Ideally, admins have complete control in administering access privileges, both individual and group, so that employees have the access they need to do their jobs and nothing more. This tight control limits the amount of access a hacker would have if one user’s identity was compromised. Limited access acts as an obstacle a hacker has to work around to get to his goal: your data.

    The more granular an IT admin’s user control, the better the overall security for the organization.

    To do this, apply standards of access permissions, authentication and authorization for your IT admins to implement. Double-check that permissions are accurate by checking individual devices and ensuring their permissions are correct. Additionally, implement IT technologies that automatically sync changes in user accounts. The technology you need should work seamlessly with Windows, Macs, Linux and other devices to prevent any terminated user ad hoc access to accounts due to their aberrational device.

    Please note that this is a quick-hitter list. These should be the minimum things that you should be doing. Are all of your ports shut down? All servers patched? Are you sure you have control over everybody accessing your servers?

    There are any number of additional tools, technologies and processes that you could use to help protect your cloud server infrastructure. IaaS is incredibly powerful. Take the steps that you need to take to protect you and your organization from being the next victim.

    — Greg Keller

  • Setting Up Google Authenticator on Multiple Servers

    Setting Up Google Authenticator on Multiple Servers

    Google Authenticator is pretty great. It allows me as an administrator to set up and configure multi-factor authentication into my UNIX boxes without having to spend money on a tool like YubiKey or RSA tokens. It’s easy to set up on any type of phone—no specialized hardware or dongles needed. It’s also pretty cool in that you don’t have to have network access from the server to the outside world. Since Google Authenticator is time-based, it doesn’t need to send an SMS or do a callout to a centralized server to get the current valid token.

    What is a bit painful, though, is needing to have a different Google Authenticator token for every one of my servers. The standard setup would have you run the google-authenticator command on each and have as many tokens as you have servers. Obviously, this quickly becomes unwieldy and untenable.

    Instead, I want to have one token for multiple servers. Here’s how I installed and configured Google Authenticator on each system.

    First Machine

    On my first machine I’m going to install Google Authenticator and create a secret key—the exact flow I’d use normally.

    1: Install Google Authenticator. This is pretty well-documented; examples can be seen at untrusted connection and How-To Geek. I won’t walk through each step since this part varies from OS to OS; the rest of the steps are identical, however.

    2: Restart the ssh service

    $ sudo restart ssh

    3: Run the google-authenticator command to generate a secret key for your account, which you’ll store in your phone. This information will be stored in a configuration file that we’re going to get into later. I don’t need to comment that you actually have to enter the secret key into your phone, do I?

    4: Give it a spin. From another shell go ahead and try it out.

    5: Let’s take a look at the configuration file. We’re going to copy these contents to our other machines that we want to have the same secret key.

    Installing Google Authenticator on Additional Machines

    For all other machines I’m going to install Google Authenticator as normal, but I’m going to use the secret key from the first machine. This will let me log in to each of them using that same secret key that I stored from the first machine.

    1: Install Google Authenticator. Again, other places describe this in detail. We’re going to install the program but not do the creation of any secret keys

    2: Create the configuration file and add the content that we got from the other machine.

    3: Set permissions for the configuration file.

    4: Restart the ssh service.

    5: Test the login.

    Voila! A shared secret key across my servers! Happy day.

    — Rajat Bhargava