วิธีอ่าน Firewall Log จับ Port Scan และ Password Spray

ครั้งแรกที่เปิด traffic log ของ firewall มันดูเหมือนกำแพงของเครื่องหมายจุลภาค แล้ววันหนึ่งมันจะเริ่มอ่านออกเป็นเรื่องเล่า: มีคนเคาะประตูเจ็ดบานในสี่วินาที อีกไม่กี่นาทีต่อมามีคนลองบอกชื่อสิบกว่าชื่อที่เคาน์เตอร์หน้าตึก และทั้งสองคนคือผู้มาเยือนคนเดียวกัน ข้อมูลไม่ได้เปลี่ยน สิ่งที่เปลี่ยนคือเรารู้ว่าแต่ละ field หมายถึงอะไร และควรถามคำถามอะไรกับมันครับ

บทความนี้เป็น lab เล็ก ๆ เราจะดูโครงสร้างของ syslog message, field ที่สำคัญใน firewall traffic log และฝึกจับสองรูปแบบ คือ port scan และ password spray จากนั้นจะเชื่อม log ของ firewall เข้ากับ log ฝั่ง identity แล้วคุยกันว่าจะเปลี่ยนรูปแบบที่เห็นให้เป็น alert ที่ไม่ปลุกเราขึ้นมากลางดึกโดยไม่มีเหตุได้อย่างไรครับ

log ทุกบรรทัดในบทความนี้เป็นข้อมูลสมมติ IP address มาจากช่วงที่ IETF สงวนไว้สำหรับเอกสาร (192.0.2.0/24, 198.51.100.0/24 และ 203.0.113.0/24 ดู RFC 5737) ส่วน hostname, username และเวลาก็แต่งขึ้นเพื่อใช้ฝึก ไม่ได้มาจากเครือข่ายจริงใด ๆ

ขั้นที่ 1: รู้จักซองจดหมายก่อน (syslog, RFC 5424)

firewall ส่วนใหญ่ส่ง log ไปยัง collector ผ่าน syslog ได้ จึงควรรู้จักซองจดหมายก่อนอ่านจดหมายครับ RFC 5424 (มีนาคม พ.ศ. 2552) กำหนด syslog message แบบใหม่ไว้ว่า ประกอบด้วย HEADER ตามด้วย STRUCTURED-DATA และ MSG ที่เป็นข้อความอิสระ (มีหรือไม่มีก็ได้) field ใน header เรียงตามลำดับตายตัวดังนี้

ขีดกลาง - คือ NILVALUE แปลว่า "ไม่มีค่า" ส่วน severity มีตั้งแต่ 0 (Emergency) ถึง 7 (Debug) และ RFC 5424 ยกตัวอย่างการคำนวณไว้ว่า facility 20 (local use 4) กับ severity 5 (Notice) ได้ PRI เท่ากับ 165

ตัวอย่าง message สมมติในรูปแบบนี้

<134>1 2026-10-20T02:14:01.204Z fw-lab-01 firewall - TRAFFIC - src=198.51.100.23 dst=192.0.2.10 dport=21 action=drop

อ่านจากซ้ายไปขวา: PRI 134 คือ facility 16 (local0) × 8 + severity 6 (Informational) ตามด้วย version 1, timestamp แบบ UTC, host ที่ส่ง, ชื่อแอป, ไม่มี process ID, ประเภท message, ไม่มี structured data และตัว message

มีข้อสังเกตเชิงปฏิบัติสองข้อ ข้อแรก รูปแบบของ timestamp จะสำคัญมากตอนที่เราเรียง log จากหลายระบบเข้าด้วยกัน RFC 5424 บังคับให้ระบุ time zone ชัดเจน เราจึงไม่ต้องเดาครับ ข้อสอง transport ก็สำคัญ syslog แบบธรรมดาผ่าน UDP (RFC 5426 port 514) ไม่มีการตอบรับ message ที่หายระหว่างทางก็หายไปเลย และไม่มีการป้องกัน message ปลอมหรือการดักอ่าน ส่วน RFC 5425 ส่ง syslog ผ่าน TLS บน TCP port 6514 เพื่อให้ได้ confidentiality, integrity และ authentication สำหรับ firewall ของ Palo Alto Networks ตัว syslog server profile เลือก transport ได้ทั้ง UDP, TCP และ SSL โดย format ค่า default คือ BSD และอีกตัวเลือกคือ IETF ค่า default ของ transport คือ UDP port 514 (Configure Syslog Monitoring)

ขั้นที่ 2: เรียนรู้ field ของ traffic log

แต่ละ vendor ตั้งชื่อ field ต่างกันเล็กน้อย ผมจึงเปิดเอกสารอ้างอิงไว้หนึ่งชุดเสมอ คือ Traffic Log Fields ของ PAN-OS 11.1 log ของมันเป็นบรรทัดคั่นด้วยจุลภาคที่มีมากกว่าร้อยตำแหน่ง แต่ตอนเริ่มต้นไม่จำเป็นต้องรู้ทั้งหมดครับ field ที่ผมอ่านก่อนเสมอมีดังนี้

มี field หนึ่งที่ต้องระวังคือ Repeat Count นิยามของมันครอบคลุม source, destination, application และ subtype โดยไม่มี destination port อยู่ในรายการ ดังนั้นก่อนจะเชื่อตัวเลข "จำนวน port ที่ไม่ซ้ำกัน" ให้ตรวจก่อนว่าแหล่ง log ของเรายุบ session ที่คล้ายกันอย่างไร และนับโดยคำนึงถึงค่า repeat ด้วยครับ

ขั้นที่ 3: รูปแบบที่ 1 source เดียว หลาย port

นี่คือ traffic log สมมติที่ตัดมาบางส่วน จาก firewall ภายในที่กั้นระหว่าง user zone กับ server zone

generated_time        src             dst          dport  app             action  end_reason
2026-10-20T02:14:01Z  198.51.100.41   192.0.2.10     443  ssl             allow   tcp-fin
2026-10-20T02:14:01Z  198.51.100.23   192.0.2.10      21  not-applicable  drop    policy-deny
2026-10-20T02:14:01Z  198.51.100.23   192.0.2.10      22  not-applicable  drop    policy-deny
2026-10-20T02:14:02Z  198.51.100.88   192.0.2.53      53  dns             allow   aged-out
2026-10-20T02:14:02Z  198.51.100.23   192.0.2.10      23  not-applicable  drop    policy-deny
2026-10-20T02:14:02Z  198.51.100.23   192.0.2.10     445  not-applicable  drop    policy-deny
2026-10-20T02:14:03Z  198.51.100.41   192.0.2.10     443  ssl             allow   tcp-fin
2026-10-20T02:14:03Z  198.51.100.23   192.0.2.10    3389  not-applicable  drop    policy-deny
2026-10-20T02:14:03Z  198.51.100.23   192.0.2.10    1433  not-applicable  drop    policy-deny
2026-10-20T02:14:04Z  198.51.100.23   192.0.2.10    5900  not-applicable  drop    policy-deny

แบบฝึกหัด: ก่อนอ่านต่อ ลอง group บรรทัดเหล่านี้ตาม source แล้วนับ destination port ที่ ไม่ซ้ำกัน ของแต่ละ source ดูครับ

  fw traffic log (synthetic)  ●                                 
  time     src            dport  act       distinct ports       
  ──────────────────────────────────────   per source           
▶ 02:14:01 198.51.100.41    443  allow  │                       
  02:14:01 198.51.100.23     21  drop   │                       
  02:14:01 198.51.100.23     22  drop   │  .23 ·············· 0 
  02:14:02 198.51.100.88     53  allow  │                       
  02:14:02 198.51.100.23     23  drop   │                       
  02:14:02 198.51.100.23    445  drop   │  .41 ·············· 0 
  02:14:03 198.51.100.41    443  allow  │                       
  02:14:03 198.51.100.23   3389  drop   │                       
  02:14:03 198.51.100.23   1433  drop   │  .88 ·············· 0 
  02:14:04 198.51.100.23   5900  drop   ┃                       
                                                                
                                           reading...           
  $ group by src, count distinct dport                          
                                                                
  $ _                                                           

