Gitleaks kiểm tra lộ proxy credentials: rule, baseline, lab

Gitleaks kiểm tra lộ proxy credentials là việc dùng công cụ quét bí mật Gitleaks để tìm tên đăng nhập và mật khẩu proxy bị ghi vào mã nguồn, tệp cấu hình, tài liệu hay log trong kho Git. Bộ rule mặc định của Gitleaks rất mạnh với khóa API của các dịch vụ lớn, nhưng không có rule riêng cho proxy. ProxyVN dựng một repo lab chỉ chứa bí mật giả, áp regex của rule mặc định và ba rule tự viết lên chín kiểu ghi proxy hay gặp, rồi thử baseline để chỉ báo lỗi mới.

Gitleaks kiểm tra lộ proxy credentials: tác vụ cụ thể và ranh giới với bài đã có

Bài này giải một việc: trước khi đẩy mã lên kho chung, biết chắc không có thông tin proxy nào nằm trong đó. Proxy trả phí thường xác thực bằng user và mật khẩu. Ai có cặp này là dùng được băng thông của anh em, trên tài khoản của anh em.

Proxy credentials lọt vào repo bằng đường nào

Đường thứ nhất là mã nguồn. Lập trình viên dán URL proxy đầy đủ vào biến để thử nhanh rồi quên xóa. Đường thứ hai là tệp .env hay tệp cấu hình bị đưa vào Git vì thiếu dòng trong .gitignore.

Đường thứ ba là danh sách proxy dạng ip:port:user:pass mà nhà cung cấp gửi, được lưu thẳng thành tệp văn bản trong repo cho tiện. Đường thứ tư là log: crawler in URL proxy khi kết nối, tệp log bị commit kèm. Đường thứ năm là tài liệu: lệnh mẫu trong README dùng proxy thật thay cho chỗ trống.

Thiệt hại khi lộ proxy

Proxy bị lộ thường bị dùng để chạy lưu lượng của người khác: cào dữ liệu, gửi spam, tạo tài khoản hàng loạt. Với proxy tính theo băng thông, hóa đơn tăng. Với proxy tính theo cổng, tốc độ giảm vì có người dùng chung. Tệ hơn, IP proxy bị đưa vào danh sách đen vì hành vi của người khác.

Proxy dùng để nuôi tài khoản còn có rủi ro riêng. Người dùng trộm đăng nhập tài khoản khác qua cùng IP, liên kết các tài khoản của anh em với tài khoản lạ trong mắt hệ thống chống gian lận. Bài vì sao mua proxy bị block nói về các nguyên nhân IP bị chặn, trong đó có chuyện dùng chung ngoài ý muốn.

Phần lớn nhà cung cấp không hoàn tiền cho băng thông bị dùng trộm khi lỗi nằm ở phía khách hàng. Phát hiện sớm là cách duy nhất để giới hạn thiệt hại.

Vì sao lộ trong Git khó gỡ

Git giữ lịch sử. Xóa dòng chứa mật khẩu ở commit mới không xóa nó khỏi các commit cũ. Ai clone repo vẫn đọc được bằng git log. Viết lại lịch sử để xóa hẳn là việc tốn công, phải ép đẩy và mọi người phải clone lại.

Khi mật khẩu proxy đã vào lịch sử Git, cách xử lý đúng là đổi mật khẩu, không phải xóa dòng. Quét trước khi commit rẻ hơn rất nhiều so với dọn sau khi lộ.

Gitleaks làm gì

Gitleaks là công cụ mã nguồn mở viết bằng Go. Theo trang GitHub của Gitleaks, công cụ quét lịch sử Git bằng lệnh gitleaks git, quét thư mục hay tệp bằng gitleaks dir, và đọc từ đầu vào chuẩn bằng gitleaks stdin. Mỗi phát hiện có tên rule, tệp, dòng, commit, độ hỗn loạn và một dấu vân tay để bỏ qua khi cần.

