ฉันมีห้าระบบ CentOS 6 linux ในที่ทำงานและพบปัญหาที่ค่อนข้างแปลกที่ดูเหมือนจะเกิดขึ้นกับuserid ของฉันในทุกระบบของ linux ที่ฉันมี ... นี่คือตัวอย่างของปัญหาจากรายการที่ฉันยกเว้นจากlastคำสั่ง .. .

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)
kkim14   pts/14       192.0.2.225      Thu Nov 15 18:02 - 15:17 (4+21:15)
gduarte  pts/10       192.0.2.135      Thu Nov 15 12:33 - 08:10 (11+19:36)
gduarte  pts/9        192.0.2.135      Thu Nov 15 12:31 - 08:10 (11+19:38)
kkim14   pts/0        :0.0             Thu Nov 15 12:27 - 15:17 (5+02:49)
gduarte  pts/6        192.0.2.135      Thu Nov 15 11:44 - 08:10 (11+20:25)
kkim14   pts/13       192.0.2.225      Thu Nov 15 09:56 - 15:17 (5+05:20)
kkim14   pts/12       192.0.2.225      Thu Nov 15 08:28 - 15:17 (5+06:49)
kkim14   pts/11       192.0.2.225      Thu Nov 15 08:26 - 15:17 (5+06:50)
dspencer pts/8        192.0.2.130      Wed Nov 14 18:24   still logged in
mpenning pts/18       alpha-console-1. Mon Nov 12 14:41 - 14:46  (00:04)

คุณสามารถดูรายการล็อกอิน pts สองรายการด้านบนที่ไม่มีที่อยู่ IP ต้นทางที่เชื่อมโยงกับรายการเหล่านั้น เครื่อง CentOS ของฉันมีผู้ใช้มากถึงหกคนที่แชร์ระบบ การเข้าสู่ระบบของฉันประมาณ 10% เห็นปัญหานี้ แต่ไม่มีชื่อผู้ใช้อื่นที่แสดงพฤติกรรมนี้ ไม่มีรายการใน/var/log/secureโดยไม่มีที่อยู่ IP ต้นทาง

คำถาม

ด้วยสคริปต์ที่ฉันเก็บไว้ในระบบเหล่านี้ (ซึ่งควบคุมโครงสร้างพื้นฐานเครือข่ายของเรามาก) ฉันรู้สึกสับสนเล็กน้อยและอยากเข้าใจว่าอะไรจะทำให้การเข้าสู่ระบบของฉันพลาดที่อยู่แหล่งที่มาเป็นครั้งคราว

• ทำไมไม่last -iแสดง0.0.0.0สำหรับรายการพีทีเอสสาย (ดูคำตอบนี้ )
• มีอะไรบ้าง (นอกเหนือจากกิจกรรมที่เป็นอันตราย) ที่จะอธิบายพฤติกรรมอย่างสมเหตุสมผลหรือไม่
• นอกเหนือจากการบันทึกเวลาทุบตีประวัติมีสิ่งอื่นที่ฉันสามารถทำได้เพื่อติดตามปัญหาลงหรือไม่

ข้อมูลข่าวสาร

ตั้งแต่นี้เริ่มเกิดขึ้นฉันเปิดใช้งานการบันทึกbashเวลาประวัติศาสตร์ (เช่นHISTTIMEFORMAT="%y-%m-%d %T "ใน.bash_profile) และยังเพิ่มแฮ็กประวัติศาสตร์ทุบตีอื่น ๆ ไม่กี่ ; อย่างไรก็ตามนั่นไม่ได้ให้เบาะแสกับสิ่งที่เกิดขึ้นในช่วงก่อนหน้านี้

ระบบทั้งหมดใช้งาน CentOS 6.3 ...

[mpenning@typo ~]$ uname -a
Linux typo.local 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[mpenning@typo ~]$

แก้ไข

ถ้าฉันใช้last -i mpenningฉันเห็นรายการเช่นนี้ ...

mpenning pts/19       0.0.0.0          Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17       0.0.0.0          Fri Nov 16 10:21 - 10:42  (00:21)

หมายเหตุสำหรับผู้ที่พยายามที่จะตอบ: ฉันยังไม่ได้เข้าสู่ระบบด้วยscreenคำสั่งหรือกุย การเข้าสู่ระบบทั้งหมดของฉันมาจาก SSH; ในการรับรางวัลรางวัลคุณต้องอ้างอิงการอ้างอิงที่เชื่อถือได้เพื่ออธิบายlast -i 0.0.0.0รายการที่มาจากทาง SSH เท่านั้น

แก้ไข 2 (สำหรับคำถามของ ewwhite)

/etc/resolv.conf(โปรดทราบว่าฉันใช้.localaddrs ในlastผลลัพธ์ด้านบนเพื่อซ่อนข้อมูล บริษัท ของฉัน)

[mpenning@sasmars network]$ cat /etc/resolv.conf
nameserver 192.0.2.40
nameserver 192.0.2.60
domain mycompany.com
search mycompany.com
[mpenning@sasmars network]$

