 So thank you for joining us today. We have DCIN labs on the webcast today joining us to talk about auto logout and session limit modules. Just a little housekeeping before we get started. Thank you for joining us. My name is Lauren. I work for the Drupal Association as our community outreach coordinator. So I run our webcast as well as our global training days and other educational programs. If you're listening from your computer, make sure to select the mic and speaker audio option. It's easier sometimes to wear a headset though up to you. You'll be muted during the call. So that means that you can ask any questions or comments through our Q&A window. We're not using the chat option today. And please feel free to take our host webinar survey. We really like to know how we can improve things and make sure that we give the best product to our community. Just a little bit about the Drupal Association. Obviously, these are our big programs, Drupal.org improvements. We host Drupal.org. We also host a little thing called DrupalCon, a huge event we have in North America coming up in May of 2015. We have one coming up in just a few weeks, actually in Amsterdam. And then we have, of course, our new exciting program happening in Latin America in Bogotá in February 2015. We also have community grants that we help with other emerging communities to get them started on some of their Drupal projects. And then, of course, we have Global Training Days, which is a free or low-cost intruded Drupal training that a lot of Drupal shops host. And it's a really great educational resource to spread the word about Drupal globally. Just a few reminders of things that are coming up. We have, obviously, DrupalCon Amsterdam coming up in a couple of weeks. We have our Drupal Global Training Days. You can find out more at Drupal.org. Learn Drupal. And then, of course, we always have ongoing webcasts. And you can see the link there and check out what we have coming up. And we just want to thank Deeson Labs and all of our supporting partners. They make it possible for us to really provide these wonderful educational resources to you guys, as well as supporting the program and the project as well. So thank you. And without further ado, a little bit about our presenter, John. John is a Solutions Architect at Deeson Online. He's a member of the UK's Institution of Engineering and Technology and a Chartered Engineer. And John likes really strong tea, so that's fantastic. Hopefully, he won't need any to get started on this webinar. So without further ado, John, I'm going to switch the presenter mode to you so you can start the presentation. Okay. Can you see my screen? Okay. Can you see that? That is the Drupal site. Yep. Okay. Thanks very much, Lauren. So yeah, today's webinar has got a security theme. I'm going to be looking at a couple of add-on modules for Drupal 7 to beef up the security of the site, but it's about applying organizational security policies to your websites. And so the modules we'll be looking at are the Auto Logout module, which limits the amount of time a user can remain inactive on the website. We'll be looking at the Session Limit module, which limits the number of times a user can log in simultaneously to the same site. And then I'll cover a little bit of the Password Policy module, which allows you to play your organizational password policy to the Drupal website. We'll be looking at some settings within the Flood Control module, and also the Security Review module, which helps you to look for some common misconfigurations in your Drupal 7 website. So I'll start with the Auto Logout module. The Auto Logout can be found on Drupal.org at Drupal.org slash project slash Auto Logout. If you'd like to test that out, there's a link straight here to simply test.me, which enables the site with the Auto Logout module already enabled, and you can follow through the instructions on there that you'll be going through today. So in order to enable the Auto Logout module, you'll do that from the module's menu. And Auto Logout also has an integration with a second module called JS Timer, which can be downloaded from Drupal.org slash project slash JS Timer. The JavaScript Timer module, we'll see how that's worked using the moment, but it allows you to put a clock on the site, which shows how much time a user's got left if they remain inactive. With the Auto Logout module and JS Timer modules enabled, you can configure the Auto Logout module from the main configuration menu, and then the Auto Logout option under people. The Auto Logout settings are here. The first one is the number of seconds that a user may remain inactive on the website. This is the general setting, and 1800 seconds is the default. This equates to 30 minutes on the site. Some users are able to set their own Auto Logout settings up to a maximum, which you can provide here. One user's session is about to expire. They will get a pop-up alert asking them if they wish to continue their session, and the amount of time that pop-up alerts remain active on the screen for is specified here in seconds, so this is 10 seconds. The Auto Logout module allows you to specify Auto Logout times per roll, so the authenticated user here is given 60 seconds, which is the minimum amount of time a user is allowed to have. Anyone with the administrator roll is given 1800 seconds here. That's 30 minutes. You'll be able to set some of the messaging as well on the module that pops up. With the configuration setting saved, I'll return to the configuration screen, and because we're going to put the timer on the page, we'll have a look at the JavaScript timer settings. The JavaScript timer setting just needs this one setting set, which is that it should load the JavaScript on every page. If I look at my administrator's settings, they'll get a new setting here, which means they can set their logout threshold themselves. The user one is set to 3600 seconds. This is one hour. With these settings saved, whenever you're on the site, on the left hand side here, we have a block which you can add from the structure blocks menu, and it shows you the amount of time you have remaining within your session. The user one administrator has 59 minutes remaining now. As you browse your site, this timer is reset, and there's also a button there for resetting the time. If I now log out of the site, I'll log out as a test user. The test user is only an authenticated user, and has only 60 seconds for their period of inactivity. We'll be able to see when this timer counts down what the logout prompt looks like. This is a good time to talk about some of the other features of the AutoLogout module. The JavaScript that includes the AutoLogout module will detect the user is working on a form, so if there is a particularly long form, each time they interact with a form element, the time on the server cell will be reset, which means that if they have a form that may take many minutes to complete, it doesn't log them out after them working on that for an amount of time. The AutoLogout module also works across tabs, so if you're working in multiple tabs on the same site, as long as you're active on one of those tabs, you will not be logged out of the site. We have a few seconds remaining of inactivity on this particular site. When this counts down to zero, we'll then get a pop-up alert asking if you want to remain on the site. If we say yes, we'll be returned to work. If we say no, or we don't press it within the 10-second window, the user will be logged out and they'll get a message. When they return to their computer, they'll get an oversee that they've been logged out of the site. That's the AutoLogout module. The next module I'd like to go over is the SessionLimit module. This can be found on dripple.org under dripple.org slash project slash session under school limits. The SessionLimit module allows the site administrator to restrict the number of active sessions a user can have on the site. So I'll start by disabling the AutoLogout module and then we'll make sure the SessionLimit module is enabled. To configure the SessionLimit module, follow the links from the configuration menu and then SessionLimit under people. The first option is the number of default maximum sessions a user can have which is set to one. This allows the user to log in once on one computer. If they then log in more than one time, the following actions may take place. The default is do nothing. This is the Drupal 7 default action. This will allow users to log in to as many work consoles as they, as many sessions as they like on the website. The second option, automatically drop the older sessions without prompting. If they were to log in at home and then they logged in again when they came to work, the session that was logged in at home being the oldest would then be logged out. So it couldn't be left unattended. The final setting is the prevent new session. With this setting set, if a user has logged in somewhere at Workstation 1, if they try and log in again at Workstation 2, they will be prevented until they've logged out to the first. If I save these settings, I'll demonstrate how that works. So we'll start by logging out of the site and I'll log in as the test user. Because this is the first session, the test user is allowed to log straight in and navigate around the site without any problems. They are logged in. In order to demonstrate the abilities of the session limit module, I'll use a feature within Google Chrome called the incognito window. Incognito window works separately to the other Google Chrome window, which means the sessions aren't stored between them. In this session, in this window, I'm not logged in. If I now try and log in, because I haven't logged out to the first one, I'm prevented from logging in and I see a session limit warning. I must go back to my first session and log out. Now that I'm logged out of the first session, I can switch back to the incognito window and I should now be able to log into the site. I'm no longer prevented from logging in. So that was the session limit module. The next module I'd like to look at is the password policy module. The password policy module allows the size administrator to apply an organization's password policy to their Drupal 7 website. Drupal 7 by default does not have a password policy as such, although you must have a password, it doesn't specify a minimum length or complexity. The password policy can be configured from the configuration menu and then password policies under people. The initial setting screen has a few options on it that are useful. The first one is the forced password change on reset so that when a user asks for a password reset when they've forgotten their password, Drupal 7's default action is to allow them to navigate the site once they follow the password reset link and they may not have reset their password. By taking this option, you can enforce that once they have forgotten their password, they are forced to reset it to a new one. In order to set a password policy, you will use the list tab at the top. This site currently has no password policies applied. We'll click to add a new one. The password policy needs a name and a description. You can then decide the roles that will apply, this policy will be applied to. So this allows you to create multiple password policies and apply different ones to different roles. We'll be applying this to the authenticated user. The expiration session allows you to specify the number of days that a user's password lasts while before it expires. So perhaps we'll set it for 90 days. In the expiration warning, we can set the number of days before the expiration date that the user will be reminded to change their password. They will receive an email for this. Under the constraints section, we'll be able to apply the password constraints which applies the policy to the passwords that people choose. There are many settings in here which can be looked at later. But some default ones are perhaps a password must have at least one digit. It must have a length of six, must contain at least one letter, and one piece of punctuation. We can also specify that the password cannot be the same as the username or cannot contain the username by setting a one in this box. The history option here allows you to specify that the password cannot be the same as the previous X number of passwords. So if you put one in there, it cannot be the same as the previous password. Now that the policy has been created, we must enable it by ticking the enable box. If you now want to ensure that all users of the site reset their password in order to abide by this policy, we can click the tab to force a password change. We can ensure that users must change their password on first time login, and we can ensure that all authentication users are told they must reset their password at their next login. If I was now logged out of the site, I should log in as the test user again. The test user is told that their password has expired and they must change it to proceed on the site. If they try and navigate away, they're brought back to the edit screen. Which is where they must reset their password. After typing in their current password, they must then type in their new password and confirm it. The password complexity settings we've put on the previous page are shown below, and these replace the standard text that Drupal ordinarily prints out here. Each of the failures of the password is displayed below. Here I've placed the same password in before, and in fact it is the same as the username. All of these things have been accounted for in the information underneath, allowing users to understand what they have done wrong with their password. This time I've put a more complex password that didn't match the previous. It does have capitals, numbers and letters and punctuation, but it does contain the username, and so the password policy module has noticed this and forbids this password. Once you've selected a good password and pressed save, the module then allows you to navigate around the site. The next module I'd like to look at is a small one called Flood Control. Drupal 7 by default has Flood Control built in. Flood Control prevents the site from being hacked via a brute force where someone knows the username and continuously tries to log in by trying different variations of the password. After a certain number of failed login attempts, Flood Control kicks in and locks that attacker out of the site and prevents them from trying to log in any further. These settings are hidden under the hood in Drupal 7 by default and the Flood Control module simply provides an easy way of accessing it. It can be found on Drupal.org under Drupal.org slash project slash flood underscore control. After logging into the site, the Flood Control settings can be found under configuration and under system Flood Control. Here are the settings. The failed login IP limit restricts the number of failed login attempts from a particular IP or network address over the course of a time window which is the default is set to one hour. The failed login username limit means that only five, in this case, only five failed logins can be provided by the same user over a six hour period. It may be that for your particular use case, your particular site, your clients and your organization, these settings aren't appropriate and the Flood Control module allows you to customize them for your particular organization's requirements. The final module we're going to look at today is the security review module. The security review module provides some simple ways of checking for misconfiguration of your websites which can cause security problems. After enabling the security review module, it can be found on Drupal.org at Drupal.org slash project slash security underscore review. After enabling the security review module, it can be very configured under the configuration menu. Sorry, the reports can be found under the reports menu and then security review. In order to review your site for the first time, you press the run checklist button and this checks your site for various common security vulnerabilities and configuration fails. Misted underneath in the report, anything red should be something you should be concerned about and something that should be corrected in order to make your site secure. One example here is errors are written to the screen. In its default configuration, Drupal will print error messages to the screen which normal users can see. Sometimes these error messages contain security, contains information which would allow an attacker to gain access to your site. By following the links through, we get to the error message configuration screen where we can then turn off these messages. If this were the live site, this is what we should be doing. If we then return to the security review page and rerun the tests and we shall see the errors written to the screen problem should now have corrected itself. The second place for looking for security vulnerabilities on your site is the standard status report script menu. This provides a variety of information across your site and anything marked as either yellow or red is something that you should look into. One of the main ones to look at is the site module information to see what modules are enabled on your site and which modules are out of date. Any listed as red will have a security patch on Drupal.org and should be updated immediately. Well, thank you for listening. That's taken me through the modules I wanted to talk about today. I'll pass back to Lauren if there are any questions. We don't have any questions just yet, so I'm going to ask a question really quickly. If you have any concerns with security as far as the features you showed us today, where can you find more information just to follow up and get a little bit more as far as detail for what you talked about? The module pages are the best place to look, I think, for particular information about the modules I've talked about today. The suqs on Drupal.org are a very good place to ask questions, so if there's not an obvious solution to the problem, if you'd ask your question on the suq for the module in question, then the maintainer should be able to get back to you and give you information on how to solve that particular problem. In terms of things like security, there's announcements from the security team, which is available from Drupal.org, that you can sign up to the mailing list there in order to get the latest security announcements. If a module you're using on your site is mentioned in the security announcements, you know that's the best time to go ahead and upgrade those modules to make sure you have the latest versions often. Awesome, it's really helpful, thank you. We have a couple of questions coming in, John. Is there a limit to how many security modules one should enable? There's no specific limits, there's no limit to anything, they're no different from any other type of module on the site. Most of the ones we covered today aren't specifically security, they're not going to improve the security of the site as such, they're more about applying organizational policy. So if the policy is that you should be logged out after an activity, which will make your site safer because if you leave your site in a session unattended, somebody else will then use it. Then things like the auto logout module and session in the modules are good things to use. So really it's about understanding your security policies, either if you're an organization or if you're an agency of the clients you're working with to make sure that you're applying the correct modules that allow those security policies to be fulfilled. Great, thank you. Next question, if you turn off the error messages, will the messages for invalid entries on web forms still be printed? Yes, so that's the kind of development error messages that we're turning off on that particular form. So it's not the same as putting a new connect field on this form. It's about printing development errors and the default configuration of Drupal 7 will print those out to the screen, so unless you do that setting within the configuration menus. You might be printing out information that the user shouldn't be seeing. Great, another question, any advice for brute force logins and spammers regularly change their IPs? Yes, that's a difficult one because the brute force logins can be seen as either spam problems or they can be seen as denial of service problems. If it's a denial of service problem, then I think you've got a bigger problem. If the website is actually being slowed down by the amount of people trying to log in, then you need to look at ways to circumvent that via improving either infrastructure or potentially putting things out like your resources out onto CDNs and the like, which better spread the load balance. In terms of trying to get away from the spammers and filling in spam forms and things like the capture module, they do things to check that the person that is trying to log into the site is an actual person. There's other modules like that, so that was capture, but there's also Honeypot is also a very good module as well, which helps to identify that the person trying to log into your site is actually a spammer and not a real person. And there's commercial offerings as well and the likes of Mollum, which can go a little bit further where they don't present a capture to start with, but if what's been filled in, for instance, if it's the comment from the Mollum will make an intelligent assessment as to whether the person who filled in is a person or not, and if they're not, they will then present them with a capture to be able to submit it. So there's a number of ways you can look into protecting your site against spam. Great, thanks John. The person that asked that question has actually a follow-up comment that says captures aren't available in the login form. I'm pretty sure you can apply the capture to the login form, so I think if you have a, I can't think of a particular resource to go too straight now, but I've definitely seen captures embedded into most forms on the site that will allow you to do that. Maybe we can look that up and put the post information up after this. Great. Awesome, so thanks John. The rest of our comments are just thank yous for sharing your advice on all these security situations and if we don't have any further questions, looks like we don't. Just a reminder, again coming up we have some programs. DrupalCon Amsterdam is this month. You can still register to attend. The information is at amsterdam2014.drupal.org. We have our Drupal level training dates the last of this year, November 14th. You can find out more about hosting or participating in some form on our website. It's again low cost or free intro to Drupal training for our newbie Drupal developers and last but not least we have a list of our webcasts coming up at association.drupal.org slash webcasts. So you can see what's coming down the pike. We're a little quiet in the rest of September. Obviously we'll be getting ready for Amsterdam and be traveling but we'll pick up back again in October and have a lot of stuff of interest for you guys. And just as a last reminder we couldn't do what we do help fund scholarships grants and servers without our organization members and individual memberships. So check out our membership page and you can see all of the information on what that entails at our link below. So thank you everyone for joining us and this will be recorded and put on YouTube in the next couple of days. Don't forget to take your survey and of course thank you John and thank you Deeson for hosting the webinar today. Thank you and have a good day.