วิธีล้าง Password และ Key ใน Config ก่อนส่งไฟล์ให้คนอื่น

ไม่ช้าก็เร็ว network engineer ทุกคนต้องเจอคำขอให้ส่ง config ให้ใครสักคน vendor support ขอ running config เพื่อเปิด case เพื่อนร่วมทีมอยากดูว่าเราทำ VPN ตัวนั้นยังไง หรือกระทู้ในฟอรัมที่น่าจะตอบง่ายขึ้นเยอะถ้าแนบไฟล์จริงไปด้วย เรา copy แล้ว paste และที่ไหนสักแห่งในหลายร้อยบรรทัดนั้นมี SNMP community, pre-shared key และ hash ของ admin ที่เราลืมไปแล้วว่ามันอยู่ตรงนั้นครับ

โพสต์นี้คือ checklist สำหรับช่วงเวลานั้น ครอบคลุมว่า secret ชอบซ่อนอยู่ตรงไหนใน config backup, script และ screenshot วิธีล้างไฟล์โดยไม่ทำให้ไฟล์พัง เครื่องมือที่ช่วยจับสิ่งที่ตาเรามองข้าม และถ้ามีอะไรหลุดออกไปแล้ว ต้องทำอะไรก่อนหลัง ท้ายแต่ละหัวข้อมีช่องให้ติ๊กครับ

ทำไมเรื่องนี้ควรมี checklist

ผู้โจมตีรู้ดีว่าต้องหาที่ไหน MITRE ATT&CK จัด Credentials In Files เป็น sub-technique T1552.001 ภายใต้ tactic Credential Access โดยอธิบายว่าผู้โจมตีจะค้น file system และ file share หาไฟล์ที่เก็บ credential ไว้อย่างไม่ปลอดภัย ทั้ง configuration file ที่ฝัง password ไว้, source code ที่ hard-code password และไฟล์ backup ส่วน mitigation ที่ ATT&CK ระบุไว้ก็ตรงไปตรงมาและใช้ได้จริง คือ audit หาไฟล์ที่มี password, ห้ามเก็บ password ไว้ในไฟล์, จำกัดสิทธิ์ของ file share และอบรม admin กับ developer ให้รู้ความเสี่ยงของ password แบบ plaintext ใน config

ฝั่ง developer ก็มีรายการของตัวเอง CWE-798, Use of Hard-coded Credentials อธิบายถึงผลิตภัณฑ์ที่ฝัง password หรือ key ไว้ข้างใน ไม่ว่าจะใช้ตรวจคนที่ login เข้ามา (inbound) หรือใช้ให้ตัวผลิตภัณฑ์เชื่อมต่อไปยังระบบอื่น (outbound) สำหรับกรณี inbound CWE ชี้ว่า password ที่ hard-code ไว้จะเหมือนกันในทุก installation ดังนั้นเมื่อมันถูกค้นพบหรือเผยแพร่ออกไป ใครก็ตามที่รู้ password นี้ก็เข้าใช้งานได้ และ weakness นี้อยู่ในรายการ CWE Top 25 ทุกฉบับตั้งแต่ปี 2019 ถึง 2024 (พ.ศ. 2562 ถึง 2567)

อุปกรณ์เครือข่ายก็ไม่ได้รับการยกเว้น ตัวอย่างที่ดีคือ advisory ของ Fortinet FG-IR-19-007 (CVE-2019-6693) ที่ FortiOS ใช้ key แบบ hard-code ในการเข้ารหัสค่า credential แบบ "ENC" ใน CLI configuration และไฟล์ backup ใครที่รู้ key และมีสำเนาไฟล์ก็กู้ค่าเหล่านั้นกลับมาได้ รายการใน NVD ระบุว่าข้อมูลที่เปิดเผยได้คือ password ของ user (ยกเว้นของ administrator), passphrase ของ private key และ password ของ HA, map ไว้กับ CWE-798 และแสดงว่า CISA เพิ่มช่องโหว่นี้เข้า Known Exploited Vulnerabilities catalog เมื่อ 25 มิถุนายน พ.ศ. 2568 ทางแก้คือ setting ชื่อ private-data-encryption ที่เปลี่ยนจาก key ในตัวมาใช้ key ที่เราตั้งเอง ระหว่างที่ยังไม่ได้แก้ Fortinet แนะนำให้ตั้ง password ป้องกันไฟล์ backup และหลีกเลี่ยงการแชร์ config แบบสาธารณะ

