Protect Boot & Single user mode

as a physical security is main factor in our security prospective

we all need to to protect unauthorised access to our linux box after we protect bios

and we all know that anyone can rest the root password via accessing the single mode

so we have 3 ways 1st thing to disable single use mode entirely  2nd adding a password 3rd encrypt the disk with luks

single use mode configuration located under /etc/sysconfig/init

the last line of the init configuration instruct the user shell for single user mode

sushell  this shell allow access with full root privilege  we can change the shell type to control the single user mode

if we sit it /sbin/nologin no single user mode will be activated on the boot and the machine will continue booting to default run level ūüėČ

we can set it to sulogin to make boot asks for root password before it continue to give a full root access

 

we can add more password layer for grub configuration via adding password –encrypt HASH from grub-crypt command

one important thing attacker can manipulate boot start services by pressing (i) in the boot sequence

attacker can disable any running service  example i disabled iptables in the boot ūüėÄ

Screen Shot 2015-08-17 at 3.32.33 AM

we can protect from this disaster by disable hot keys in /etc/sysconfig/init

protect console from reboot via ctrl-alt-delete

attacker can press ctrl-alt-delete to your machine to make it reboot

to disable it we need to change behaviour of this intercept in /etc/init/control-alt-delete.conf

by add comment to the exec line to disable reboot

SSH Tunnelling

the most famous method is using D parameter in ssh connection to bind a port local in your machine and this port tunnel back to our remotebox
to send our traffic to this server

example

then you can configure your application and browser to use the your local ip 127.0.0.1 with the port 1337 to send traffic to the remote server

this is the traditional tunnelling way

lets make bigger scenario

lets assume that we have access to box with 2 interfaces
first interface with public ip and second one with internal private lan

the public ip 41.x.x.x
the private lan ip 192.168.0.10

inside the private lan machine with ip 192.168.0.20 and running ssh service and we want to connect to this machine
its impossible to connect to it from outside without tunnelling

lets do some tunnel magic

from our box to the remote box we will do ssh
OURBOX ==SSH==> 41.x.x.x
inside the remote box we will tunnel back to our machine

this will open port 1337 in the OURBOX this port redirect to 192.168.0.20 machine in port 22

REMOTEBOX ==SSH+LOCAL FORWARD==>OURBOX

this ssh connection will lead u to the 192.168.0.20:22

sometimes you may need to skip ssh host verification as you connect to your local machine via this ssh option parameters UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

also this method could be use to bind to your internal ip to send ssh server back to better administration with vim also it possible to forward X via this tunnelling method

 

example scenario

our client don’t have public ip and writing commands in teamviewer is very silly thing

so we ask our client to connect back to our machine

after client log in inside our machine we can connect to our client ssh via

 

Happy Tunnelling

 

Secure/Lock accounts with PAM tally2

pam_tally2 is a PAM module to allow interaction in users interface on numbers of failed login attempt it can can reset count on success, can deny access if too many attempts fail.

this module is unique because it  not just reflect remote connection but also reflect the ttys and any system login method as it use PAM

example from tty:

 

some parameters

  1. deny used to block access of numbers of failed attempts
  2. unlock_time used to to set a time duration for blocked access in seconds
  3. even_deny_root root is excluded by default, you set this parameter to tell tally2 count for root too
  4. root_unlock_time same as unlock_time but  for root only

 

example PAM config:

 

to reflect the tty access we have to configure our tally2 module in /etc/pam.d/system-auth

 

here is our final layout for system auth

to reflect the  remote connections  that use password example sshd

we config our /etc/pam.d/password-auth with tally

 

notice that we have done 2 things  one in auth interface that verify the account and 2nd one in the account interface to reflect the permissions of the account

 

here is the  some output of /var/log/secure

 

as you see tally2 kills the connection ūüôā

for manual interaction with tally2 counter

there is a command called pam_tally2

to remove a counter failures

 

 

password policy with pam_cracklib

cracklib pam module is method to check the password against dictionary list and gives you availability to check the strength of the password and set rules to identify the poor passwords

 

here is the most important parameters for this module

  1.  minlen minimal password length
  2. dcredit maximum number of digits
  3. ucredit maximum upper case letters
  4. lcredit maximum lower case letters
  5. ocredit maximum other letters not similer to the old one
  6. maxrepeat limit repeated letters
  7. reject_username check if the username inside the password to avoid this week accounts bob/bob or bob/bob123
  8. enforce_for_root this is the most important one , why ? , because if you didn’t apply it users will just notice the warrning and whatever password will be applied with the parameter will force the use to use our policy ūüėČ
  9. dicpath set crack lib dictionary to specific passwords database base i recommend (rockyyou) database coz it contains many leaked passwords and used by  many attackers to bruteforce the system example dicpath=/var/wordlist/rockyyou.txt

 

time to deploy our password policy

we want to apply this for new password also we can force the users to update their passwords once they do login via this command

this command  have high impact  it will find all users with bash shell and  force them to update the password even the root  u can exclude the root by piping the output from grep and use grep -v root

example result

we will use the passwd module inside /etc/pam.d/passwd

to add our new policy

 

here is the output of different failed password change

BAD PASSWORD: is too similar to the old one
BAD PASSWORD: it is based on a dictionary word
BAD PASSWORD: it is based on a (reversed) dictionary word
BAD PASSWORD: it is too short

 

 

Pluggable Authentication Modules

Linux comes with a Pam Modules to help you to interact with the running services in hardening way and custom the services security to much your need.

PAM is extra Rules to Control user interfaces ( Auth,Account,Session)  layers for the applications

the applications/services should be compiled with libpam.so

here is example for sshd service

Continue reading Pluggable Authentication Modules