Managing Users and Authentication

Managing Users and Authentication

When it comes to security of users and authentication often Linux Admins can overlook and invoke a big security hole. Check the system for unused and unlocked user accounts on a regular basis, and set passwords on any accounts that aren't protected. Make sure that no non-root user accounts have the user ID of 0.

When you install software like oracle or any other software that creates a default user account and password, be sure to change the vendor's default password immediately. A centralized user authentication method (such as OpenLDAP or other LDAP implementations) can help to simplify user authentication and management tasks, which might help to lower the risk of unused accounts or accounts with null passwords.

To tell exactly who has performed a privileged administrative action, set up the system so it is not possible to log in directly as root. Instead, all administrators should log in to the system first as a named user and then use the su or sudo commands to perform tasks as root. To prevent users from logging in as root directly, edit the /etc/passwd file, changing the shell from /bin/bash to /sbin/nologin. Modify the /etc/sudoers file using visudo to grant specific users authority to perform administrative tasks.

Oracle Linux supports PAM, which makes it easier to enforce strong user authentication and password policies, including password complexity, length, age, expiration rules. PAM also prevents the use of previous passwords. It can be configured to block user access after too many failed login attempts, after normal working hours, or if too many concurrent sessions are opened. PAM is highly customizable by adding different modules, and you can add external password integrity checkers to test password strength.

Linux NTPD - Network Time Protocol (NTP) daemon

Linux NTPD  - Network Time Protocol (NTP) daemon

SYNOPSIS
       ntpd [ -46aAbdDgLnNqx ] [ -c conffile ] [ -f driftfile ] [ -i jaildir ] [ -k keyfile ] [ -l logfile ] [ -p pidfile ] [ -P priority ] [ -r broad-
       castdelay ] [ -s statsdir ] [ -t key ] [ -u user[:group] ] [ -v variable ] [ -V variable ]

DESCRIPTION

       The ntpd program is an operating system daemon which sets and maintains the system time of  day  in  synchronism  with  Internet  standard  time  servers. It is a complete implementation of the Network Time Protocol (NTP) version 4, but also retains compatibility with version 3, as defined
       by RFC-1305, and version 1 and 2, as defined by RFC-1059 and RFC-1119, respectively. ntpd does most computations in 64-bit floating point arith- metic  and  does  relatively clumsy 64-bit fixed point operations only when necessary to preserve the ultimate precision, about 232 picoseconds.
       While the ultimate precision is not achievable with ordinary workstations and networks of today, it may be required with  future  gigahertz  CPU  clocks and gigabit LANs.

HOW NTP OPERATES

       The ntpd program operates by exchanging messages with one or more configured servers at designated poll intervals. When started, whether for the first or subsequent times, the program requires several exchanges from the majority of these servers so the  signal  processing  and  mitigation  algorithms  can accumulate and groom the data and set the clock. In order to protect the network from bursts, the initial poll interval for each server is delayed an interval randomized over a few seconds. At the default initial poll interval of 64s, several minutes can elapse before  the
       clock  is set. The initial delay to set the clock can be reduced using the iburst keyword with the server configuration command, as described on the Configuration Options page.

       Most operating systems and hardware of today incorporate a time-of-year (TOY) chip to maintain the time during periods when the  power  is  off. When  the  machine  is booted, the chip is used to initialize the operating system time. After the machine has synchronized to a NTP server, the
       operating system corrects the chip from time to time. In case there is no TOY chip or for some reason its time  is  more  than  1000s  from  the  server  time,  ntpd  assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by
       hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the  clock  will  be  set  to  the server  time  regardless  of  the  chip  time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock  counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway.


   Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous  and  without  discontinuities.  Under  conditions  of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is
       equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets  exceeding  128  ms,  unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset,       steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to  a  vanishingly  low incidence.

       As  the  result  of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path  congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the  clock
       to  be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be   unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

       The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million  (PPM)  as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can
       take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is  outside  the  acceptable  range.  During  this  interval  the  local  clock  will not be consistent with any other network clock and the system cannot be used for distributed applications that  require correctly synchronized network time.

       In spite of the above precautions, sometimes when large frequency errors are present the resulting time offsets stray outside the  128-ms  range  and  an  eventual step or slew time correction is required. If following such a correction the frequency error is so large that the first sample
       is outside the acceptable range, ntpd enters the same state as when the ntp.drift file is not present. The intent of this behavior is to quickly  correct  the  frequency  and  restore operation to the normal tracking mode. In the most extreme cases (time.ien.it comes to mind), there may be  occasional step/slew corrections and subsequent frequency corrections. It helps in these cases to use the burst  keyword  when  configuring  the  server.

Understanding TOP Command

If you see the above snapshot taken of the TOP command, then lets understand this whole output and interpretation of TOP command in below notes :-

TOP ROW

This first line indicates in order:

current time (15:00:52)
uptime of the machine (up 41 min)
users sessions logged in (6 users)
average load on the system (load average: 1.20, 0.33,0.12) the 3 values refer to the last minute, five minutes and 15 minutes.

TASKS ROW

The second row gives the following information:

Processes running in totals (178 total)
Processes running (4 running)
Processes sleeping (174 sleeping)
Processes stopped (0 stopped)
Processes waiting to be stoppati from the parent process (0 zombie)

CPU ROW

The third line indicates how the cpu is used. If you sum up all the percentages the total will be 100% of the cpu. Let’s see what these values indicate in order:

Percentage of the CPU for user processes (90.3%us)
Percentage of the CPU for system processes (9.7%sy)
Percentage of the CPU processes with priority upgrade nice (0.0%ni)
Percentage of the CPU not used (0.0%id)
Percentage of the CPU processes waiting for I/O operations(0.0%wa)
Percentage of the CPU serving hardware interrupts (0.0% hi — Hardware IRQ
Percentage of the CPU serving software interrupts (0.0% si — Software Interrupts
The amount of CPU ‘stolen’ from this virtual machine by the hypervisor for other tasks (such as running another virtual machine) this will be 0 on desktop and server without Virtual machine. (0.0%st — Steal Time)

Now the memory usage

The fourth and fifth rows respectively indicate the use of physical memory (RAM) and swap. In this order: Total memory in use, free, buffers cached. On this topic you can also read the following article

Now the Processes list

And as last thing ordered by CPU usage (as default) there are the processes currently in use. Let’s see what information we can get in the different columns:

PID – l’ID of the process(5016)
USER – The user that is the owner of the process (oracle)
PR – priority of the process (20)
NI – The “NICE” value of the process (0)
VIRT – virtual memory used by the process (287m)
RES – physical memory used from the process (21m)
SHR – shared memory of the process (8888)
S – indicates the status of the process: S=sleep R=running Z=zombie (S)
%CPU – This is the percentage of CPU used by this process (38.9)
%MEM – This is the percentage of RAM used by the process (0.5)
TIME+ –This is the total time of activity of this process (0:52.84)
COMMAND – And this is the name of the process (gnome-terminal)