/etc/hosts ข้อมูล (โปรดทราบว่าไฟล์โฮสต์ที่กำหนดเองนี้มีอยู่ในหนึ่งในเครื่องที่มีปัญหาเหล่านี้เท่านั้น)

[mpenning@sasmars network]$ cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
192.0.2.44      sasmars.mycompany.com sasmars
::1             localhost6.localdomain6 localhost6

## Temporary kludge until I add reverse hostname mappings...
## Firewalls
192.0.2.254     a2-inet-fw1
192.0.2.253     a2-inet-fw2
192.0.2.254     a2-wan-fw1
192.0.2.253     a2-wan-fw2
192.0.2.201     a2-fab-fw1
192.0.2.202     a2-fab-fw2
192.0.2.203     t1-eds-fw1
192.0.2.42      sasvpn
192.0.2.246     sasasa1
192.0.2.10      sasoutfw1
## Wireless
192.0.2.6       saswcs1
192.0.2.2       l2wlc3
192.0.2.4       l2wlc4
192.0.2.12      f2wlc5
192.0.2.16      f2wlc6
192.0.2.14      f2wlc1
192.0.2.8       f2wlc2
[mpenning@sasmars network]$

sftpผลผลิตจาก/var/log/secure*

Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: called (pam_tacplus v1.3.7)
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: user [mpenning] obtained
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: called
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: obtained password
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: password obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: tty [ssh] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: rhost [192.0.2.91] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: trying srv 0
Dec 26 10:36:38 sasmars sshd[26016]: Accepted password for mpenning from 192.0.2.91 port 55118 ssh2
Dec 26 10:36:38 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26016]: pam_unix(sshd:session): session opened for user mpenning by (uid=0)
Dec 26 10:36:38 sasmars sshd[26018]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26018]: subsystem request for sftp
Dec 26 10:37:20 sasmars sshd[26016]: pam_unix(sshd:session): session closed for user mpenning
Dec 26 10:37:20 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)

การแก้ไขขั้นสุดท้าย

ดูคำตอบของฉันด้านล่าง

script ความแตกต่างของพฤติกรรมระหว่าง RedHat และ Debian

ไลบรารีที่เชื่อมโยง

CentOS 6.3 - สคริปต์ (util-linux-ng 2.17.2)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff077ff000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f309f5d1000)
libutempter.so.0 => /usr/lib64/libutempter.so.0 (0x00007f309f3cf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f309f03b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f309f7e1000)

Ubuntu 12.04 - สคริปต์ (util-linux 2.20.1)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff375ff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc0d7ab0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc0d76f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d7cdc000)

PTY

ขึ้นอยู่กับซอร์สโค้ดอัปสตรีมscriptจากทั้งสองเวอร์ชันเปิด pty ใหม่ ต่อไปนี้คือการทดสอบ

Ubuntu 12.04

john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ script
Script started, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 09:52  (00:44)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp$ exit
exit
Script done, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ 

Ubuntu 12.04 scriptเปิด pts ใหม่ (2) /var/log/wtmpมันก็ไม่ได้อัปเดต

CentOS 6

ฉันข้ามการทดสอบเพราะเรารู้อยู่แล้วว่าscriptopen pty และลงทะเบียนด้วย wtmp

libutemper

• โครงการ: http://freecode.com/projects/libutempter
• คำอธิบาย: libutempter จัดเตรียมอินเตอร์เฟสไลบรารีสำหรับเทอร์มินัลอีมูเลเตอร์เช่นหน้าจอและ xterm เพื่อบันทึกเซสชันผู้ใช้ไปยังไฟล์ utmp และ wtmp

ดังนั้นความแตกต่างที่สำคัญน่าจะเป็นไลบรารีพิเศษ ( libutempter.so.0) CentOS ที่scriptเชื่อมโยงกับ

ทดสอบกับ Ubuntu 12.04

รวบรวมscriptด้วย libutempter

john@U64D211:~/tmp/util-linux-2.20.1$ sudo apt-get install libutempter-dev
john@U64D211:~/tmp/util-linux-2.20.1$ ./configure --with-utempter
john@U64D211:~/tmp/util-linux-2.20.1$ make
john@U64D211:~/tmp/util-linux-2.20.1$ cd term-utils/
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ldd ./script
linux-vdso.so.1 =>  (0x00007fff54dff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f289e635000)
libutempter.so.0 => /usr/lib/libutempter.so.0 (0x00007f289e432000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f289e072000)
/lib64/ld-linux-x86-64.so.2 (0x00007f289e861000)

การทดสอบ

ก่อนเริ่มวิ่ง script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:28)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

ภายใน script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ./script
Script started, file is typescript
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37   still logged in   
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ exit
exit
Script done, file is typescript

หลังจากscriptจบ

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last
john     pts/2                         Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        :0               Sat Jan  5 09:09   still logged in   
reboot   system boot  3.2.0-35-generic Sat Jan  5 09:08 - 10:38  (01:30)    
john     pts/0        :0               Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  3.2.0-35-generic Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

สาเหตุหลักของชื่อโฮสต์ emtpy

