Security is an important aspect of website development, but it's not as simple as just enabling a plugin or firewall. Igor Antipkin has some thoughts - and as you'll learn in this episode, you need to design with security in mind.
There are no tweaks or key changes you can make
Threat Modeling
Think through all of the threats and attack vectors for your software and server.
Principle of Least Privileges
Tools on Plesk
Above all, be informed about the software you use.
Joe: (0:02) Hello and welcome to Next Level Ops, a podcast that explores tools, tips and techniques for hosting and managing websites presented by Plesk. Today our guest is Igor Antipkin and we are talking about security. Now I thought this topic is interesting because I figured we would talk about just firewalls and making sure your plugins are up to date, but Igor really gets high level here and talks about the actions that you should take on any project to make sure you're doing things in a secure fashion from the top down instead of just patching up holes, which I really like. So, I think you’ll get a lot out of this. But before we get started a quick reminder. Subscribe to this podcast to get the latest episodes as soon as they come out. You can do that wherever you're listening to this podcast right now. OK. So, let's get on with the show.
Hey everybody and welcome to Next Level Ops presented by Plesk. Today we are going to be talking about some tips to keep your server secure. For that topic, we have our special guest Igor Antipkin. He is a security engineer over at Plesk. Igor, how are you today?
Igor: (1:20) Fine Joe. Pretty good. How are you?
Joe: (1:25) I'm doing very well. Thank you very much. So, the weather is starting to get nice here finally in the United States. I am excited to talk about this today because security is, as a web developer, something that is always top of mind for me but I'm not always sure of the best things to do. You know? Aside from kind of push some buttons in my managed hosting environment and maybe install a WordPress plugin. So, I'm excited to talk about this with you. Maybe first you could tell us a little bit about your background. So, kind of who you are, what you do over at Plesk and then we can get into some common security issues that people see and how to fix them.
Igor: (2:11) I'm working at Plesk since 2012. First, I started with quality assurance engineer and then switched to the security team. So, for the past four years I am working as a security engineer.
Joe: (2:29) Great. Great. So, you were in QA first. Was that testing? Was that like essentially testing new features before Plesk rolled them out to the general population or was that more like a customer service sort of thing?
Igor: (2:44) Well it included testing with Plesk features and release to the product for their customers. Also, we have much work about the response for their customers; questions and so on. Also, it was kind of development of their automation product for testing of the product. It was some kind of a complex role for their company.
Joe: (3:20) Gotcha. Yeah it sounds like a little bit of everything there. Which means that as you moved to the security team you were probably pretty well familiar with some of the products that were rolling out for Plesk but also some of the common problems that the end user was seeing. Is that right?
Igor: (3:39) Yes. Of course.
Joe: (3:40) Cool. So, what do you do as a security engineer at Plesk?
Igor: (3:48) Well it's difficult mission may be. First of all, the main goal is to make the Plesk product more secure. So, all the activities are made for this goal. So, in general it sounds like about security in Plesk.
Joe: (4:11) Gotcha. So that's kind of a multifaceted thing when we talk about it with regards to Plesk, right? Because if I'm just Joe software developer, yes, my job is to make sure that there are no security vulnerabilities in my software. But for something like Plesk, yeah you are making software but you're also putting it on other people's hardware. So, how much of your job is split between making sure the Plesk product itself is secure with no vulnerabilities and how much of it is making sure that maybe your customers, your hosting providers have a secure offering for their clients? Does that make sense?
Igor: (4:56) Yes. But I cannot separate in a percentage this question. I mean we focus it on the security of the product, and we are also interested in the response from our customers who provide us about how can we advise the customers of our customers here to make their product, their websites they host them on the Plesk more secure. If the original question is about a percentage, then I cannot provide you the percentage.
Joe: (5:42) Gotcha. Gotcha. Yeah, well I think that makes sense, right? Because you are making a secure product and then you said you’re interested in the response from your customers about how to secure things for their customers. So, why don’t we kind of dive into that topic. In a previous episode, we did talk about specifically the WordPress product and some security issues surrounding that. You know kind of like non-updated plugins, but we also talked about the metaphor of securing your WordPress installation but not securing your server, right? So, it's like locking all of the bedroom doors in your house but still leaving the front door wide open. So, this long kind of metaphor is to hopefully segue into what are some of the common security problems that you see from the end user? I have a website. What are some of the security problems that I might encounter?
Igor: (6:49) Well, first of all, I would like to note that the topic is not an easy question. For me keeps it some kind of tweaks or easy steps that you can do to increase server security. But unfortunately, it doesn't work so well. I mean it is highly dependent on what your server works for, made for and what do you have on your server. Security is a process. It is an approach that should be taken into account when you work on a project. So, I would better say we will talk about some general recommendations and approaches that will help you to become more secure.
Joe: (7:33) Yeah. I think that's a fantastic point to make, right? I can’t just enable a security plugin or press the secure my website in in my hosting provider and then assume my site is going to be secure, right? So, what are some general recommendations, or as somebody who works with other people making websites, what are some of the things or processes I can help put in place for them to make sure they have a secure website?
Igor: (8:05) The first thing I would like to note is threat modeling. I mean it doesn't matter are we talking about a single server or a complex project? The first thing you should do is to realize your security risks. You should identify possible risks that you can face and consider them on a design phase. On work for a complex project and continuous development, all these things like threat modeling or risk assessment, security development lifecycle and so on. They can be not so easy. But if you're talking about a single server then don't be afraid. It becomes much easier. So, at this step, I would like you to think a little bit more. All you need on a project design phase is to start thinking about security. If you have a single server then just ask yourself first what kind of security threats and risks, you might have. At least write it down; all things you can imagine on the paper or you can note, but if you do so then you are already on the right way to achieve the goal to make your server secure. So, then think of ways you're going to fight against them and consider the ways of organization. Just don't think much. Otherwise you have the risk of becoming a security engineer. What would it give to you? First of all, it will significantly reduce the likelihood of security breaches that can occur. Also, it will help you to avoid additional resources for reworking the project in case of any problems in future. For a complex project you should consider risks for the whole project. You're going deeper and deeper into each part. So, in this case, the server can be only part of a project. Risks in this case are highly dependent on what your server is made for. For example, maybe it is needed to be highly reliable and available 24 hours a day. Then you just need to think over DDOS protection, yeah? Or maybe you have zero accounts in your web application, and you do not control password strengths for these accounts. Then you might have to think when an account needs brute force protection as an example. So, the threat modeling is a very important thing to do. Howard and Lipner, in their book, The Security Development Lifecycle they noted that if we could do the only one thing to improve software security, we would do threat modeling. I would strongly suggest to start with that on a project design phase.
Joe: (11:11) Gotcha. I think that is a really good point. So, with threat modeling basically looking at your project as a whole in the design phase to identify potential security risks. This will be different from project to project, right? If you have people logging in, part of your threat model should be making sure the passwords are hashed properly, right? They’re not just like stored as plain text. Maybe it's two factor authentication, in case you know passwords are compromised or guessable. How much of that actually is educating the user, right? Because I know probably, I think it's at least common in computer science, probably even more common in security especially, but the biggest security threat is the end user, right? Because it's maybe a lack of knowledge or a lack of understanding, you know? My friend’s password was her first name twice, until I told her that’s a terrible password and she changed it. So, how much of user education goes into threat modeling if any?
Igor: (12:27) User education itself, it's not going to make your secure, Yeah?
Joe: (12:37) Right, right, yeah.
Igor: (12:39) Well it's really a problem now a days that the end users do not care so much about security. From the security side, from the security team here, we make attempts to teach or talk with our customers on how to make it, or how you can increase security in their project. So, the threat modeling is about the project. Then you should include these steps into the development phase or into the design phase for your organization.
Joe: (13:22) Gotcha. Gotcha. That makes sense and so I know that you said there is not like a blueprint, or like do these three things to make your server or your project more secure, but as we think about you know what you're doing for Plesk in the software, or what your end-users are seeing, the things that you hear from them, what are some of the more common responses you get from customers about security? Is there like a couple of things that they find are common across a bunch of their own servers or across their own customer accounts and things like that?
Igor: (14:05) Well we receive many responses from our customers and it even appears that they brought some kind of vulnerabilities in Plesk, also we had some incidents in the past about hacked servers, so we also investigated to find out was it problem in the Plesk software or was it a problem in their website for example. Yeah? Hopefully there aren’t so much incidents, so most of the problem is web applications. So, the most common problem of security is outdated software on the server. So, the next step, I would like to say, is to keep your software up to date. If we are talking about a single server then make sure it has all the latest updates installed. You can also configure automatic updates for the server and if it's about some web applications with different dependencies then you should also keep it up to date. It will save you from attacks and exploiting in the software. In most cases for the attackers, it is very easy to detect your software and then they just need to find known vulnerabilities and try to exploit them. Most of the modern web applications have an embedded mechanism for auto updating. Just use it. The main idea of these is to keep all your compliance up to date. Regularly updating all your system packages; it's not enough. So, keep all software updated.
Joe: (16:32) Again, I think that's a really great tip, right? Because you're right. Outdated software is a common (I hope I’m using this term right. I’ve heard my friend use it) a common attack vector for people, right? Where they will look for exploits. It’s
almost like if we’re looking at the house analogy again. It's almost like if you have a wooden door to your house and you kind of just let it decay and you never replace it, It’s going to be easier for people to get into your house because now your door has a giant hole in it, because you haven’t repaired it or whatever. Awesome! So, make sure your software is up to date. And as far as you help kind of investigate hacked servers, you patch up vulnerabilities in Plesk. If we’re looking at a stack, like a website stack, there’s something at each level, right? Where a user can secure their website, right? So, again if it's WordPress, making sure it's up to date, making sure that they do some of the common WordPress security practices, like not having admin as a username or making to the passwords are not guessable. But if we go one level above that, there's like things like firewalls and stuff like that, right? What are some things that a user can implement just as the bare minimum, to make sure that there their websites and their servers are secure?
Igor: (18:00) In this case I would suggest to use the principle of least privilege. So, when you design your system it's important to use the principal of least privileges. Obviously, you should not use the root user to run web applications scripts, yeah? If you’re running some kind of web application on the server then you most likely should not create a user for that with a shell access. Maybe you also have different application users. Then you might have different roles for these users. You should define which role is applicable for a particular user or not. Or maybe you should think of opening only necessary ports and network interfaces on the server. If you have a database on the server, and it is only needed to accessible by the internal network then there is no need to expose it to the external. You can apply corresponding firewall rules, you can limit access to the specific IP range and so on. All of these should be taken into account. When you use the principle of least privileges, then it becomes much easier. Just ask yourself every time do you really need this to be or not? It can bring some additional efforts to you and make your system a bit complex, but security is always an opposite side of usability.
Joe: (19:30) Yeah, I think that's really good. Like you said, yeah, it's a little bit of a pain but it will keep you most secure. Again, if we said before that often the weakest link in the security chain is the person, then you want to limit the amount of damage any individual can do to a website or server, right? So, just to recap that, the principle of least privilege, don't use root, limit the roles based on the person, only give them access to the things they need access to, only open necessary ports for things to work. If the server does not need to be externally accessed, right? Then that's probably a big help.
Igor: (20:18) Yeah. Well as I have already said, it's highly dependent on what you have on the server. So, I would say it's just use this principle when you design the project. So, it will help you significantly.
Joe: (20:36) Right yeah, Yeah that's a good point, right? The thing I just said if my server wasn't externally accessible then that’s pretty useless. Because I have a website that needs to be accessed by the world. So, the principle of least privilege is something that you should think about as you're creating your software, setting up your system. Fantastic! So, as we wrap up here, I'm curious about the things that a hosting provider or a user can do inside Plesk as far as security goes. Are there specific security features that you’re particularly excited about in Plesk to help end users? You know, maybe like a firewall feature or a backup feature or anything that can kind of help with security that you want to highlight?
Igor: (21:29) Well, with the WordPress Toolkit, it has the ability to secure your WordPress instance and also we have an advisor in the extension. It will also show you some kind of a score for your server. Also, the firewall extension is also available for Plesk. So, yeah. There are features in Plesk that can help you to achieve these.
Joe: (22:02) Awesome! I know I’ve mentioned it twice already, but you know, just in case for completeness, what is a firewall exactly?
Igor: (22:14) In context of Plesk or your server?
Joe: (22:16) Just in general. Like if we’re defining what a firewall is to somebody. So, a server in general.
Igor: (22:21) A firewall makes you manage your connections and ports. So, it allows you to control the network configuration. So, it will help you on the network level to increase your security.
Joe: (22:50) Gotcha. So, it's almost like, I like to think of it as a bouncer in a club, right? The firewall will allow people who are allowed in the club in but will prevent people who are not allowed, they’ll have to stay outside, right?
Igor: (23:06) Yeah.
Joe: (23:11) Cool. That's everything that I kind of had on my list. I think just to recap, the most important things that somebody can do to keep their server secure, are threat modeling is really important, right, at the design phase because it lets you think of everything, all the important places where you need to secure. Make sure your outdated software is up to date. That sounds like a very important one. Educate users and then practice the principle of least privilege. That's another way that you can make sure that your server is, or that your software is only being accessed by users who absolutely need to access certain features or areas, right? Awesome!
Igor: (24:00) One more thing I would like to…it’s very close to the keep your server up to date point but I want to separate it. I would call it be informed about the software you use. Receive notifications from software vendors. It is common practice nowadays for software distributers to notify users of security and releases. Especially in an open source world it can be email notifications, or maybe RSS feeds, or other methods. In Plesk we receive lots of notifications from software vendors for packages that the company uses in Plesk. We investigate every case. So, if you are properly notified and handle the notification then you can make a decision if your systems are affected not. It is also important to be up to date with community around the software you use. So, as you can see, the point is very close to be up to date, but there are situations when vendors do not consider a security issue as an issue in their software. They recommend to protect you from breaches on other levels. Like a network level, when you can use firewall rules or some kind of these for example, yeah? So, in this situation you can be potentially vulnerable if you only install the latest updates for your software. But if you are only notified of all these threats on time then you can react responsively.
Joe: (25:47) Wow! Yeah. I think that's a fantastic point; be informed about the software you use, have notifications turned on. I know that in certain industries, right? Like the financial, at least in the United States, the financial sector has the ISEC group FSISEC. There’s REN-ISAC, which is for at higher education and things like that. But being involved in the community for the software you use, to stay informed about those security vulnerabilities is really important. I think one at the time of this recording that was fairly recent was the let's encrypt vulnerability for certain certificates. I luckily heard about that because I follow security people on twitter. The hosting company that I used did not inform me about it and I actually had to reach out and ask and say, “is it's going to affect me?” What are you doing to mitigate this? I've got a bunch of sites with you. Am I going to have to spin up my own servers, my own new certificates? So luckily, I was informed, and it didn't have to affect my clients and my hosting company was on top of it. It would've been nice if they told me though.
Igor: (27:02) Yeah.
Joe: (27:03) Awesome! Igor? I appreciate your time today. Thank you so much for your fantastic advice. I know I learned a lot. I had never heard the term threat modeling today. So, I really appreciate that. I know are our listeners did to. So, thank you.
Igor: (27:19) Thank you Joe.
Joe: (22:22) Thanks so much to Igor for joining us today. We talked at a pretty, I am going to say a pretty high level because we got into some specifics but the idea of threat modeling and user education and then the principle of the least privilege, I think are all important concepts to know as you approach any project. So, you just don’t say like, oh. I got my firewall installed. Great, I am secure. No. You look at each project individually to make sure you're doing the right thing. So, thank you again to Igor for sharing his expertise with us. For all of the show notes head over to Plesk.com/podcast. If you like this episode, please consider subscribing and giving us a rating and review In Apple podcasts. It helps people discover the show. Thanks so much for listening to Next Level Ops. Until next time remember to take it to the next level.