Phát hiện dựa trên rule. Mỗi rule là một biểu thức chính quy, kèm từ khóa để lọc nhanh, ngưỡng độ hỗn loạn để bỏ chuỗi quá đơn giản, và danh sách cho phép để bỏ ví dụ hay chỗ trống.

Ranh giới với bài đã có

Các bài về bảo mật proxy trên ProxyVN đã khuyên không chia sẻ và che mật khẩu. Bài xác thực proxy bằng IP whitelist hay user password so hai cách xác thực. Bài này đi vào công cụ: viết rule, chạy quét, đọc kết quả, dựng baseline và phân loại phát hiện.

Phát hiện URL proxy chứa mật khẩu trong repo và log, viết rule và baseline có giới hạn khi Gitleaks kiểm tra lộ proxy credentials

Phần này phân tích các kiểu ghi proxy, vì sao rule mặc định bỏ sót và cách viết rule riêng cho từng kiểu.

Năm kiểu ghi proxy cần bắt

Năm kiểu ghi proxy

Bảng: Năm kiểu ghi proxy cần bắt

Kiểu ghi	Ví dụ giả	Hay nằm ở
URL proxy HTTP có user và mật khẩu	http://user:matkhau@ip:port	Mã nguồn, .env
URL proxy SOCKS5 có user và mật khẩu	socks5h://user:matkhau@ip:port	Mã nguồn Python
Dòng ip:port:user:pass	203.0.113.51:8000:userA:matkhau	Tệp danh sách proxy
Header Proxy-Authorization Basic	Basic chuỗi base64	Log gỡ lỗi
Lệnh curl -x có user và mật khẩu	curl -x http://user:matkhau@ip:port	README, ghi chú

Kiểu thứ ba rất phổ biến ở Việt Nam vì nhiều nhà cung cấp gửi proxy theo định dạng này. Bài định dạng proxy giải thích các định dạng và cách chuyển đổi.

Vì sao rule mặc định bỏ sót

Rule mặc định và rule riêng

Cấu hình mặc định của Gitleaks có hơn hai trăm rule, phần lớn nhận dạng khóa có tiền tố riêng của từng dịch vụ như AWS, GitHub, Slack. Proxy không có tiền tố riêng. Mật khẩu proxy chỉ là chuỗi chữ số bình thường đặt sau dấu hai chấm trong URL.

Rule chung generic-api-key tìm chuỗi đứng sau các từ như key, token, secret, password kèm dấu bằng hay dấu hai chấm. URL proxy không có cấu trúc này. Rule curl-auth-user tìm curl kèm -u hoặc --user, trong khi lệnh qua proxy dùng -x. Lab bên dưới cho thấy cả hai rule đều không bắt được dòng nào trong chín dòng có bí mật proxy.

Rule cho URL proxy

Rule đầu bắt URL có lược đồ http, https, socks4, socks4a, socks5 hoặc socks5h, theo sau là user, dấu hai chấm, mật khẩu, dấu @ và tên máy. Mật khẩu là nhóm bắt thứ hai, được dùng để tính độ hỗn loạn.

Rule loại trừ các ký tự hay gặp trong chỗ trống như dấu ngoặc nhọn, dấu đô la, dấu nhỏ hơn và lớn hơn. Nhờ vậy URL dạng biến môi trường hay mẫu có ngoặc nhọn không khớp từ đầu. Mật khẩu phải dài ít nhất sáu ký tự để bỏ các ví dụ như user:pass.

Thử regex trước khi đưa vào cấu hình

Viết regex cho bí mật rất dễ sai theo hai hướng: quá rộng thì báo nhầm hàng loạt, quá hẹp thì bỏ sót. Cách làm an toàn là dựng một tệp mẫu gồm cả dòng phải bắt và dòng không được bắt, chạy regex lên tệp đó, chỉnh cho tới khi kết quả đúng hết.