และใช่script.cสร้างwtmpรายการด้วยชื่อโฮสต์ที่ว่างเปล่า ดูโค้ดบล็อกต่อไปนี้ในutil-linux-2.20.1/term-utils/script.cLine: 245-247

#ifdef HAVE_LIBUTEMPTER
    utempter_add_record(master, NULL);
#endif

ขึ้นอยู่กับ libutempter-1.1.5/utempter.h

extern int utempter_add_record (int master_fd, const char *hostname);

ดังนั้นเป็นจริงผ่านชื่อโฮสต์ที่ว่างเปล่าเข้าไปscript.cutempter_add_record

BackHat RedHat

สิ่งที่น่าสนใจคือต้นน้ำจริงไม่สนับสนุนutil-linux-ng-2.17.2 libutempterดูเหมือนว่า Redhat ตัดสินใจที่จะเพิ่มการสนับสนุนที่กลับมา

john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp

คำสั่งดังกล่าวส่งคืนผลลัพธ์ที่ว่างเปล่า

ข้อสรุป

ดังนั้นความแตกต่างในพฤติกรรมระหว่างสอง distros ไม่ใช่ข้อผิดพลาด แต่เป็นทางเลือก RedHat ตัดสินใจที่จะสนับสนุนฟีเจอร์นั้นในขณะที่ Debian ข้ามไป

นี่ทำให้ฉันงงงวยจริงๆ ควรใช้ชื่อ DNS หรือที่อยู่ IP ฉันตรวจสอบlast.cไฟล์แล้ว แต่ฉันยังหาไม่ได้ว่าทำไมถึงไม่แสดงอะไรเลย อาจได้เวลาสักครู่ฉันสามารถหาส่วนประมาณ 0.0.0.0

int dns_lookup(char *result, int size, int useip, int32_t *a)
307 {
308     struct sockaddr_in  sin;
309     struct sockaddr_in6 sin6;
310     struct sockaddr     *sa;
311     int         salen, flags;
312     int         mapped = 0;
313 
314     flags = useip ? NI_NUMERICHOST : 0;
315 
316     /*
317      *  IPv4 or IPv6 ?
318      *  1. If last 3 4bytes are 0, must be IPv4
319      *  2. If IPv6 in IPv4, handle as IPv4
320      *  3. Anything else is IPv6
321      *
322      *  Ugly.
323      */
324     if (a[0] == 0 && a[1] == 0 && a[2] == htonl (0xffff))
325         mapped = 1;
326 
327     if (mapped || (a[1] == 0 && a[2] == 0 && a[3] == 0)) {
328         /* IPv4 */
329         sin.sin_family = AF_INET;
330         sin.sin_port = 0;
331         sin.sin_addr.s_addr = mapped ? a[3] : a[0];
332         sa = (struct sockaddr *)&sin;
333         salen = sizeof(sin);
334     } else {
335         /* IPv6 */
336         memset(&sin6, 0, sizeof(sin6));
337         sin6.sin6_family = AF_INET6;
338         sin6.sin6_port = 0;
339         memcpy(sin6.sin6_addr.s6_addr, a, 16);
340         sa = (struct sockaddr *)&sin6;
341         salen = sizeof(sin6);
342     }
343 
344     return getnameinfo(sa, salen, result, size, NULL, 0, flags);
345 }

ตัวแปรโกลบอลสองตัวที่ใช้ในบริบท ได้แก่

int usedns = 0;     /* Use DNS to lookup the hostname. */
72 int useip = 0;       /* Print IP address in number format */

ดังนั้นในทางทฤษฎีมันควรใช้ dns หรือ IP

ฉันจะดูว่าฉันสามารถขุดอะไรเพิ่มเติม แต่สิ่งที่ ewwhite ถามคือคำถามที่ถูกต้อง

ดังนั้นผมเคยขับรถผ่านมาในการดีบักเกอร์ซึ่งหวังว่าจะช่วยให้คุณอย่างน้อยบางคำตอบให้กับคำถามของคุณ ความรู้สึกของฉันคือสาเหตุที่ลึกกว่า

เหตุใด -i สุดท้ายจึงแสดง 0.0.0.0 สำหรับรายการ pts

วิธีที่ดีที่สุดในการอธิบายสิ่งนี้คือสิ่งที่เกิดขึ้นเมื่อคุณไม่ผ่าน -i

เหตุผลนี้อยู่ในส่วนรหัสนี้ของ last.c

if (usedns || useip)
  r = dns_lookup(domain, sizeof(domain), useip, p->ut_addr_v6);
if (r < 0) {
   len = UT_HOSTSIZE;
   if (len >= sizeof(domain)) len = sizeof(domain) - 1;
   domain[0] = 0;
   strncat(domain, p->ut_host, len);
}

ทั้งusednsและuseip(โดยใช้ตัวเลือกเริ่มต้น) จะไม่ถูกตั้งค่าสถานะ นี้ทำให้ตรรกะในการคัดลอกจากที่ struct p->ut_hostซึ่งตามที่มีชื่อเข้าสู่ระบบจากระยะไกลบันทึกไว้โดยสิ่งที่เขียนลงในman utmputmp

char ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                              kernel version for run-level
                              messages */

ในกรณีของคุณค่าในที่นี้คือเลขศูนย์ นี่คือเหตุผลที่เมื่อคุณเรียกใช้lastไม่มีอะไรปรากฏขึ้นสำหรับคุณ

ในกรณีlast -idns_lookup จะถูกเรียกใช้ สิ่งนี้จะผ่านรายการ (p-> ut_addr_v6) เพื่อแก้ไขผ่าน DNS ในกรณีของคุณค่านี้ยังมีเลขศูนย์

ส่วนใหญ่dns_lookupเป็นของตกแต่งหน้าต่างและ heusteric getnameinfoโดยทั่วไปสิ่งที่สำคัญก็คือฟังก์ชั่น ut_addr_v6นี้เป็นสายห้องสมุดซึ่งในกรณีนี้จะพยายามอย่างดีที่สุดในการแก้ไขค่าไบนารีที่เก็บไว้ใน เมื่อรายการนี้มีเลขศูนย์ (เช่นในกรณีของคุณ) คุณกำลังแก้ไขปัญหานี้0.0.0.0เป็นสิ่งที่เกิดขึ้นกับlast -iผลลัพธ์ของคุณ

มีอะไรบ้าง (นอกเหนือจากกิจกรรมที่เป็นอันตราย) ที่จะอธิบายพฤติกรรมอย่างสมเหตุสมผลหรือไม่

อาจเป็นข้อผิดพลาดหรือการกำกับดูแล มันไม่น่าจะเป็นอันตรายได้เพราะดูเหมือนว่าโง่ที่จะทิ้งร่องรอยใด ๆไว้ในฐานะผู้โจมตีแทนที่จะละทิ้งแหล่งที่อยู่

จุดเน้นของคำตอบจนถึงตอนนี้กำลังมองที่ผิด lastเพียงอ่านหรือutmp wtmpอย่างไรก็ตามlastการทำอย่างดีที่สุดกับข้อมูลที่มี

สาเหตุที่แท้จริงของคุณอยู่ในที่ที่utmpถูกเขียนไป !

ในขณะที่แอปพลิเคชั่นบางตัวเขียนลงไปโดยตรงutmpฉันเดาว่าสาเหตุของปัญหาของคุณอยู่ที่การsshdจัดการเซสชัน

นอกเหนือจากการบันทึกเวลาทุบตีประวัติมีสิ่งอื่นที่ฉันสามารถทำได้เพื่อติดตามปัญหาลงหรือไม่

utmpโดยทั่วไปจะไม่สามารถเขียนได้และไม่ได้หมายถึงการเป็น utmpถูกเขียนโดยแอปพลิเคชันที่ออกแบบมาเพื่อล็อกอินและตั้งค่าเซสชันของคุณ sshdในกรณีของคุณที่

ทำไม sshd ไม่จัดการผู้ใช้ของคุณอย่างถูกต้องแปลกมากเพราะมันควรจะคัดลอกในชื่อโฮสต์ที่คุณเข้ามา นี่คือที่ความพยายามในการแก้ไขข้อบกพร่องควรจะมุ่งเน้น เริ่มต้นด้วยการเพิ่ม debug output ของ sshd ลงในบันทึกของคุณและดูว่ามีสิ่งผิดปกติเกิดขึ้นหรือไม่

หากคุณต้องการแก้ไขปัญหา (หรืออาจจะค้นพบเพิ่มเติมเกี่ยวกับปัญหา) คุณสามารถใช้pam_lastlogเพื่อจัดการutmpด้วยการเพิ่มลงในรายการเซสชันใน /etc/pam.d/sshd

ตามความเป็นจริงมันไม่เจ็บที่จะตรวจสอบว่ามันมีอยู่แล้ว - เพราะpam_lastlogมีnohostตัวเลือกที่แน่นอนจะอธิบายพฤติกรรมของคุณที่คุณกำลังประสบอยู่

ในที่สุดคุณไม่สามารถใช้งานได้ตลอด aulastทำงานเดียวกันผ่านระบบย่อยการตรวจสอบ

อาจมีค่าลองดูว่าที่มีการจัดการอย่างน้อยเขียนที่อยู่ที่ถูกต้อง หากยังไม่ได้ปัญหาของคุณจะต้องอยู่กับ sshd เนื่องจาก sshd กำลังส่งชื่อ DNS รอบ ๆ ระบบย่อยที่แตกต่างกันเช่น utmp หรือการตรวจสอบ

(1) ฐานlastเอาท์พุทOP

หลังจากล็อกอินผ่าน ssh คุณสามารถ ssh ไปยัง localhost และรับ 0.0.0.0 ในlast -iภายหลัง

อ้างอิงจากบันทึกของ OP สี่บรรทัดแรก

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)

pts/19เข้าสู่ระบบอยู่ภายในpts/17ช่วงเวลาที่เข้าสู่ระบบ

pts/17เข้าสู่ระบบอยู่ภายในpts/1 ช่วงเวลาที่เข้าสู่ระบบ

