Tony Perez On Security, Business, And Life
The need to use HTTPS on your website has been spearheaded by Google for years (since 2014), and in 2018 we saw massive improvements as more of the web became encrypted by default. Google now reports that 94% of its traffic on the web is now encrypted.
What exactly does HTTPS mean though? And how does that relate to SSL or TLS? These are the more common questions I get when working with customers and in this article I hope to break it down for the every day website owner.
The Managed WordPress ecosystem welcomes a new entrant – Automattic. Today they officially announced that WordPress.com Business now supports plugins and third-party themes.
I am fascinated by the move because I believe it to be an obvious impact to the Managed WordPress ecosystem. In the interest of full disclosure, I work in the security division for one of the largest Managed WordPress hosts – GoDaddy – via my affiliation with Sucuri.
The world of hosting is complex, it’s further complicated when you throw security into the mix. A few months back I wrote an article on the delicate line between where the hosts security responsibility begins, and where yours, as the website owner, is required. That however did not address one key question – Which hosting environment is more secure? This is one of the most common questions I get asked.
The response, as you might imagine, is not as simple as the question itself. This question is often confused with misinformation and bias and the responses are often grossly inaccurate. I will spend some time thinking through the various points, applying insight where possible, in the hopes of helping you making a more informed decision on the type of hosting environments, and which ones make the most sense for you.
This a quick post, for those of you that manage multiple agents under your manager, there might be instances where your email notifications will group different agent notifications together.
This has to do with two things:
By default, OSSEC has a max email setting in their configuration, when it reaches the max, it will then group and email all remaining emails. In this instance, it bundles them all together, which leads to different messages from different agents being bundled.
If you don’t know, I’m a big fan of two-factor authentication. I often talk about it integrated into your web applications access points, like wp-admin in WordPress and administrator in Joomla, but in this post I’m going to talk about leveraging it with your SSH connections.
When configuring your server access points it’s important you enable Public Key authentication in the place of passwords. Mainly because, unlike passwords, you can’t exactly brute force the access point with the keys enabled. There is also a functional aspect to it, not having to worry about passwords is great. Once you have it configured you can quickly access any of your boxes without having to remember or store the passwords. An example of where this would have been in your favor is the SSHD rootkit outbreak in February. With public keys enabled, those affected would have been spared compromises as passwords would not have been stolen.
I’ve always wondered what a Distributed Denial of Service (DDOS) really looks like. Fortunately, there is now this pretty awesome video illustration of what it looks like:
I’ll be in Miami this weekend, for WordCamp Miami 2013, giving a new, updated talk on Website Security. Come by and say hi if you’re around — If you’re not, no problem, I’ve included my slides below in this post for your reference.
My talk is titled Staying of the Website Threats and Becoming One with Malware. In it, I talk about the latest threats and things you can do to help yourself and your site stay secure. The idea is to educate and in the process, help you gain a deeper appreciation for the underbelly of the web and the realities of the web based malware.
OSSEC HIDS
Being that my focus is on website security my employment and utilization of the product will be as such. I won’t talk much to the configuration and monitoring of large scale enterprises, but will likely get into large n-tier implementations of web enterprises. This could include the utilization of load balancers, web servers and database servers, and possibly some storage devices. Pretty straight forward stuff.
So naturally, as of late, I have found myself doing more than I probably need to on my servers and in the process causing more headaches then required. One of those issues has been with the communication between my agents and the mother-ship (command control) server with my OSSEC installs. For more details information, be sure to check out the OSSEC Host-Based Intrusion Detection Guide
The first thing to understand is how to check the status of your agents and easiest way to do that is running the following on the server install (my mothership):
# /var/ossec/bin/agent_control -lc
This will list out all your agents and if they are active it’ll read Active. If they are inactive, they don’t read inactive unfortunately, they just don’t show up.
I wrote an article recently talking to the use of Basic Access Authentication to help harden your administrator panel.
I have been monitoring my logs to see how it protects and this is what I found:
The past couple of weeks I have found myself dabbling in a number of system / network centric tasks. In the process I have been configuring a number of servers and thinking through a number of initial tasks that need to be taken. From time to time I find myself compelled to take a few minutes to summarize the steps not only to benefit readers but myself later on.
Here is a quick post that will show you how to enable access to your server via SSH keys in the place of passwords.
Pretty excited, today I got my very own copy of the OSSEC Host-Based Intrusion Detection (HIDS) Guide
If you haven’t heard about it, it was developed a few years back and was founded by our founder at Sucuri, Daniel Cid.
Its core features include:
Ok, as simple as a post as this might appear I recently undertook an effort to install and configure ModSecurity on my little server. In the process I quickly learned a number of things, specifically that I needed to uninstall from my production box and push it over to a staging box.
I’m not a system administrator and quickly learned that sometimes its good to follow your own advise, don’t get crazy with changes on a production box without testing on a staging box.
So what better way to kick off my security related posts than to summarize the steps I took to get this website up. Big thanks to Daniel Cid for all the guidance and hand holding.
This post will provide a cradle to grave review of the process I just went through in the past 48 hours. It will include everything from configuring the server, to installing and finally hardening. Its a bit lengthy so I’ve add a few short-cuts to help those that might be interested only in a few areas:
It is important to note though that this will all be done via the command line interface (CLI) (a.k.a. terminal). It’s not complicated or difficult, but does require some working knowledge in the terminal environment. If compared to most I would be classified as a noob when it comes to hands-on system administration in the terminal environment, so if I can do it you can too. Also, if you see any inefficiencies in my process please let me know.
So let’s get started!