บทเรียนที่ผมได้จากเรื่องนี้คือ ค่าที่ดูเหมือนถูกเข้ารหัสใน config ไม่ได้แปลว่าแชร์ได้อย่างปลอดภัยเสมอไป ให้ถามทุกครั้งว่า key อะไรปกป้องค่านั้นอยู่ และใครอีกบ้างที่มี key นั้นครับ

Secret ชอบซ่อนอยู่ตรงไหนใน network config

เวลาผมตรวจไฟล์ก่อนส่งออกไป ผมจะมองหาค่าตามกลุ่มเหล่านี้ ตารางนี้เขียนแบบกลาง ๆ แต่ละ vendor สะกด keyword ต่างกันไปครับ

บางกลุ่มต้องดูให้ละเอียดขึ้น

Cisco type 7 ไม่ใช่การเข้ารหัส เอกสารของ Cisco เอง Protecting Secrets on Cisco Network Devices อธิบายว่าการตั้งค่า password-encryption ที่มีมานานสร้างค่า type 7 ด้วย Vigenère cipher ที่ใช้ static key ฝังอยู่ในระบบปฏิบัติการ และ key นี้ถูกค้นพบต่อสาธารณะมาหลายสิบปีแล้ว type 7 จึงควรถูกมองเหมือน plain text เอกสารเดียวกันแบ่ง secret ในอุปกรณ์เป็นแบบ non-reversible (password สำหรับ login ที่อุปกรณ์แค่ตรวจ) กับแบบ reversible (key ของ TACACS+/RADIUS, key สำหรับ routing authentication) ที่อุปกรณ์ต้องถอดรหัสออกมาใช้ และยังเล่าว่าผู้โจมตีได้ config ไปด้วยวิธีไหนบ้าง เช่น ใช้ credential ที่รู้อยู่แล้ว, ขโมย flash card, เจอ TFTP หรือ HTTP server ที่ไม่มีการยืนยันตัวตนซึ่งเก็บ config file ไว้ และไฟล์ที่ถูกเก็บไปจากคอมพิวเตอร์ส่วนตัวของ admin

SNMP community คือ password RFC 3410 (Section 8.2) ระบุว่า SNMPv1 และ SNMPv2c รองรับแค่ authentication แบบ trivial ที่อาศัย community string แบบ plain text ทำให้ไม่ปลอดภัยโดยพื้นฐาน ถ้า community อยู่ในไฟล์ ใครที่อ่านไฟล์ได้ก็ได้สิทธิ์เท่ากับที่ community นั้นได้รับ

ก้อนที่ถูกเข้ารหัสขึ้นอยู่กับ key ของมัน Firewall ของ Palo Alto Networks เข้ารหัส password และ private key ทั้งหมดด้วย master key และ เอกสารเรื่อง master key แนะนำให้ตั้ง key ของเราเองแทนการใช้ค่า default ถึงอย่างนั้นผมก็ยังลบก้อนเหล่านี้ออกก่อนแชร์ เพราะคนที่รับไฟล์ไม่จำเป็นต้องใช้มัน และผมไม่อยากต้องพึ่งว่า key ถูกดูแลมาดีแค่ไหนครับ

Hash ก็ยังเป็น secret เอกสารของ Cisco ถือว่า type 8, 9 และ 10 เป็นแบบที่ปลอดภัย เพราะใช้ hashing ที่แข็งแรงและวนซ้ำหลายรอบจนการ crack ทำได้ยากมาก ซึ่งดีกว่า type 7 มาก แต่เอกสารเดียวกันก็ชี้ว่าบรรทัด account ที่เป็น hash นั้นย้ายไปใช้ที่อื่นได้ ถ้านำไปตั้งค่าในอุปกรณ์อีกเครื่อง ก็จะได้ user เดิมพร้อม password เดิม บวกกับความเสี่ยงทั่วไปที่ว่า password ที่อ่อนซึ่งซ่อนอยู่หลัง hash ที่แข็งแรงก็ยังถูกเดาแบบ offline ได้ จึงแทบไม่มีเหตุผลดี ๆ ที่จะต้องส่ง hash ให้ใครครับ

Checklist:

• ค้นหา keyword ทุกกลุ่มในตาราง สำหรับทุก vendor ที่อยู่ในไฟล์
• มอง type 7 และค่าที่แค่ "obfuscate" ไว้ว่าเป็น plain text
• มอง hash, ก้อนที่เข้ารหัส และ certificate ว่าเป็นข้อมูลอ่อนไหวด้วย
• ดูให้ไกลกว่า config หลัก: script, ตัวแปรของ Ansible หรือ Terraform, ไฟล์ .env, spreadsheet ที่ export ออกมา และ screenshot ของ CLI session

ล้าง config ก่อนแชร์

                replace the value, keep the line                
                                                                
  ┌─ backup.cfg ───────────────────────────────┐                
  │ hostname <HOST-1>                          │                
  │ interface ethernet1/1                      │  raw value     
  │  ip address <IP-1>/24                      │    found       
  │ !                                          │  placeholder   
  │ username admin secret 9 <REDACTED>         │                
  │ snmp-server community <REDACTED> ro        ┃                
 ▶│ !                                          ┃◀ scanner       
  │ crypto ikev2 keyring PEERS                 ┃                
  │  pre-shared-key Tr0ub4dor&3                ┃                
  │ !                                          ┃  keywords      
  │ tacacs-server key 7 0822455D0A16           │  stay put      
  │ api-key LUFRPT1xYz9q==                     │                
  └────────────────────────────────────────────┘                
                                                                
  $ sanitize backup.cfg > backup-share.cfg                      

คนที่เราส่งไฟล์ไปให้มักต้องการ รูปร่าง ของมัน ว่าเปิด feature อะไรไว้, policy เรียงลำดับยังไง, peer ไหนใช้ proposal ไหน แทบไม่เคยต้องการค่าจริง กฎที่ผมใช้จึงเป็น replace อย่า delete ครับ

การลบทั้งบรรทัดทำให้ไม่เห็นเลยว่า feature นั้นมีอยู่ และคนที่ตรวจอาจไปไล่หาปัญหาที่ไม่มีอยู่จริง การแทนแค่ค่าทำให้หลักฐานยังครบ:

snmp-server community <REDACTED> ro
crypto ikev2 keyring PEERS
 pre-shared-key <REDACTED>
logging host <IP-2>

นิสัยเล็ก ๆ ที่ช่วยให้ได้ผลดีขึ้น

