Scribd
Upload
20 views9 pages

1-SELinux - SSH Key Based Authentication

Uploaded by

Mostafa Elrashidy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
20 views9 pages

1-SELinux - SSH Key Based Authentication

Uploaded by

Mostafa Elrashidy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

SElinux:

It will tell us which application have which type of access and user used to which
directories in our computers.

We use SElinux if our server is connected to the internet to avoid attacks but if we
are in our data center and the server is protected we do not have to use it.

Protection from Users and Services from any security risk. SELinux Depends on
Mandatory access control (MAC). SELinux implemented in the kernel.

SElinux modes and policies:


1. System calls are sent to the SELinux
2. If the service is enables it will run perfect and check the policy, if it is denied by
the SElinux policy.
3. The service is logged by the auditd service which is in /etc/audit/auditd.conf and
written to /var/log/audit/audit.log
4. If SElinux in the Enforcing mode it will deny the service and write in the auditd
but if SEliux in permissive mode it will run the service and audit in the log file.
5. Disable mode will disable the SElinux service and the auditd service.

Note: to move from disabled mode to either Permissive or enforcing mode you
have to restart the machine and vice versa.

Understanding SElinux modes and policies:


To edit SElinux we use it file in /etc/sysconfig/selinux it is softlink to
/etc/selinux/config

[root@server ~]#getenforce ==> tell me the mode SELinux Mode


[root@server ~]#sestatus
[root@server ~]#setenforce ==> it will change the mode (1 for enforcing, 0 for
permissive)

We toggle between enforce and permissive for troubleshooting mode because


when we start service like FTP may be the problem with the SElinux or the FTP
Server, the same for the webserver.

Everything in the RHEL have security context (label).

It is composed of subject and object where subject can be (users or services) trying
to access object (files, folders, ports and sockets).

The context protects process, file and ports form any change not match with the
policy set.

[root@server ~]#ls –Z /var/www/html/web1.html ==> to display file context


[root@server ~]#ps –auxZ | grep httpd ==> to display process httpd context
[root@server ~]#netstat –utlpnZ | grep httpd ==> display the port number and its
security context it match the process that we access.

Context consist of 3 parts on (files, folders, process and ports)


1. User part
2. Role part
3. Type part
User Section:
1. file or directory: system_u
2. Process: system_u
3. Port: system_u

Role Section:
1. file or directory: object_r
2. Process: system_r
3. Port: system_r

Type:
1. file or directory: httd_sys_content_t
2. Process: httpd_t
3. Port: httpd_t

Note: any change in the above the context, that is means the policy do not match
and the service will break down. The service protects itself with context and the
files in the directories inherit this context form the directory.

Note: each service have its own context on the system, so to let service access the
other service we must make policy. Any service components (files, process and
port)

To set context we have semanage utility:


This utility make changes on the SEliunx policy then to the file system
Semanage ===> policy ===> file system
Restorecon ===> file system
So semanage ===> restorecon ===> file system

[root@server ~]#semanage --help

port ==> Manage network port type definitions


fcontext ==> Manage file context mapping definitions
boolean ==> Manage Booleans to selectively enable functionality

[root@server ~]#man semanage ==> man page for semanage


[root@server ~]#man semanage-fcontext ==> it makes redirection to each option
in man pages. here we can find examples for files we can also copy and paste the
example as we need it.
Using File system labels:
In RHEL 8 the context must be generated from semanage, in RHEL 6 the context
already available.

It is a very nice utility when something goes wrong because it check the context of
the directory and make sure that it matches the policy.

To modify the context, we need to know which context we should use easy
solution see the configuration of service because there is many contexts.

[root@server ~]#semanage fcontext –l | less ==> will display all contexts of the
system.
[root@server ~]# semanage fcontext –l | grep httpd

[root@server ~]#semanage fcontext -a add -t type /directory


[root@server ~]#restorecon -R recursive -v verbous /directory

Analyzing Selinux log files:


[root@server ~]#systemctl status auditd ==> it is working fine
[root@server ~]#less /var/log/messages ==> log file of service
[root@server ~]#less /var/log/audit/audit.log

Configuring SElinux for sshd:


Editing in the sshd Service port number:
[root@srv1 ~]# vim /etc/ssh/sshd_config ==> ssh configuration file
Restarting SShd Service:

View the Content of the log file:

SELinux Message Content:


[root@srv1 ~]# sealert -l 3b0127ce-9c3e-41ae-808c-75189fe18c46
sshd service port addition with SElinux:

Verify the configuration:

Restarting the sshd service:

Add the port to the Firewall from the machine consol:

Login with the new port:

Using Port Forwarding:


Disable Root Login to sshd service:

[root@srv1 ~]# vim /etc/ssh/sshd_config

[root@srv1 ~]# systemctl restart sshd

sshd service architecture:


1. Server needs to prove its identity because it is part of security to avoid man in
the middle attacks.
2. client initiate request to the server so the server listens to port 22
3. server send its public key which is saved in /etc/ssh/ssh_host_rsa_key.pub
4. server ask me are you sure that you want to connect if yes → The server 's
public key in the users 's and finger print ~/.ssh/known_hosts file.
5. server asked for password
To show the server fingerprint, it is found in .ssh/known_hosts

Note: fingerprint is found when we connect from the client to the server, it will ask
me to save the fingerprint on my client machine, this is the server public key.

The server private key is found in:

public and private key can be used in another way in ssh user can use them instead
of password:
1. At the client side ssh [email protected] → user has its private key that is
saved at ~/user1/.ssh/id_rsa message sent with the private key.

2. At the server side /home/user1/.ssh/id_rsa.pub sent to client then a mathematical


operation is done to authenticate with public key so user1 is authenticated.

Key Based Authentication:


It asks for password but someone can get your password so to be more secure ,
your key based authentication private key stored locally & public key stored on the
server and when connection authenticate token signed with private key, if matched
with public key then you are authenticated.
Note:
passphrase: we use it when we are using private key to protect private key
id_rsa → private key
id_rsa.pub → public key

To copy the Public key to the server:

Try to Login to the system:

You might also like