สำหรับเหตุการณ์ที่เฉพาะเจาะจงนี้มันเป็นตรรกะที่จะคาดเดาว่า OP ssh จาก 192.0.2.91 ( pty/1) จากนั้นภายในเซสชัน ssh นั้นล็อกอินในเครื่อง ( ssh localhost) ไปยังเซิร์ฟเวอร์อีกครั้ง ( pts/17) และอีกครั้ง ( pts/19)

โปรดตรวจสอบว่าการทับซ้อนนี้เกิดขึ้นกับเหตุการณ์อื่นหรือไม่

การติดตามอาจช่วยระบุสาเหตุ

• คุณใช้ ssh-key หรือไม่ ถ้าใช่บนเซิร์ฟเวอร์คุณตั้งค่า ssh-key เพื่อเข้าสู่ระบบในเครื่องหรือไม่?
• ตรวจสอบหรือโพสต์ / var / log / ปลอดภัยของกรอบเวลาเดียวกัน มันอาจให้คำใบ้บางอย่าง
• ตรวจสอบสคริปต์ที่คุณใช้
• ตรวจสอบนามแฝงเชลล์ที่คุณใช้
• ตรวจสอบประวัติคำสั่งของคุณ

(2) Secnario เพิ่มเติม

สถานการณ์ 1 - sudo และเทอร์มินัล

1. UserA login X Window
2. เปิดหน้าต่างเทอร์มินัลให้ทำ xhost + localhost
3. su - UserBหรือsudo su - UserBเปิดเทอร์มินัลใหม่ (xterm, gnome-terminal, etc)
4. UserB จะแสดงเป็น 0.0.0.0 ใน last -i

su - UserBจะไม่ลงทะเบียนเป็นการUserBเข้าสู่ระบบล่าสุด แต่จะเปิดเทอร์มินัล

สถานการณ์ 2 - เข้าสู่ระบบ

1. ssh เข้าสู่เซิร์ฟเวอร์
2. ชนิด sudo login
3. เข้าสู่ระบบด้วยตัวคุณเอง
4. ตรวจสอบlastและlast -i

lastไม่แสดงชื่อโฮสต์หรือที่อยู่ IP login sessionสำหรับ last -iจะ IP 0.0.0.0 login sessionสำหรับ

john@U64D211:~$ last -5
john     pts/0                         Sun Dec 23 20:50   still logged in   
john     pts/0                         Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        :0               Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  3.2.0-35-generic Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        js.example.com   Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012
john@U64D211:~$ last -5i
john     pts/0        0.0.0.0          Sun Dec 23 20:50   still logged in   
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  0.0.0.0          Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        192.168.1.90     Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012

คำตอบของMifeแสดงบล็อคโค้ดของlast.cแล้ว เหตุผลที่lastแสดงชื่อโฮสต์ / IP ที่ว่างเปล่าเป็นเพราะut_hostสำหรับบันทึกเหล่านั้นจะว่างเปล่าจริงๆ สำหรับโครงสร้าง wtmp ที่สมบูรณ์ให้ทำman wtmpบนระบบ linux ใด ๆ

สถานการณ์ 2 สถานการณ์ที่นี่แสดงให้เห็นว่าแม้แต่แพ็คเกจมาตรฐานภายใต้สถานการณ์บางอย่างก็สามารถสร้างได้

(3) Bash History Hack

มันจะทำงานเฉพาะในกรณีที่เซสชั่นใช้bashเป็นเปลือกโต้ตอบ

.bashrcและเป็นเพียงการใช้โดย.bash_profilebash

พวกเขาจะไม่ได้รับแหล่งโดยอัตโนมัติหากเซสชั่นใช้เปลือกอื่น ๆ (sh, csh, ฯลฯ ) หรือรันโปรแกรมโดยตรงและจะไม่มีประวัติทุบตี

(4) การบัญชีกระบวนการ

เนื่องจาก OP ไม่ได้พูดถึงsecureไฟล์เลยฉันจะถือว่ามันเป็นจุดจบและมันก็ให้คำแนะนำในตอนนี้

หากสมมติฐานดังต่อไปนี้ถูกต้อง

`last` 0.0.0.0 entries are actually created with in OP own session

auth.log (debian) / secure (CentOS) จะไม่ช่วย เนื่องจากมีการบันทึกเฉพาะการกระทำที่เกี่ยวข้องกับการรับรองความถูกต้องเท่านั้น

wtmp / utmp ด้วยข้อ จำกัด ในโครงสร้างข้อมูลของพวกเขาก็เป็นจุดจบ ไม่มีข้อมูลเกี่ยวกับสิ่งที่สร้างขึ้น

ที่ปล่อยให้เรามีตัวเลือกหนึ่งบัญชีกระบวนการ นี่คือปืนใหญ่และต้องใช้ด้วยความระมัดระวัง

1. อาจขัดกับนโยบายของ บริษัท
2. ผู้ใช้รายอื่นในระบบที่ใช้ร่วมกันอาจมีความสุข / ไม่สบายใจเมื่อเปิดใช้งาน
3. ไฟล์บันทึกสามารถใช้พื้นที่ดิสก์ได้มาก จับตาดูอัตราการเติบโตของขนาดไฟล์