คำตอบคือ .41 แตะ port เดียว (443 สองครั้ง), .88 แตะ port เดียว (53) ส่วน .23 แตะ port ต่างกันถึง เจ็ด port บนเซิร์ฟเวอร์เครื่องเดียวกันภายในราวสี่วินาที และถูก drop ทุกครั้ง ลองดู port พวกนี้ด้วย ในทะเบียน port ของ IANA port เหล่านี้เป็นของ FTP, SSH, Telnet, Microsoft-DS (SMB), MS WBT Server (RDP), Microsoft SQL Server และ Remote Framebuffer (protocol ที่ VNC ใช้) จึงไม่ใช่ตัวเลขสุ่ม แต่เป็น remote service ที่พบได้ทั่วไปครับ

MITRE ATT&CK เรียกพฤติกรรมนี้ว่า Network Service Discovery (T1046) คือผู้โจมตีพยายามหา service ที่รันอยู่บนเครื่องปลายทาง รวมถึง service ที่อาจถูก exploit จากระยะไกลได้ โดยมักใช้ port scan หรือ vulnerability scan analytic ตัวหนึ่งของ ATT&CK สำหรับเทคนิคนี้มองหารูปแบบนี้พอดี คือการเชื่อมต่ออย่างรวดเร็วจากจุดเดียวไปยังหลาย service หรือหลาย host

รูปแบบที่ควรจำมีสองแบบ

• Vertical: source เดียว destination เดียว หลาย port (แบบที่เราเพิ่งเห็น)
• Horizontal (sweep): source เดียว port เดียว หลาย destination เช่นคนที่กำลังหาทุกเครื่องที่เปิด port 445

รูปแบบไม่ใช่คำตัดสินนะครับ vulnerability scanner ขององค์กรเราเองก็สร้างรูปแบบเดียวกันนี้โดยตั้งใจ คำถามถัดไปคือ source นี้ควรทำแบบนี้หรือเปล่า?

ขั้นที่ 4: รูปแบบที่ 2 logon ล้มเหลวกระจายไปหลายบัญชี

คราวนี้สลับไปดู log ฝั่ง identity บน Windows การ logon ที่ล้มเหลวคือ event 4625 "An account failed to log on" Microsoft ระบุว่า event นี้ถูกบันทึกทุกครั้งที่ logon ล้มเหลว บนเครื่องที่มีการพยายาม logon field ที่สำคัญที่สุดสำหรับเรามีดังนี้

• Account For Which Logon Failed → Account Name: ชื่อบัญชีที่ถูกลอง
• Logon Type: เช่น 2 (Interactive), 3 (Network) และ 10 (RemoteInteractive สำหรับ Remote Desktop)
• Failure Information → Status / Sub Status: เหตุที่ล้มเหลว
• Network Information → Source Network Address และ Workstation Name: ความพยายามนั้นมาจากไหน

เรื่องเล่าอยู่ใน status code สี่รหัสแรกด้านล่างมาจากตารางสำหรับ monitor ในหน้าเอกสารนั้น ส่วนรหัสสุดท้ายคือค่า Status ที่เอกสารระบุว่า event นี้มักมี โดยมี failure reason ว่า "Account locked out"

นี่คือ Security log สมมติที่ตัดมาบางส่วนจาก domain controller

