devopsy.kinsta.cloud

Tag: hacking

  • WordPress Hacks: Best Ways to Protect WordPress from Hacking

    WordPress Hacks: Best Ways to Protect WordPress from Hacking

    When it comes to website security, even an iota of prevention is really worth a large pool of measures to restore a website from its affected state. WordPress websites are most vulnerable to security attacks from sophisticated hackers as well as the bots that are capable of exploiting security vulnerabilities. These security vulnerabilities range from weak passwords, outdated themes and plugins, and poor-quality web hosting.

    But, there are several time-tested measures that can prevent such security compromises and risks and keep a website performing and secure. 

    Make Use of Strong Passwords

    Weak passwords often cause security risks for websites. You can prevent such risks by using strong passwords and for this, you can use tracking tools such as 1Password that can track all the passwords and prevent you from using the same password on all your internet accounts. The tool also prevents you from using easy and easily rememberable passwords. Thanks to the tool you can only use unmemorable, long, difficult passwords.

    Using this tool you can easily test the strength of the existing passwords and can create passwords that are long, complex and not easy to guess. The tool helps you maintain all your web accounts with strong passwords. 

    Updating WordPress Core, Themes and Plugins

    Most updates of the WordPress core, or the themes and plugins, come to mitigate the security loopholes and risks. This is why making updates once a month is far from enough. Whenever a vulnerability will surface, your non-updated website can be the first victim of the security risk. This is why one must update as soon as there is an available update. For all the plugins that don’t come with important features and functions, one can use a Shield WordPress Security plugin to auto-update. 

    Insist on WordPress Hardening 

    There are several WordPress hardening methods that can easily prevent hacking from taking place. Let’s have a quick look at these hardening methods.

    • Add extra allow/deny rules through your .htaccess file.
    • Keep login URLs restricted to specific IP range(s).
    • Safeguard your wp-config file.
    • Prevent image hotlinking and mobile directory browsing.
    • Do not use public WiFi or VPN to log in to the website.
    • Remove unused WordPress plugins and files.
    • Keep the server clean.

    Prevent a WordPress Hack with a Website Firewall

    A vast majority of WordPress websites are frequently hacked as they are more vulnerable to security risks than other CMS platforms. A common issue that security experts stumble upon often is that WordPress version update is often not possible, thanks to the incapabilities of plugins or themes. This is when a WordPress website can easily become vulnerable to hacks.

    For such cases, enabling a WordPress firewall is strongly recommended to provide security patches for your website. A Web Application Firewall (WAF), when enabled, can take on such security risks. A WAF basically works like a pass for your website visitor traffic, and effectively filters out bad requests comprising hack attempts, exploits, DoS attacks and many more.

    A WordPress firewall does the following things to strengthen WordPress security:

    • Prevents all future hacking attempts by detecting and thwarting all hacking methods and behaviors, thus keeping your WordPress website protected against malicious attacks. 
    • The firewall provides a virtual security update for your WordPress website software, even when the website doesn’t have any new security updates.
    • A WordPress firewall also blocks brute force attacks or any unwanted visitors from accessing the wp-admin or wp-login page and makes use of brute force automation to detect your password.
    • It deals with Distributed Denial of Service (DDoS) attacks that basically try to overload a web server or the resources of an application with too many requests. By blocking DDoS attacks, a WAF ensures constant accessibility and performance of a WordPress website in all circumstances. 
    • A WordPress firewall helps boost WordPress performance by storing website caches and keeping bounce rate lower. This also ensures optimum website engagement, business conversions and steady search engine ranking. 
    • The cloud-based WordPress firewall solutions, besides preventing attacks, also boost WordPress website speed by using a Content Delivery Network (CDN). 

    Make Sure You Have an SSL Certificate Installed

    This is a basic and very important security measure for most websites. It safeguards data by encrypting the data you and users use and transfer via a website. For example, when one submits a contact form or uses login in web pages, the data that is transferred remains encrypted. With SSL installed on a website, secure login can be ensured even while traveling. While some hosts and hosting plans provide this for free, with some you need to use a separate SSL plugin for the purpose. 

    Avail Better Web Hosting

    Choosing good hosting companies can also be crucial for your WordPress security. Some hosting service providers such as WP Engine, Kinsta, Site Ground and a few others are great for WordPress security. These service providers take care of routine security scans and provide cleaning of hacked websites for free. Apart from performance, one should also consider security aspects for website hosting. 

    Taking Backup of Your Site

    Though taking regular backups may not always be effective for preventing a WordPress hack, they can sometimes play a great role in disaster recovery. It is particularly useful in preventing a website database from damages due to malicious attacks. 

    Continuous Website Monitoring

    Finally, continuous monitoring of websites can help greatly in tracking and mitigating security risks of all types. Setting Google Search Console alert is important concerning all issues on your website. Apart from that, you should monitor the error logs on your website through the cPanel File Manager or FTP (SFTP). You should also see the Raw Access Logs on the server to keep track of the users accessing website files on the site. You should also use a plugin called Shield WordPress Security plugin and use its Audit Trail feature to keep track of all the file changes and website accessibility issues. 

    Conclusion

    All the above-mentioned ways are time tested as successful to prevent security attacks and keep security vulnerabilities at check. These measures, besides a meticulous choice of plugins and themes, can help a WordPress website perform well and remain secure.

  • Keys to the Kingdom: Protect Your Server from Hackers

    Keys to the Kingdom: Protect Your Server from Hackers

    Automation and DevOps undeniably improve the agility and responsiveness of IT. Most of us have taken up at least a bit of the wave of automation that DevOps and Agile have brought to our door, and many are far along on their DevOps journey.

    But every once in a while, we need to look back and lend a hand to those still coming. The fact of the matter is that sometimes we forget to warn those who are new to massive automation about some serious issues.

    It is intuitively obvious, if you think about security at all, that putting together a command and control server—we’ll use Ansible in this blog, but any tool that can roll out applications to a collection of servers—creates a big screaming target for any hacker that gets into your infrastructure. You cannot assume that will never happen, so organizations need to think about protective systems/architectures early, or spend more time patching things up. Remember, the more you build, the more weight there is to making major changes.

    For starters, severely limit access to the command and control machine. It belongs on a management subnet/VLAN with only a few access points. The servers it is managing absolutely should not have access back to the command and control server. If they do, any one of them getting controlled will provide a pathway to all of them getting controlled.

    Next up, early on there were quite a few debates/discussions about which user accounts should be able to run command and control scripts (Playbooks in Ansible). Eventually, the bulk of the community settled on each individual running them, not a single generic user with a name like “ansibledeploy.” Some still use a central user, but the majority wants the ability to track down the leak that individuals running commands allow—searching for strange/uncommon command execution in logs will cough up which account got compromised and allow for rapid response—which outweighs centralization.

    Third, learn and use the security features available in your application. Ansible offers Ansible Vault to allow encryption of playbooks. Since many playbooks require root access, encryption allows those playbooks to hide root access. Use of Ansible Vault has grown over time, and there are excellent tutorials out there to help use it to lock down command and control. Your product will have a similar tool, because putting root passwords in plain text, all over the disk, is just not acceptable.

    In the Ansible Galaxy/Github repositories, you can find excellent roles to help in your quest to lock things down. Geerlingguy is one of the most popular, and his Ansible Role – Security is excellent if you follow the caveats he provides in the readme.

    This is simply an advisory, not a step-by-step solution set. Overall, just remember that putting together a command and control server makes a tempting target. And like Geerlingguy points out in his readme, your security is your concern.

    Look at where the server can be accessed from, who can access it, where sensitive data bits such as passwords are stored—hint: plain text passwords in files went out of fashion when mainframes were hooked up to LANs—and how to protect all of the above. It’s been done, there are plenty of resources to help in your given environment. Take the time to look them up and implement relevant suggestions.

    After all, I won’t get a call in the dead of night if your servers are all taken over, you will. Do everything you can to avoid getting that call. And keep rocking. Everyone remote working has made many organizations more susceptible to all forms of attack, don’t let your guard down.

  • Murphy’s DevOps: The Internet Apocalypse

    Murphy’s DevOps: The Internet Apocalypse

    I’ve been immersed in cybersecurity for a good stretch, since it was known as just “infosec” and “security.” Over time, I’ve had opportunities to work with some brilliant minds and young-gun “hackers” (I’m not a name dropper, so I’ll refrain from using them as SEO-bait). I’ve watched attackers transition from being basement-dwelling teenagers to organized intruders to APTs. At one point or another, I’ve met all of Five Horsemen of the Internet Apocalypse: Scam, Extortion, Embarrassment, Theft and Death.

    The biggest cybersecurity news story of all time is still Edward Snowden. Fancying himself a “whistleblower,” champion of the Constitution and privacy rights expert, this fugitive data thief accused of espionage by the United States government has done more to force businesses and individuals to think about digital security and privacy than anyone or incident before him.

    Snowden aside, there are thousands of other stories about just how fragile our online lives and businesses are. If you were at the devopsy.kinsta.cloud Rugged DevOps event at RSA 2015 and caught the presentation by Wired cybersecurity and privacy writer Kim Zetter, “2015 — The Year in Hacks,” then you had a chance to get a great overview of some of 2015’s biggest digital crimes. You might have even noticed the Internet Apocalypse Horsemen riding through.

    With an ear to the ground on everything the NSA and APT-using hackers are guilty of, @KimZetter never fails to intrigue readers and live audiences. Whenever you read her stories or listen to her speak, you always walk away reassured that when all the smoke and headlines have cleared, the great deep-down reality is that everything we digitize is subject to the whim of Scam, Extortion, Embarrassment, Theft and Death. If you didn’t have a chance to attend, please enjoy some of the highlights listed below.

    China vs. U.S., Spy vs. Spy

    Internet Apocalypse

    She kicked off with the biggest hack of 2015: the one that penetrated the U.S. Office of Personnel Management (OPM). The full extent of the damage done and who the actual attackers were may never be fully realized. Were they Chinese spies, rogue hackers or a combination of both? What we do know is that it exposed millions of identities tied to covert U.S. operatives and their family members listed on security clearance forms. It may have even exposed personal information on everyone who has ever applied for a job with the federal government. One for-sure lesson is that even after several decades of security product development (with more than 800 available for review at RSA), the world is still in need of innovation in the space.

    Men Behaving Badly …

    Internet Apocalypse

    Some might argue that Embarrassment made a special appearance at Ashley Madison, but the fact that suicide was part of that hack leaves me to think that Death was the lead actor there. @KimZetter pegged the data theft as the most brazen hack of 2015. With 30+GB of account information stolen and dumped, login credentials for 32 million accounts purloined, credit card transaction information accessed and even several suicides tied to the incident, the hack again reminded the world that the great deep-down reality is that everything we digitize can be used by attackers to scam, extort, embarrass, steal and even kill us.

    From the Keyboards of Babes …

    Anyone at the presentation must agree that Embarrassment really stole the show in the hack of CIA Director John Brennan’s AOL email account. Allegedly perpetrated by a teenager, Zetter describes the incident more deeply in her October story: Teen Who Hacked CIA Director’s Email Tells How He Did It

    Internet Apocalypse

    Keep Calm and Internet On

    Anyone reading this may be walking away with a rather pessimistic view of our chances of remaining secure online. The truth, however, is that the existence of determined hackers should do no more to stop individuals or businesses from going online than road rage should to prevent anyone from getting behind the wheel of a car.

    If any lesson can be learned from news articles pumped out by @KimZetter and her peers, it’s that the world should continue to take full advantage of the Internet but to also take the time needed to apply effective security. Quite simply, we all should keep calm and Internet on …

  • Hacking Your Auditor

    Hacking Your Auditor

    No, not that kind of hacking, give me a little credit…

    Recently I was having a conversation with a consulting friend about DevOps, and he found himself in a bit of a tough situation. The organization he was working with was a pure cloud/DevOps shop, but one that was stepping into having the meet compliance obligations. Needless to say, things weren’t going well with the auditor.

    For those of you who haven’t had to deal with the miasma of audits, one of the strongest requirements, for nearly any regulation/contract/agreement, is strong change management. This is especially true after those Enron guys screwed everything up for the rest of us.

    Change management makes a ton of sense from both an operational and compliance standpoint. I, myself, have blown things up in production but not being smart about my change management. For compliance, it is absolutely essential. If you are dealing with anything with financial or privacy implications, you sure as heck want to get it into a stable, secure, compliant state and ensure that state is kept over time.

    There is a big misconception out there that DevOps-style organizations don’t have change management. That when you push multiple changes per developer per day into production, there is no accountability or control. Now, while you can certainly build things this way, that sure isn’t how I see successful teams doing it. Not even close.

    The problem isn’t that DevOps necessarily skips change management, it’s that it looks different. Much of change management becomes automated, and the fundamental nature of changes themselves is different. But think about how you describe DevOps to your traditional IT-focused friends. Now imagine trying to explain this to an auditor working off set standards that are still figuring out if cloud includes a co-hosted Mac Mini duct taped to a rack.

    Here are some tips on how to both adjust your process, and explain it to the auditors:

    • First, figure out which pieces of your application and operations are in-scope for the regulation. Odds are only financial and privacy related bits are, and you can then apply more-granular controls or logging to these if you need.
    • Make sure your continuous integration tool (if you have one) includes some security checks and logs all updates/changes. If you push right from your code repository to production, get a CI tool.
    • Keep records of all changes as they flow from dev to test to prod (or whatever you use). Again, this should be trivial to automate and dump the records to a secure log repository someplace.
    • Unless your cloud provider tracks all API calls (like CloudTrail does on AWS, although that only works for some services and regions) use an API or web UI proxy like Netflix’s Asgaard. This really is a good security practice anyway, and can actually speed up infrastructure and platform management processes anyway. Keep the logs from this to make the auditor happy.
    • If you SSH into instances, you need to log that activity and dump the logs to a central repository.
    • Make sure you keep revisions of both all code changes and infrastructure automation changes (e.g. your CloudFormation templates, Chef/Puppet scripts/etc.). This is often built-in, but make sure you configure it correctly.
    • Those suggestions now give you logs of all application changes, infrastructure changes, and direct access to instances. These are the things the auditor wants to know exist.
    • Filter them based on your in-scope compliance requirements. Such as payment systems components only.
    • Explain to your auditor that all changes go through an automated approval system that checks the code, tests it (detail the tests), tracks the change, and then moves it into production. That all server logins and infrastructure changes are logged, as is the complete history of the structure of your entire environment. And that you can provide all the documentation, filtered for the pieces within compliance scope.

    This might look like a lot, but odds are very high you are already doing most of this. You keep code revisions, run changes through test suites before they go into production, and track all infrastructure changes. You might not have your own Ops portal/proxy, but you really should for a lot of reasons that have nothing to do with compliance.

    The trick is explaining this to your auditor in their terms. They expect manual checks and records. You need to show them that you still have these checks and balances, but they are automated. You still might need to add some pieces, such as an alert if certain parts of your code are changed (e.g. the file with payment processing or account reconciliation), but these will hopefully be minimal.

    A good DevOps environment actually has a much better compliance infrastructure in place than traditional infrastructure. The automation and template-driven models give us much better control and insight as compared to manually fixing everything, even when we push more day to day changes. The trick is to document this, add a couple pieces if you need it, and then explain it all to someone with… less than refined technical skills.