Repo lab của bài chính là tệp mẫu như vậy, chia thành ba nhóm: bí mật giả trông như thật, chỗ trống trong tài liệu, và chuỗi không liên quan proxy. Khi đổi regex, chạy lại cả ba nhóm để chắc không làm hỏng chỗ đã đúng.

Rule cho dòng ip:port:user:pass

Rule thứ hai bắt bốn trường ngăn bằng dấu hai chấm, trường đầu là địa chỉ IPv4, trường hai là cổng. Rule không có từ khóa lọc trước vì dòng này không chứa chữ cố định nào. Gitleaks vẫn chạy được, chỉ chậm hơn một chút trên repo lớn.

Rule cho header Basic

Rule thứ ba bắt dòng Proxy-Authorization: Basic kèm chuỗi base64. Chuỗi này giải mã ra user:mật khẩu, nên lộ header là lộ mật khẩu. Header này hay xuất hiện trong log gỡ lỗi của thư viện HTTP khi bật mức chi tiết.

Baseline có giới hạn

Repo đã có lịch sử thường có sẵn nhiều phát hiện cũ. Baseline là một báo cáo Gitleaks dùng làm mốc: lần quét sau chỉ báo phát hiện không có trong mốc. Cách này cho phép bật kiểm tra ngay mà không chặn mọi người vì lỗi cũ.

Giới hạn quan trọng: baseline không làm bí mật cũ an toàn hơn. Nó chỉ tạm ẩn chúng. Mỗi dòng trong baseline vẫn là một mật khẩu cần đổi. Nên coi baseline là danh sách việc, có hạn xử lý, không phải danh sách được tha.

Chuẩn bị phiên bản, secret giả và môi trường thử khi Gitleaks kiểm tra lộ proxy credentials

Lab chạy ngày 29/10/2026 trên Windows 10 với Python 3.12.10. Mọi bí mật trong lab là chuỗi ngẫu nhiên tự đặt, địa chỉ thuộc dải tài liệu 203.0.113.0/24, tên máy dùng miền .test.

Không chạy được tệp Gitleaks

ProxyVN tải bản Gitleaks 8.30.1 cho Windows nhưng chế độ an toàn của môi trường lab chặn việc chạy tệp thực thi tải từ Internet. Vì vậy lab không chạy gitleaks.exe. Thay vào đó, script Python đọc tệp cấu hình mặc định chính thức gitleaks.toml lấy từ nhánh master ngày 29/10/2026, lấy regex, từ khóa, ngưỡng độ hỗn loạn và danh sách cho phép của rule, rồi áp lên repo lab.

Đây là giới hạn lớn nhất của bài. Bộ máy regex của Go và của Python giống nhau ở phần lớn cú pháp nhưng không trùng hết. Script đổi ký hiệu cuối chuỗi \z của Go sang \Z của Python. Kết quả của rule tự viết đã được kiểm bằng Python, cần chạy lại bằng Gitleaks thật trước khi dùng.

Repo lab

Repo lab có bảy tệp mô phỏng một dự án crawler nhỏ:

• src/config.py chứa một URL proxy HTTP và một URL proxy SOCKS5 có mật khẩu.
• .env chứa biến HTTPS_PROXY có mật khẩu.
• proxies.txt chứa hai dòng ip:port:user:pass.
• docs/README.md chứa chỗ trống dạng user:pass, dạng ngoặc nhọn, một lệnh curl -x có mật khẩu giả trông như thật, và hai mẫu có chữ password, example.
• .github/ci.yml chứa URL proxy dùng biến môi trường.
• logs/crawler.log chứa một dòng in URL proxy và một dòng in header Proxy-Authorization.
• src/agent.js chứa URL proxy cho thư viện Node và một URL Redis có mật khẩu.

Script thay cho Gitleaks