time_utc              event  target_user  status      sub_status  logon_type  source_ip
2026-10-20T02:17:10Z  4625   alice        0xC000006D  0xC000006A  3           198.51.100.23
2026-10-20T02:17:16Z  4625   bob          0xC000006D  0xC000006A  3           198.51.100.23
2026-10-20T02:17:23Z  4625   carol        0xC000006D  0xC000006A  3           198.51.100.23
2026-10-20T02:17:29Z  4625   dave         0xC000006D  0xC000006A  3           198.51.100.23
2026-10-20T02:17:36Z  4625   erin         0xC000006D  0xC0000064  3           198.51.100.23
...   (อีกเจ็ดบัญชี บัญชีละหนึ่งครั้งในช่วงนี้)
2026-10-20T02:18:44Z  4625   dave         0xC000006D  0xC000006A  3           198.51.100.23
2026-10-20T02:18:52Z  4625   ivan         0xC000006D  0xC000006A  3           198.51.100.23

แบบฝึกหัด: นับจำนวนครั้งที่ล้มเหลวต่อบัญชี แล้วนับจำนวนบัญชีที่ไม่ซ้ำกันต่อ source ดูครับ

 event 4625 (failed logon), synthetic                           
                                                                
                                         PER-USER VIEW          
 alice  · ·   bob    · ·   carol  · ·    max fails/account      
                                         ···············│0/5    
 dave   · ·   erin   · ·   frank  · ·    lockout limit          
                                                                
 grace  · ·   heidi  · ·   ivan   · ·                           
                                         PER-SOURCE VIEW        
 judy   · ·   ken    · ·   lena   · ·    accounts failed        
                                         ······│······ 0        
                                         alert line             
                                                                
                                         counting...            
 src ◆  198.51.100.23                                           
                                                                
 $ group by src, count distinct user                            
 $ _                                                            

ถ้านับต่อบัญชี ไม่มีบัญชีไหนล้มเหลวเกินสองครั้ง lockout threshold ที่ตั้งไว้สูงกว่านั้นจึงไม่ทำงาน แต่ถ้านับต่อ source จะเห็นว่า address เดียวล้มเหลวกับ สิบสอง บัญชีในเวลาไม่ถึงสองนาที นี่คือลายเซ็นของ Password Spraying (T1110.003) คือการลอง password ที่ใช้กันบ่อยหนึ่งตัว (หรือรายการสั้น ๆ) กับหลายบัญชี แทนที่จะลองหลาย password กับบัญชีเดียว เพื่อหลบ lockout โดยเฉพาะ ATT&CK ยังบอกอีกสองเรื่องที่ทำให้มองเห็นยากขึ้น ข้อแรก ผู้โจมตีอาจลดความเร็วเพื่อให้อยู่ใต้เกณฑ์ detection ข้อสอง การ spray ผ่าน LDAP หรือ Kerberos อาจสร้าง event logon ล้มเหลวน้อยกว่าการลองผ่าน SMB ซึ่งมักสร้าง event พวกนี้ ดังนั้นดู 4625 อย่างเดียวอาจไม่เห็นภาพทั้งหมดครับ

บรรทัด 0xC0000064 บรรทัดเดียวเป็นเบาะแสเล็ก ๆ เพิ่มเติม มีคนลอง username ที่ไม่มีอยู่จริง ซึ่งเข้ากับรายชื่อที่ได้มาจากที่อื่นที่ไม่ใช่ directory ของเรา

ขั้นที่ 5: เชื่อมสองเรื่องเข้าด้วยกันด้วยเวลาและ source

วาง log สองชุดไว้ข้างกัน เรื่องจะเล่าตัวมันเองครับ

1. 02:14:01–02:14:04 198.51.100.23 สำรวจ service port เจ็ด port บน 192.0.2.10 รวมถึง SMB (445)
2. 02:17:10–02:18:52 address เดียวกัน logon ล้มเหลวกับสิบสองบัญชีผ่านเครือข่าย (logon type 3)