1. ใช้ placeholder ให้สม่ำเสมอ ถ้า peer address เดียวกันโผล่ห้าที่ ให้ใช้ tag เดียวกันทุกที่ (<PEER-1>) คนอ่านจะยังตามตรรกะได้ เช่น "tunnel ไป PEER-1 ใช้ proposal B"
2. เก็บตาราง mapping ไว้ offline ถ้าต้องแปลคำตอบของ support engineer กลับเป็นค่าจริง ให้เก็บตาราง placeholder-to-value ไว้ในเครื่องเราเอง ห้ามอยู่ในไฟล์ที่แชร์หรือใน ticket
3. ทำบนสำเนา ล้าง backup.cfg ออกมาเป็น backup-share.cfg อย่าแก้ backup ชุดเดียวที่เรามี
4. ให้เครื่องมือเงียบ script ที่ใช้ล้างควรรายงานว่าเจออะไร ที่ไหน (ไฟล์, บรรทัด, ประเภท) ไม่ใช่พิมพ์ secret ออกมา ไม่อย่างนั้น terminal history และ log จะกลายเป็นจุดรั่วถัดไป gitleaks ก็ใช้แนวคิดเดียวกันกับ flag --redact ที่ซ่อน secret ใน output ของมันเอง (gitleaks README)
5. Diff ก่อนส่ง เทียบไฟล์ต้นฉบับกับสำเนาที่ล้างแล้วแบบ side by side ทุกบรรทัดที่เปลี่ยนต้องเป็นบรรทัดที่เราตั้งใจเปลี่ยน และทุก secret ต้องอยู่ในบรรทัดที่เปลี่ยนแล้ว
6. ตรวจ screenshot สองรอบ blur หรือ crop ก่อน paste เพราะเครื่องมือค้นหาข้อความใน screenshot แบบที่ค้นในไฟล์ข้อความไม่ได้ ข้อนี้จึงต้องพึ่งตาเราเอง

Checklist:

• ล้างบนสำเนา ไม่ใช่ต้นฉบับ
• แทนค่าด้วย placeholder ที่สม่ำเสมอ เก็บ keyword และบรรทัดไว้ครบ
• ตาราง mapping เก็บไว้ offline
• Diff ต้นฉบับกับสำเนาที่ล้างแล้ว
• Screenshot ถูก crop หรือ blur แล้ว

Scan repo และโฟลเดอร์

การตรวจด้วยตาพลาดได้ โดยเฉพาะในไฟล์ยาว ๆ และ commit เก่า ๆ เครื่องมือสองแบบช่วยได้ครับ

GitHub secret scanning secret scanning ของ GitHub หา credential ทั่วทั้ง Git history ในทุก branch รวมถึง issue, pull request, discussion, wiki และ secret gist ทำงานอัตโนมัติฟรีบน public repository ส่วน private repository ที่องค์กรเป็นเจ้าของต้องใช้ GitHub Secret Protection สำหรับ secret ของ partner GitHub จะแจ้งผู้ให้บริการที่ออก secret นั้นให้ดำเนินการ เช่น revoke token และเมื่อมี alert คำแนะนำของ GitHub คือให้ rotate credential ทันที

Push protection Push protection block การ push ที่มี secret ที่รองรับก่อนจะเข้า repo แบบระดับ user เปิดไว้เป็น default บน GitHub.com และครอบคลุมการ push ไป public repository ส่วนแบบระดับ repository ปิดไว้เป็น default และต้องมี Secret Protection สำหรับ push protection ระดับ repository โดย default คนที่มีสิทธิ์ write สามารถ bypass ได้ แต่ต้องเลือกเหตุผล การ bypass จะถูกบันทึกใน audit log และ owner, security manager กับ repository administrator ที่ watch repository นั้นอยู่จะได้รับ email แจ้ง

gitleaks ทั้งในเครื่องและใน CI gitleaks เป็น scanner ที่ใช้ license MIT สำหรับ git repo, directory และ stdin คำสั่งที่ผมใช้บ่อย:

gitleaks git -v path_to_repo           # scan history ของ repo
gitleaks dir -v path_to_config_folder  # scan ไฟล์ที่ไม่ได้อยู่ใน git เช่นโฟลเดอร์ backup
gitleaks git --redact -v .             # เหมือนกัน แต่ไม่พิมพ์ secret ออกมา

มันรันเป็น pre-commit hook ได้ secret จึงถูกจับก่อนจะถูก commit และรับไฟล์ .gitleaks.toml สำหรับ rule ที่กำหนดเอง ซึ่งเป็นที่ที่เราจะเพิ่ม pattern ของ keyword ของ vendor ที่เราใช้ ข้อสังเกตจาก README: ผู้ดูแลระบุว่า gitleaks feature complete แล้ว release ต่อจากนี้จะเป็นแค่ security patch