Script lab làm bốn việc giống Gitleaks: lọc dòng theo từ khóa, chạy regex, tính độ hỗn loạn Shannon trên nhóm bí mật, rồi áp danh sách cho phép và stopword. Mỗi phát hiện được ghi tệp, dòng, rule, ba ký tự đầu của bí mật, độ hỗn loạn và lý do bị bỏ qua nếu có.

Dấu vân tay trong script là tổ hợp tệp, rule và dòng. Gitleaks thật thêm mã commit khi quét lịch sử. Phần baseline của script so dấu vân tay giữa hai lần quét, giống cách Gitleaks dùng --baseline-path.

Không đưa credentials thật vào lab

Không dùng proxy thật của ProxyVN hay của khách hàng trong bất kỳ tệp nào. Không quét repo của người khác. Bài viết cũng chỉ in ba ký tự đầu của mỗi bí mật giả, phần còn lại thay bằng dấu sao, giống tùy chọn --redact của Gitleaks.

Cấu hình tối thiểu và phạm vi từng thiết lập khi Gitleaks kiểm tra lộ proxy credentials

Toàn bộ rule tự viết nằm trong một tệp proxy-rules.toml, mở rộng cấu hình mặc định.

Tệp cấu hình

title = "proxy credentials"
[extend]
useDefault = true
 
[[rules]]
id = "proxy-url-credentials"
description = "URL proxy co user:password"
regex = '''(?i)\b(?:https?|socks5h?|socks4a?)://([^\s:@/'"<>{}$]{1,64}):([^\s@/'"<>{}$]{6,128})@[a-z0-9.-]+(?::\d{2,5})?'''
secretGroup = 2
entropy = 3.0
keywords = ["://"]
[[rules.allowlists]]
regexes = ['''://(?:user|username|login):(?:pass|password|pwd)@''']
stopwords = ["password", "changeme", "example"]
 
[[rules]]
id = "proxy-ip-port-user-pass"
description = "Dong proxy dang ip:port:user:pass"
regex = '''\b(?:\d{1,3}\.){3}\d{1,3}:\d{2,5}:([^\s:]{2,64}):([^\s:]{6,128})\b'''
secretGroup = 2
entropy = 3.0
 
[[rules]]
id = "proxy-authorization-basic"
description = "Header Proxy-Authorization Basic trong log"
regex = '''(?i)proxy-authorization:\s*basic\s+([a-z0-9+/]{12,}={0,2})'''
secretGroup = 1
entropy = 3.0
keywords = ["proxy-authorization"]

Giải nghĩa từng thiết lập

Bảng: Giải nghĩa từng thiết lập

Thiết lập	Tác dụng	Giá trị lab
useDefault	Giữ toàn bộ rule mặc định, thêm rule mới	true
regex	Biểu thức nhận dạng	Ba biểu thức ở trên
secretGroup	Nhóm bắt chứa bí mật, dùng để tính độ hỗn loạn và so stopword	2, 2, 1
entropy	Ngưỡng độ hỗn loạn Shannon tối thiểu	3.0
keywords	Chuỗi phải có trong dòng thì mới chạy regex	"://", "proxy-authorization"
allowlists.regexes	Bỏ phát hiện nếu toàn chuỗi khớp	Mẫu user:pass, username:password
allowlists.stopwords	Bỏ phát hiện nếu bí mật chứa từ này	password, changeme, example

README của Gitleaks ghi stopwords so với phần bí mật đã tách, còn regexes trong allowlist so với toàn chuỗi khớp. Ghi chú này quan trọng khi viết danh sách cho phép. Từ phiên bản 8.21.0, mục cho phép trong rule đổi tên thành dạng mảng [[rules.allowlists]].

Vì sao ngưỡng 3.0