เวอร์ชันแพคเกจ psacct ควรเป็น6.3.2-56ขึ้นไปตามโพสต์นี้

หากสิ่งนี้จะถูกใช้และ/var/logมีพื้นที่ จำกัด ให้เปลี่ยนไฟล์บันทึก acct เป็นไดเรกทอรี (เข้าถึงเฉพาะ root) ภายใต้/homeซึ่งมักจะมีพื้นที่มากขึ้น

นี่เป็นปืนที่ใหญ่จริงๆ ด้วยอัตราการเกิด OP 10% น่าจะมีผลลัพธ์ภายในหนึ่งสัปดาห์ หากในช่วงเวลานั้นรายการที่ว่างเปล่าแสดงขึ้นในlastแต่ไม่มีอะไรจากบันทึกบัญชีมันกลายเป็นความลึกลับ สถานการณ์และจะต้องมีการกระทำที่รุนแรง

ต่อไปนี้เป็นตัวอย่างผลลัพธ์ของ lastcomm

lesspipe               john     pts/8      0.02 secs Mon Dec 24 17:10
lesspipe          F    john     pts/8      0.00 secs Mon Dec 24 17:10
dirname                john     pts/8      0.00 secs Mon Dec 24 17:10
basename               john     pts/8      0.00 secs Mon Dec 24 17:10
kworker/1:2       F    root     __         0.00 secs Mon Dec 24 16:54
tty                    john     pts/6      0.01 secs Mon Dec 24 17:09
tty                    john     pts/4      0.01 secs Mon Dec 24 17:09
cron              F    root     __         0.05 secs Mon Dec 24 17:09
sh               S     root     __         0.01 secs Mon Dec 24 17:09
find                   root     __         0.01 secs Mon Dec 24 17:09
maxlifetime            root     __         0.00 secs Mon Dec 24 17:09
php5                   root     __         0.23 secs Mon Dec 24 17:09
which                  root     __         0.00 secs Mon Dec 24 17:09
lastcomm               root     pts/0      0.01 secs Mon Dec 24 17:08
tty                    john     pts/1      0.01 secs Mon Dec 24 17:08
dconf worker         X john     __         5.46 secs Mon Dec 24 16:58
lastcomm               root     pts/7      0.04 secs Mon Dec 24 17:05
mesg             S     root     pts/7      0.00 secs Mon Dec 24 17:05
bash              F    root     pts/7      0.00 secs Mon Dec 24 17:05
dircolors              root     pts/7      0.00 secs Mon Dec 24 17:05

คุณสามารถใช้ 'dump-acct' เพื่อแสดงข้อมูลเพิ่มเติม

PS1: ฉันพยายามเปิดเซสชันเทอร์มินัลและ ssh ไม่กี่ครั้ง มันไม่ชัดเจน (หรือไม่ใช่เรื่องง่ายที่จะปักหมุด) สิ่งที่เปิดแต้มใหม่ อย่างไรก็ตามมันจะแสดงทุกอย่างที่วิ่งภายใน pts / เซสชันนั้น

PS2: บล็อกโพสต์เกี่ยวกับการใช้บัญชีโดยไมค์

เมื่อคุณลงชื่อเข้าใช้งานเครื่องจักรรายการเหล่านี้อาจเป็นรายการน้อยในคำสั่งสุดท้าย

geekride   tty2                        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/1                       Fri Dec 21 13:45   still logged in   
geekride   pts/1        :pts/0:S.0     Thu Dec  6 12:49 - 00:40  (11:50)    
geekride   pts/1        10.31.33.47    Thu Dec  6 12:49 - 00:40  (11:50)    

รายการแรกที่มี tty * มาเมื่อคุณล็อกอินผ่านเทอร์มินัลหรือคอนโซลโดยกด CTRL + ALT + F1-6 มันค่อนข้างชัดเจนจากเครื่องที่ใช้

โดยปกติแล้วรายการที่สองเข้ามาในรูปภาพเมื่อคุณเข้าสู่เครื่องและเปิดหน้าต่างเทอร์มินัลใน GUI จะมีรายการแม้ว่าคุณจะเปิดแท็บใหม่ในหน้าต่างเทอร์มินัลเดียวกัน

รายการประเภทที่สามมาเมื่อคุณเปิดเซสชันหน้าจอหลังจากที่ล็อกอินผ่าน SSH ที่จะสร้างรายการที่นั่นและไม่มีที่อยู่ IP ใด ๆ

รายการที่สี่เป็นเรื่องปกติที่ทุกคนเข้าใจดี

หากคุณทำlast -iตามรายการต่อไปนี้คุณจะเห็นสิ่งนี้:

geekride   tty2         0.0.0.0        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/9        0.0.0.0        Fri Dec 21 13:45   still logged in   
geekride   pts/1        0.0.0.0        Thu Dec  6 12:49 - 00:40  (11:50)    

ฉันค่อนข้างมั่นใจว่ากรณีของคุณมาใน 2 กรณีใดกรณีหนึ่งกับหน้าต่างเทอร์มินัลใน GUI และอื่น ๆ ที่มีเซสชันหน้าจอ