NIST เรียกสิ่งนี้ว่า event correlation คือการหาความสัมพันธ์ระหว่าง log entry สองรายการขึ้นไป แบบที่พบบ่อยที่สุดคือใช้ rule จับคู่ด้วย timestamp, IP address และประเภทของ event (SP 800-92 หัวข้อ 3.2)

 correlate by source and time, synthetic logs                   
         7 ports              src = 198.51.100.23               
 fw       xx·───────·────·───────·──··─···─────··──·─────────   
                                                                
 dc 4625  ───··──────··──────────────·────xxxxxxxx─xxxx──x─x─   
                                             12 accounts        
          ┬─────────┬─────────┬─────────┬─────────┬─────────┬   
        02:14     02:15     02:16     02:17     02:18     02:19 
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
 $ join fw, dc on src within 10m                                
 $ _                                          clocks: NTP ●     

มีสามเรื่องที่ทำให้การเชื่อมนี้พังได้แบบเงียบ ๆ ตรวจก่อนจะเชื่อผล correlation

• นาฬิกา SP 800-92 เตือนว่าถ้านาฬิกาของเครื่องผิด timestamp ใน log ก็ผิดตาม และยกตัวอย่างว่า log อาจบอกว่า event A เกิดก่อน event B 45 วินาที ทั้งที่จริง A เกิดหลัง B สองนาที วิธีแก้ของ NIST คือ sync นาฬิกาของทุกแหล่ง log เข้ากับแหล่งเวลาเดียวกัน เช่น NTP
• Time zone ระบบหนึ่งเขียนเวลาท้องถิ่น อีกระบบเขียน UTC ให้ normalise ทุกอย่างเป็น zone เดียว (timestamp แบบ RFC 5424 มี offset ติดมาด้วย ช่วยได้มาก)
• NAT ถ้า firewall แปลง source address log ฝั่ง identity อาจเห็น NAT Source IP ไม่ใช่ address ต้นฉบับ field นี้จึงควรเก็บไว้ใน index

ข้อควรระวังทั่วไปอีกข้อ: IP address เป็นเบาะแส ไม่ใช่ตัวบุคคล address ถูกหมุนเวียนให้คนอื่นใช้ได้ ควรเพิ่มบริบทของ user, hostname และเวลาก่อนจะระบุตัวใครครับ

และอย่าข้ามการค้นหาต่อนะครับ หน้าเอกสารของ 4625 เองระบุ event 4624 "An account was successfully logged on" ไว้เป็น event ที่เกี่ยวข้อง (ตัวอย่างในเอกสารคือการจับคู่ด้วย field Logon ID) หลังการ spray บรรทัดที่ผมอยากเจอที่สุดคือ logon ที่ สำเร็จ ของชื่อบัญชีชุดเดียวกันจาก source เดียวกัน ข้อควรระวังจากหน้าเอกสาร 4624 คือ field IP address และ workstation ขึ้นกับ protocol ที่ใช้ network logon ผ่าน Kerberos มักไม่มีข้อมูล workstation ส่วน logon ผ่าน NTLM จะไม่มีรายละเอียด TCP/IP

ขั้นที่ 6: Log management เพื่อให้มี log ตอนที่ต้องใช้

ทุกอย่างข้างบนตั้งอยู่บนสมมติฐานว่า log มีอยู่จริง ส่งมาถึง และถูกเก็บไว้ SP 800-92 Guide to Computer Security Log Management ของ NIST (กันยายน พ.ศ. 2549) ยังเป็นเอกสารอ้างอิงคลาสสิก NIST เผยแพร่ฉบับปรับปรุงที่ยังเป็นร่าง คือ SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide เป็น initial public draft เมื่อ 11 ตุลาคม พ.ศ. 2566 ประเด็นจากฉบับปี พ.ศ. 2549 ที่ผมว่ามีประโยชน์ที่สุดมีดังนี้

• ปัญหาหลัก คือการรักษาสมดุลระหว่างทรัพยากรที่มีจำกัดกับ log ที่ไหลเข้ามาไม่หยุด ยิ่งยากขึ้นเมื่อมีแหล่ง log มาก format และ timestamp ไม่ตรงกัน และปริมาณโตขึ้นเรื่อย ๆ
• ตัดสินใจอย่างตั้งใจว่าจะ log อะไร ตัวอย่างหัวข้อ policy ของ NIST รวมถึงว่าแต่ละส่วนจะ log event ประเภทไหนและบันทึกรายละเอียดอะไร เช่น username และ source IP address สำหรับการพยายามยืนยันตัวตน ซึ่งคือสิ่งที่ขั้นที่ 4 ต้องใช้พอดี
• Normalise field โดยเฉพาะวันที่และเวลา เพื่อให้เทียบข้อมูลต่าง format กันได้
• Aggregate ตัวอย่างของ NIST เอง: entry หนึ่งพันรายการที่แต่ละรายการบันทึกส่วนหนึ่งของการสแกน ยุบรวมเป็น entry เดียวที่บอกว่าสแกนไปกี่เครื่องได้
• Retention กับ preservation retention คือการ archive log ตามรอบปกติ ส่วน preservation คือการเก็บ log ที่ปกติจะถูกทิ้ง เพราะมันบันทึกกิจกรรมที่น่าสนใจ เช่นระหว่างเกิด incident
• Integrity เก็บ message digest ของ log ที่ archive ไว้อย่างปลอดภัย เพื่อให้รู้ได้ว่ามีใครแก้ไขหรือไม่

เรื่อง ควรเก็บนานแค่ไหน SP 800-92 ไม่ได้ให้ตัวเลขเดียว เอกสารบอกว่า retention ควรมาจาก requirement ขององค์กร (กฎหมาย ระเบียบ และ policy ภายใน) และค่าตัวอย่างในเอกสารเป็นแค่จุดเริ่มต้น ไม่ใช่ค่าที่ควรนำไปใช้ทั้งดุ้น เอกสารยังเตือนว่างาน forensic อาจต้องใช้ข้อมูลหลังเหตุการณ์ไปแล้วหลายสัปดาห์หรือหลายเดือน หลักส่วนตัวของผมคือ ตัดสินใจเรื่อง retention ก่อน เกิด incident เพราะเราย้อนกลับไปเก็บสิ่งที่ไม่ได้เก็บไว้ไม่ได้ครับ

ขั้นที่ 7: เปลี่ยนรูปแบบให้เป็น alert โดยไม่จมกองแจ้งเตือน

การจับรูปแบบด้วยตาคือ lab การทำแบบนั้นทุกนาทีโดยอัตโนมัติคืองานจริงครับ นิสัยต่อไปนี้ช่วยให้ alert ยังมีประโยชน์

