Symbolic link

Symbolic links are files that points to another file or directory. It is also called symlink or soft link. It is simply a pointer to the original directory. As a system administrator, we need to have a good understanding of these symlink and its working.  In this blog we will see simulating different situations around symbolic link and how things work.

Create symlink

Symlink can be created using ln command as shown below, 

#ln -s orginal_directory_path symlink_filename

1.1 Create symlink

We can identify if a file is just a regular file or symlink by looking at the "ls -ltr" command output, where we see "l" in first place in the permission column - which denotes link. 

1.2 List symlink

We can also compare the inodes of both original and symlink to see if both are same and it should be same. 

1.3 Inode for files

When we create or change anything inside the symlink, it will reflect in source/original directory.

Let's try creating and deleting files inside of the symlink to demonstrate same. 

1.4 Create files under symlink

1.5 Delete files under symlink

Now we are quite clear that contents of symlink are same as the original directory and any change will impact both destination.

Let's now take it further to change the symlink file itself and see what will happen.

Remove symlink

We can remove a symlink we can use "rm" or "unlink" command. however when using rm command ensure you are not using / in the end as it will remove the contents instead of removing the symlink file.

1.6 Remove symlink with rm command

1.7 Remove symlink with unlink command

Notice that when we try / in the end using unlink comamnd it will throw error saying not a directory, however when we use it with rm it will delete contents. Its always safe to use unlink command to delete a symlink rather than rm comamnd to avoid accidently removing the original files.

1.8 Remove original file

However when we remove the original file tagged to the symlink, will break the symlink to work as shown above. 

Symlink allows us to be created in a different filesystem, in this example i have created symlink in a different mount /data whereas the source directory exist in the /home directory. 

1.9 Filesystem structure used in this blog

Update symlink

What if we renamed the original directory, let's explore now. 

When we rename the original directory the symlink becomes unusable the referenced pointer is no longer exist as it is moved to a different. however all the files are still available in the original directory in the moved place and to access them we can directly go to the original directory using the moved path. 

 

1.10 Rename original directory

Now to fix this, we need to update the symlink file, this is simply run the symlink command with force option to remove the existing symlink file and create new symlink file with new destination. 

#ln -sf /original_directory symbolic_link_file 

1.11 Update symlink path

Now everything looks back normal. 

Linux User SSH Access Control

Technology growth is rapid, implementing solutions without proper restriction would cause data leak, cyberattacks. First line of defence for any solution would be its users. Granting granular privilege and role based access is one of the critical task that should be implemented.

SSH is Secure SHELL protocol works on port 22. In Linux, Users over remote connect to administer and manage daily activities on the server. There are multiple security ways of handling user access. In this blog I will be writing how we will restrict SSH access to server. 

Create a Group in Linux that will contain all the users who will be provided SSH access to the server. 

#groupadd ssh-users

You can also specify a group id for this group and maintain it across your environment to manage it with config automation tools like ansible and others in a large scale in future. 

#groupadd -g 3000 ssh-users

Create user and add to the ssh-users group 

# useradd -c "SSH Allowed user" -m -d /home/karthick -s /bin/bash -aG ssh-users karthick 

where, 

-c is comment for a administrator to identify what user or a brief about the user. 

-d is mention home directory of the user 

-s is login shell that the user will be using. 

-a is to append user to the mentioned group

-G is to add user to the secondary groups mentioned.

SSH Restriction

Edit the sshd_config file under /etc/ssh/sshd and add the following line in the end.

AllowGroups ssh-users

Restart the sshd service. 

#systemctl restart sshd

Now, ssh will be restricted to all users, except for those who are added in this ssh-users group.

Ansible Automation

I have written a sample ansible play to automate these tasks in my git - SSH-Restriction

Best Practices: 

Never allow any Privileged/Admin accounts Remote SSH Access.

Always provide SSH access to normal user and then allow sudo escalation or su to privileged user with password. 

References:

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html

OS: 

RHEL, SUSE Linux, Centos

Privilege escalation with sudo

Privilege escalation with sudo

Normal user in Linux can be allowed to execute privileged commands with sudo rights.

Sudoers configuration file is /etc/sudoers, however editing this file directly is not advisable either you can use visudo to edit this file or create a template file under /etc/sudoers.d. 

I would suggest use template file under /etc/sudoers.d which will be more easier to manage multiple user privileges and it can me efficient in managing granular access. 

Syntax - Who Where = (Runas-Who:group) What_Commands

Who - which user you want to give sudo rights/privilege.

where - In what server you want to grant the user access to execute mentioned commands.

Runas-Who:group - As which user will the user execute the granted commands. 

What_commands - Finally the commands that you want to provide access to user for executing. 

User Shiva is a normal user here and he is now allowed to list the repositories on the server without providing root password. 

NOPSSWD directive may be a security issue as it will not ask for a password when elevating privilege to execute the command. 

To over come this security issue you may use the line "defaults     !targetpw" - This will ask for the users password when elevating privilege.

Example: 

# visudo /etc/sudoers.d/shiva

defaults !targetpw

shiva ALL = (ALL:ALL) /usr/sbin/yum repolist

You can also enforce asking for root users password when elevating privilege. 

"defaults targetpw" 

Best practice:

Edit sudoers file with visudo which will validate the content when exiting and if anything wrong in the format it will show you error and you can edit the file to fix the issues. 

While editing the sudoers template, ensure you have two session opened with root rights and let one session be running with TOP command. After implementing sudoers config make sure that sudo command is working without any problem on a new session and then you can terminate the top command and its session. It would be helpful if the sudoers went wrong and you are locked out of root. 

This situation can occur when you have wrong sudo file and there is no root user login allowed directly. 

To validate the sudoers configuration you created using visudo -vf %s if it is formatted correctly