Shulou(Shulou.com)06/01 Report--

This article mainly introduces how the Linux system to sort errors through the log, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Syslog records information about hardware, software, and system problems in the system, as well as monitoring events that occur in the system. Users can use it to check the cause of the error or to look for traces left by the attacker when they are attacked.

Reason for login failure if you want to check whether your system is secure, you can check for failed login and successful but suspicious users in the authentication log. Authentication failures occur when someone logs in through improper or invalid credentials, usually when using SSH for remote login or su to other local users for access. These are recorded by the plug-in verification module (PAM). You will see strings like Failed password and user unknown in your log. The successful authentication record includes strings such as Accepted password and session opened.

Examples of failures:

Pam_unix (sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2 Failed password for invalid user hoover from 10.0.2.2 port 4791 ssh3 pam_unix (sshd:auth): check pass; user unknown PAM service (sshd) ignoring max retries; 6 > 3 examples of success:

Accepted password for hoover from 10.0.2.2 port 4792 ssh3 pam_unix (sshd:session): session opened for user hoover by (uid=0) pam_unix (sshd:session): session closed for user hoover you can use grep to find out which users failed login the most times. These are potential attackers trying and accessing failed accounts. This is an example on a ubuntu system.

$grep "invalid user" / var/log/auth.log | cut-d'- f 10 | sort | uniq-c | sort-nr 23 oracle 18 postgres 17 nagios 10 zabbix 6 test because there is no standard format, so you need to use different commands for each application's log. Log management system, you can automatically analyze logs, classify them effectively, and help you extract keywords, such as user names.

The log management system can use the automatic parsing feature to extract the user name from the Linux log. This allows you to see the user's information and filter it through clicks. In the following example, we can see that the root user logged in 2700 times, because the log we filtered shows only the login attempt record of the root user.

The log management system also allows you to view the chart with time as the coordinate axis, making it easier for you to find anomalies. If someone fails to log in once or twice in a few minutes, it may be a real user and forget the password. However, if there are hundreds of failed logins and use different user names, it is more likely to be trying to attack the system. Here, you can see that on March 12, someone tried to log in to Nagios hundreds of times. This is obviously not a legitimate system user.

The reason for the restart is that sometimes a server goes down due to a system crash or restart. How do you know when it happened and who did it?

Shutdown command if someone runs the shutdown command manually, you can see it in the verification log file. Here, you can see that someone remotely logged in as a ubuntu user from IP 50.0.134.125, and then shut down the system.

Mar 19 18:36:41 ip-172-31-11-231 sshd [23437]: Accepted publickey for ubuntu from 50.134.125 port 52538 ssh Mar 19 18:36:41 ip-172-31-11-231 23437]: sshd [pam_unix (sshd:session): session opened for user ubuntu by (uid=0) Mar 19 18:37:09 ip-172-31-11-231 sudo: ubuntu: TTY=pts/1; PWD=/home/ubuntu; USER=root COMMAND=/sbin/shutdown-r now kernel initialization if you want to see all the reasons for server restart (including crashes), you can look for it in the kernel initialization log. You need to search for kernel classes (kernel) and cpu initialization (Initializing) information.

Mar 19 18:39:30 ip-172-31-11-231 kernel: [0.000000] Initializing cgroup subsys cpuset Mar 19 18:39:30 ip-172-31-11-231 kernel: [0.000000] Initializing cgroup subsys cpu Mar 19 18:39:30 ip-172-31-11-231 kernel: [0.000000] Linux version 3.8.0-44-generic (buildd@tipua) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3) -1ubuntu5) # 66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 (Ubuntu 3.8.0-44.66~precise1-generic 3.8.13.25) detect that there are many reasons for memory problems that may cause the server to crash But a common reason is running out of memory.

When your system runs out of memory, the process is killed, usually killing the process that uses the most resources. An error occurs when the system uses all memory and new or existing processes try to use more memory. Look in your log file for strings like Out of Memory or kernel warnings like kill. This information indicates that the system intentionally killed the process or application, rather than allowing the process to crash.

For example:

[33238.178288] Out of memory: Kill process 6230 (firefox) score 53 or sacrifice child [29923450.995084] select 5230 (docker), adj 0, size 708, to kill you can use tools like grep to find these logs. This example is in ubuntu:

$grep "Out of memory" / var/log/syslog [33238.178288] Out of memory: Kill process 6230 (firefox) score 53 or sacrifice child remember that grep also uses memory, so just running grep can also cause out-of-memory errors. This is another reason why you should store logs centrally!

The scheduled task error log cron daemon is a scheduler that runs processes at specified dates and times. If the process fails or fails to complete, then cron's error appears in your log file. Depending on your distribution, you can find this log in / var/log/cron,/var/log/messages and / var/log/syslog. There are many reasons why cron tasks fail. Typically, the problem lies in the process rather than the cron daemon itself.

By default, the output of the cron task is emailed over the postfix. This is a log that shows that the message has been sent. Unfortunately, you can't see the contents of the email here.

Mar 13 16:35:01 PSQ110 postfix/pickup [15158]: C3EDC5800B4: uid=1001 from= Mar 13 16:35:01 PSQ110 postfix/cleanup [15727]: C3EDC5800B4: message-id= Mar 13 16:35:01 PSQ110 postfix/qmgr [15159]: C3EDC5800B4: from=, size=607, nrcpt=1 (queue active) Mar 13 16:35:05 PSQ110 postfix/smtp [15729]: C3EDC5800B4: to=, relay=gmail-smtp-in.l.google.com [74.125.130.26]: 25, delay=4.1, delays=0.26/0/2.2/1.7, dsn=2.0.0 Status=sent (2502.0.0 OK 1425985505 f16si501651pdj.5-gsmtp) you can consider recording the standard output of cron in your log To help you locate the problem. This is an example of how you can use the logger command to redirect cron standard output to syslog. Using your script instead of the echo command, helloCron can be set to the name of any application you want.

* / 5 * echo 'Hello World' 2 > & 1 | / usr/bin/logger-t helloCron the log entries it created:

Apr 28 22:20:01 ip-172-31-11-231 CRON [15296]: (ubuntu) CMD (echo 'Hello Worldwide' 2 > & 1 | / usr/bin/logger-t helloCron) Apr 28 22:20:01 ip-172-31-11-231 helloCron: Hello World! Each cron task records a different log based on the specific type of task and how the data is output.

Thank you for reading this article carefully. I hope the article "how to arrange errors in the Linux system through this log" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.