http://www.itsprite.com/how-to-monitor-user-login-history-on-centos-with-utmpdump-2
Keeping, maintaining and analyzing logs (i.e., accounts of events that have happened during a certain period of time or are currently happening) are among the most basic and essential tasks of a Linux system administrator. In case of user management, examining user logon and logout logs (both failed and successful) can alert us about any potential security breaches or unauthorized use of our system. For example, remote logins from unknown IP addresses or accounts being used outside working hours or during vacation leave should raise a red flag.
On a CentOS system, user login history is stored in the following binary files:
In this post I’ll show you how to use utmpdump, a simple program from the sysvinit-tools package that can be used to dump these binary log files in text format for inspection. This tool is available by default on stock CentOS 6 and 7. The information gleaned from utmpdump is more comprehensive than the output of the tools mentioned earlier, and that’s what makes it a nice utility for the job. Besides, utmpdump can be used to modify utmp or wtmp, which can be useful if you want to fix any corrupted entries in the binary logs.
In order to display the contents of /var/run/utmp, run the following command:
To do the same with /var/log/wtmp:
and finally with /var/log/btmp:
As you can see, the output formats of three cases are identical, except for the fact that the records in the utmp and btmpare arranged chronologically, while in the wtmp, the order is reversed.
Each log line is formatted in multiple columns described as follows. The first field shows a session identifier, while the second holds PID. The third field can hold one of the following values: ~~ (indicating a runlevel change or a system reboot), bw (meaning a bootwait process), a digit (indicates a TTY number), or a character and a digit (meaning a pseudo-terminal). The fourth field can be either empty or hold the user name, reboot, or runlevel. The fifth field holds the main TTY or PTY (pseudo-terminal), if that information is available. The sixth field holds the name of the remote host (if the login is performed from the local host, this field is blank, except for run-level messages, which will return the kernel version). The seventh field holds the IP address of the remote system (if the login is performed from the local host, this field will show 0.0.0.0). If DNS resolution is not provided, the sixth and seventh fields will show identical information (the IP address of the remote system). The last (eighth) field indicates the date and time when the record was created.
1. Check how many times (and at what times) a particular user (e.g., gacanepa) logged on to the system between August 18 and September 17.
If you need to review login information from prior dates, you can check the wtmp-YYYYMMDD (or wtmp.[1…N]) and btmp-YYYYMMDD (or btmp.[1…N]) files in /var/log, which are the old archives of wtmp and btmp files, generated by logrotate.
2. Count the number of logins from IP address 192.168.0.101.
3. Display failed login attempts.
In the output of /var/log/btmp, every log line corresponds to a failed login attempt (e.g., using incorrect password or a non-existing user ID). Logon using non-existing user IDs are highlighted in the above impage, which can alert you that someone is attempting to break into your system by guessing commonly-used account names. This is particularly serious in the cases when the tty1 was used, since it means that someone had access to a terminal on your machine (time to check who has keys to your datacenter, maybe?).
4. Display login and logout information per user session.
In /var/log/wtmp, a new login event is characterized by ‘7’ in the first field, a terminal number (or pseudo-terminal id) in the third field, and username in the fourth. The corresponding logout event will be represented by ‘8’ in the first field, the same PID as the login in the second field, and a blank terminal number field. For example, take a close look at PID 1463 in the above image.
So far I covered somewhat trivial examples. You can combine utmpdump with other text sculpting tools such as awk, sed,grep or cut to produce filtered and enhanced output.
For example, you can use the following command to list all login events of a particular user (e.g., gacanepa) and send the output to a .csv file that can be viewed with a pager or a workbook application, such as LibreOffice’s Calc or Microsoft Excel. Let’s display PID, username, IP address and timestamp only:
As represented with three blocks in the image, the filtering logic is composed of three pipelined steps. The first step is used to look for login events ([7]) triggered by user gacanepa. The second and third steps are used to select desired fields, remove square brackets in the output of utmpdump, and set the output field separator to a comma.
Of course, you need to redirect the output of the above command to a file if you want to open it later (append “> [name_of_file].csv” to the command).
In more complex examples, if you want to know what users (as listed in /etc/passwd) have not logged on during the period of time, you could extract user names from /etc/passwd, and then run grep the utmpdump output of /var/log/wtmp against user list. As you see, possibility is limitless.
Before concluding, let’s briefly show yet another use case of utmpdump: modify utmp or wtmp. As these are binary log files, you cannot edit them as is. Instead, you can export their content to text format, modify the text output, and then import the modified content back to the binary logs. That is:
This can be useful when you want to remove or fix any bogus entry in the binary logs.
To sum up, utmpdump complements standard utilities such as who, w, uptime, last, lastb by dumping detailed login events stored in utmp, wtmp and btmp log files, as well as in their rotated old archives, and that certainly makes it a great utility.
Via:http://xmodulo.com/monitor-user-login-history-centos-utmpdump.html
Keeping, maintaining and analyzing logs (i.e., accounts of events that have happened during a certain period of time or are currently happening) are among the most basic and essential tasks of a Linux system administrator. In case of user management, examining user logon and logout logs (both failed and successful) can alert us about any potential security breaches or unauthorized use of our system. For example, remote logins from unknown IP addresses or accounts being used outside working hours or during vacation leave should raise a red flag.
On a CentOS system, user login history is stored in the following binary files:
- /var/run/utmp (which logs currently open sessions) is used by who and w tools to show who is currently logged on and what they are doing, and also by uptime to display system up time.
- /var/log/wtmp (which stores the history of connections to the system) is used by last tool to show the listing of last logged-in users.
- /var/log/btmp (which logs failed login attempts) is used by lastb utility to show the listing of last failed login attempts.
In this post I’ll show you how to use utmpdump, a simple program from the sysvinit-tools package that can be used to dump these binary log files in text format for inspection. This tool is available by default on stock CentOS 6 and 7. The information gleaned from utmpdump is more comprehensive than the output of the tools mentioned earlier, and that’s what makes it a nice utility for the job. Besides, utmpdump can be used to modify utmp or wtmp, which can be useful if you want to fix any corrupted entries in the binary logs.
How to Use Utmpdump and Interpret its Output
As we mentioned earlier, these log files, as opposed to other logs most of us are familiar with (e.g., /var/log/messages, /var/log/cron, /var/log/maillog), are saved in binary file format, and thus we cannot use pagers such as less or more to view their contents. That is where utmpdump saves the day.In order to display the contents of /var/run/utmp, run the following command:
1
|
# utmpdump /var/run/utmp
|
To do the same with /var/log/wtmp:
1
|
# utmpdump /var/log/wtmp
|
and finally with /var/log/btmp:
1
|
# utmpdump /var/log/btmp
|
As you can see, the output formats of three cases are identical, except for the fact that the records in the utmp and btmpare arranged chronologically, while in the wtmp, the order is reversed.
Each log line is formatted in multiple columns described as follows. The first field shows a session identifier, while the second holds PID. The third field can hold one of the following values: ~~ (indicating a runlevel change or a system reboot), bw (meaning a bootwait process), a digit (indicates a TTY number), or a character and a digit (meaning a pseudo-terminal). The fourth field can be either empty or hold the user name, reboot, or runlevel. The fifth field holds the main TTY or PTY (pseudo-terminal), if that information is available. The sixth field holds the name of the remote host (if the login is performed from the local host, this field is blank, except for run-level messages, which will return the kernel version). The seventh field holds the IP address of the remote system (if the login is performed from the local host, this field will show 0.0.0.0). If DNS resolution is not provided, the sixth and seventh fields will show identical information (the IP address of the remote system). The last (eighth) field indicates the date and time when the record was created.
Usage Examples of Utmpdump
Here are a few simple use cases of utmpdump.1. Check how many times (and at what times) a particular user (e.g., gacanepa) logged on to the system between August 18 and September 17.
1
|
# utmpdump /var/log/wtmp | grep gacanepa
|
If you need to review login information from prior dates, you can check the wtmp-YYYYMMDD (or wtmp.[1…N]) and btmp-YYYYMMDD (or btmp.[1…N]) files in /var/log, which are the old archives of wtmp and btmp files, generated by logrotate.
2. Count the number of logins from IP address 192.168.0.101.
1
|
# utmpdump /var/log/wtmp | grep 192.168.0.101
|
3. Display failed login attempts.
1
|
# utmpdump /var/log/btmp
|
In the output of /var/log/btmp, every log line corresponds to a failed login attempt (e.g., using incorrect password or a non-existing user ID). Logon using non-existing user IDs are highlighted in the above impage, which can alert you that someone is attempting to break into your system by guessing commonly-used account names. This is particularly serious in the cases when the tty1 was used, since it means that someone had access to a terminal on your machine (time to check who has keys to your datacenter, maybe?).
4. Display login and logout information per user session.
1
|
# utmpdump /var/log/wtmp
|
In /var/log/wtmp, a new login event is characterized by ‘7’ in the first field, a terminal number (or pseudo-terminal id) in the third field, and username in the fourth. The corresponding logout event will be represented by ‘8’ in the first field, the same PID as the login in the second field, and a blank terminal number field. For example, take a close look at PID 1463 in the above image.
- On [Fri Sep 19 11:57:40 2014 ART] the login prompt appeared in tty1.
- On [Fri Sep 19 12:04:21 2014 ART], user root logged on.
- On [Fri Sep 19 12:07:24 2014 ART], root logged out.
So far I covered somewhat trivial examples. You can combine utmpdump with other text sculpting tools such as awk, sed,grep or cut to produce filtered and enhanced output.
For example, you can use the following command to list all login events of a particular user (e.g., gacanepa) and send the output to a .csv file that can be viewed with a pager or a workbook application, such as LibreOffice’s Calc or Microsoft Excel. Let’s display PID, username, IP address and timestamp only:
1
|
# utmpdump /var/log/wtmp | grep -E "\[7].*gacanepa" | awk -v OFS="," 'BEGIN {FS="] "}; {print $2,$4,$7,$8}' | sed -e 's/\[//g' -e 's/\]//g'
|
As represented with three blocks in the image, the filtering logic is composed of three pipelined steps. The first step is used to look for login events ([7]) triggered by user gacanepa. The second and third steps are used to select desired fields, remove square brackets in the output of utmpdump, and set the output field separator to a comma.
Of course, you need to redirect the output of the above command to a file if you want to open it later (append “> [name_of_file].csv” to the command).
In more complex examples, if you want to know what users (as listed in /etc/passwd) have not logged on during the period of time, you could extract user names from /etc/passwd, and then run grep the utmpdump output of /var/log/wtmp against user list. As you see, possibility is limitless.
Before concluding, let’s briefly show yet another use case of utmpdump: modify utmp or wtmp. As these are binary log files, you cannot edit them as is. Instead, you can export their content to text format, modify the text output, and then import the modified content back to the binary logs. That is:
1
2 3 |
# utmpdump /var/log/utmp > tmp_output
<modify tmp_output using a text editor> # utmpdump -r tmp_output > /var/log/utmp |
To sum up, utmpdump complements standard utilities such as who, w, uptime, last, lastb by dumping detailed login events stored in utmp, wtmp and btmp log files, as well as in their rotated old archives, and that certainly makes it a great utility.
Via:http://xmodulo.com/monitor-user-login-history-centos-utmpdump.html
No comments:
Post a Comment