Rule generic-api-key mặc định dùng ngưỡng 3.5. Mật khẩu proxy do nhà cung cấp cấp thường dài 8 tới 12 ký tự, độ hỗn loạn khoảng 3.0 tới 3.5. Đặt 3.5 sẽ bỏ sót nhiều mật khẩu thật. Lab chọn 3.0 sau khi đo độ hỗn loạn của các mật khẩu giả mười ký tự, đều khoảng 3.32.

Đánh đổi là chuỗi chữ bình thường dài cũng có thể vượt 3.0. Danh sách stopword và điều kiện độ dài tối thiểu giúp giảm báo nhầm.

Lệnh chạy với Gitleaks thật

gitleaks git --config proxy-rules.toml --redact -v .
gitleaks dir --config proxy-rules.toml --redact logs/
gitleaks git --config proxy-rules.toml --report-path baseline.json .
gitleaks git --config proxy-rules.toml --baseline-path baseline.json --report-path new.json .

Hai lệnh đầu quét lịch sử Git và quét thư mục log. Lệnh ba tạo baseline. Lệnh bốn quét lại và chỉ ghi phát hiện mới vào new.json. Các lệnh này lấy theo README, ProxyVN chưa chạy được trong bài.

Chạy đối chứng, đọc kết quả và phân loại phát hiện khi Gitleaks kiểm tra lộ proxy credentials

Script lab quét bảy tệp, ghi mọi chuỗi khớp, đánh dấu chuỗi bị bỏ qua và lý do, rồi tạo baseline và quét lần hai.

Kết quả tổng

Bảng: Kết quả tổng

Chỉ số	Giá trị
Dòng có bí mật proxy giả	9
Phát hiện bởi rule mặc định generic-api-key	0
Phát hiện bởi rule mặc định curl-auth-user	0
Phát hiện bởi rule proxy-url-credentials	6
Phát hiện bởi rule proxy-ip-port-user-pass	2
Phát hiện bởi rule proxy-authorization-basic	1
Tổng phát hiện báo cáo	9
Chuỗi khớp regex nhưng bị bỏ qua	2

Chín dòng có bí mật giả đều bị bắt, mỗi dòng đúng một phát hiện. Rule URL bắt sáu dòng, rule ip:port:user:pass bắt hai dòng, rule header bắt một dòng. Hai chuỗi khớp regex nhưng bị bỏ qua là hai mẫu trong tài liệu, phân tích ở mục dưới.

Rule header được thêm sau lần chạy đầu, khi ProxyVN thấy dòng log Proxy-Authorization không bị rule nào bắt. Đây là cách viết rule hợp lý: chạy, đọc phần bỏ sót, thêm rule, chạy lại.

Để rõ hơn, bảng dưới liệt kê từng phát hiện.

Bảng phát hiện

Bảng: Bảng phát hiện

Tệp	Dòng	Rule	Độ hỗn loạn	Phân loại
.env	1	proxy-url-credentials	3,32	Lộ thật, tệp bí mật bị commit
proxies.txt	1	proxy-ip-port-user-pass	3,32	Lộ thật, danh sách proxy
proxies.txt	2	proxy-ip-port-user-pass	3,32	Lộ thật, danh sách proxy
docs/README.md	3	proxy-url-credentials	3,32	Lộ trong tài liệu, cần thay bằng chỗ trống
logs/crawler.log	1	proxy-url-credentials	3,42	Lộ qua log
logs/crawler.log	2	proxy-authorization-basic	4,42	Lộ qua log, base64 giải ra user:mật khẩu
src/agent.js	1	proxy-url-credentials	3,32	Lộ thật trong mã
src/config.py	1	proxy-url-credentials	3,42	Lộ thật trong mã
src/config.py	2	proxy-url-credentials	3,32	Lộ thật, URL SOCKS5

Không có báo nhầm trong chín phát hiện. Mọi dòng đều chứa bí mật giả mà lab cố tình đặt. Lý do chính là rule viết hẹp, chỉ nhắm vào cấu trúc proxy.

Chuỗi bị bỏ qua đúng