หวังว่าสิ่งนี้จะช่วยได้

ฉันไม่คิดว่าเราจะไปได้ไกลขนาดนี้โดยไม่ต้องดีบั๊กครั้งสุดท้าย แต่ก็ไม่ควรยากเกินไปเพราะมันรวบรวมได้อย่างง่ายดาย ...

สิ่งหนึ่งที่เป็นไปได้คือการดัมพ์ไฟล์ / var / log / wtmp โดยใช้คำสั่งutmpdumpและดูเร็กคอร์ดดิบซึ่งอาจทำให้คุณมีปัญหา ถ้าไม่ได้โปรดโพสต์ผลลัพธ์ที่เกี่ยวข้องจาก

utmpdump /var/log/wtmp 

เพื่อให้เราสามารถสร้างสำเนาของ wtmp ในเครื่องของคุณเพื่อดีบักด้วย

utmpdump -r <dumpfile >wtmp

ฉันตรวจสอบแอพพลิเคชันเซิร์ฟเวอร์ที่ใช้ CentOS และ RHEL 6.3 จำนวน 12 แห่ง ไม่มีใครแสดงพฤติกรรมนี้ ไม่มีรายการที่ขาดหายไปในlastผลลัพธ์จะกลับไป 4-5 สัปดาห์

ฉันคิดว่ามันเป็นสิ่งสำคัญที่จะเห็น/etc/hostsรายการไฟล์ของคุณเพื่อให้แน่ใจว่าสอดคล้องกับรูปแบบนี้

นอกจากนี้คุณกำลังทำอะไรเพื่อแก้ไขปัญหา DNS คุณโพสต์ของคุณได้/etc/resolv.confไหม

คำตอบอื่น ๆ ที่ระบุว่า0.0.0.0แสดงถึงการเชื่อมต่อในท้องถิ่นนั้นถูกต้อง ตัวอย่างทั่วไปคือการรีบูตและเข้าสู่ระบบคอนโซลเหตุการณ์:

 reboot   system boot  0.0.0.0          Sat Dec  8 06:12 - 05:57 (12+23:45)  
 reboot   system boot  0.0.0.0          Sat Dec  8 05:25 - 06:09  (00:44)    
 reboot   system boot  0.0.0.0          Fri Nov 30 14:28 - 05:22 (7+14:54)   
 root     tty1         0.0.0.0          Fri Nov 30 13:52 - 13:55  (00:03)    
 reboot   system boot  0.0.0.0          Fri Nov 30 13:51 - 14:25  (00:34)    

เนื่องจากสิ่งนี้ดูเหมือนว่าจะเกิดขึ้นกับผู้ใช้ที่ระบุชื่อมีการเปลี่ยนแปลงใด ๆ ที่มีบางสิ่งที่ขี้ขลาดที่มาหรือเรียกใช้ในสคริปต์การเข้าสู่ระบบของพวกเขา? คุณเปลี่ยน~/.bashrcหรือ~/.bash_profileจากค่าเริ่มต้น? มีสคริปต์การเข้าสู่ระบบพิเศษอื่น ๆ ในสภาพแวดล้อมหรือไม่?

--Edit--

ฉันยังคงไม่สามารถทำสิ่งนี้ซ้ำได้ ฉันดูองค์ประกอบสำคัญสองอย่าง lastคำสั่งมีเสถียรภาพและยังไม่ได้รับการเปลี่ยนแปลงในระยะเวลานาน ดูการเปลี่ยนแปลงของsysvinit-toolsไม่มีข้อบกพร่องที่เกี่ยวข้อง เหมือนกันสำหรับinitscripts (wtmp)

หากคุณสามารถบังคับให้สิ่งนี้เกิดขึ้นลองกับบัญชีผู้ใช้อื่นจากเครื่องต้นทางเดียวกัน แต่ฉันไม่เห็นสิ่งบ่งชี้ว่านี่เป็นปัญหาของระบบปฏิบัติการ

การแก้ไขขั้นสุดท้าย

ฉันได้รับโบนัสแล้วดังนั้นนี่เป็นคำถามสำหรับผู้ใช้ Google ในอนาคตอย่างแท้จริง

เหตุผลนี้ปรากฏในเพียง ~ 10% ของการเข้าสู่ระบบของฉันเพราะเมื่อฉันทำการเปลี่ยนแปลงที่สำคัญกับเราเตอร์หรือสวิตช์ของฉันฉันใช้script foo.logเพื่อให้ฉันมีบันทึกการเปลี่ยนแปลงที่สมบูรณ์ ด้วยเหตุผลที่ฉันยังไม่เข้าใจ CentOS สร้างptsรายการเมื่อคุณใช้scriptคำสั่ง ... ฉันจะแสดงผลลัพธ์last -iก่อนและหลังการเรียกใช้script...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)
[mpenning@sasmars net]$ script ~/something_random.log
Script started, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ date
Thu Jan  3 16:14:19 CST 2013 # <--------------------------------------------------
[mpenning@sasmars net]$ exit
exit
Script done, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ last -i | head
mpenning pts/15       0.0.0.0          Thu Jan  3 16:14 - 16:14  (00:00) # <------
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
[mpenning@sasmars net]$ cat /etc/redhat-release
CentOS release 6.3 (Final)
[mpenning@sasmars net]$

