Best Practices for Security on Your New Ubuntu Server: Users, Console and Firewall

Reading Time: 4 minutes

Thank you for taking the time to review this important information. You will find this guide broken down into six major sections that coincide with Ubuntu’s security policy guide. The major topics we talk on throughout these articles are as follows:

User Management

User management is one of the most important aspects of any security plan. Balancing your users’ access requirements against their everyday needs, versus the overall security of the server will demand a clear view of those goals to ensure users have the tools they need to get the job done as well as protect the other users’ privacy and confidentiality. We have three types or levels of user access:

  1. Root: This is the main administrator of the server. The root account has full access to everything on the server.  The root user can lock down or, loosen users roles, set file permissions, and ownership, limit folder access, install and remove services or applications, repartition drives and essentially modify any area of the server’s infrastructure. The phrase “with great power comes great responsibility” comes to mind in reference to the root user.
  2. A sudoer (user): This is a user who has been granted special access to a Linux application called sudo.  The “sudoer” user has elevated rights to run a function or program as another user. This user will be included in a specific user group called the sudo group. The rules this user has access to are defined within the “visudo” file which defines and limits their access and can only be initially modified by the root user.
  3. A user: This is a regular user who has been set up using the adduser command, given access to and, who owns the files and folders within the user /home/user/ directory as defined by the basic settings in the /etc/skel/.profile file.

Linux can add an extreme level of granularity to defined user security levels. This allows for the server’s (root user) administrator to outline and delineate as many roles and user types as needed to meet the requirements set forth by the server owner and its assigned task.

 

Enforce Strong Passwords

Because passwords are one of the mainstays in the user’s security arsenal, enforcing strong passwords are a must. In order to enact this guideline, we can modify the file responsible for this setting located here:  /etc/pam.d/common-password.

To enact this guideline, we can modify the file responsible for this setting by using the ‘chage’ command:

chage -m 90 username

This command simply states that the user’s password must be changed every 90 days.

/lib/security/$ISA/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-2 dcredit=-2 ocredit=-1

 

Restrict Use of Old Passwords

Open ‘/etc/pam.d/common-password‘ file under Ubuntu/Debian/Linux Mint.
vi /etc/pam.d/common-passwordAdd the following line to ‘auth‘ section.

auth        sufficient  pam_unix.so likeauth nullok

Add the following line to ‘password‘ section to disallow a user from re-using last five of his or her passwords.

sufficient    pam_unix.so nullok use_authtok md5 shadow remember=5Only the last five passwords are remembered by the server. If you tried to use any of five old passwords, you would get an error like:
Password has been already used. Choose another.

 

Checking Accounts for Empty Passwords

Any account having an empty password means its opened for unauthorized access to anyone on the web and it’s a part of security within a Linux server. So, you must make sure all accounts have strong passwords, and no one has any authorized access. Empty password accounts are security risks, and that can be easily hackable. To check if there were any accounts with an empty password, use the following command.

cat /etc/shadow | awk -F: '($2==""){print $1}'

 

What is Console Security?

Console security simply implies that limiting access to the physical server itself is key to ensuring that only those with the proper access can reach the server. Anyone who has access to the server can gain entry to the server, reboot it, remove hard drives, disconnect cables or even power down the server! To curtail malicious actors with harmful intent, we can make sure that servers are kept in a secure location. Another step we can take is to disable the Ctrl+Alt+Delete function. To accomplish this run the following commands:

systemctl mask ctrl-alt-del.target
systemctl daemon-reload
This forces attackers to take more drastic measures to access the server and also limits accidental reboots.

What is UFW?

UFW is simply a front end for a program called iptables which is the actual firewall itself and, UFW provides an easy means to set up and design the needed protection. Ubuntu provides a default firewall frontend called UFW (Uncomplicated firewall). This is another line of defense to keep unwanted or malicious traffic from actually breaching the internal processes of the server.

 

Firewall Logs

The firewall log is a log file which creates and stores information about attempts and other connections to the server. Monitoring these logs for unusual activity and/or attempts to access the server maliciously will aid in securing the server.

When using UFW, you can enable logging by entering the following command in a terminal:

ufw logging on

To disable logging, simply run the following command:

ufw logging off

To learn more about firewalls, visit our Knowledge Base articles.

We’ve covered the importance of passwords, user roles, console security and firewalls all of which are imperative to protecting your Linux server. Let’s continue onto the next article where we’ll cover AppArmor, certificates, eCryptfs and Encrypted LVM.

 

Kubernetes RBAC Authorization

Reading Time: 4 minutes

What is RBAC?

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.

Prerequisites for using Role-Based Access Control

To take advantage of RBAC, you must allow a user the ability to create roles by running the following command:

root@test:~# kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole cluster-admin --user

Afterwards, to start a cluster with RBAC enabled, we would use the flag:

--authorization-mode=RBAC

 

The RBAC Model

Basically, the RBAC model is based on three components; Roles, ClusterRoles and Subjects. All k8s clusters create a default set of ClusterRoles, representing common divisions that users can be placed within.

The “edit” role lets users perform basic actions like deploying pods.
The “view” lets users review specific resources that are non-sensitive.
The “admin” role lets a user manage a namespace.
The “cluster-admin” allows access to administer a cluster.

Roles

A Role consists of rules that define a set of permissions for a resource type. Because there is no default deny rules, a Role can only be used to add access to resources within a single virtual cluster. An example would look something like this:

kind: Role
apiVersion: rbac.authorization.domain.com/home
metadata:
namespace: testdev
name: dev1
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"] verbs: ["get", "watch", "list"]

In this case, the role defines that a user (dev1) can use the “get”, “watch” or “list” commands for a set of pods in the “testdev” namespace.

ClusterRoles

A ClusterRole can be used to grant the same permissions as a Role but, because they are cluster-scoped, they can also be used to grant wider access to:

  • cluster-scoped resources (like nodes)
  • non-resource endpoints (like a folder named “/test”)
  • namespaced resources (like pods) in and across all namespaces. We would need to run kubectl get pods --all-namespaces

It contains rules that define a set of permissions across resources like nodes or pods.
An example would look something like this:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]

The default ClusterRole command looks like this:

root@test:~# kubectl create clusterrole [Options]

A command line example to create a ClusterRole named “pod“, that allows a user to perform “get“, “watch” and “list” on a pod would be:

root@test:~# kubectl create clusterrole pod --verb=get,list,watch --resource=pod

 

RoleBinding

A RoleBinding is a set of configuration rules that designate a permission set. It binds a role to subjects (Subjects are simply users, a group of users or service accounts). Those permissions can be set for a single namespace (virtual cluster), with a RoleBinding or, cluster-wide with a ClusterRoleBinding.A RoleBinding is a set of config rules that designate a permission set.

Let’s allow the group “devops1” the ability to modify the resources in the “testdev” namespace:

root@test:~# kubectl create rolebinding devops1 --clusterrole=edit --group=devops1 --namespace=dev rolebinding "devops1" created

Because we used a RoleBinding, these functions only apply within the RoleBinding’s namespace. In this case, a user within the “devops1” group can view resources in the “testdev” namespace but not in a different namespace.

ClusterRoleBindings

A ClusterRoleBinding defines which users have permissions to access which ClusterRoles. Because a “role” contains rules that represent a set of permissions, ClusterRoleBindings extend the defined permissions for:

  • unique namespace in resources like nodes
  • resources in all namespaces in a cluster
  • undefined resource endpoints like ”/foldernames”

The default ClusterRoles (admin, edit, view) can be created using the command:

root@test:~# kubectl create clusterrolebinding [options]

An example of creating a ClusterRoleBinding for user1, user2,and group1 using the cluster-admin ClusterRole

root@test:~# kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

 

ConfigMaps

What is a configMap?

A configMap is a resource that easily attaches configuration data to a pod. The information that is stored in a ConfigMap is used to separate config data from other content to keep images/pods portable.

How Do I Create A ConfigMap?

To create a configmap, we simply use the command:
kubectl create configmap <map-name> <data-source>

Let’s create a default.yaml file to create a ConfigMap:
kubectl create -f default.yaml /configmaps/location/basic.yaml

Basic RBAC Commands For Kubectl

Note
These commands will give errors if RBAC isn’t configured correctly.

kubectl get roles
kubectl get rolebindings
kubectl get clusterroles
kubectl get clusterrolebindings
kubectl get clusterrole system:node -o yaml

 

Namespaces

Namespaces are used to define, separate and identify a cluster of resources among a large number of users or spaces. You should only use namespaces when you have a very diverse set of clusters, locations or users. They are used in settings where companies have multiple users or teams that are spread across various projects, locations or departments. A Namespaces also provides a way to prevent naming conflicts across a wide array of clusters.
Inside a Namespace, an object can be identified by a shorter name like ‘cluster1’ or it can be as complex as ‘US.MI.LAN.DC2.S1.R13.K5.ProdCluster1’ but, there can only be a single ‘cluster1’ or a ‘US.MI.LAN.DC2.S1.R13.K5.ProdCluster1’ inside of that namespace. So, the names of resources within a namespace must be unique but, not spanning namespaces. You could have several namespaces which are different, and they can all contain a single ‘cluster1’ object.

You can get a list of namespaces in a cluster by using this command:

root@test:~# kubectl get namespaces
NAME STATUS AGE
cluster2dev Active 1d
cluster2prod Active 4d
cluster3dev Active 2w
cluster3prod Active 4d

Kubernetes always starts with three basic namespaces:

  • default: This is the default namespace for objects that have no specifically identified namespace (eg. the big barrel o’ fun).
  • kube-system: This is the default namespace for objects generated by the Kubernetes system itself.
  • kube-public: This namespace is created automatically and is world readable by everyone. This namespace is primarily reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.

Finally, the essential concept of role-based access control (RBAC) is to ensure that users who require specific access to a resource can be assigned to those Roles, Clusterroles, and ClusterRolebindings as needed or desired. The granularity of these permission sets is structured and enabled to allow for increased security, ease of security policy modification, simplified security auditing, increased productivity (RBAC cuts down on onboarding time for new employees). Lastly, RBAC allows for increased cost reduction via removing unneeded applications and licensing costs for less used applications. All in all, RBAC is a needed addition to secure your Kubernetes infrastructure.

Ready to Learn More?

Reach out to one of our Solutions team via chat to decide if a Private Cloud service from Liquid Web will meet your Kubernetes needs!

How To Remove a User from a MySQL Database in cPanel

Reading Time: 1 minute

This tutorial assumes you’ve already logged in to cPanel, and are starting on the home screen.  Let’s learn how to remove a user from a database.

  1. Click the “MySQL Databases” icon.cpanel-pl-mysql-7-removeuser-02
  2. In the table of databases, locate the database you wish to remove a user from, locate the specific user assigned to that database that you want to remove and click the delete icon.cpanel-pl-mysql-7-removeuser-04
  3. Click “Revoke User Privileges from Database” to confirm.cpanel-pl-mysql-7-removeuser-05
  4. That’s it! The user has been removed from the database.cpanel-pl-mysql-7-removeuser-06
  5. The user hasn’t been deleted … you can see it’s still listed in the list of current users. It has simply been removed from that database.cpanel-pl-mysql-7-removeuser-07