README dòng bốn có hai mẫu. Mẫu username:password khớp regex nhưng có độ hỗn loạn 2,75, dưới ngưỡng 3.0, nên bị bỏ. Mẫu demo:example123 có độ hỗn loạn 3,12, vượt ngưỡng, nhưng chứa stopword example nên bị bỏ.

Các mẫu khác không khớp regex từ đầu. user:pass có mật khẩu bốn ký tự, ngắn hơn sáu. Dạng ngoặc nhọn và dạng biến ${PROXY_PASS} trong tệp CI chứa ký tự bị loại trừ. Đây là hành vi mong muốn: chỗ trống không được báo.

Thứ không bắt được

URL Redis có mật khẩu trong agent.js không bị rule nào bắt. Rule proxy chỉ nhận lược đồ HTTP và SOCKS, còn rule mặc định không có mẫu cho URL Redis kiểu này. Đây không phải lỗi của bài toán proxy, nhưng là lời nhắc: rule proxy không thay cho việc quét bí mật nói chung.

Đọc độ hỗn loạn trong báo cáo

Cột độ hỗn loạn cho thấy mật khẩu giả mười ký tự đều quanh 3,32, header base64 lên 4,42 vì chuỗi dài và đa dạng ký tự hơn. Mẫu username:password chỉ 2,75. Khoảng cách giữa 2,75 và 3,32 là chỗ đặt ngưỡng. Repo có mật khẩu proxy ngắn hơn hoặc đơn điệu hơn cần đo lại trước khi giữ ngưỡng 3.0.

Baseline và phát hiện mới

Baseline chỉ báo cái mới

Lần quét đầu ghi chín phát hiện vào baseline, mỗi phát hiện có dấu vân tay dạng tệp, rule, dòng. Script thêm tệp src/new.py chứa một URL proxy giả mới rồi quét lại. Lần hai có mười phát hiện, so với baseline chỉ còn một phát hiện mới: src/new.py dòng 1.

Gitleaks thật dùng dấu vân tay gồm commit, tệp, rule và dòng. Nếu ai đó sửa một dòng phía trên làm dòng chứa bí mật dịch xuống, dấu vân tay đổi và phát hiện cũ sẽ hiện lại như mới. Đây là điều cần biết khi dùng baseline lâu dài.

Gỡ cấu hình thử, quản lý bí mật và checklist khi Gitleaks kiểm tra lộ proxy credentials

Checklist Gitleaks proxy

Phát hiện chỉ có giá trị khi được xử lý. Phần này đi qua việc cần làm sau khi quét và cách đưa Gitleaks vào quy trình.

Xử lý từng loại phát hiện

Với bí mật trong mã và .env: đổi mật khẩu proxy ngay ở trang quản lý của nhà cung cấp, chuyển mã sang đọc từ biến môi trường, thêm .env vào .gitignore. Với danh sách proxy: chuyển tệp ra ngoài repo hoặc vào kho bí mật, giữ trong repo một tệp mẫu chỉ có chỗ trống.

Với log: sửa mã ghi log để che mật khẩu trước khi in, xóa log khỏi repo, thêm thư mục log vào .gitignore. Với tài liệu: thay bằng chỗ trống dạng ngoặc nhọn để rule không bắt nhầm về sau.

Đổi mật khẩu trước, dọn lịch sử sau

Đổi mật khẩu là bước bắt buộc ngay khi phát hiện, vì không biết ai đã clone repo. Dọn lịch sử Git bằng công cụ viết lại lịch sử là bước tùy chọn, chỉ cần khi repo công khai hoặc nhiều người truy cập. Với proxy trả phí, kiểm thêm lịch sử sử dụng băng thông để biết có ai dùng trộm không.

Nhiều nhà cung cấp cho đổi sang xác thực theo IP. Khi đó dù mật khẩu lộ, người ngoài không dùng được từ máy khác. Bài proxy trong GitHub Actions có cách đưa thông tin proxy vào CI qua secrets thay vì ghi trong tệp.