1. นับสิ่งที่ไม่ซ้ำกัน ต่อ source ต่อช่วงเวลา เช่น destination port ที่ไม่ซ้ำ destination host ที่ไม่ซ้ำ บัญชีที่ล้มเหลวที่ไม่ซ้ำ การนับจำนวน event ดิบ ๆ จะลงโทษเครื่องที่ยุ่งแต่ปกติ การนับแบบไม่ซ้ำจะเจอ รูปทรง ของพฤติกรรม
2. เริ่มจาก baseline ที่รู้ค่า firewall มี threshold ของตัวเองมาให้ ตัวอย่างเช่น reconnaissance protection ของ PAN-OS ตั้งค่า default ให้ TCP port scan ทำงานเมื่อเจอ 100 event ภายใน 2 วินาที และ host sweep ใช้ช่วง 10 วินาที (Reconnaissance Protection settings) สังเกตความหมายของมัน: scan เจ็ด port ของเราจะไม่ทำให้มันทำงานเลย scanner ที่ช้าและระวังตัวอยู่ใต้ threshold แบบตายตัวได้เสมอ จึงควรเพิ่มช่วงเวลาที่ยาวกว่า (เช่น จำนวน port ที่ไม่ซ้ำต่อชั่วโมง) ใน SIEM เป็นตาข่ายชั้นที่สอง
3. ยกเว้นเฉพาะ scanner ของเราเอง และแค่นั้น แนวทางของ Palo Alto เรื่อง exclusion คือให้ยกเว้นเฉพาะ address ของกลุ่มภายในที่เชื่อถือได้ซึ่งทำ vulnerability testing รายการนี้ควรสั้นและถูกทบทวนเสมอ
4. ร้อย signal เข้าด้วยกันเพื่อกำหนด severity scan อย่างเดียวคือระดับต่ำ logon ล้มเหลวกระจายหลายบัญชีอย่างเดียวคือระดับกลาง แต่ scan ตามด้วย spray แล้วมี 4624 สำเร็จจาก source เดียวกัน คือเรื่องที่ควรปลุกคนขึ้นมาดู
5. ใช้ code ให้เป็นประโยชน์ Microsoft ระบุว่า 0xC0000064 (ชื่อบัญชีไม่ถูกต้อง) หลายครั้งติดกันอาจเป็นสัญญาณของ user enumeration นอกจากนี้ Microsoft แนะนำให้เฝ้าดู 4625 ทุกรายการของบัญชี local และ service account เพราะบัญชีพวกนี้ปกติไม่ควรถูก lock out
6. แก้ที่ต้นเหตุ ไม่ใช่แค่ alert mitigation ของ ATT&CK สำหรับ spraying คือ MFA, account use policy (รวมถึง conditional access) และ password policy ที่สมเหตุสมผล ส่วนของ network service discovery คือปิด service ที่ไม่จำเป็น, network intrusion prevention และ network segmentation alert ที่ tune ดีแล้วเป็นเรื่องดี แต่ attack surface ที่เล็กลงดีกว่า
7. ทดสอบด้วยข้อมูลสมมติ เขียน log แบบในบทความนี้ ป้อนเข้า pipeline แล้วตรวจว่า alert ทำงาน และบรรทัดปกติไม่ทำให้มันทำงาน

Checklist ฉบับพกพา

• field ไหนคือ เวลา และนาฬิกาของใครเป็นคนเขียน?
• source เป็น address ต้นฉบับหรือถูกแปลงแล้ว (NAT)?
• group ตาม source แล้ว มี port, host หรือบัญชี ที่ไม่ซ้ำกัน กี่ตัว?
• action และ end reason บอกว่า ถูกบล็อก หรือ ผ่าน?
• source เดียวกันทำอะไร ต่อ (มองหา logon ที่สำเร็จ)?
• source นี้ ควร ทำแบบนี้หรือเปล่า (scanner, admin, ระบบ monitor)?

เมื่อคำถามเหล่านี้กลายเป็นนิสัย กำแพงของจุลภาคจะกลายเป็น timeline และ timeline คือสิ่งที่เราใช้เหตุผลกับมันได้ครับ

แหล่งอ้างอิง

• RFC 5424: The Syslog Protocol (IETF)
• RFC 5426: Transmission of Syslog Messages over UDP (IETF)
• RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog (IETF)
• RFC 5737: IPv4 Address Blocks Reserved for Documentation (IETF)
• Palo Alto Networks: Configure Syslog Monitoring (PAN-OS 11.1)
• Palo Alto Networks: Syslog Field Descriptions (PAN-OS 11.1)
• Palo Alto Networks: Traffic Log Fields (PAN-OS 11.1)
• Palo Alto Networks: Reconnaissance Protection settings (PAN-OS 11.1)
• MITRE ATT&CK T1046: Network Service Discovery
• MITRE ATT&CK T1110.003: Brute Force: Password Spraying
• Microsoft Learn: 4625(F) An account failed to log on
• Microsoft Learn: 4624(S) An account was successfully logged on
• IANA: Service Name and Transport Protocol Port Number Registry
• NIST SP 800-92: Guide to Computer Security Log Management (หน้าเผยแพร่)
• NIST SP 800-92 (PDF)
• NIST SP 800-92 Rev. 1 (Initial Public Draft): Cybersecurity Log Management Planning Guide