ทั้งสองเครื่องมือไม่ได้เข้าใจ config ของอุปกรณ์เครือข่ายทุกยี่ห้อตั้งแต่แกะกล่อง ผล scan ที่สะอาดจึงแปลว่า "ไม่เจออะไรชัด ๆ" ไม่ใช่ "ไม่มีอะไรเลย" OWASP Secrets Management Cheat Sheet แนะนำให้ตรวจจับตั้งแต่เนิ่น ๆ (ใน IDE หรือด้วย pre-commit hook) และใช้มากกว่าหนึ่งเครื่องมือ แล้วรวมผลที่ซ้ำกันครับ

Checklist:

• เปิด secret scanning และ push protection ในที่ที่ทำได้
• gitleaks (หรือเครื่องมือคล้ายกัน) เป็น pre-commit hook และอยู่ใน CI
• มี rule ที่กำหนดเองสำหรับ keyword ของ vendor ที่ใช้
• Scan โฟลเดอร์ backup ด้วย ไม่ใช่แค่ repo

เก็บ secret ให้ถูกที่

วิธีที่ดีที่สุดที่จะไม่ต้องมาล้าง secret ออกจากไฟล์ คือไม่เอามันใส่ไฟล์ตั้งแต่แรก ประเด็นหลักของ OWASP cheat sheet สรุปสั้น ๆ:

• รวมศูนย์ secret ไว้ใน secrets manager และบันทึกว่าแต่ละตัวใช้ทำอะไรและใช้ที่ไหน
• Least privilege: ไม่ใช่ engineer ทุกคนต้องอ่าน secret ได้ทุกตัว ให้สิทธิ์ราย secret ถ้า platform รองรับ
• ทำ rotation อัตโนมัติ และเลือกใช้ credential แบบ dynamic อายุสั้นเมื่อทำได้
• อย่าเก็บ secret ไว้ใน code, config file หรือ container image ให้แอปดึงตอน runtime OWASP ยังเตือนว่า environment variable อาจรั่วผ่าน log และ dump ได้
• ห้าม log secret

สำหรับอุปกรณ์เครือข่าย แปลเป็นงานที่จับต้องได้ไม่กี่อย่าง คือใช้รูปแบบการเก็บที่แข็งแรงที่สุดที่ platform รองรับ ตั้ง key ของอุปกรณ์เอง (config key สำหรับ Cisco type 6, master key ของ Palo Alto, private-data-encryption ของ FortiOS) และเก็บ key เหล่านั้นแยกจาก config ที่มันปกป้อง ตามที่เอกสารของ Cisco แนะนำไว้สำหรับ key ของ type 6 ครับ

ถ้า secret รั่วไปแล้ว: rotate ก่อน แล้วค่อยล้าง

              rotate first, then clean the history              
                                                                
┌─ git history ──────┐   ┌── VAULT ─────┐                       
│ a1f3 add config    │   │            ◇ │                       
│ c7e9 fix vpn       │   │              │     ┌─ service ──────┐
│ 9b02 key=Kx7qP2v9  │   │ ● Kx7qP2v9   │     │                │
│ e44d docs          │   │              │•─•──│ uses Kx7qP2v9  │
│ ...                │   │              │     │                │
└────────────────────┘   │              │     └────────────────┘
                         │              │                       
                         └──────────────┘                       
                                                                
                      1 rotate → 2 revoke → 3 clean history     
                                                                
ops>                                                            
                                                                

เราอยากรีบลบ commit หรือกระทู้ในฟอรัมทันที ให้หยุดก่อนแล้วสลับลำดับครับ ทั้ง GitHub และ OWASP ให้การ revoke มาก่อน