Che mật khẩu trong log từ gốc

Log là đường lộ khó chặn nhất vì nó sinh ra lúc chạy, không phải lúc viết mã. Thư viện HTTP ở mức gỡ lỗi có thể in nguyên URL proxy hoặc header Proxy-Authorization. Tắt mức gỡ lỗi khi chạy thật, và khi bật thì bật kèm bộ lọc che thông tin.

Trong Python, một bộ lọc logging thay mọi chuỗi dạng ://user:mật khẩu@ bằng ://user:***@ trước khi ghi là đủ cho phần lớn trường hợp. Áp bộ lọc ở handler gốc để mọi logger con đều đi qua. Sau đó chạy lại rule proxy-url-credentials trên tệp log mới để chắc không còn sót.

Chạy trước khi commit

Gitleaks có thể chạy như hook trước commit qua công cụ pre-commit. README hướng dẫn thêm hook với repo gitleaks và đặt biến SKIP khi cần bỏ qua một lần. Hook chặn commit có bí mật ngay trên máy lập trình viên, trước khi bí mật vào lịch sử.

Trên CI, chạy gitleaks git với --log-opts giới hạn trong các commit của nhánh đang xét, để nhanh và không báo lại lỗi cũ. Kết hợp với baseline cho repo cũ.

Quét định kỳ cả kho cũ

Hook trước commit chỉ bảo vệ từ nay về sau. Các repo cũ, repo đã lưu trữ và repo của dự án đã kết thúc vẫn có thể chứa proxy cũ. Một lượt quét định kỳ, ví dụ mỗi tháng, trên toàn bộ repo của nhóm bằng gitleaks git giúp phát hiện những bí mật nằm im lâu ngày.

Với mỗi phát hiện từ lượt quét này, kiểm proxy đó còn hoạt động không. Proxy đã hết hạn thì rủi ro thấp, chỉ cần ghi lại. Proxy còn chạy thì đổi mật khẩu như phát hiện mới. Danh sách proxy đang dùng từ trang quản lý của nhà cung cấp giúp đối chiếu nhanh.

Dấu gitleaks:allow và tệp .gitleaksignore

Khi một chuỗi cố tình là bí mật thử nghiệm, thêm chú thích gitleaks:allow ở cuối dòng. Khi muốn bỏ một phát hiện cụ thể, thêm dấu vân tay vào tệp .gitleaksignore. README ghi tính năng .gitleaksignore đang ở mức thử nghiệm.

Dùng hai cách này tiết kiệm. Mỗi lần thêm là một lỗ trong lưới. Ghi lý do bên cạnh để người sau hiểu vì sao được bỏ qua.

Định dạng báo cáo cho người xử lý

Báo cáo JSON hợp cho máy, nhưng người xử lý cần biết ba thứ: tệp nào, dòng nào, và việc phải làm. Gitleaks hỗ trợ báo cáo dạng CSV, JUnit, SARIF và mẫu tùy biến. SARIF hiện được trong giao diện quét mã của nhiều nền tảng Git, giúp lập trình viên thấy phát hiện ngay trong yêu cầu hợp nhất.

Với nhóm nhỏ, một bảng như bảng phân loại ở trên là đủ: cột phân loại cho biết lộ thật, lộ trong tài liệu hay lộ qua log, kèm việc tương ứng. Luôn dùng --redact để báo cáo không chứa bí mật, vì báo cáo cũng hay bị chia sẻ rộng.

Giới hạn suy luận của bài

ProxyVN không chạy được gitleaks.exe trong bài. Kết quả là của regex chạy bằng Python trên cùng cấu hình, đủ để kiểm logic rule nhưng không đủ để khẳng định Gitleaks cho kết quả y hệt. Cơ chế tính dấu vân tay, giải mã base64 tự động và quét lịch sử Git chưa được thử.

