 Hello, welcome everyone to After Lunch. I have coffee, not enough for you seem to, so good luck. This is a very technically focused talk. I hope a lot of the content though, whether you're a very extreme tech person or you're just getting a Drupal or all these different kind of lines that we could draw with experience and skill set, I hope that each of you are gonna grab something out of this talk. We do go through the full stack. So everything from core OS services all the way up to Drupal plugins to add hardening to your deployment. So we'll probably be a little tight on time. I'll be here after my talk. I'll probably just head out that way so we can get out of the way of the next presenter. But if you do have questions, I do have business cards and all that. So I would love to get you answers if you have them and let's get started. So I'm Mark Stanislav. I'm with a company called Duo Security. We do two factor authentication. So hopefully some of you guys might know what that is. We'll talk a little bit in here about two factors since it's kind of an important deal with CMSs these days. If anyone saw the disco botnet with WordPress with thousands of computers taken over because of WordPress, basically brute force credentials. So that's kind of what we're focused on across all platforms and software. My background's in something like 12 years of PHP. I was a sys admin for about a decade. I did penetration testing code audits for security teams. My master's degrees in information and security and some other stuff. So I have a kind of a nice broad background to hopefully give you guys content that will actually be useful to you and not just kind of talking over you and hoping that you grab something. The CMS in general, I realize this isn't 100% Drupal at this point. Hopefully I think you guys are all wishing that a third of all CMSs or a third of all sites were in Drupal. But really one in three sites do run some sort of CMS. Now Drupal of course has a big market share. A lot of enterprises uses Drupal. So that's certainly very important. What really doesn't come out a lot when you're not thinking about things holistically in terms of what security looks like for an organization is that the web server, the web services that you run, a lot of which might be based on Drupal or some other CMS, that is often one of the biggest targets for any enterprise. And the segmentation between that website and the rest of an organization is a lot smaller than some of you might think or maybe you already know that, hey, my web server is also tied into my corporate network somehow or the web server is on the data center network with a bunch of our services that we provide customers. So if you look at things in terms of as an attacker, if I'm gonna do a penetration test, your corporate website is just as interesting to me as anything else. If for nothing else, one good example being, if I can steal passwords from your sys admins, if they're not all using random, unique passwords with something like LastPass, maybe I get one of their passwords off your Drupal site and then that lets me into your VPN and that lets me into the corporate email account. So don't think of things as really as compartmentalized as they may seem. Think about things in terms of what can an attacker do, what kind of malware could they send out with your, if they compromise the Drupal site, what kind of credentials could they steal on and on and on. There are with whether PHP or any other language, anytime you have a CMS, you have a lot of attack surface because there's a lot of complexity. Now you can abstract the complexities certainly, but things like plugins and themes, libraries that you might include, each of those things are themselves one new thing for an attacker to go after. So if you got the coolest plugin that just came out to do Bitcoin or something, right? Thousands of sites could deploy that Bitcoin plugin and how many of you ever had a code audit done of that by a security professional? Probably none of you. And that's almost every plugin. Certain development teams certainly have some good knowledge behind them. However, information security, especially when it comes to code audits, there are things I could show you with PHP that you would not believe you could do with code that looks completely secure. And that's kind of the trouble is you don't need necessarily the experts as a Drupal, you know, sysadmin or a Drupal theme designer or a plugin writer. You do have to know some of the things that attackers are gonna do so that you can at least kind of mitigate for those. In order to actually hopefully have a chance at security with any website, with any web service, we really do have to think of things top down, bottom up. It has to go both ways. You can't look at just the plugins or just the kernel hardening or just the firewall. And anything in that stack that isn't strong or that hasn't been protected adequately will be the way that I will get in when I do a penetration test. So let's talk about what we can actually do and some of the change we can have. So here's the quick overview of some statements. We're gonna go through these one at a time. Whether your role, again, is a developer or a sysadmin or somewhere else in the grand scheme of a Drupal deployment, you're each gonna run into things where maybe your management team says, oh, let's put a firewall up and no one's gonna break in now or maybe a plugin designer's gonna talk to his buddy that does security and says, oh, if you just get this one web scan that scans you every single day, that'll make sure you don't have vulnerabilities in your website. There's a lot of misinformation about how security actually works and the ways that you think you might be protected might be a little bit more theater than it is actual real security. And the thing I know about the development community as being part of it is engineers, software engineers, software developers want to know what's wrong with things. They don't wanna be told, oh, everything's fine, don't worry about it. You want to know why that one method doesn't go at like four milliseconds. You want to break into that problem and break it down and understand it. So hopefully some of these will, whether it's your point of view or someone that you believe in or maybe hopefully no one's told you some of these, we'll go over them one at a time. The idea of a third-party web server or having a demilitarized zone, so DMZ, this part of your network that's segmented from the rest of your corporate network so that if an attacker did break into your web server, they wouldn't be able to do anything bad. Kind of what I was foreshadowing on before is as simple and as the idea that no one would ever target you, those kinds of tropes that we'll talk about, there is so much value in that one little web server for your company and it's not just to make your company look bad often, it's often just a leg to then move laterally through your organization to actually get to the real important stuff. So maybe your corporate Drupal site or something else similarly not too scary, if I can break into that and then move laterally through your organization, maybe I get to the credit card numbers, maybe I get to the insurance documents with social security numbers. So don't think of it just like, oh, well, it's just the corporate website, that's still a big deal. Any, there are about a dozen or two that I've seen just looking at websites over the years where it says, Scanned Buy, McAfee Today, Hacker Proof. And it's just so frustrating to see that as someone in the information security because it's not that anyone could break into that day or would break into that server that day, but it's that there's no single scan, none, that will ever tell you if your web server or service or app is not vulnerable at that given time. You can do due diligence, you can hire firms to do ethical hacking type operations, but there's nothing to call hacker proof. You cannot know that at all. If you're investing your money in something like a web server scanning you every single day and you're paying 50 bucks a month or something for that, I would take all that money every year and invest it in one code audit or at least a partial code audit by someone qualified who will actually look at what you're doing and not just throw a blanket over it and say, it looks fine to me today. Web servers, any server for that matter, but it's certainly DrupalCon, right? Web servers have a lot of value. You can, I think I mentioned in the earlier slide, you can host malware and the malware that you host, if you're an important enterprise website, there's this idea of a watering hole attack. If you wanna go, if you had a village you wanted to kill a bunch of people, you would poison the well, right? You would go after the source where everyone's gonna go, everyone's gonna gather and everyone's gonna drink out of. If you're a large enterprise running a Drupal site and I can compromise your web server, I can do what's known as drive by malware attacks, I can give out malware to people when they visit your site that they will probably never even know I gave to them and now I've compromised their computer using your server. That's one example of bad things that happen, but simpler things, using your server as another of millions of bots in a denial of service attack. Hosting piracy off your server was a hugely popular thing for many years before the age of torrents. General attacks against other people and then of course malware. So even if your site doesn't hold data, that's important. Your server, your organization's reputation, the legal team at your organization, the security team if you have one, all of those people will be in a very bad place if your server gets compromised even if there's no data on that specific box. You should patch daily. You should patch as able, of course you should have a QA and some review and testing before you update plugins and other best practices, but as soon as you're able, you should be updating code. Especially if you have code that has a change log entry for a security feature or a vulnerability or a bug or something. However, and many of you probably know this if you are plugin maintainers, you write a plugin one day, you put it up publicly, you throw it on GitHub, wherever you wanna host it. And at some point, you run out of time or you find some friends project that looks cooler and you start working on that or someone comes out with a competing plugin and they're like, yeah, maybe I'll just not do my plugin anymore and just call it a day. Well, there are people out there that for the next five years will have your plugin installed, they won't necessarily know that you've stopped developing on it if they're not paying attention. So keep in mind that developers and some of you in this room may not patch plugins regularly. They may never have a code audit done. They may not actually respond when people like me contact them and say you have a vulnerability. They may go, thanks for reporting that. You know, talk to you later. I've seen everything in my different roles between development and security where there's a lot of apathy at the end of the day for some of the stuff that I've submitted to plugin maintainers, honestly. So keep in mind that the best you can do is use plugins that hopefully you've had someone audit, which I understand is not very likely, but at the very least keep in mind the development life cycle. Keep in mind that these people are still working on these projects and not just dropping them dead. And at the same time, the cool thing about Drupalcon and similar organizational, with Drupal Association stuff, you guys have a lot of money here if you're not realizing that. Think of how many core plugins that people might contribute to or download and use. What if each of your organizations instead of like getting the best banner at Drupalcon took a little bit of that money and put that towards a fund for a security audit of all the things that you guys make your money off of every day? So think about different ways to give back to the community and one thing that we don't see often enough in the open source, we've started seeing a bit of a change after Heartbleed, the Heartbleed fiasco is that not enough people are contributing to the security of the software that runs their entire ecosystem effectively. So think about that in terms of Drupal specifically. Computers, well let me rephrase. The people breaking into your systems are very rarely gonna be going after your organization in a targeted manner. We know IPv4 space is relatively small compared to IPv6 of course. It actually takes right now about 45 minutes for a software that got developed at the University of Michigan out by me, 45 minutes to scan a single port on the entire internet. So I can go to every single one of your web servers in 45 minutes on the entire internet and get the banner, get the headers for Drupal, grab the index file, figure out what version you're running. If I can do that and I can do that every 45 minutes, what if I as an attacker can find a vulnerability in one of the most popular plugins in Drupal? I don't have to target you. I just have to scan the internet, dump all the Drupal versions, get the modules that you're running through fingerprinting or whatever else and then run my exploit against the entire internet in 45 minutes. So don't think of it as no one's gonna target us, no one cares about us, no one's looking at our server, everyone's looking at your server because they don't have to care what you do. Of course, depending on which enterprises some people might be targeting you, you might actually be a direct target. However, for most of you, it's really just rushing roulette of if someone has a bug and they know how to attack it and exploit it, they will go after as many servers on the internet as possible. So here's kind of the breakdown of what we're gonna go over today in terms of overall security. Obviously, a bit of an eye chart that's for a reason, security in terms of a stack is complex and there's a lot to it. So we'll break into each one of these, again, get a business card after if you have a specific question on parts of these as I know there's gonna be a lot to go over today and the slides are available as well, so no worries. The OS and services level is interesting. I think the agility that we've been given with things like Amazon Web Services, for instance, has made this less of a big deal. I mean, you can start an elastic load balancer, build some instances, pull up a network stack and web stack and then if you wanna update, you can literally just create like 10 new instances with the patches and then take one out, put one in, take one out, put one in, now you have updated architecture. So we're in a better place than we used to be. Certainly, depending on how long some of you have been working in this industry, you may have had a web server that was running the same version of Apache and the same version of PHP for four, five or six years if no one really needed to fix anything. So we have more agility now and we have to think about using it. One way to do that is have a managed services provider take care of your underlying architecture. You can be the developers, you can be the app people but perhaps if you're not the best at security or perhaps you don't have enough cycles to do patch management, look to a third party to maybe do that for you. Manitory access controls is a big gnarly area of security. The too long didn't read on what mandatory access controls are is if you think about read, write, execute the basics of any file access. Those models, if I own a file, I can say, oh, I want everyone to read this file, I want everyone to write this file but no one to execute this file. And I can set that, it's to my discretion which is why it's called discretionary access controls. Manitory access controls are kind of a top down kernel level where the administrator and that doesn't have to mean like root or administrator actually, but the kernel level control can actually make policy and that policy can be enforced at the kernel level not in the hands of a user. So even if I said, I want all people on every account on the system to have access to all of my files, read, write, execute, delete them, add them, edit them, whatever. The kernel can still say, no, that's a terrible idea, you should not let everyone do that and I'm gonna stop you from doing that. So in Ubuntu, you'll see app armor enabled on CentOS and REL, you'll see SE Linux enabled, they both effectively do the same thing and these policies can do it on files, they can do it on ports, they can do it on network services and actually restrict bad things that could possibly happen if someone did break in and got low enough privilege to actually start attacking the system. And for Ubuntu and CentOS and REL, those are generally on by default unless you have a custom build or something else. So take a look if you get a chance if you haven't. One of the oldest things that everyone has said but when I do pen test, I disagree that everyone heard everyone the first time, network services that need to be exposed should be exposed, you want your network services to work. However, if you don't have a specific reason for that specific host to be exposed, not just to the internet, but to your internal network. If you have an Amazon deployment and VPC and all this awesome stuff going on your backend, don't give SSH access to every host from every host. Don't give a backend web service that you're managing clients with to every host. Even if you think you're behind a firewall or a VPN or whatever it is, always segment as much as possible. Don't leave things to chance. If you can control it, go ahead and do it. And then two factor authentication, whether it's the Drupal credentials for the actual accounts that administrate Drupal, it's Linux, it's your VPNs. You don't have to trust people are gonna make good passwords anymore. You don't have to trust that people aren't gonna get their passwords phished or brute forced. Don't do it, whether you use Duo Security or one of the other 100 vendors out there, use some kind of two factor, just promise me that. So patches, going over the top, the core patches, like an app get upgrade or a yum update, do those things. You should do those things on your Linux boxes or the Windows equivalent, right? One place that I see things fall down often is the latency in actually updating things like PHP. You're like, hey, we built on this version of PHP, we trust it, we know it works. There are vulnerabilities that directly affect PHP, not the version of software you're running PHP with, but actual PHP code has had inherent vulnerabilities that have been patched and have been rolled out. If you use other stacks, so maybe, obviously not everyone here is just a Drupal person, you probably have other jobs and other projects and other cool things. So if you're a Perl person, update CPAN stuff, if you're a Ruby person, update Gems, Perl for PHP, keep those libraries updated as well. It's not just the system level stuff. A lot of times you might grab a library from Perl or something, throw it into a project and not actually have system level updates for it, think about what that means long term. Will that code ever be updated? What if there's a patch to that library? Will you ever get it? And one other thing that gets missed, especially if you still have actual physical servers in a data center, is things like firmware, out of band access, lights out access. Those pieces of firmware often have vulnerabilities or backdoors or hard coded passwords or other bad things. So think about if you do control your hardware, what kind of access people have to those? Because if I can get to a web server on your network and then your router or your firewall, your switch has default credentials, what do you think I'm gonna go and do next? I'm gonna mand middle all that traffic on the back end and just start taking it in. So things, it starts really small and attackers really, we talk about footholds. The simplest minute aspect to a PHP library can go all the way down through your entire network in a matter of minutes with the right person. So I kind of gave you the, well, let me throw this up here. I gave you the overview of this. So basically discretion access controls, you have access to, as the owner, say what's gonna happen, mandatory, a higher power above you decides what's gonna happen even if you own the files. So here's a bunch, and again, this is why I have the slides because you guys would hate me if you had to type all these links out. Networking, firewall, stuff like that. Yes, you should still have a firewall. No firewalls won't really stop a lot. However, that doesn't mean you should get rid of things. Firewalls are generally easy to maintain. You basically say what you want open and ideally what you don't want open. Sometimes people just say, oh, I don't need a firewall. It doesn't matter. Keep in mind, one thing that firewalls do for you is if an attacker does get onto a server, if they can then connect outbound or inbound in whichever way they want, they can very easily take a PHP vulnerability, open a network socket, and then have command and control over that open port because you didn't have a firewall. So it might not stop them, but it will slow them down, it will frustrate them, and it might actually break some automated attacks we see. Again, most things that are happening out there bad to you are actually automated. They're not actually a person taking time. So if you can break the workflow of some of these attackers through their automated means, they're gonna get frustrated and go to the other 100 people down the road from you that also have vulnerabilities in their server somewhere. Network allowances, you can do cool things by user and group. So you can say this user is allowed to open this port or this group can open this port. And you can actually limit, again, more access for what network ports are happening on that. Things like denial of service, Cloudflare, if you can afford them and you wanna use them, that's a great option. Any other kind of CDN is usually a pretty good option. It will limit denial of service effects and it will hopefully keep your site up. But there's also, excuse me, there's also a lot of cheat methods to do that. Built-in IP tables, firewall, packet filtering on Linux. You can actually do some basic load balancing with that. There's, of course, there's other ways with proxies and some other cool stuff. And then one last part is you can actually also do time or calendar kind of constraints. So if your organization only works on a certain web service backend between X and Y hours, or you only log into remote systems between X and Y hours, you can actually then further mitigate the potential that someone might break in or see a service that's open when it shouldn't be or any other kind of edge case. If you have that kind of hard lines for certain things that you do in your organization, you can actually control that a little bit better by implementing some of that. So two factor, you can do two factor with a bunch of ways. There's mobile app ways, there's SMS phones, tokens. Again, there's a lot of vendors out there. Go find one that works well for your company. Web servers, you know, Apache I think has been the worst of this for all the years that I've been using Apache since the early one three days. Apache specifically has enabled modules after modules after modules out of the box that most people will never, ever, ever need. Now granted, over the years very few of those has had severe vulnerabilities, but again, think about things as reducing scope, reducing attack surface, okay? If you guys walk out of here and you go back to your office and say, yeah, Mark said don't reduce scope or reduce attack surface, that's the best thing you can say ever because it's true, like most things don't come down to what you patch or what you, you know, or the plugin that you think's really secure, it comes down to if you didn't need it, get rid of it. If you can lock it down, lock it down. That's really where security honestly at the end of the day comes from. So if you do have modules and you don't use them or you don't know what the hell they do, probably look them up first, they don't break stuff, and then disable them if you don't need them. Simple things and you know, especially in the security community we're really, really finicky about saying like security through obscurity is a bad thing and you guys are dumb because you think it works and blah, blah, blah, not true. Security through obscurity does work. What it does, it gives you lead time and that's sometimes all you need, right? It's like you don't have to run away from the line, you just have to run faster than your friend. It's true and if you think about Heartbleed, Heartbleed came out and everyone started looking at all your servers to see if you were affected by Heartbleed. What if there was a way where very easily depend how Heartbleed or something else would have worked, what if they were looking for a banner like Apache 227? If you don't have a banner Apache 227, they're gonna scan the internet, find all the ones that do have 227, go after them first and then maybe circle back to the rest of the internet later and maybe that's all you needed for the next four hours to get your stuff patched. That seems like a win to me. So simple things like you don't want banners, you don't want PHP version numbers showing, you don't want WordPress version numbers showing, anything you can get rid of, because remember automated targets, automated everything, if they can't find you they will leave you alone most of the time. So make yourself less of a target. SSL TLS, we'll talk about that more in a second. And logs, most people don't keep logs off site, most people have their logs local on their server, if something breaks they might look at it, if they get breached maybe they catch it, probably not. You should be logging all your stuff off that server. So let's go down on a few of these. Again, if you have a web server that has a lot of modules, disable them one at a time, re-start, test your app, go through your, or your Selenium test or something else, make sure you didn't break everything and then go on to the next one until you get rid of all your extra stuff. So these I can tell you very, and I realize now everyone's Apache here, but these are things you have to have in Apache for things not to go boom in most cases. So try not to disable those, just try the other ones after. So information disclosure stuff, Apache, Nginx, Lighty, those are values that you want to set in your configs, those values will take out some of the verbosity of what those servers say when a request comes in, and again, you might reduce yourself as a target just enough to get patched in time. So this is really important, and it's really important because it's really fast and it's really easy, because I usually grade things in how quickly can I get them done as a value add to my day and be like, look, I got five projects for security done. This is one you can get done very quickly. There's a whole SSL Labs team, they're from a company called Qualis, and you can go to that link where it says second, you can go to that link and you can put your web server in there. It will test everything about your SSL TLS deployment. It won't just say, oh good, you have secure sockets layer, congratulations. It will say, what Cypher suites are you running? What's your common name? Does this match, does that match? It will give you a report card and tell you what you got wrong and then you can go make those edits, retest and validate that you have a proper configuration. Yeah, yep, yep, these slides will be available. Yep, no problem. It's ssllabs.com slash SSL test if anyone's really impatient wants to test right now, that too. But yeah, just rinse and repeat until you get an A or an A plus. Like it's very, it's a grading system you all are very familiar with. So it will tell you what you need to do, the PDF file that's above will give you enough information to understand why these things are good or bad and hopefully get you on a better path. As soon as a server is breached, your logs on that server mean nothing. They mean nothing to the FBI, they mean nothing to me as an auditor, they mean nothing, they mean nothing. As soon as I break into your server, I probably can overwrite your logs, delete them, manipulate them, whatever I wanna do. So don't trust logs on the server. What you should be doing is actually pushing those logs off to a central service. Now, that central service ideally should only be for logs. You should very much lock that server down, of course, but if you're just sending SysLog data over the network, if someone breaks in, they can't delete what already happened, right? It's a one-way path, so data's going out, data's going out, they break in, they delete all your logs locally, and all your logs are already over to the safe like Bastion hosts where no one can break into it hopefully. So think about longevity, don't keep logs for a day or a week. One thing that I think happens a lot is we don't spend enough time log tuning, you might tune logs for performance to understand what's happening, but are you tuning logs for security? So think more about that, how your organization's kind of matured through security, and think about what logs you're getting and what logs might be security relevant, and then try to store those off-site. And that literally can mean maybe you have a completely different Amazon web services account with one host, just for logs. Whatever you want to go to, whatever links you want to go to, your organization probably has much different needs than everyone else is in here. All right, development platform. The same basic principle of any software like we were just talking about with Apache, if you don't need it, you should get rid of it. The same thing happens with languages. You have modules that at one point you were testing out and you thought, hey, that would be a cool feature and then you decide not to use it. Get rid of that module. Let me get these up here so hopefully you guys have a little more time to catch up. Information, same thing. If you have a PHP version, you can disable that. We'll show you how in a second. Privilege separation is maybe a foreign concept or not a phrase that you're all that familiar with. At any point in time that you can, again, limit scope or limit access to an attacker, if you can break down the level of privilege that one process or one app has so that it doesn't give access to all your other apps or all your other processes or all your other databases, you have then made, again, a bigger pan the ass for the attacker. And lastly, we'll go over one thing about kind of back end security. So libraries and modules, again, a lot of people are consuming code. Sometimes that code is not maintained or it's forgotten about or they just stop caring. The one thing I've seen a lot of is, how many people over the years have used TinyMCE and then turned out to hate it? Okay, yes. I'm not shocked. So TinyMCE has actually had dozens, let's say, maybe more than dozens. You might have to round up to a three-digit number at some point. It's had a lot of vulnerabilities over the years. Other kind of WYSIWYG-y type things have also had default code that it would install and that code was for testing by an admin. Well, that code would be default and you would never delete it because you didn't look in that folder to note it was there and then turned out there was a vulnerability in that default test code. And then you could exploit that and now you have access to the actual web server. So things get really bad very quickly when the wrong thing's in the wrong place. If you could hold on to the hope, that's great, but remember, at some point your favorite plugin, your favorite core library in Drupal, your favorite method, there probably will be some vulnerability in that. So keep in mind that even if everyone's using a plugin, that does not mean the plugin's safe. OpenSSL is a great example of everyone's using OpenSSL and OpenSSL had a huge, huge implementation problem, okay? So while many eyes and all that is great in open source and it does work and eventually comes around, sometimes it takes like five years. So don't make that your only hope, maybe if you can again, code out it's yourself, but just don't forget that just because it's popular doesn't mean it's secure and at the same point, take a look at the community, whether it's GitHub or wherever else, look at the issues that are coming in because there might be an issue in there for security and the maintainer might just not be looking, but guess who's looking at GitHub issues for vulnerabilities? Attackers, they're gonna be looking for issues that aren't patched yet for the reason of attacking them. So be ahead of the game if you really care about a certain project if you're able. Same thing with PHP, go ahead and expose PHP off, never ever ever show errors, always handle your errors. This is no more important than ever when it comes to things like SQL injection. If I can see an error for SQL injection, I don't need a person, I need a bot and I can do SQL injection against all of your plugins or all your sites or whatever it is, very quickly without any knowledge if there's a single error message for SQL. So hide those things, it's only gonna help attackers, it doesn't hurt you and honestly like production systems you probably should never show like unfiltered errors to users in the first place. Couple other ideas. One area that gets forgotten about a lot is your cookies, so your session cookies and other kind of cookies that are important. Those two settings in your PHP config are probably one of the best things you can ever do to prevent a bunch of different attacks. Now if you have SSL enabled, the second line down there, cookie secure one, means that only cookies over SSL will be transmitted. So that means if there's an attacker and your user's logging in from a coffee shop and someone's sniffing their connection man in the milling them, that attacker can't get the cookie because it's not being given because it's not encrypted. So that's a big thing and very easy to turn on. The other one which isn't done enough still is HTTP only. Cross-site scripting, I'm sure you've all heard of it at one point or another, you basically know what it looks like, how it happens. HTTP only means that if someone does find cross-site scripting, they won't be able through, without a lot of headaches on their end, to actually be able to steal the cookie from the user because that's one of the most common reasons why cross-site scripting is a big deal. If you have a cross-site scripting vulnerability on your website and you don't have HTTP only, odds are that the attacker can trick the user into clicking the link and it will immediately spit out their cookie and send it over to them and they are now your user. That's the risk and these two settings together, very quick things to turn on make a big difference. Privilege separation, if you have things like MySQL or any other kind of SQL, you've probably done what we've all done which is like grant all privileges on foo.star to user at identified by. You've all run a manual, you've granted all privileges immediately to that user and oftentimes you might do that to root. You might just say grant all privileges to root at local host. Don't do that. There's a reason why there's a structure, there's a reason why you can segment privilege because you're supposed to. So when you create a Drupal instance, create a Drupal instance, a user, a password, a database, only for that instance of Drupal. If you add another app, don't reuse the same credentials. And why? Because you wanna limit if an attacker does get credentials for Drupal, they won't have credentials for you. Other dozen sites that you're hosting on that same server. MySQL often, and again you guys are probably at some scales here that are pretty awesome and maybe you're not even using MySQL or you're using Postgre or God only knows what else these days. However, think about things in terms of MySQL is a network service. However, many of you have single deployments that don't actually have network service needs. You have local host needs. You have connect local socket and use MySQL. If you have to have network privileges for MySQL, you probably should have SSL running between those SQL servers. You should not have networking enabled if you don't need it, so turn it off. Couple things, commands that are executed. And let me give a quick example of this. I don't think it's anywhere else in here. MySQL, if you grant all privileges on a database with a user, one of those privileges is the file privilege in MySQL. If you give me the file privilege as an attacker and I can manipulate SQL queries like SQL injection, I can actually do things like write files to parts of your file system. I can also read files from your file system and there are really clever ways that I, without writing any data in your file system, reading out of PROC, how many people know what PROC is or have at least heard of PROC. So it's a pseudo file system, it's on Linux by default and it just has a bunch of metadata basically about the system, about processes. Using my browser, changing headers in my browser, connecting to your web server and having the ability to read a file, I can execute arbitrary PHP. I don't even have to write files to your file system, I don't have to pull it up in Apache. I can actually do exploitation just by reading PROC through my SQL, right? So again, it seems like oh, it's just MySQL, like maybe they could steal my database but they can't hurt the server. No, no, we absolutely can do bad things to your server using MySQL or Postgre or many of the other databases. And the PHP and CGI mode actually does do segmentation. It's not one giant account that runs all the processes. It actually, sir? So the trick there is if you have a virtual switch, like if it's like vSphere or something that you have a bunch of VMware stuff, that data, if it's not encrypted, is still vulnerable. So it's not so much that it's segmented privately. That's good that it's segmented privately and it's over a virtual switch. However, if you're still not protecting that data or if I'm an attacker on a different box or different VM instance and I'm on the same virtual switch, I can then attack MySQL over that network connection. If you have to have it at all, it should be encrypted and if not, shut it off, yeah. All right, let's get some backend security up here. So one thing that you guys might not be super familiar with is this idea of an SQL proxy. And an SQL proxy like many other proxies takes data or network data and it passes it on somewhere else. So you might have reverse proxies in your environment. You might be using load balancing type of functions for proxies, whatever. Green SQL is one example. They used to be free, I think they're all, they might have a free version these days but I think they're mostly commercial. They're cool though because the connections that you make from your web app to your database service, you actually proxy through something like green SQL. And what happens is when it gets the database connection, it looks at all the queries coming over your SQL commands from your app and it can actually flag them or deny them if it looks like SQL injection. So if all of a sudden it gets a database query that's trying to read Etsy password off a host, it's gonna stop then and prevent it from actually happening. Same thing, mod security, mod security has been around for a very long time, is free. Kind of a huge pain in the ass to set up but luckily there's some people that have taken a lot of the pain for you for Drupal. And mod security will actually do that kind of operation but at the web app web server level. So when a request comes in through the web server before it hits your app, it will actually say no, no, no, this looks like an attack. I'm not going to let you do that to this web app. So your web app doesn't even have to necessarily be security because mod security or green SQL will actually intercept those queries and stop them. Now this isn't how you should live your life certainly, you should still be protecting your apps and doing security and doing whatever you can. However, remember, you're not always gonna know when a vulnerability came out. You're not always gonna know that there's a bug in your software so you wanna layer on these extra controls if you're able to. So DAC Mac, we talked about earlier, anytime you can lock down permissions and privilege on files, do it. One big thing with PHP apps especially, and well I guess web apps in general, is having like that temp space in your web server directory that really, really sucks for security. If you can have read-only files in your web service directory, that's good stuff, do that. And then getting back to what we were just chatting about, if you are using MySQL with multiple servers or anything else that's network enabled, it doesn't matter if it's on the backplane network or over the internet, have that data encrypted between both points. All right, last few slides here. Patches, again, themes, themes have often been one of the worst parts of security with CMSs. Drupal in my honest opinion is probably not nearly as bad as WordPress has been. WordPress has had a ton of theme vulnerabilities. Remember, themes are, at the end of the day, code, and code have vulnerabilities. So if you have themes that do really cool stuff, you might also have some really cool vulnerabilities as well. So again, contributed themes, contributed plugins, just be selective, try not to just use all the things, try to think about what you're actually installing, and if you have themes and you're not using them, get rid of them. Again, if you have a team of experts, luckily in your company, which most people don't unfortunately, there are way too many organizations to count that do code audits, that do code reviews, that will do penetration testing. If you're in a place that you're able to budget something like that, I would highly recommend it. It'll be the best money you've ever spent. Don't just disable a theme or a plugin. This seems super unintuitive. Plug-in code that's sitting there dormant and theme code sitting there dormant, if the vulnerability affects it in such a way that I can call a file or somehow otherwise manipulate PHP to call an object in that file, which again, there's crazy stuff you guys wouldn't believe. If that code is sitting there, I might actually be able to execute that code and then use that vulnerability in that code to then escalate privilege or gain data access or whatever else. So if you're not using a plugin or a theme, get rid of it, don't disable it. Disabling it does help, but it doesn't do enough. Open source, open SSL, heart bleed. If you're using open source stuff, you're using free stuff, you've seen all the licensing, licensing will not save you, you're not gonna sue anyone. So if this is a corporation with billions of dollars flowing through it and you are the Drupal admin, get a couple of bucks to have someone look at your code. So a few different things, security kit. Does anyone use security kit? I think it's a little bit unmaintained now. I think January might've been the last little patch to it. However, security kit has cool things. All right, I'm sorry, I'm thinking of another one that we'll talk about. I think security kit's still good to go. But cross-site scripting, cross-site request forgery, click jacking, and some man in the middle stuff. Each of these components has their own threats and their own realities and their own risks. Obviously we don't have enough time to talk about all these and what they mean necessarily in a grand scheme. Just know that security kit is here to help you and it's here to help mitigate those as risks. So HSTS is actually a header that modern browsers, so everything, but IE these days, I think, you can actually set with the browser and say, oh, you've come to my site. Well, I support SSL and the browser will never, ever, ever again go to that site without using SSL. And what that means is if an attacker can redirect them to a site or part of the site that's clear text where they might've otherwise stolen data over the network or they may have stolen credentials, this won't let your browser do dumb things. Like you might click a link and do a dumb thing, but your browser will say, no, no, no, this site's SSL enabled, I'm all using SSL and that could actually help. And that's just a check box in this and as well as you can enable it if you're writing custom PHP code. Duo, we do two factor, good. So Tiny IDS, this is the one I think might be slightly under maintained. I don't think there's any Drupal 8 builds, so maybe you might wanna be the new contributor to that and make sure things work. But again, simple things like Tiny, so IDS stands for intrusion detection system. It's often a network type security control. However, Tiny IDS will look at your logs and actually look at them to say, oh, that looks like someone tried doing cross-site scripting or that person looks like they tried doing SQL injection and maybe at that point you might get a little bit of a heads up that, hey, some people are attacking us, maybe we should block them with our firewall or block them with Cloudflare or whatever else. And then security review will basically just say, here's a bunch of things you should be doing for security, you are not doing these three things, you should fix those. And it's just a really quick litmus test that you can enable and all these plugins are free. Even do a security is free up to 10 users. So if you have 10 Drupal admins or less, you can use us free for that as well. All right, who's exhausted and hates me and thinks that I should do all the code odds for them for free? Yeah, no, I realize that. And I really wish I would be able to come up here and show you a bunch of funny photos and give you a couple of anecdotes, but this is the shit that will make you secure. Like this honestly will help your organization if you do this stuff. So it's not security theory, it's not making you feel good, it's not the once a month scan from McAfee. Like if you do this stuff, an attacker might still break in, they might find a vulnerability in your code. But if they can't get through your network and they can't get in your system in really convenient ways for them and they can't get access to your databases because you've segmented them and they can't escalate privileges because you've done mandatory access controls. Like that is the stuff you can control. You cannot control when there will be a vulnerability in one of the 100 plugins you might have deployed this year. So don't think about those things, think about here's all the stuff that you could do. Now try to pick some of it and work with your team hopefully. So layering security, a firewall won't do it, a security module won't do it, a patching won't do it, all those things together will help, right? So think of it holistically, think of it the big picture, think of the entire stack, not just one layer. Attackers will do really creative things that you would never believe. If you ever get to go to like a PHP conference and look at some of the talks just about PHP security, there are things in PHP that would blow your mind that could happen just with a couple lines of code. It's not all SQL injection, it's not all local file inclusion, there's crazy, crazy stuff. So consider that an attacker often won't go after the things you think they might attack. They actually might attack the things you never would think they would attack like your disabled themes and your disabled plugins. Don't forget that Drupal actually is really security forward. They're contrib vulnerability announcements, they're PSAs, they're security page. So get on those mailing lists, look at those feeds, interact with that kind of data as well because often times they're gonna be a good notice that hey, bad things are happening, we need to patch immediately. All right, do I have two minutes or five minutes? I don't know how, does it run 2-12 or to like 11-50? Oh, two o'clock, okay, great. Perfect, well then we have a couple minutes for questions actually for once. So there's all my contact details, I did wanna tell you that if you can handle more security and I think it's more directed towards actual coding security at this point, go see this talk at 2-15. There's two guys doing this talk I believe. So if you like what you saw here and like what you heard about, but maybe things like CSERF, CSRF doesn't mean anything to you or Christ like scripting is still kind of this nebulous thing, I believe they're gonna talk more about that at developer level which is great, great knowledge for you to have. All right, any questions? Sir? Yeah? Yep, so within MySQL you can actually do file read and write operations. You can actually, you could do a select statement that said select blah into file var www and if MySQL has privilege to var www somewhere, it can actually write a file out, the same thing. Anything that MySQL, the actual user in the Unix space of MySQL, anything that can read on the file system, you can then read through MySQL's actual code. So you can say file load and it will load that file if it's CSV file data or text data, whatever, it will load up and where that becomes a problem is, and since we have a couple minutes, I'll clue you guys in. There's a part of PROC, this meta file system, that when you're using PHP, it will actually have data that will display if you read it. And what one of the pieces of data it has is header data. And if I as an attacker in my browser change my header to be PHP shell, so like something like exact dollar sign underscore get command, I can actually put that in my browser headers and when I go and actually go to that web service, it will open up PROC and it will actually execute because it's reading PHP code, it will execute it and I now have control of that web service to execute commands as if I was the everyday Apache user for instance. Things like MySQL have vulnerabilities all the time, there are MySQL vulnerabilities, probably too rarely. One of my favorite is there was a vulnerability two years ago or two or three years ago that if you tried logging in as root on MySQL like 97 times or 170 times or something like that, really low number, it would actually have an integer overflow type problem and it would log you in as root. So when I say turn off MySQL support if you don't need networking, that's why. It's not because someone's gonna necessarily break in or brute force your password, there could just be a vulnerability that you had no clue could ever happen and that's the reason why we turn stuff off that we don't need. That's a good question. I'm not super keen on GreenSQL, I think in some instance and it depends on your deployment model. If you ran GreenSQL on the actual web server and then that had an SSL connection between GreenSQL and your actual back end MySQL, that's one way to go about it. Often I'm not totally sure though, but great question. Sir, there can be, you know 2014 like my iPhone has more power than my computer did like three years ago. So honestly encryption's kind of cheap, it's not as expensive as people think. Certainly if you have crazy scalability thing that I can't even begin to imagine, yeah you might wanna test that. But for most people rolling out like two or three database servers on the back end and like a dozen web nodes or something in a reverse proxy between, you're probably gonna be okay, you're probably not gonna notice quite honestly. Yes, so let me qualify it and then I'll answer your question, penetration testing tools in general, if you don't know how to use them and you're not gonna spend the time to learn how to use them, you're probably not gonna get any benefit out of them. There are certainly tools that are point and click, like they just work, however, if you do wanna do this, which I don't think anyone should be dissuaded from ever trying to be a better security professional, always please set up a test environment. You'd be surprised the number of developers I've worked with over the years that like, oh yeah we tested against production and like the site fell over. I was like, why did you do that in the first place? So that's my thought on that. There's a Linux distribution called Kali K-A-L-I and it's a live distribution and you can just run it and it has just crazy amount of tools built into it. One example that you guys might wanna take a look at if you're gonna go down that road would be SQL map, so SQL map and SQL map, you literally point it at a URL and like a query string and it'll actually try to brute force to see if that query is actually vulnerable to SQL injection. And if it is, it'll be able to actually by itself say, oh I believe this is a MySQL server four point some version because of that I build this SQL statement like this and now it gives you code execution, credential dumping privileges and all kinds of other crazy stuff just by pointing it at a web server. And that's a really good thing for PHP developers because SQL injection historically has been a huge problem for us. So if you wanna test something like that, SQL maps a cool one. There's also Metasploit which is a whole exploit framework and it'll actually have a bunch of tools that it actually is all open source code and you can actually, it's Ruby based for what that's worth but it's all open source code and you can actually test known exploits very safely against your enterprise testing system. It's been made to be tested and retested by professionals. A lot of the exploits on the internet that you might see on a website or passing around like Pacefin or on Reddit or something, a lot of those haven't really been tested and sometimes bad things happen and also sometimes people put backdoors into them. So be careful if you ever take exploits off the internet just because something looks cool. We saw this happen with Heartbleed where people were testing sites with Heartbleed that people posted online to test and it was actually doing really bad things to their servers. So be careful whenever you're in that space, sir. Yeah, so basically the question is like if best practices would be keeping code out of file paths that could be accessed by the web server if you didn't need to have them there because if code's accessible by the web service bad things could happen, right? So kind of a simple thing for instance if you have something like HT access files where you do basic authentication to a certain part of your website those files should always be out of the web service route. Those should be getting read by the web server within the guys of I need to read this file. So as long as I have file privileges on the server I'm okay. The web server however does not need to give those files ever to anyone on the internet. So if you have files whether it's PHP whether it's configuration data if you don't need to call that code directly by the web server you might be able to get away by moving it out of the directory and then if you have to like change some file headers to point to a new path or something else. With Drupal however I'm not sure if there's like a project that goes two lengths to make that happen. I probably wouldn't recommend doing it yourself unless you really wanna spend time maintaining it because ultimately as soon as you start changing like include and auto require statements and all these other things you might start breaking stuff every patch upgrade and that's probably gonna be the security gains by not having those files there if you start delaying your patching I would patch before I worry about the other. I would just say like again themes, plugins you don't need to get rid of them if you have built in code with a package you downloaded from like GitHub or something if you see code you don't need to get rid of it but of course things like Drupal are based on this principle that hey the stuff we're including in core Drupal is kind of important so maybe not screw with that I guess but it's a good point though I mean that's the right mindset for sure. So do you mean like proper jails like Linux jail jails? Oh I see, I see. Yeah I mean historically that's had workarounds for attackers. You know I think things like is anyone a docker person in here or starting to think about being a docker person? I think docker has the right the compartmentalization mindset of how docker operates and segmenting apps like that that's really interesting to me. You know I think that you know we used to take the approach when we didn't have VMs like oh every server should do one thing and then ultimately budgets would say no every server should do like nine things. Now we're to the point with VMs and you know Linux containers that we can then now again actually segment as much as we should segment and then between apps actually have networking between apps to say oh no this PHP app should never communicate with this MySQL server only this MySQL server that's pretty interesting to me but there are actual Linux jail opportunities the stuff that's built in in PHP is not that rigid. I did mention earlier at the start of my deck things like GR security will actually add some additional protections to what's known as CH roots or shroots which actually kind of limits that scope kind of what PHP is doing. So GR security might be something to look at but then also SE Linux or App Armor the mandatory access control stuff we were talking about those will do things like if you have code that's trying to access files outside of the web server file path it will actually through policy say no you're not allowed to do that so that's another way to kind of limit the availability of files or data after someone might breach out PHP app. Any one question? Yes. So uncompiled.com is my website all my slide and there's a bunch of other security crap up there too you guys might find interesting also puppet stuff if you got puppet so yeah all the slides are up there go see this other talk if you can stand more security I have cards so run up to me really quick if you want a card and otherwise I'll be out there for a little bit so thank you so much for your time guys have a great week.