1. Rotate และ revoke คู่มือของ GitHub เรื่อง การลบข้อมูลอ่อนไหวออกจาก repository บอกว่าขั้นแรกคือ revoke หรือ rotate secret และเมื่อมันใช้งานไม่ได้แล้ว นั่นอาจแก้ปัญหาได้โดยไม่ต้องเขียน history ใหม่ ส่วนขั้นตอน incident ของ OWASP คือ revoke, rotate, remove แล้วจึง log
2. ตรวจว่ามันถูกใช้หรือยัง ขั้น log ของ OWASP คือการรู้ว่าใครเข้าถึงได้และ secret ถูกใช้เมื่อไร ให้ดู authentication log ของ account หรือ key นั้น
3. แล้วค่อยล้าง ถ้ายังจำเป็นต้องเอาค่าออก (เช่นมันเผย pattern ที่เราใช้ซ้ำ) คู่มือของ GitHub ใช้ git-filter-repo เพื่อลบไฟล์ออกจากทุก history หรือแทนข้อความด้วย --replace-text และบอกต้นทุนไว้ตรง ๆ: commit hash เปลี่ยน, clone เก่าและ fork ยังมีข้อมูลอยู่, คนที่ pull แล้ว push จาก clone เก่าอาจเอามันกลับเข้ามา และ cached view อาจต้องให้ GitHub Support จัดการ

รายการผลข้างเคียงนั้นคือเหตุผลที่ดีที่สุดที่ต้องทำข้อ 1 ก่อน หน้า secret scanning ของ GitHub เองก็พูดตรงกัน ว่าการเขียน history ใหม่นั้นช้า และมักไม่จำเป็นเมื่อ credential ถูก revoke ไปแล้วครับ

Checklist หน้าเดียวก่อนแชร์

Copy อันนี้ไปไว้ในโน้ต, template ของ ticket หรือ wiki ของทีมได้เลยครับ

ก่อนแชร์ config, script หรือ screenshot

• ทำบนสำเนา ตั้งชื่อให้ไม่มีใครเข้าใจผิดว่าเป็น backup จริง
• ค้นหาแล้ว: password และ hash, key แบบ reversible (TACACS+, RADIUS, routing, IKE PSK), SNMP community และ key ของ v3, API key และ token, private key และ certificate
• มอง type 7 และค่าที่แค่ "obfuscate" ไว้ว่าเป็น plain text
• เอาก้อนที่เข้ารหัสและ hash ออกด้วย
• แทน hostname, public IP, username และชื่อองค์กรด้วย placeholder ที่สม่ำเสมอ
• ตาราง mapping ของ placeholder เก็บไว้ offline
• รัน scanner กับสำเนาที่ล้างแล้ว (gitleaks dir พร้อม --redact)
• Diff ต้นฉบับกับสำเนาที่ล้างแล้ว
• Screenshot ถูก crop หรือ blur แล้ว
• ส่งผ่านช่องทางที่ได้รับอนุญาต ไปถึงคนที่ต้องใช้จริง

ถ้ามีอะไรรั่ว

• Rotate และ revoke ก่อน
• ตรวจ log ว่า secret ตัวเก่าถูกใช้หรือไม่
• แล้วจึงล้าง history, ticket และโพสต์
• บันทึกต้นเหตุ (ขาด hook? ขาด rule?) และแก้ให้เรียบร้อย

เรื่องพวกนี้ไม่หวือหวาเลย และนั่นก็ไม่เป็นไร การเช็กไม่กี่นาทีก่อนกดส่ง ถูกกว่าการต้องมา rotate ทุก key ใน firewall cluster ทีหลังมากครับ

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

• MITRE ATT&CK, T1552.001 Unsecured Credentials: Credentials In Files
• MITRE CWE-798, Use of Hard-coded Credentials
• Fortinet PSIRT, FG-IR-19-007: Hardcoded symmetric key in FortiOS configuration backups
• NVD, CVE-2019-6693
• Cisco, Protecting Secrets on Cisco Network Devices (PDF)
• RFC 3410, Introduction and Applicability Statements for Internet-Standard Management Framework
• Palo Alto Networks, Device > Master Key and Diagnostics
• OWASP Secrets Management Cheat Sheet
• GitHub Docs, About secret scanning
• GitHub Docs, About push protection
• GitHub Docs, Removing sensitive data from a repository
• gitleaks on GitHub