Repo lab nhỏ và viết có chủ đích. Repo thật có thể sinh báo nhầm khác, ví dụ URL có user:password trong dữ liệu kiểm thử của thư viện. Ngưỡng 3.0 cần chỉnh theo repo của anh em.

Checklist Gitleaks kiểm tra lộ proxy credentials

• Thêm ba rule proxy vào cấu hình, giữ useDefault bằng true.
• Chạy với Gitleaks thật trên repo mẫu, so kết quả với bảng trong bài.
• Quét cả thư mục log và tài liệu, không chỉ mã nguồn.
• Đổi mật khẩu proxy cho mọi phát hiện thật, kể cả phát hiện trong baseline.
• Thay ví dụ trong tài liệu bằng chỗ trống dạng ngoặc nhọn.
• Che mật khẩu trong log trước khi in.
• Bật hook trước commit và bước quét trên CI.
• Ghi lý do cho mỗi gitleaks:allow và mỗi dòng .gitleaksignore.

Sau khi đổi mật khẩu, nên chuyển sang proxy cho phép xác thực theo IP để giảm thiệt hại nếu lộ lần nữa. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5, cấp xác thực user và mật khẩu hoặc theo IP. Anh em có thể mua proxy tốc độ cao tại trang chủ ProxyVN rồi lưu thông tin trong kho bí mật thay vì trong repo.

Câu hỏi thường gặp về Gitleaks kiểm tra lộ proxy credentials

Có nên quét cả máy chủ chạy crawler?

Nên quét thư mục cấu hình và thư mục log trên máy chủ bằng gitleaks dir. Bí mật không chỉ lộ qua Git mà còn qua bản sao lưu, ảnh đĩa và tệp chia sẻ. Rule proxy dùng được cho mọi thư mục, không riêng repo.

Rule mặc định của Gitleaks có bắt proxy không?

Trong lab, generic-api-key và curl-auth-user không bắt dòng nào trong chín dòng có bí mật proxy. Cần rule riêng.

Có nên đặt ngưỡng độ hỗn loạn thấp hơn 3.0?

Thấp hơn sẽ bắt thêm mật khẩu ngắn nhưng báo nhầm nhiều hơn. Bắt đầu ở 3.0, xem báo cáo trên repo thật rồi chỉnh.

Gitleaks có gửi bí mật đi đâu không?

Gitleaks chạy cục bộ, đọc tệp và lịch sử Git trên máy. Dùng --redact để không in bí mật ra màn hình và báo cáo.

Quét tệp log lớn có chậm không?

Rule có từ khóa chạy nhanh vì bỏ dòng không chứa từ khóa. Rule ip:port:user:pass không có từ khóa nên chậm hơn trên tệp lớn. Có thể giới hạn rule này cho các đường dẫn tệp văn bản cấu hình.

Rule này có dùng được cho GitLab hay Bitbucket?

Được. Gitleaks quét repo Git trên máy, không phụ thuộc nơi lưu repo. Tệp cấu hình rule dùng chung cho mọi nền tảng.

Đã xóa tệp .env khỏi repo thì có cần lo?

Có, nếu tệp từng được commit. Quét bằng gitleaks git để kiểm lịch sử, và đổi mật khẩu nếu thấy.

Gitleaks kiểm tra lộ proxy credentials và những điều cần nhớ

Gitleaks kiểm tra lộ proxy credentials chỉ hiệu quả khi có rule riêng cho proxy. Lab cho thấy rule mặc định không bắt dòng nào, ba rule tự viết bắt đủ chín dòng, bỏ đúng hai mẫu và baseline chỉ báo một bí mật mới. Đổi mật khẩu cho mọi phát hiện, che log, bật hook trước commit. Cần proxy có xác thực theo IP để giảm rủi ro khi dùng Gitleaks kiểm tra lộ proxy credentials, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.