บัญชีเมลถูกยึดจริง หรือแค่โดนเดารหัส พิสูจน์ให้ชี้ขาดก่อนแจ้ง
หลักฐานที่แยกคำว่า ถูกยึด ออกจาก แค่โดนเดารหัส มีอยู่ข้อเดียว คือมี IP แปลกหน้าที่ยืนยันตัวตนผ่านได้จริงหรือไม่ ที่เหลือเป็นแค่ข้อสังเกตประกอบ ไม่พอจะไปแจ้งใคร
พอดีคืนหนึ่งผมไล่เมนล็อกของเซิร์ฟเวอร์เมล แล้วเจอบัญชีของลูกค้าที่มีความพยายามล็อกอินเข้ามาจากต่างประเทศวันละหลายร้อยครั้ง ตอนนั้นผมเกือบพิมพ์เมลแจ้งลูกค้าไปแล้วว่าบัญชีของคุณถูกยึด กรุณาเปลี่ยนรหัสด่วน แต่เผอิญหยุดคิดก่อนกดส่ง แล้วกลับไปไล่หลักฐานอีกรอบ ปรากฏว่าไม่ได้ถูกยึด และคำอธิบายจริงเป็นคนละเรื่องกันเลย ผมเลยเก็บวิธีตรวจชุดนี้ไว้ใช้ทุกครั้ง
การบอกลูกค้าว่าบัญชีเมลของเขาถูกยึด ไม่ใช่คำแนะนำเชิงเทคนิคธรรมดา มันเป็นข้อกล่าวหา ที่พอส่งไปแล้วลูกค้าต้องเปลี่ยนรหัสในเครื่องทุกเครื่องที่ใช้บัญชีนั้น ต้องไปตามสแกนคอมพิวเตอร์ในออฟฟิศ บางรายต้องแจ้งคู่ค้าว่าเมลที่ส่งไปช่วงนั้นอาจไม่ใช่ของจริง ถ้าเราแจ้งผิด ต้นทุนตกอยู่กับลูกค้าทั้งหมด แล้วรอบหน้าที่เราแจ้งจริงเขาจะไม่เชื่อ ผมเลยตั้งกฎกับตัวเองว่า ห้ามใช้คำว่าถูกยึด จนกว่าจะมีหลักฐานที่ตอบคำถามข้อเดียวได้
มี IP ที่ไม่ควรเป็นของลูกค้า ยืนยันตัวตนผ่านสำเร็จ อย่างน้อยหนึ่งครั้งหรือไม่ ถ้ามี คือถูกยึด ไม่มีข้อโต้แย้ง ถ้าไม่มี ต่อให้โดนพยายามเดารหัสวันละพันครั้งจากห้าร้อยไอพี ก็ยังไม่ใช่การถูกยึด และห้ามเขียนหาลูกค้าว่าถูกยึดเด็ดขาด จำนวนครั้งที่ล้มเหลวไม่ใช่หลักฐานของการสำเร็จ มันเป็นหลักฐานของการล้มเหลว
บทความนี้เป็นเรื่องการพิสูจน์และการตัดสินล้วนๆ ส่วนวิธีตรวจจับว่ามีเมลขาออกผิดปกติ ผมเขียนไว้แล้วใน ตรวจจับกล่องเมลที่ถูกยึดไปส่งสแปม และวิธีรับมือฝั่งไฟร์วอลล์อยู่ใน ระบบปลดบล็อกอัตโนมัติสำหรับเมล กับ ปลดบล็อกไอพีออฟฟิศที่โดนเครื่องผีในสำนักงานลากไปติดร่างแห ตอนนี้จะไม่เล่าวิธีปลดบล็อกซ้ำ
หลักฐานชี้ขาด อยู่ที่คำว่า A=login: ในเมนล็อก
Exim เขียนบรรทัดรับเมลเข้าคิวด้วยเครื่องหมาย <= แล้วต่อท้ายด้วยข้อมูลว่ารับมาจากไหนและยืนยันตัวตนแบบไหน ฟิลด์ที่สำคัญที่สุดคือ A= ถ้ามันปรากฏเป็น A=login:ชื่อบัญชี แปลว่า รหัสผ่านที่ใช้ในครั้งนั้นถูกต้อง เซิร์ฟเวอร์ตรวจแล้วผ่าน ไม่ใช่ความพยายาม ไม่ใช่การเดา
2026-07-15 16:39:43 1abcde-0000000G33P-2dT1 <= [email protected]
H=(rcxxd) [203.0.113.218] P=esmtpsa X=TLS1.3:TLS_AES_256_GCM_SHA384:256
A=login:[email protected] S=3549
T="Immediate Opening - Part-Time & Flexible" for [email protected]
บรรทัดเดียวนี้บอกครบสี่อย่าง คือ ใครเป็นผู้ส่ง มาจากไอพีไหน ยืนยันตัวตนสำเร็จด้วยบัญชีอะไร และหัวข้อเมลคืออะไร ผมเลยใช้บรรทัดชนิดนี้เป็นวัตถุดิบหลักของทุกการสอบสวน ส่วนบรรทัดที่ขึ้นว่า authenticator failed คือฝั่งล้มเหลว ซึ่งเป็นคนละกองกันและห้ามเอามาปนกัน
# ทดสอบชี้ขาด: ทุก IP ที่ยืนยันตัวตนสำเร็จในนามบัญชีนี้ มีใครบ้าง
[email protected]
LOGS="mainlog.4 mainlog.3 mainlog.2 mainlog.1 mainlog"
for L in $LOGS; do grep -aE " <= .*A=[a-z_]+:$ACCT" "/var/log/exim/$L"; done \
| while IFS= read -r l; do
ip=$(echo "$l" | grep -oE '\[[0-9.]+\]' | tail -1 | tr -d '[]')
cc=$(geoiplookup "$ip" 2>/dev/null | grep -oE '[A-Z]{2},' | head -1 | tr -d ',')
echo "$cc $ip"
done | sort | uniq -c | sort -rn
กับดักแรกคือ ต้องใช้ tail -1 ไม่ใช่ head -1 ตอนคว้าไอพีจากวงเล็บ เพราะวงเล็บอันแรกในบรรทัดคือที่อยู่ในวงแลนที่ตัวโปรแกรมเมลฝั่งลูกข่ายประกาศตัวเองมา เช่น 192.168.10.20 ส่วนอันสุดท้ายถึงจะเป็นไอพีจริงที่วิ่งมาถึงเรา ถ้าหยิบผิดตัว จะได้ผลว่าทุกการเชื่อมต่อมาจากวงแลน ซึ่งไม่มีความหมายอะไรเลย · กับดักที่สองคือ ต้องมีเครื่องหมายจุลภาคต่อท้ายในรูปแบบที่ค้นหา เพราะเครื่องมือค้นประเทศพิมพ์ออกมาว่า GeoIP Country Edition แล้วตามด้วยรหัสประเทศ ถ้าค้นแค่ตัวอักษรใหญ่สองตัวเปล่าๆ จะได้คำว่า IP ที่มาจากคำว่า GeoIP กลับมาทุกบรรทัด แล้วการเทียบประเทศจะพังทั้งชุดโดยไม่มีข้อความผิดพลาดใดๆ ให้เห็น
เคส A ถูกยึดจริง หลักฐานสี่ชั้นที่ซ้อนกัน
บัญชีแรกที่ผมตรวจ ผลจากคำสั่งข้างบนออกมาชัดตั้งแต่บรรทัดแรก
distinct IP ที่ยืนยันตัวตนสำเร็จในนามบัญชีนี้
201 x 203.0.113.55 US โฮสต์คลาวด์ต่างประเทศ (ชื่อเครื่องเป็นแบบที่ผู้ให้บริการคลาวด์ตั้งอัตโนมัติ)
11 x 198.51.100.30 TH เน็ตบ้าน/สำนักงานของลูกค้า
7 x 198.51.100.92 TH เน็ตบ้าน/สำนักงานของลูกค้า
6 x 198.51.100.71 TH เน็ตบ้าน/สำนักงานของลูกค้า
4 x 203.0.113.144 US โฮสต์คลาวด์ต่างประเทศ
... ที่เหลือเป็นไอพีไทยของออฟฟิศทั้งหมด
หลักฐานชั้นแรกคือมีการยืนยันตัวตนสำเร็จ 201 ครั้งจากโฮสต์คลาวด์ต่างประเทศเครื่องเดียว ซึ่งไม่ใช่ที่ทำงานของลูกค้าและไม่ใช่มือถือของพนักงาน ชั้นที่สองคือชื่อเครื่องที่ประกาศตอนทักทาย เป็นชื่อเครื่องเซิร์ฟเวอร์วินโดวส์ที่ระบบคลาวด์ตั้งให้อัตโนมัติ ไม่ใช่ชื่อเครื่องพนักงาน ชั้นที่สามคือฮิสโตแกรมหัวข้อเมล ซึ่งเป็นหลักฐานที่คนอ่านไม่ใช่ช่างก็เข้าใจได้ทันที
# หัวข้อเมลที่ถูกส่งออกในนามบัญชีนี้ เรียงตามจำนวน
for L in $LOGS; do grep -aE " <= .*A=[a-z_]+:$ACCT" "/var/log/exim/$L"; done \
| grep -oE 'T="[^"]*"' | sort | uniq -c | sort -rn | head
190 T="Proof of payment - <ชื่อสายการบิน> NFT Penalty Invoice."
6 T="Price list Inquiry"
4 T="Proof of payment - <ชื่อธนาคาร>"
1 T="SuperMailer Test email"
ชั้นที่สี่คือปลายทาง ผมไล่โดเมนปลายทางออกมาแล้วพบว่าเป็นผู้ให้บริการเมลฟรีของรัสเซียกับยูเครนเป็นหลัก ตามด้วยองค์กรในเอเชียกลาง ทั้งที่บัญชีนี้เป็นของบริษัทไทยที่ทำการค้าในประเทศ ไม่มีความสัมพันธ์ทางธุรกิจกับปลายทางกลุ่มนั้นเลยสักราย
# โดเมนปลายทางที่ถูกส่งไปในนามบัญชีนี้
for L in $LOGS; do grep -aE " <= .*A=[a-z_]+:$ACCT" "/var/log/exim/$L"; done \
| grep -oE 'for [^ ]+@[^ ]+' | awk -F@ '{print $2}' | sort | uniq -c | sort -rn | head
ตัวเลขที่น่าสนใจที่สุดในตารางนี้คือเลขศูนย์ตรงกลาง ไอพีที่ยึดบัญชีไปใช้ ไม่เคยเดารหัสผิดเลยสักครั้ง แปลว่ารหัสไม่ได้ถูกเดาแตก แต่รู้มาก่อนแล้ว ซึ่งชี้ไปที่โปรแกรมขโมยรหัสในเครื่องที่ใช้กล่องเมลนั้น หรือรหัสเดียวกันที่ไปรั่วจากบริการอื่น ประเด็นนี้สำคัญมากเวลาไปคุยกับลูกค้า เพราะถ้าต้นทางเป็นเครื่องติดโปรแกรมขโมยรหัส การเปลี่ยนรหัสอย่างเดียวไม่จบ รหัสใหม่จะรั่วออกไปทางเดิมภายในไม่กี่วัน ต้องไปสแกนเครื่องด้วย
อีกจุดที่ผมเขียนไว้ในรายงานเสมอคือ ชื่อโปรแกรมที่ผู้บุกรุกใช้ ในเคสนี้คือ SuperMailer ซึ่งเป็นโปรแกรมส่งเมลจำนวนมาก และมันหลุดหัวข้อเมลทดสอบของตัวเองออกมาหนึ่งฉบับตอนเริ่มงาน หลักฐานชิ้นนี้ปิดช่องอธิบายทางอื่นได้หมด เพราะไม่มีเหตุผลใดที่พนักงานบัญชีจะต้องใช้โปรแกรมส่งเมลจำนวนมากจากเครื่องเซิร์ฟเวอร์คลาวด์ต่างประเทศ
เคส B ที่ผมเกือบแจ้งผิด ตัวเลขดูน่ากลัวกว่าเคส A ด้วยซ้ำ
บัญชีที่สองอยู่โดเมนเดียวกัน และตอนแรกทุกคนในวงสนทนารวมทั้งผมสรุปไปแล้วว่าน่าจะโดนด้วย เพราะจำนวนความพยายามเข้ามันเยอะกว่าเคสแรกมาก แต่พอรันคำสั่งชี้ขาดตัวเดียวกัน ผลกลับตรงข้าม
# แยกสองกอง: IP ที่เคยสำเร็จ กับ IP ที่ล้มเหลวอย่างเดียว
OK=$(mktemp); FL=$(mktemp)
for L in $LOGS; do grep -aE " <= .*A=[a-z_]+:$ACCT" "/var/log/exim/$L"; done \
| while IFS= read -r l; do echo "$l" | grep -oE '\[[0-9.]+\]' | tail -1 | tr -d '[]'; done \
| sort -u > "$OK"
for L in $LOGS; do grep -a 'authenticator failed' "/var/log/exim/$L" | grep "set_id=$ACCT"; done \
| sed -nE 's/.*\[([0-9.]+)\].*/\1/p' | sort -u > "$FL"
echo "IP ที่ยืนยันตัวตนสำเร็จ : $(wc -l < "$OK")"
echo "IP ที่ล้มเหลวอย่างเดียว : $(comm -13 "$OK" "$FL" | wc -l)"
rm -f "$OK" "$FL"
IP ที่ยืนยันตัวตนสำเร็จ : 10 -> ไอพีไทยของออฟฟิศลูกค้าทั้งหมด
IP ที่ล้มเหลวอย่างเดียว : 516 -> ไม่มีสักตัวที่เคยสำเร็จ
ถูกยึด
- มีไอพีนอกที่สำเร็จ 201 ครั้ง
- ไอพีนั้นไม่เคยล้มเหลวเลย
- หัวข้อเมลเป็นใบแจ้งหนี้ปลอม 190 ฉบับ
- ปลายทางไม่มีความสัมพันธ์ทางธุรกิจ
- ใช้โปรแกรมส่งเมลจำนวนมาก
ไม่ได้ถูกยึด
- ไอพีที่สำเร็จ 10 ตัว เป็นออฟฟิศทั้งหมด
- ไอพีต่างประเทศ 516 ตัว ล้มเหลวล้วน
- ไม่มีเมลขาออกที่ผิดปกติเลย
- ชื่อบัญชีอยู่ในลิสต์ที่คนโจมตีใช้กันทั่วไป
- รหัสยังไม่ถูกเจาะ
คำอธิบายที่ถูกต้องของเคส B คือ ชื่อบัญชีอยู่ในรายการเป้าหมายของการยัดรหัสที่รั่วจากที่อื่น ซึ่งเป็นชื่อที่เดาง่ายและมีอยู่ในหลายโดเมนทั่วโลก มีไอพีต่างประเทศเข้ามาลองวันละร้อยกว่าตัว แต่ละตัวลองแค่หนึ่งถึงสองครั้งเพื่อให้อยู่ใต้เกณฑ์ที่ไฟร์วอลล์จะจับ กระจายกันเป็นการโจมตีแบบกระจายตัว แต่รหัสไม่ได้แตก การเขียนถึงลูกค้าที่ถูกต้องสำหรับเคสนี้คือ ชื่อบัญชีของคุณตกเป็นเป้า แต่รหัสยังปลอดภัย ไม่ใช่ บัญชีคุณถูกยึด สองประโยคนี้ทำให้ลูกค้าทำคนละอย่างกันเลย
ต้นเหตุจริงของอาการ ออฟฟิศส่งเมลไม่ได้ อยู่ในออฟฟิศเอง
เรื่องมันไม่จบแค่นั้น เพราะสิ่งที่ลูกค้าโทรมาบ่นตั้งแต่แรกคือส่งเมลไม่ได้เป็นช่วงๆ ทั้งออฟฟิศ ซึ่งถ้าคิดว่าเป็นเพราะโดนโจมตีจากต่างประเทศก็จะแก้ผิดทาง ผมเลยเปลี่ยนมุมมาไล่เฉพาะ ความล้มเหลวที่มาจากไอพีของออฟฟิศเอง แล้วดูว่าเป็นบัญชีไหน
# ในบรรดาการยืนยันตัวตนที่ล้มเหลว ซึ่งมาจากไอพีของออฟฟิศเอง เป็นของบัญชีไหน
DOM=example.com
for L in $LOGS; do grep -a 'authenticator failed' "/var/log/exim/$L" | grep "set_id=[^ ]*@$DOM"; done \
| sed -nE 's/.*\[([0-9.]+)\].*set_id=([^ )]+).*/\1|\2/p' \
| grep -E '^(198\.51\.100\.)' \
| awk -F'|' '{print $2}' | sort | uniq -c | sort -rn
1336 [email protected]
2 [email protected]
ตัวเลข 1,336 จากทั้งหมด 1,338 ครั้ง คือ 99.85 เปอร์เซ็นต์ มาจากบัญชีเดียว และเป็นบัญชีเดียวกับเคส B ที่รหัสยังดีอยู่ ภาพรวมเลยกลายเป็นแบบนี้ มี เครื่องอัตโนมัติสักตัวในออฟฟิศที่ถือรหัสเก่าไว้ อาจเป็นเครื่องสแกนเอกสารที่ส่งเมล เครื่องพิมพ์ ระบบหลังบ้าน หรือฟอร์มบนเว็บ มันพยายามส่งเมลซ้ำๆ ด้วยรหัสที่ผิด ชั่วโมงละสิบกว่าครั้ง
กฎที่นับความล้มเหลวของการยืนยันตัวตนเพื่อแบนไอพี มันไม่รู้จักคำว่าลูกค้าหรือคนร้าย มันเห็นแค่ไอพีเดียวล้มเหลวเกินเกณฑ์ในเวลาสั้น แล้วแบน 1,800 วินาที ผลคือทั้งออฟฟิศทุกคนทุกกล่องเมลส่งไม่ออกพร้อมกัน แล้วก็หายเองเมื่อครบเวลา วนแบบนี้ทุกหนึ่งถึงสองชั่วโมง ตรงกับที่ลูกค้าบอกว่าเดี๋ยวได้เดี๋ยวไม่ได้เป๊ะ นี่คือความผิดพลาดของการตั้งค่าฝั่งลูกค้า ไม่ใช่การถูกโจมตี และสำคัญมากที่ต้องแยกให้ออก เพราะสองอย่างนี้แก้คนละที่กันคนละแบบ
ทำไมการใส่ไอพีออฟฟิศเข้ารายการยกเว้นทีละตัว แก้ไม่ได้
พอรู้ต้นเหตุแล้ว ทางแก้แรกที่ทุกคนคิดออกคือ ก็ใส่ไอพีออฟฟิศเข้ารายการยกเว้นสิ ผมลองไล่ดูจริงว่าไอพีของออฟฟิศนี้เปลี่ยนบ่อยแค่ไหน เพราะเป็นเน็ตแบบที่ผู้ให้บริการแจกไอพีใหม่ทุกครั้งที่ต่อใหม่
ตัวเลขชุดนี้ปิดทางเลือกทีละข้อ การใส่ไอพีทีละตัวใช้ไม่ได้เพราะสี่สัปดาห์เปลี่ยนไปสิบหกครั้ง และเราไม่รู้ว่าเดือนหน้าจะเป็นเลขอะไร การรวบเป็นวง /24 ก็ไม่ช่วย เพราะสิบหกไอพีนั้นกระจายอยู่คนละ /24 เกือบทั้งหมด มีแค่วงเดียวที่บังเอิญมีสองตัว ส่วนการยกเว้นทั้ง /16 นั้นเป็นทางที่ต้องปฏิเสธตั้งแต่แรก
สิบวง /16 คือประมาณ หกแสนห้าหมื่นที่อยู่ ซึ่งเป็นย่านที่ผู้ใช้ทั่วไปของผู้ให้บริการรายนั้นใช้อยู่ทั้งหมด และในบันทึกช่วงเดียวกันก็มีไอพีจากย่านเดียวกันนี้เข้ามาโจมตีโดเมนนี้เองด้วย การใส่รายการยกเว้นแบบนั้นเท่ากับเปิดประตูให้คนกลุ่มนั้นเข้ามาลองรหัสได้ไม่จำกัด เพื่อแลกกับการแก้อาการของลูกค้าเจ้าเดียว ราคาไม่คุ้มกันเลย ทางที่ถูกคือทำรายการยกเว้นที่ ต่ออายุตัวเองจากพฤติกรรมที่พิสูจน์แล้ว ไม่ใช่รายการที่พิมพ์ค้างไว้
เมื่อสรุปว่าถูกยึดจริง ลำดับงานหลังจากนั้น
ถ้าหลักฐานครบและตัดสินว่าถูกยึดจริง ผมทำตามลำดับนี้เสมอ และจุดที่คนพลาดมากที่สุดคือข้อสองกับข้อสี่
- ตัดทางเข้าก่อน บล็อกไอพีต้นทางที่ยืนยันตัวตนสำเร็จ พร้อมเขียนเหตุผลกำกับไว้ในคำสั่ง เพื่อให้คนที่มาอ่านทีหลังรู้ว่าบล็อกเพราะอะไร
- เปลี่ยนรหัสโดยค้นหาเจ้าของบัญชีจากรายการโดเมน อย่าเดาชื่อผู้ใช้ เพราะชื่อผู้ใช้ในระบบกับชื่อโดเมนมักไม่ตรงกัน เดาผิดแล้วไปแก้รหัสของคนอื่นคือสร้างเหตุการณ์ที่สอง
- ตรวจคิวเมลก่อนลบ ดูรายการที่ค้างในคิวด้วยตาก่อน แล้วค่อยลบเฉพาะที่มาจากบัญชีนั้น อย่าล้างคิวทั้งกอง เพราะเมลของลูกค้ารายอื่นก็อยู่ในคิวเดียวกัน
- ส่งรหัสใหม่ทางช่องทางอื่นที่ไม่ใช่อีเมล เพราะเหตุที่รหัสเดิมรั่วโดยไม่มีการเดาเลย แปลว่ามีเครื่องที่อ่านกล่องเมลนี้ติดโปรแกรมขโมยรหัสอยู่ ถ้าเมลรหัสใหม่เข้าไปในกล่องเดิม ก็รั่วซ้ำทันที
- เตือนลูกค้าเรื่องเครื่องที่ตั้งค่าไว้ทุกเครื่อง ให้ตามแก้พร้อมกันในคราวเดียว ไม่งั้นเครื่องที่ยังถือรหัสเก่าจะกลายเป็นเครื่องผีตัวใหม่ แล้วลากไอพีออฟฟิศไปโดนแบนแบบเคส B
# หาเจ้าของบัญชีจากรายการโดเมน ปลอดภัยกว่าเดาชื่อผู้ใช้จากชื่อโดเมน
OWNER=$(grep -rl '^example\.com$' /usr/local/directadmin/data/users/*/domains.list \
| sed -E 's#.*/users/([^/]+)/.*#\1#')
URL=$(/usr/local/directadmin/directadmin api-url --user="$OWNER")
curl -sk "${URL}/CMD_API_POP" \
--data-urlencode action=modify \
--data-urlencode domain=example.com \
--data-urlencode user=service \
--data-urlencode passwd="<รหัสใหม่>" --data-urlencode passwd2="<รหัสใหม่>"
# ที่ควรได้กลับมา: error=0&text=Account%20password%20changed
# ตรวจก่อน แล้วค่อยลบเฉพาะของบัญชีนั้น
exim -bpc # จำนวนที่ค้างในคิวตอนนี้
exiqgrep -i -f 'service@example\.com' # ดูรายการก่อน
exiqgrep -i -f 'service@example\.com' | xargs -r exim -Mrm
เขียนรายงานให้แยกคำว่า พบ ออกจาก น่าจะ
สิ่งสุดท้ายที่ผมเปลี่ยนหลังจากเคส B คือวิธีเขียนรายงาน เมื่อก่อนผมเขียนรวมกันหมดเป็นเรื่องเล่า ตอนนี้ผมแยกเป็นสามส่วนตายตัว ส่วนแรกคือข้อเท็จจริงที่มีบรรทัดในบันทึกรองรับ ส่วนที่สองคือการตีความ ส่วนที่สามคือสิ่งที่ยังไม่รู้ และห้ามเอาสามส่วนนี้มาปนกันในย่อหน้าเดียว
ข้อเท็จจริงเขียนว่า พบการยืนยันตัวตนสำเร็จ 201 ครั้ง จากไอพีนอกประเทศ ระหว่างวันที่เท่าไรถึงเท่าไร · การตีความเขียนว่า ลักษณะนี้สอดคล้องกับการที่รหัสผ่านรั่วออกไปก่อน ไม่ใช่การเดารหัสแตก · สิ่งที่ยังไม่รู้เขียนว่า ยังไม่ทราบว่ารหัสรั่วจากช่องทางใด ต้องตรวจเครื่องที่ใช้กล่องเมลนี้เพื่อยืนยัน · แค่แยกสามส่วนนี้ออกจากกัน ลูกค้าก็อ่านแล้วรู้ทันทีว่าอะไรคือของแน่ อะไรคือข้อสันนิษฐาน และเราก็ไม่ต้องกลับคำทีหลัง
บทเรียนที่ผมได้จากสองเคสนี้ตรงกันข้อเดียว คือเครื่องมือที่นับความล้มเหลวของการยืนยันตัวตน มองไม่เห็นการถูกยึดบัญชีเลย เพราะคนที่มีรหัสถูกต้องไม่เคยล้มเหลวสักครั้ง สัญญาณที่จับคนกลุ่มนี้ได้คือ ปริมาณเมลขาออก ไม่ใช่จำนวนการล็อกอินที่ล้มเหลว และในทางกลับกัน จำนวนการล็อกอินที่ล้มเหลวมหาศาลก็ไม่ได้แปลว่ามีใครเข้าไปได้ ผมเลยเลิกใช้กราฟความล้มเหลวเป็นตัวตัดสิน แล้วเปลี่ยนมาใช้คำถามข้อเดียวที่เขียนไว้ตอนต้นแทน ใครจะเอาชุดคำสั่งนี้ไปปรับให้เข้ากับรูปแบบบันทึกของเครื่องตัวเองก็ตามสะดวกครับ ตรงไหนผมอธิบายตกหล่นหรือพิมพ์ผิด เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย