Setuid, Setgid and Sticky Bits are special types of Unix/Linux file permission sets that permit certain users to run specific programs with elevated privileges. Ultimately the permissions that are set on a file determine what users can read, write or execute the file. Linux provides more advanced file permissions that allow you to do more specific things with a file, or directory. Typically, these file permissions are used to allow a user to do certain tasks with elevated privileges (allow them to do things they normally are not permitted to do). This is accomplished with three distinct permission settings. They are setuid, setgid, and the sticky bit.
In this article, we will denote the security best practices for 2020 and beyond. Because security is such a challenging subject for many, it often goes unheeded, and as such, many are caught unaware when an issue arises. By following these best practices, you can significantly lower your risk of being compromised by a malicious actor.
Reading Time: < 1minuteWhen using phpMyAdmin, it’s essential to have the correct user permissions to create edits/writes to the database. Otherwise insufficent permissions can lead to errors like the ones pictured below “#1044 – Access denied for user …[using password: YES]” and “#1045 – Access denied for user…[using password: YES]”. In our tutorial, we’ll show you how to correct this issue using the command line terminal. Let’s get started! Continue reading “Troubleshooting: MySQL/MariaDB Error #1044 & #1045 Access Denied for User”→
Reading Time: 6minutesWhen investigating site infections or defacing on a Windows Servers, the most common root cause is poor file security or poor configuration choices when it comes to how IIS should access file content. The easiest way to prevent this is to start with a secure site.
Setting up a website in IIS is exceedingly easy, but several of the default settings are not optimum when it comes to security or ease of management. Further, some practices that used to be considered necessary or standards are no longer or were never necessary, to begin with. As such, we recommend that you follow these steps to set up a website to ensure that it is set up correctly and securely. And while some of these setting or permission changes may seem nitpicky, they go a long way on systems that host multiple domains or multiple tenants as they prevent any cross-site file access.
Add the Site to IIS
To add a website in IIS (Internet Information Services), open up the IIS manager, right-click on Sites, and select Add Website.When adding a site to IIS, we typically recommend using the domain name as the “Sitename” for easy identification. Next, under “Physicalpath”, you will need to supply the path to where your website content is located or use the “…” to navigate to and select the folder. Configuration options under “Connectas…” and “Test Settings…” do not need to be modified.
When it comes to configuring site bindings, popular belief suggests that you should select a specific IP from the “IP address” drop dropdown; however, that is based on out of date practices typically in relation to how SSLs used to require dedicated IPs. This is no longer necessary and can actually cause issues when getting into any eplicated or highly available configuration, so it is best to leave IP addresses set to All Unassigned and type the domain name you plan to host in the “Hostname” field. Do note that you can only supply one value here; additional host names can be added after creating the site by right-clicking on the site and going to Bindings. Further, depending on your needs, you may opt to select “https” instead of “http”. To host a site with an SSL, please visit our article on the subject after setting up the site to add an SSL and configure it.
Set the Anonymous User
Technically that is all you need to do to set up a site in IIS; however, the site may or may not work, and the security settings on the site are not optimum. The next step in securing your site is to configure the IIS user that will access your files. To do this, you will need to change the associated Anonymous user and make a few security changes on the website’s content folder.
In IIS, select your new site on the left, in the main window double click on Authentication, select AnonymousAuthentication, and then click “Edit…” on the right action bar.
What is IUSR in IIS?
By default, a new site in IIS utilizes the IUSR account for accessing files. This account is a built-in shared account typically used by IIS to access file content. This means that it will use the application pool’s identity (user) to access file content.
It may be okay to leave this configured if you only plan on hosting one domain; however, when it comes to hosting multiple domains, this is not secure as it would then be possible for any site using the same account to access files from another site. As such, and as a standard practice, we recommend switching away from using the IUSR account for sites, and instead selecting “Application pool identity” and clicking OK. Alternately, you could manually create a user on the system for each site; however, then you need to manage credentials for an additional user, need to configure permissions for two users (the anonymous user and the application pool user) and possible complications with password complexity and rotation requirements your server or organization may have.
There is nothing further you need to configure in IIS in terms of security; however, for reference, let’s take a look at the application pool settings really quick. To check the settings on the application pool, in IIS, select Application Pools on the left menu, select the application pool for the site you created (typically the same name as the name of the site), and then click “Advanced Settings…” on the right action bar.
In here, the related setting is the identity, which by default is “ApplicationPoolIdentity”. This means to access file content, IIS and the associated application pool will use a hidden, dynamic user based off the name of the application pool to access files. This user has no associated password, can only be used by IIS, and only has access to files specifically granted to it. As such, it removes the requirement of managing system users and credentials.
Set Folder Permissions in IIS
Now, as mentioned, the “ApplicationPoolIdentity” user has very few permissions, so the next and last step is to ensure that the website files have proper security settings set on them. Browse through your file system and find the folder where you plan on hosting your site’s files. Right-click on the folder and go to properties. In the properties interface, select the Security tab.
By default, there are a number of security permissions set up on the folder that are unnecessary and potentially insecure (there may be more than shown here). To best secure a site, we recommend removing all but the “SYSTEM” and “Administrators” groups and adding the “ApplicationPoolIdentity” user (and possibly any other user you may require, such as an FTP user); however, to do this, you will need to disable inheritance. To do this, click on “Advanced”, then click on “Disable inheritance”.
Here you will get a popup asking if you want to copy the current settings or start with no settings. Either option can work; however, it is easier to copy the current settings and then remove the unnecessary permissions. So select “ConvertConcert inherited permissions into explicit permission on this object” and then click OK.
At this point, to remove the unnecessary permissions, click Edit and remove everything other than the “SYSTEM” and “Administrators” groups. Next, you need to add the “ApplicationPoolIdentity” user to this folder. To do this, click “Add…”. Now, depending on your server configuration, you may get a pop-up asking for you to authenticate to an active directory domain. Simply click the cancel button a few times until you get the Select Users of Groups screen shown below.
On this screen, you will want to make sure that the “Location” selected is your computer. If it is not, click “Locations…” and select your computer (should be at the top; you may also need to click cancel on some authentication windows here as well).
The “ApplicationPoolIdentity” user is a hidden user, so it is not possible to search for this user. As such, you will have to type the username to add it. The username you will need to type is “IIS AppPool\<applicationpoolname>“. Please see the following example and fill yours out accordingly:
Once you type the user name, click OK. Now that you’ve added the user, which is by default only granted read permissions, you will want to verify your security settings look similar to the following image, and then click OK.
And with that, you’re done and have a secure site ready to be viewed by the masses without needing to fear that hackers will deface it.
Securing within Powershell
As a bonus, if you’re looking to get your fingers wet with some Powershell, the steps covered in this article can also be accomplished on a Windows Server 2012 or newer server through Powershell. Simply fill out the first two variables with your domain name and the path to your content, and then run the rest of the PowerShell commands to set up the site in IIS and configure folder permissions.
Additional Notes: In some cases, sites may need additional write or modify permissions on specific files or folders for file uploads, cache files, or other content. It is important that you do not apply modified permissions to the entire site. Instead, modify specific directories or files as needed. To apply these settings, go to the file or folder that needs modification, right-click on it, and select Properties. Switch to the Security tab and click Edit. In there, select the user that has the name of the website (liquidweb.com in my example above), select modify under the Allow column, and then click OK. This will give the ApplicationPoolIdentity and IIS the ability to write to or modify the file(s) or folder(s).
Still need additional protection for your Liquid Web server? Our Server Protection packages provides a suite of security tools especially for Windows servers. You’ll get routine vulnerability scans, hardened server configurations, anti-Virus and even malware cleanup, should your site get hacked. Don’t wait another vunerable minute, check out how we can protect you.
Login errors with Microsoft SQL Server (MSSQL) are a fairly common issue and can be easily solved with some basic troubleshooting steps. Before we dig in, let’s take a look at the details of the error to try and determine the cause.
Solutions to Microsoft SQL Server Error 18456
Sometimes, the error presents as “login failed for user ‘<username>’,” this information will help us as we identify the user we need to troubleshoot. From the message, we’ll know the error number as a reference to search for next steps. In this case, it is Microsoft SQL Server, Error: 18456.
Other times, we may only see “Microsoft SQL Server Error 18456” along with the severity and state number. On its own, a state number might not mean much, yet it can offer more details as to what is wrong and where to look next.
These states of the error, 18456, are the most common. The descriptions and potential solutions offer a quick explanation and potential troubleshooting guide.
Step 1: Log In with Remote Desktop
The troubleshooting and solutions require you to login to the server or at least be able to make a Windows Authentication connection to MSSQL using Microsoft SQL Server Management Studio. The most common and easiest method is to connect directly to the server with a Remote Desktop Connection. If you need more information about Remote Desktop Connection, these Knowledge Base articles will help you get connected:
Once you are logged into the server, you’ll want to run Microsoft SQL Server Management Studio (SSMS). SSMS is the tool best suited to configure, manage, and administer MSSQL.
When you start SSMS, you will be asked to log in to the server. By default, most MSSQL servers have Windows Authentication enabled, meaning you must log in with the Windows Administrator or the account specified as the SQL Administrator when MSSQL was installed and configured.
In addition to Windows Authentication, MSSQL supports SQL Server Authentication. Depending on the version of MSSQL and how it was installed and configured, you may or may not have SQL Server Authentication enabled by default.
Step 3: Checking the Server Authentication Mode
Once we login to SSMS using Windows Authentication, we need to check the security settings to confirm whether MSSQL is set up to allow both Windows and SQL Authentication.
In SSMS, right-click the Server Name at the top of the Object Explorer window and choose Properties.
Next, click the Security page.
If you find Windows Authentication is the only mode configured, this is the likely cause of Error 18456, Login failed for user ‘<username>’.
Setting the Server authentication mode to allow SQL Server and Windows Authentication, you will be able to login to MS-SQL with a SQL user and password or a Windows user and password. After making this change, you will need to restart the SQL Server service.
Step 4: Restart the SQL Service
In SSMS, right-click the Server Name at the top of the Object Explorer window and choose Restart to apply the new authentication mode settings.
In the above example, Windows Authentication mode was the only mode configured, and the Error 18456 occurred because the user ‘sa’ is a SQL user and SQL Server Authentication was not permitted.
Step 5: Checking SQL User Permissions
As we check the SQL user permissions, we need to answer the following questions:
Is the user allowed to log in?
Does the user have a valid password set up?
Does the user have the needed permissions for access to the desired database?
In SSMS Object Explorer, expand Security, Logins. Locate the user that was failing to log in. A redx on the user indicates this user has login disabled.
To allow the user to login, right-click the user and choose Properties, then click the Status page. Enabling login for the user and click OK.
After refreshing the list user logins, we can confirm the user no longer has a red x present. This should allow the user to log in. In this example, the SQL user ‘sa’ failed to log in because there was no permission to log in.
Continuing with user troubleshooting, right-click the user and choose Properties, then click the General page. Here you can enter a new password and then enter the confirmation password. Click OK to save the new password. We set a new password for the user so that we are certain of the password when we attempt to log in.
Step 6: Mapping the User to the Database
Our last step in troubleshooting a user is to check user mapping to verify the user has access to the desired database and to set or verify their role for the database. Right-click the user and choose Properties, then click the User Mapping page. Select the Database from the list of databases. From the database role memberships, select the desired/required memberships. Click OK.
In this example, we mapped the user ‘ProdX709’ to the database Production X709.2019 and granted them database role db_owner. In many cases, you only need a user to have db_datareader and db_datawriter roles to be able to read and write to the database.
In this troubleshooting article, we learned how to identify specifics of Error 18456 to help us track down the root cause of the issue. Still looking for support? Our MSSQL database solutions come with assistance from our technical support team. Find out how our high-availability database can work for you!
Kubernetes Role-Based Access Control or the (RBAC) system describes how we define different permission levels of unique, validated users or groups in a cluster. It uses granular permission sets defined within a .yaml file to allow access to specific resources and operations.
Starting with Kubernetes 1.6, RBAC is enabled by default and users start with no permissions, and as such, permissions must be explicitly granted by an admin to a specific service or resource. These policies are crucial for effectively securing your cluster. They permit us to specify what types of actions are allowed, depending on the user’s role and their function within the organization.
Reading Time: 4minutesThe most common way to remotely manage a Windows server is through Remote Desktop Protocol. By default, Liquid Web’s Windows servers only allow the members of the administrators’ group remote desktop access. However, the Remote Desktop Users group grants its members access to securely connect to the server through RDP (Remote Desktop Protocol) as well.
This article will go over the basics of the Remote Desktop Users group. By the end, you will be able to add users to the group, understand permissions, and basic user management.
The information below covers methods to configure the Remote Desktop Users group for Windows Server 2012 through Windows Server 2016 on any Liquid Web Windows server. As a valued customer, if you do not feel comfortable performing these steps independently, please contact our support team for additional assistance. Liquid Web support is happy to walk you through the steps and answer any questions you may have.
Managing Local Users and Groups
Users and groups on Windows servers are managed in a number of different ways, but the most user-friendly way is through the Local Users and Groups interface. There are several ways to open the interface. However, the easiest is to run “lusrmgr.msc”. Lusrmgr.msc can be launched by searching the start menu, command line, or through a run dialog. These methods allow you to find users and groups easily.
To manage local users and groups, you will need to be logged in with a user that has the proper permissions to do so. This is most commonly a user that is already a member of the Administrators group.
Once you open the Local Users and Groups interface, you will see two folders on the left, one for Users, and one for Groups. By selecting Users, you will see a full list of local users on the server. You can also see a variety of related tasks by right-clicking Users, Groups, a user’s name, or a blank area of the middle pane.
There are several ways to add a new user through the Local Users and Groups interface. These methods all result in the same “New User” dialog box opening where you can then configure a Username, Password, and other options. Choose one of the options below to create a new user:
With the Users folder selected in the left pane, click the Action menu, then select “New User…”.
With the Users folder selected in the left pane, click “More Actions” from the right- hand pane, then select “New User…”.
Right-click the Users folder, then select “New User…”.
With the Users folder selected in the left pane, right-click in a blank area of the middle page, then select “New User…”.
Once you have created a new user, or have identified the username of the existing user, you are ready to assign that user to a Group. Users assigned to a group are known as group members.
As with user management, group management can also be performed in several ways. The options below cover several of the most common ways to assign a new member to the Remote Desktop Users group:
Select the Users folder from the left pane of the Local Users and Groups interface, open the Users Properties window by double-clicking the user, select the “Member Of” tab, then click “Add…”. Now type “Remote Desktop Users” in the text box and click OK.
Select the Groups folder from the left pane of the Local Users and Groups interface, double-click the “Remote Desktop Users” group, click “Add…”, enter the user’s name in the text box and click OK.
Open the system settings by right-clicking the start menu and selecting “System”, choose “Advanced system settings”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
Open the “Server Manager”, select “Local Server” from the left pane, click the blue text next to “Computer Name”, select the “Remote” tab, click the “Select Users…” button then click the “Add” button. Now enter the user’s name in the text box and click OK.
When selecting users or groups, it is recommended to click the “Check Names” button after typing in the user or group name. If the name is underlined after clicking the “Check Names” button, then the name was identified correctly.
You can also use the “Advanced…” button when selecting users or groups instead of typing its name. Clicking the “Advanced…” button followed by the “Find Now” button will result in a list of users to select.
Notes on Permissions & Security
By default, there are no members of the Remote Desktop Users group and only members of the Administrators group are allowed to connect through RDP. Members added to the Remote Desktop Users group are considered non-Administrative users. These users will be unable to perform most management tasks such as installing software, managing IIS, or rebooting the server.
If a user requires management abilities, the user will need explicit access to that task or will need to be a member of the Administrators. Please use the best practice of “least privilege” when configuring your users, groups, and permissions.
Test/Verify Group Membership
When configuring new user and group memberships, you should always review group membership once complete. Reviewing group membership is most commonly performed through the Local Users and Groups interface. In addition to verifying membership, we also recommend attempting a remote desktop connection with your newest Remote Desktop Users group member. If you are unable to connect with your user, please see our Remote Desktop Troubleshooting article.
Once you have logged in with your newest member of the Remote Desktop Users group, you can further verify that groups are set up correctly by running the command “whoami /groups” from a command line. The output of this command lists the username and its associated Group names.
This tutorial assumes you’ve already logged in to cPanel’s File Manager
To change the permissions of a file, select it first. Single click on “testfile.html”.
Click on Change Permissions.
You will see a popup window with some checkboxes. Let’s understand this window first.
There are three type of owners of the file.
User – means you.
Group – the users from your website, who have access to these files.
World – end users who access your site via a web browser.
These are read, write and execute options. Each row give access to read, write and execute files.
In this case, User will have access to read and write this file.
Group will have only read access.
And World will have Read access only.
Please note that unless any particular script needs special permissions, a file should always have 644 permissions, and a Folder should always have 755 permissions.
To set 755 permissions, just check the boxes appropriately.
Now click on Change Permissions to apply these changes.