พฤติกรรมนี้ดูเหมือนจะไม่ซ้ำกับ CentOS 6 ... เรามี CentOS 4.7 เครื่องในห้องแล็บที่ไม่ได้ใส่รายการว่างไว้ในwtmp... เครื่อง Debian / Gentoo ไม่แสดงพฤติกรรมเช่นนี้ ผู้ดูแลระบบลินุกซ์ของเรากำลังเกาหัวทำไม CentOS จะเพิ่มptsรายการอื่นโดยเจตนาเมื่อคุณดำเนินการscript... ฉันสงสัยว่านี่เป็นข้อผิดพลาด RHEL

แก้ไข : ฉันยื่นปัญหานี้เป็นรหัส RHEL Bug 892134

บันทึก

บางคนได้ถือว่าไม่สมควรฉันใส่scriptในของฉันหรือ~/.bashrc ~/.bash_profileนี่คือข้อโต้แย้งที่มีข้อบกพร่อง ... หากเป็นจริงฉันwtmpควรมี0.0.0.0รายการหลังจากการล็อกอิน ssh ทุกครั้งของฉัน ...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/18       0.0.0.0       Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/15       0.0.0.0       Thu Dec 27 08:31 - 08:32  (00:00)  # <-----
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)  # <-----

แน่นอนว่าไม่ใช่กรณี ...

การเชื่อมต่อ Pseudo Terminal Slave (pts) เป็นการเชื่อมต่อ SSH หรือ telnet ที่หมายถึงการเชื่อมต่อทางอ้อมกับระบบ การเชื่อมต่อทั้งหมดเหล่านี้สามารถเชื่อมต่อกับเชลล์ซึ่งจะช่วยให้คุณสามารถออกคำสั่งไปยังคอมพิวเตอร์ ดังนั้นเมื่อคุณเปิดเทอร์มินัลในระบบของคุณจากกุยมันจะเปิด pts พร้อม source ip 0.0.0.0 จากข้อมูลที่คุณให้ดูเหมือนว่ามันเกิดขึ้นเพราะสคริปต์ทำงานบนเซิร์ฟเวอร์หรือกำหนดเวลานี้ซึ่งใช้บริการ ssh หรือ telnet หรือ pts ในพื้นที่เพื่อโยนเอาต์พุตในเทอร์มินัล

ssh ไคลเอ็นต์ใดที่คุณใช้ ไคลเอนต์ ssh บางคนสามารถเชื่อมต่อหลายเทอร์มินัลผ่านการเชื่อมต่อเดียวและฉันสังเกตเห็นเซสชันทั้งหมดของคุณโดยไม่ต้อง IP อยู่ในเซสชันที่ยาวกว่าซึ่งมี IP ที่บันทึกไว้

ฉันไม่สามารถทำซ้ำพฤติกรรมนี้ด้วย ssh ที่นี่

บางทีที่อยู่ IP ของคุณอาจแปลงเป็นสตริงว่างบนเซิร์ฟเวอร์ DNS เครื่องใดเครื่องหนึ่งของคุณอาจเป็นที่รองหากเกิดขึ้นเพียง 10 เปอร์เซ็นต์ของเวลา (หรืออาจเป็นเพียงไฟล์โฮสต์หากมีการแจกจ่ายจากที่เก็บส่วนกลาง) นั่นจะอธิบายรายการที่ขาดหายไป (หรือพื้นที่สีขาว) และสอดคล้องกับการอ่านแหล่งข่าวของ Soham

"0.0.0.0" หมายถึงว่าเป็นผู้ใช้ภายใน (ไม่ใช่การเข้าสู่ระบบระยะไกล) ซึ่งอาจเรียกใช้โดยแอปพลิเคชันเช่น cronjob

มันเกิดขึ้นเพราะคุณใช้ระบบโลคัลและ 0.0.0.0 หมายถึงที่อยู่ ip ของอินเทอร์เฟซทั้งหมด หากคุณคิดว่าอาจมีบางคนที่ถูกแฮ็กคุณพยายามตั้งค่าการบันทึกเต็มรูปแบบของเชลล์รวมถึงคำสั่งผ่าน ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

ฉันแก้ไขมันโดยการเพิ่มสคริปต์ลงใน ~ / .bashrc สคริปต์จะค้นหาที่อยู่ IP แหล่งที่มาการเชื่อมต่อล่าสุดของ telnet จากนั้นคุณสามารถเพิ่ม IP ลงในล็อกไฟล์หรือทำสิ่งที่คุณต้องการ ..

client_ip=$(echo $(netstat -nae | grep $(netstat -nae | grep 23 | awk  '{print $8}' | sort -n | tail -n1) | awk '{print $5}') | awk -F':' '{print $1}' )

echo "client_ip=$client_ip"

ชารอน