Americas

  • United States
sandra_henrystocker
Unix Dweeb

Using Unix commands to profile your users

How-To
Jan 09, 20175 mins
Data CenterLinux

profiles2
Credit: IDG

User profiles aren’t restricted to what shells your users use, what groups they are members of, and what privileges they have been allocated. While these factors are important, so are when they log in, how much disk space they are using, and what they’re actually doing on your systems. Periodic reviews of your users can help you get a better feel for how they use your systems and can sometimes help you to pinpoint problems.

Unix provides a lot of commands that can help pull together a quick picture of how your users are set up and when they are active.

Recent logins

The last command will show you recent logins for any particular user or for everyone. Depending on when the source file for this information (your wtmp file) rolls over, this might represent months of user logins.

$ last shs    pts/0  192.123.76.32    Fri Jan  6 15:58  still logged in shs    pts/0  192.123.76.32    Fri Jan  6 13:28 - 15:57  (02:29) jck    pts/0  the.planet.net   Thu Jan  5 21:49 - 21:49  (00:00) tbg    pts/0  10.11.174.132    Tue Jan  3 13:06 - 13:09  (00:02) wtbg   pts/0  10.12.123.88     Mon Jan  2 01:56 - 01:56  (00:00) jcc    pts/1  208.167.254.36   Fri Dec 30 08:02 - 08:02  (00:00) 

Pulling up reports on how many times your users have logged in on a server recently can give you an idea how active they are. Viewing when they log in might give you an entirely different perspective. This kind of command will show you the earliest time of the day that someone logged in.

# last tbg | grep -v begins | grep pts | awk '{print $7}' | sort | head -1

03:10

A similar command will show you the latest time that someone logged in.

# last ec2-user | grep -v begins | awk '{print $7}' | sort | tail -1 22:52

You can generate a report showing the last login for each user on your system with a script like this:

while IFS=: read user _; do     last "$user" | head -n 1 done /passwd

It will display a line for every user in your /etc/passwd file. Those who have never logged in will result in blanks lines. On some systems, that could be a very sparse report. To omit the blanks lines, you can run the script like this:

$ ./bin/showLastLogins | grep pts

Or, if you prefer, you can add the pseudo-terminal specification to the script itself to remove the blank lines.

while IFS=: read user _; do     last "$user" | grep pts | head -n 1 done /passwd

The output will look something like this:

$ showLastLogins

tbg pts/0 10.11.174.132 Tue Jan 3 13:06 - 13:09 (00:02)

abc pts/0 192.123.76.32 Sat Dec 24 08:28 - 08:30 (00:02)

jcc pts/0 the.planet.net Thu Jan 5 21:49 - 21:49 (00:00)

shs pts/1 192.161.76.32 Fri Jan 6 16:23 still logged in

tpb pts/11 static-71-179-54 Tue Nov 15 10:49 - 10:49 (00:00)

If you want, instead, to produce a report showing only the accounts for which there have been no recent logins, you can use a script like this one. Just keep in mind that you’re going to see a lot of system accounts. In general, user accounts will be displayed last since the /etc/passwd file is being processed top to bottom.

#!/bin/bash while IFS=: read user _; do     cnt=`last "$user" | wc -l`     if [ $cnt == 2 ]; then         echo $user     fi done /passwd

Depending on the type of work your users do, middle of the night logins might be fairly standard or very unusual — even suspect. Knowing what to expect, on the other hand, is generally always useful.

Origin of logins

Where your users are logging in from can also provide useful information. For some organizations, logins are nearly always from on-site machines. For others, logins from external IP addresses, even international IP addresses might be the norm.

Here’s an example of a command that will list the source IP addresses and counts of logins from information provided by the last command.

$ last tbg | grep -v begins | grep pts | awk '{print $3}' | sort | uniq -c

22 10.23.167.11

1 10.23.174.132

2 104.235.21.191

16 188.143.232.62

Group memberships

You can pull group memberships from the /etc/passwd and /etc/group files, but the groups command makes fetching that information even easier.

$ groups tbg ec2-user : tbg admins wheel

User Privileges

When trying to ascertain what privileges a user might have on some particular system, you should never overlook the /etc/sudoers file. If enabled, wheel group membership might allow a user to run any command as root using sudo.

## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL

User Activity

You can get a feel for the kind of work your users are doing by reviewing their command history, but you’re probably going to find yourself looking at far too much data or looking at a data summary that doesn’t give a lot of insight. Still, a command like this can provide some insights.

# cat ~tbg/.bash_history | awk '{print $1}' | sort | uniq -c
      1 alias
     21 cd
     10 clear
      1 cp
      1 date
     12 echo
      7 fix
      4 history
     24 ls
      1 man
      1 mkdir
     11 mv
     10 pwd
      1 set
     16 setpos
      1 touch
     92 vi

Looking for possible malicious activity would require a lot more insight. For one thing, history files can be edited by users, so they’re more of a convenience than a source of evidence. For another, the volume of data can make finding what you’re looking for quite difficult. Commands like that shown above aren’t going to show you what files are being edited — obviously a critical piece of information if you’re trying to do a deep dive on someone’s activity on your system. And you aren’t likely to notice if someone has temporarily aliased “ls” to a very different command.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.